write_and_poll_value reports false success for discharge_start_time/discharge_end_time — entity never actually changed, underlying integration shows no write attempt

[Vict20]

Describe the bug
Verified writes are not actually happening

Expected behaviour
Predbat's log shows a clean, verified write at the scheduled export start:

2026-08-25 16:00:07.877: Inverter 0 set new export start time to 16:00:00
2026-08-25 16:00:09.924: Inverter 0 write_and_poll_value: Wrote 16:00:00 to discharge_start_time, successfully now 16:00:00
2026-08-25 16:00:09.924: Inverter 0 Set new export end time to 20:01:00 was 23:59:00
2026-08-25 16:00:11.971: Inverter 0 write_and_poll_value: Wrote 20:01:00 to discharge_end_time, successfully now 20:01:00

But checking time.growatt_battery_grid_first_time_period_9_start directly in Developer Tools → States (bypassing any dashboard caching) shows it still reads 00:00:00, not 16:00:00.

More tellingly, the underlying Growatt Modbus integration's own debug log has zero entries whatsoever for the corresponding registers (1086/1087, confirmed via prior register scan) anywhere in the log around this time — no write attempt logged, successful or failed, by the integration itself. For comparison, a separate write in the same run (idle_start_time → 20:01:00) is correctly reflected in its entity and presumably would show up in the integration's own logs too.

This suggests write_and_poll_value's "successfully now X" confirmation may not be doing a genuine fresh read of the entity — it's reporting success for a write that, as far as the target integration is concerned, never happened at all, rather than catching the discrepancy.

Separately (and I believe unrelated) — the same log window shows the underlying integration repeatedly rejecting direct writes to the Enable select entities (time_period_1_enable, time_period_3_enable, registers 1102/1108) with Illegal Function exceptions — but Predbat's apps.yaml config for this inverter doesn't reference those entities at all (charge/discharge are represented via zero-duration windows, not an enable toggle), so I don't think this is the cause of the above, just flagging it as background noise from separate manual testing earlier in the day.

Given the real financial/behavioral consequence of a silently-failed control write during a live export window, this felt worth reporting promptly.

Predbat version
8.53.1
xxxx

Environment details

Custom inverter type (GROWATTSPH), local Modbus via the Growatt Modbus TCP integration, discharge_start_time/discharge_end_time mapped to time.growatt_battery_grid_first_time_period_9_start/_end. Predbat v8.53.1, in Control charge & discharge mode. These control the inverter when entities are set manually

[gcoan]

please provide full logfile (not a snippet) and your debug.yaml to aid diagnosis

thanks

[springfall2008]

🤖 Automated first-pass triage — generated by a triage bot. A maintainer will review before any action is taken.

Classification: bug · Priority: priority_medium

Investigated against current main (v8.53.2-32-gf88eaaf1). You report 8.53.1; no log was attached, so I could not confirm the running version from a log header.

Two things in the write/verify path check out as real, and one of them reproduces your symptom exactly.

1. Your suspicion is correct — refresh=True is a no-op on a normal HA install

write_and_poll_value() re-reads with refresh=domain != "sensor" (apps/predbat/inverter.py:2171) and write_and_poll_option() with refresh=True (apps/predbat/inverter.py:2251). Both land in:

# apps/predbat/ha.py:798
if refresh and not self.ha_key:
    # Only refresh from DB/HA if we are not the primary data source
    self.update_state(entity_id)

When ha_key is set — the normal add-on case — that condition is false, so no fresh read happens and the comparison is made against the websocket state cache. (update_state() also returns early at ha.py:835 without ha_key, so the /api/states/<entity> REST read is unreachable from this path at all.) This came in with #2342. So "successfully now X" is indeed not a fresh read of the entity.

2. The likelier direct cause: which function logged that line

Your log line comes from write_and_poll_value. A time.* entity never reaches it — write_and_poll_option() routes input_select/select/time/input_datetime down its own branch (inverter.py:2216) and would have logged Inverter 0 Wrote discharge_start_time to 16:00:00 successfully instead. So whatever discharge_start_time resolves to in your apps.yaml is not in that set.

I probed the combinations against the test harness (temporary probe added on top of the inverter test module, reverted afterwards):

arg entity domain	path taken	service called	result
time.*	write_and_poll_option	time/set_value {'time': '16:00:00'}	True, correct
select.*	write_and_poll_option	select/select_option	True, correct
sensor.*	write_and_poll_option → write_and_poll_value	none	True — false success
time.* forced through write_and_poll_value	—	time/set_value {'value': ...} (wrong param name)	False, warns

The sensor.* row is your symptom. write_and_poll_value treats domain == "sensor" as "Predbat owns this entity" (inverter.py:2155-2156) and calls set_state_wrapper() instead of any service; that POSTs to /api/states/<entity> (ha.py:1071-1077), which overwrites the value in HA's state machine without invoking the owning integration at all, then reads that same value straight back as confirmation. No service call, no Modbus write, nothing for the Growatt integration to log — and the state reverts at the integration's next poll, which is what Developer Tools shows you now.

Note the last row: had a genuine time.* entity gone down the write_and_poll_value path you would have seen Warn: ... didn't complete, not a success, because time.set_value needs time= and not value=. Further evidence that the entity actually configured is not the time.* one.

3. Contributing gap

call_service_wrapper()'s return value is discarded at every write site in inverter.py (e.g. :2161, :2238, :2244). A service call HA rejects — including the Illegal Function rejections you saw on the enable selects — is invisible to the write/verify logic; it only surfaces separately as Warn: Service call .../... failed from ha.py:531.

What I need to tell these apart

The bug template's log and predbat_debug.yaml weren't attached. Please post:

• the control-entity section of your apps.yaml — specifically the exact discharge_start_time / discharge_end_time values, and whether they are the bare time.growatt_... entity ids or wrapped in anything (a template, a list, a sensor. mirror);
• predbat.log covering roughly 15:58–16:03, so I can check whether a Warn: Service call time/set_value ... failed line appears alongside your two write lines.

If discharge_start_time does point straight at time.growatt_battery_grid_first_time_period_9_start, then the line you quoted should not have been reachable on 8.53.1, and the raw log is needed to see what actually ran.

Possibly related: #4636 (control entities echoing Predbat's own writes, so read-back can't prove a write landed) — same family of problem, different trigger.

[Vict20]

predbat (1).log Logfile, Predbat was switched from read only to full control at 14:05 Today 25/8/26

predbat_debug.yaml.txt

[chalfontchubby]

Thanks - please do attach the debug files as requested when the issue is first filed - this one went through unsuccessful auto-triage before those files were provided. We can restart that process but it's easier if we don't have to

[Vict20]

Thanks - please do attach the debug files as requested when the issue is first filed - this one went through unsuccessful auto-triage before those files were provided. We can restart that process but it's easier if we don't have to

Apologies, and noted!

Thanks for the detailed triage — sorry for the delay pulling this together, wanted to actually resolve as much as I could before replying rather than report piecemeal.

Your analysis prompted me to check the actual config rather than assume it was right — and it wasn't.

You noted that a genuine time.* entity should route through write_and_poll_option, not write_and_poll_value, and suggested discharge_start_time might not actually resolve to the time.* entity I thought it did. On checking, you were right to be suspicious — my apps.yaml had accumulated real problems over several weeks of edits:

1. discharge_start_time/discharge_end_time were defined twice. An early Monitor-mode block (from before I had real control entities) still had:

`discharge_start_time:

• input_datetime.predbat_dummy_discharge_start
  discharge_end_time:
• input_datetime.predbat_dummy_discharge_end`
  (I see you have a fix open to prevent this)

...and much later in the same file, the real block:

`discharge_start_time:

• time.growatt_battery_grid_first_time_period_9_start
  discharge_end_time:
• time.growatt_battery_grid_first_time_period_9_end`

I'd never removed the first one when I added the second.

2.charge_start_time had a real indentation bug — accidentally nested one level too deep, inside the inverter: block rather than as its own top-level key.
3.There was also a duplicate inverter_type/inverter: block — an old GROWATTMON (monitor-only, all control disabled) definition sitting alongside the real GROWATTSPH one. (I see you have a fix open to prevent this)

I rebuilt the file from scratch, deduplicated everything, fixed the indentation, and confirmed Validation of apps.yaml was successful in the log.

With the clean config, a related but separate problem surfaced: Cannot find battery discharge curve (settings missing) — I'd deliberately never configured discharge_rate at all (I want discharge to always run at full rate, not be throttled, so I'd omitted it rather than build a bridge for it). Turns out Predbat needs some value there regardless. I added a dedicated input_number helper (isolated from the real inverter entity, so Predbat "controlling" it has zero real-world effect) and pointed discharge_rate at that.

This gave me a clean confirmation the write/verify mechanism genuinely works when the entity domain is right:

Inverter 0 write_and_poll_value: Wrote 3000 to discharge_rate, successfully now 3000.0

with a real input_number/set_value service call in the log — exactly matching the sensor./input_number. path your trace described, working as expected.

But discharge_start_time, now genuinely and confirmed pointed at the real time.* entity, still shows the original symptom: write_and_poll_value logs "successfully now 16:00:00" (wrong function for a time.* entity per your own trace), while time.growatt_battery_grid_first_time_period_9_start in Developer Tools never actually changes from 00:00:00.

Where I'd honestly leave this: given the config is now genuinely clean and the symptom persists, this looks like it could be a real bug in the time.* routing logic after all — but I've since found something on the Growatt Modbus integration side that complicates the picture (raised separately there): a raw register scan shows this exact entity's registers holding byte-identical values to an unrelated slot's registers, a real hardware/integration-level issue independent of Predbat.

Given that other writes on this same inverter (discharge_rate, idle_start_time) are landing and reading back correctly through the same write/verify mechanism, I actually suspect Predbat's write to discharge_start_time is genuinely reaching the register correctly, and the register-mirroring issue on the Growatt side is what's actually causing the entity to display the wrong value afterward — rather than Predbat's write failing outright. But I can't fully confirm that split until the Growatt-side issue is resolved and I can re-test cleanly.

Happy to provide the full apps.yaml, predbat_debug.yaml, or re-test cleanly once the Growatt-side issue is resolved — wanted to get the complete, honest picture to you now rather than wait.

[chalfontchubby]

Hopefully the pr I link above #4745 resolves that.

[Vict20]

I'm the original reporter here. Really appreciate the fast root-cause and fix — the diagnosis in #4745 matches exactly what I was seeing:

My discharge_start_time pointed at a real time.growatt_battery_grid_first_time_period_9_start entity, and Predbat's "successfully wrote" log line was genuine, just aimed at a self-generated placeholder sensor rather than my actual hardware.

I've had Predbat parked in Read Only mode since raising this, specifically to avoid any live control based on writes that weren't reaching the inverter. Keen to get this verified — happy to pull the fix branch and test against my real GROWATTSPH setup as soon as it's mergeable, and report back here with confirmation either way.

Is there anything useful I can provide in the meantime to help this along?