v4.2.4: editable number entities can hold a value above their own max (bounds taken from SOC-dependent BMS limits), incl. TOU slot currents

[petervanderwaal1982]

After updating to v4.2.4 (which includes #462, "Resolve editable entity bounds by authoritative limits") several editable number entities on my system now hold a value above their own max, and the TOU slot currents inherit a bound that I don't think they should.

System: S6-EH3P10K-H + Dyness HV (2× Tower T10), Modbus TCP via the datalogger, v4.2.4.

entity	state	min	max
battery_max_charge_current	50.0 A	0	44.4
battery_max_discharge_current	50.0 A	0	18.4
grid_time_of_use_discharge_battery_current_slot_1	50.0 A	0	18.4

Why the bound moves. On this pack the BMS derates hard by state of charge. Measured over 10 days of recorder history (max observed battery power per SOC%, ~30k samples):

• discharge: 0–29% SOC → ~5.2 kW, 30–100% → ~10 kW
• charge: 0–69% → ~10 kW, 70–90% → ~5.6 kW, 91–100% → ~3.4 kW

At ~291 V that 5.2 kW is ≈18 A, which is exactly the 18.4 A now showing as max — the battery was at 12% SOC when I took the table above. Earlier the same day, at high SOC, the pack sustained 9.9 kW ≈ 34 A. So the bound isn't a fixed capability, it tracks SOC and moves through the day.

Two things that seem unintended:

1. state (50.0) sits above max (18.4). A number entity outside its own range is not really a valid state, and in practice the value becomes one-way: lower it once and the UI won't let you put it back, because the box is clamped to whatever the BMS happens to allow at that moment.
2. The TOU slot currents are scheduled configuration — you set up tonight's discharge slot while the battery may be empty this morning. Bounding that by the instantaneous limit means the allowed range depends on when you happen to open the page.

Suggestion. Would it make sense to keep the configuration bound at the register's own range, and surface the BMS runtime limit separately — as a sensor or an entity attribute — rather than as the number's max? That keeps "what I may configure" and "what the battery can do right now" as two different things, which is what they are. If clamping is desirable, doing it on write (with a log warning) would avoid the out-of-range state.

I appreciate the intent — stopping people from configuring a current the pack can't deliver is a real problem worth solving, and the derating data above suggests it's a bigger effect than most would guess. Just flagging that the current form has these side effects.

Not blocking for me: I drive the battery through solis_dispatch in watts and never write these registers, so I'm reporting this rather than asking for a fix. Happy to test a patch on HV hardware if useful.

[Valiante]

Seeing a related but distinct symptom on 4.2.4, worth adding as a data point, since this matches your SOC-derating diagnosis exactly but manifests as an outright write rejection rather than a silently-stuck state.

I have a Home Assistant automation cycling number.solis_modbus_time_charging_charge_current (a TOU-type entity, same category as the slot currents you mention) between three values based on EV charger load, so this hits your point 2 directly: it's scheduled configuration, written whenever the load crosses a threshold, not tied to when I "happen to open the page."

Symptom: writes to the higher value (60) intermittently fail with a raised out_of_range exception, rather than clamping or silently sticking. The entity's own reported bounds look normal (0-65) when I check manually after the fact. Retrying immediately (2-3 attempts, seconds apart) fails identically every time; it only clears after several minutes, consistent with your point about the bound tracking something that moves on its own timescale (SOC/BMS-derived) rather than being an instant fix.

Your suggestion of keeping the configuration bound at the register's own static range, and surfacing the BMS runtime limit separately, would resolve this cleanly on my end too. Happy to share HA automation traces/logs if useful.