charge_limit writes occasionally land one cycle late — no verification/retry (Sunsynk/SK driver via Solar Assistant)

[nicoverlinde]

Setup:

Predbat v8.54.1
Inverter: Deye SUN-12K-SG05LP3-EU + Deye SE-F16-C battery (16 kWh)
Connected via Solar Assistant (Raspberry Pi 5, RS485/Modbus to inverter, MQTT to Home Assistant)
inverter_type: "SK" (Sunsynk driver), one dedicated program point (select.inverters_1_program_point_2) reserved for Predbat, other points parked

Issue:
charge_limit writes (backed by number.inverters_1_capacity_point_2) intermittently fail to apply within the same planning cycle. The readback consistently matches the previous cycle's target, not the current one — across six consecutive occurrences, over irregular intervals (3 to 25 minutes apart), the pattern never broke:

100 → readback 15
15 → readback 100
47 → readback 15
15 → readback 47
44 → readback 15
100 → readback 44

Predbat logs the write as sent, then on the next cycle skips re-sending because it believes the previous call already succeeded:

Inverter 0 Skipped service charge_start_service domain charge service_name select/select_option as it was previously called.

Real-world impact: this isn't only cosmetic. On one occasion, predbat.status showed "Charging" while select.inverters_1_program_point_2 on the inverter was still "General" (verified both in HA and on the physical Deye display) — Predbat believed it was charging while the inverter was doing nothing. sensor.totals_battery_power stayed flat/slightly negative for several minutes until I manually re-sent the same select.select_option call via Developer Tools, which landed instantly and battery power jumped from ~-30W to +850W within seconds.

What I've ruled out:

Not a config issue: manual select.select_option / number.set_value calls to the same entities always land immediately and correctly — the write path itself works.
Not a stale MQTT setting-changes gate: Solar Assistant's "Allow setting changes" toggle was confirmed Enabled (and the broker restarted to apply it) — the pattern persisted identically afterward.
Not simple fixed-interval Modbus lag: intervals between occurrences vary (3–25 min) with no fixed relationship, but the "one cycle behind" relationship between attempted value and readback is 100% consistent across every occurrence observed so far.

Question / suggestion: would it be feasible for Predbat to verify a select/number write actually took effect (e.g. re-reading the entity state after a short delay) before marking it complete or skipping a repeat write on the next cycle, rather than trusting the service-call log alone? I noticed recent release notes mention a feature for detecting external changes fighting Predbat (#4638) — not sure if that's related to what I'm seeing here, or if this is a separate write-confirmation gap. Happy to share more log excerpts if useful.

[gcoan]

Question / suggestion: would it be feasible for Predbat to verify a select/number write actually took effect (e.g. re-reading the entity state after a short delay) before marking it complete or skipping a repeat write on the next cycle, rather than trusting the service-call log alone? I noticed recent release notes mention a feature for detecting external changes fighting Predbat (#4638) — not sure if that's related to what I'm seeing here, or if this is a separate write-confirmation gap. Happy to share more log excerpts if useful.

there have/are changes being made by @chalfontchubby to the write/read cycle to do as you suggest. Rik can comment on where these are in the pipeline, but from what I understand I think it could be what you are looking for

[chalfontchubby]

A lot of write to inverters are checked on the write - bad writes are not that uncommon. I'm not familiar with Solar Assistant, but some of the integrations we interact with cache values anyway - even if predbat does read back to check, the value didn't get pushed to the inverter yet. If communication with the inverter is asynchronous - and cached, it's quite hard for predbat to tell whether a value read back is really in the inverter.

I've not really looked at this area much, but to answer your questions I'd want to look at the logs from predbat and the intergration (Solar Assistant?) - easiest if you create an issue supplying the information requested in the issue template.

[chalfontchubby]

#4845 might be relevant

[nicoverlinde]

Thanks for the pointers — #4845 lines up very closely with what I'm seeing, especially the "notification fires even though the write wasn't verified" mechanism. I've opened a formal bug report with logs at #4876, referencing both this discussion and #4845.