Repository navigation
docs(debug-journal): fold in the 2026-10-06 queue slice (5 candidates); correct the Sunsynk control-cache bounds (PR #5360) and the IOG car-need-gate reading (PR #5403) - #5426
Merged
Conversation
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
The journal drops a still-relevant PR #5396 diagnostic and contains several inaccurate or malformed updates.
5 open findings
What changed in this PR
Updates the debug journal with five triage findings and corrects prior Sunsynk/DEYE and Octopus guidance.
Changes:
- Adds findings for issues #5417, #5419, #5420, #5421, and #5424.
- Updates guidance following PRs #5360 and #5403.
- Adds
githubusercontentto the spelling dictionary.
| File | Description |
|---|---|
tools/debug-journal.md |
Updates troubleshooting and triage guidance. |
.cspell/custom-dictionary-workspace.txt |
Adds a required spelling term. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| @@ -113,13 +113,13 @@ Grep for the named symbol rather than trusting a line number. | |||
| | HA write/verify (`ha.py`, `inverter.py`) | `get_state(refresh=True)` is a no-op in a normal HA add-on install: it only re-reads when `not self.ha_key`, and `ha_key` is set in that case, so verification reads the websocket cache, never a fresh value (`ha.py:798`, since PR #2342). Separately, `write_and_poll_value()` treats `domain == "sensor"` as Predbat-owned and POSTs `/api/states/<entity>` directly (`inverter.py:2155`, `ha.py:1071-1077`) instead of calling the integration. Probed empirically across all four write-path/domain combinations (GH#4738): a control entity that resolves to a `sensor.*` domain by mistake gets a direct state overwrite that reads back as success, with zero corresponding lines in the real integration's log. `call_service_wrapper()`'s return value used to be discarded at every `inverter.py` write site, so a rejected HA service call (e.g. a Modbus "Illegal Function" error) never reached the verify logic. That is no longer true everywhere: PR #4878 made `call_service_template()` check it (`inverter.py:2817`) and log "was not accepted, it will be retried next cycle". The other eleven `call_service_wrapper()` call sites in that file still discard it, so check the specific write path before repeating the general claim. Later triage extended this row rather than replacing it. `write_and_poll_switch()` builds its service name as `domain + "/turn_..."` straight from the entity's own domain with no validation (`inverter.py:2102`), and `adjust_inverter_mode()` routes every `has_ge_eco_toggle` inverter through it - so an `inverter_mode` pointed at a `select.*` entity produces `select.turn_on`, an HA-invalid service retried 10x at 10s per attempt, and the string coercion just below (`inverter.py:2110-2111`) maps any select state to False, so the force-export direction reports success having written nothing (GH#4909, still live — though on 3-phase GEC the real problem is one stage deeper: no eco register exists at all, and the write path is skipped with `No entity_id for ECO Toggle`; see the GE Cloud row). `adjust_force_export`/`adjust_charge_window` format their times at plan precision with no snapping (`TIME_FORMAT_HMS`, `inverter.py:2608`/`:2615`), so against an integration whose select only offers 15-minute options (Solar Assistant/Deye) Predbat writes e.g. `20:55` and `write_and_poll_option` retries the impossible value 10x every cycle; nothing anywhere reads a select's `options` attribute, and `charge_time_entity_is_option` only decides *how* an entity is written, never which values are legal. The fix precedent is already in tree - AlphaESS's `snap_time_grid()` (`alphaess_const.py:215`), snap start forward and end backward with a collapse check (GH#4947). A second, independent way plan-precision times fail on the same select path: `write_and_poll_option()` only strips the seconds from an 8-char `HH:MM:SS` write when the *previous* state is a healthy 5-char `HH:MM:SS` read — the read feeding it returns `None` for an entity missing from the state cache (`ha.py:817`) or the literal `"unknown"`/`"unavailable"` when degraded (`ha.py:815`), either skips the strip and the raw `HH:MM:SS` goes to `select_option`, which HA rejects; all 10 retries re-read and fail identically, and the log reads `didn't complete got unknown` (GH#5009, probe-verified on main). That degraded-read shape can also be **permanent**: an SA slot select can report `unknown` for days — every write read-back `unknown`, zero verified writes, across an SA rebuild and both native-API and MQTT transports — so both symptoms (read path `unable to read Export window - ... returned no data` every cycle via `time_string_to_stamp("unknown")` → `None`, and the write path above) fire continuously; state reporting varies by SA backend (GH#5214). **A user edit of `config.py`'s INVERTER_DEF `charge_time_format` to anything ≠ exactly `"HH:MM:SS"` is a masking workaround, not a fix (GH#5214):** the `!= "HH:MM:SS"` branch (`inverter.py`) swaps apps.yaml entities for Predbat's own `sensor.predbat_{type}_{id}_*` dummies — reads parse Predbat's own echo and writes become direct `set_state` POSTs that never reach the inverter — so the log goes quiet while SA window control is silently severed. Tells, all observed in #5214's attachments: a `Creating dummy entity sensor.predbat_{TYPE}_{id}_charge_start_time` line in the log (`create_entity()` only logs when the entity is missing from HA state, so its presence proves the ≠ branch ran); the debug yaml's live `args` naming dummy ids while `args_from_apps_yaml` still lists the real `select.*` entities; and warnings stopping after a user restart then resuming after an addon update (which overwrites the edited `config.py`, wiping it). Also: pre-#3533 SA shipped `charge_time_format: "S"` (dummy time entities, no SA select wiring), so "SA time warnings started after updating" can mean the user crossed the #3533 template wiring rather than a format regression. The fix that serves both is reading the select's `options` attribute — nothing in the codebase does today. Six of the eight `adjust_*` writers discard the write helper's boolean and fire `call_notify()`/`mqtt_message()` regardless, and `rest_setReserve()` has the same gap (GH#4845). `call_service_template()` used to record its dedup hash *before* the call, so a silently failed `select_option` was skipped as "previously called" on every later cycle; fixed (it now records only on success and drops the record on failure), though it still deliberately returns True so callers cannot downgrade a freeze into a stop (GH#4876). From that same report, a false-alarm class worth recognising: a `didn't complete got X` where X is exactly the *previous* cycle's target, on an integration that republishes its entities slowly, is the verify window reading HA's cache - the write had already landed by the next cycle. That window is arithmetic, not a constant: up to `INVERTER_MAX_RETRY` (10) writes, each polled through one `inv_write_and_poll_sleep` budget with a doubling read interval - **~40s on GS, ~100s on GE/GEC/GEE** (`write_and_poll_sleep` is 10 for those types, 4 for GS). **Per-type since PR #5297 (merged 2026-09-29):** `INVERTER_DEF[type]["write_max_retry"]`/`["write_backoff"]` (consumed by `_write_attempts()`/`_write_backoff_result()`), and currently only `GWMQTT` deviates - 3 attempts, 10s apart - plus a per-control degraded state for those types: a write of the *same* target failing `INVERTER_WRITE_BACKOFF_FAILURES` (2) times in a row drops to one attempt per `INVERTER_WRITE_DEGRADED_INTERVAL` (300s) until a write verifies, the read-back matches or a different target arrives (full ladder restored at once); a degraded control still reads back, logs and records the failure every call - nothing is skipped silently. Every other type keeps 10 attempts and its existing sleep. A settling bounce that outlasts it is a second false-alarm shape (GH#5130): a HA `number.*` entity can step through intermediates (0 → a float → the settled int) for tens of seconds after a timed-slot write (~44s observed on solax_modbus), so a `didn't complete got <float>` whose value sits *between* the old and target values is a settling read-back, not a failed write - it self-heals next cycle when the initial read matches. The bounce reads feed only `value_matched()` (keep polling vs rewrite) and only the final read reaches the control ledger (`record_write` on match, `clear` on failure), so the worst case is a redundant same-value rewrite plus the false warning; the in-repo precedent for re-reading after settling is Solis Cloud's `verify_settle_seconds` re-read. And the discharge-stop fallback (GH#5094, still live): `adjust_charge_immediate()` issues a "stop discharge" service step before the charge/freeze step, and when `discharge_stop_service` is not configured it falls back to `charge_stop_service` with `domain="discharge"` - a documented fallback dating to #1614. On Tesla service-hook setups `charge_stop_service` maps to `self_consumption` + backup reserve 0, which on a Powerwall is **active discharge to load** (the EV charger counts as load), not a stop - so every freeze/hold cycle Predbat sends "discharge normally" and then re-commands "hold" ~2s later, and Tesla occasionally applies the first and drops the second, so the battery discharges into the car until the next 5-minute cycle. Verified from the reporter's log: the exact pair fires from the carHolding branch ("Disabling battery discharge whilst car 0 is charging" → `adjust_charge_immediate(soc_percent, freeze=True)`); the reporter had commented out `discharge_stop_service` (and `discharge_start_service`) when disabling export control, which is what exposed the fallback. Workaround: define `discharge_stop_service` in apps.yaml with commands that actually stop discharge (for a no-export setup, the same commands as `charge_freeze_service`). Caveat on the reporter's own `repeat: False` idea: enabling the service dedup means accepted calls are not re-sent (see the GH#4876 entry above - HA accepts the call but Tesla firmware can still drop it), so dropped freeze commands would never be retried. Both this and the fixed export clobber below stem from the same property of the Tesla template set: `charge_stop_service` and the freeze/discharge templates all write the same `operation_mode` select, and the templates mean opposite things on this hardware. **A sibling of the same family, over the reserve register rather than the mode selects (GH#5300, triaged 2026-09-29 against d951201e, reporter on a hand-built apps.yaml):** inside one 5-minute pass the hook charge (`adjust_charge_immediate()` issues `charge_freeze_service`/`charge_start_service` via `call_service_template`, inverter.py) and `execute.py`'s reserve reset (`if self.set_reserve_enable and resetReserve: inverter.adjust_reserve(0)`) both touch the Powerwall's reserve and the reset has **no isCharging guard** - `resetReserve` initialises True whenever `set_charge_window or set_export_window` and is cleared only by the freeze / hold-charging / car / iBoost hold branches - while `adjust_reserve()` floors at `reserve_percent` and writes through `write_and_poll_value()`, so the reset always ends up holding the register, against hook writes that are fire-and-forget. A service hook that uses the reserve register as its charge signal loses that race on every charge-window cycle. The shipped template is immune by two mechanisms, both worth checking before triaging any "Tesla reserve overwritten" report: `templates/tesla_powerwall.yaml` sets `has_reserve_soc: False` in the `inverter:` block (`fetch_inverter_data()` then force-disables `set_reserve_enable`/`set_reserve_hold`, logging `Note: Inverter does not support reserve - disabling reserve functions`), and with no `reserve:` arg wired Predbat dummies the arg (`create_missing_arg`/`create_entity`, inverter.py) so `adjust_reserve` writes land on a Predbat placeholder - the Sigenergy dummy-arg shape again. Discriminator for real-vs-dummy reserve wiring: the `Inverter N Current Reserve is X% ... and new target is Y%` and `Wrote X to reserve, successfully now Y` lines name the register, not the entity - a non-zero current read means the `reserve:` arg resolves to a real wired entity; a dummy reads 0 and at an equal target prints `already at target` instead. Dump-config tells from the same report: a `set_reserve_enable` switch showing `value: null` in a debug dump can still resolve True (expert-mode-switched item, hidden and entity not created while expert mode is off), and unknown keys in the dump's `args:` mean a hand-built config - do not assume the shipped template. | `inverter` | | |||
| | GE Cloud (`gecloud.py`) | Gateway fields can come back null. `merge_non_null` stops nulls overwriting good values, and the publish path guards null containers — GH#4656 was a null crash in that area. `number_event` clamps an out-of-range write silently and does not report the clamped value back, while `write_and_poll_value()` keeps comparing against the original pre-clamp target - a permanent false `had_errors` and an unbounded retry (GH#4826). PR #4828 clamped inside `adjust_reserve()` only; the shared write helper still has no min/max awareness and the other `inverter.py` write sites still pass unclamped targets (GH#4831). The error-code path has since been reworked (`9560c61a`, `d6e5998c`) after GH#4896 showed `success: false` nulled `data` before the code branch could read it, so codes GivEnergy documents as never succeeding on a repeat (-3/-4/-7) were retried the full budget and `message` was never surfaced. Separately, **fixed in PR #4954 (merged 2026-09-06)** - keep the mechanism for anyone holding an older log: for `GE`/`GEC`/`GEE` the max battery rate was taken solely from the `charge_rate` entity's `max` attribute, and the `elif "battery_rate_max"` branch below it was unreachable for those types. Percentage-rated models (the 3-phase units) have no absolute charge power register, so `ge_cloud_automatic` left `charge_rate` unset and the attribute read returned the 2600 W default; both the correct rate GECloud writes into `battery_rate_max` and the user's own apps.yaml value went unread, and every rate was clamped to 2600 W. On those models it also corrupted the writes, since the percentage registers are set as `new_rate / battery_rate_max_raw * 100` against a denominator 3.8x too small. The fix falls back to `battery_rate_max` only when `charge_rate` resolves to nothing (GH#4908). GH#4198 is the same code shape on SolaX and is not covered by that fix. A model-string parser gap sits above that path (GH#5136): **the integer-rating half was fixed in PR #5293 (merged 2026-09-30, v9.3.3)** — `get_max_inverter_rate_from_model()` now parses an integer segment straight after the `3HY` token (`GIV-3HY-11` → 11 kW) *before* the decimal pass, so a later decimal segment cannot hide it; it also guards a null model, strips trailing punctuation (`GIV-HY-8.0-G3-HV.`) and warns readably on an unparseable rating ("using max charge rate instead - set inverter_limit in apps.yaml"); keep the pre-#5293 signature (decimal-only match, so an integer-rated `GIV-3HY-11` fell back to `max_charge_rate` — which the GE Cloud API can change independently, 11000 → 9984 W observed). **Still live:** `publish_info()` reads only `max_charge_rate`, never the `max_discharge_rate` in the same payload, and `battery_rate_max` is bound to the `_max_charge_rate` entity — a model whose discharge rating differs keeps the wrong rate. Distinct from GH#4908 (the absent-`charge_rate` 2600 W default). Start on any "GEC inverter rate is wrong" report by checking the model string for a decimal point; the tests now cover the integer-3HY cases too. `automatic_config()` binds `inverter_limit` to the resulting `_max_inverter_rate` sensors and `prediction.py` clips PV against `inverter_limit`, so the error reaches the plan. **Mixed fleets: the rate read/write gates test key existence, not per-slot state (GH#5359, probe-verified on main b161949d via `tools/triage_test.sh`):** `get_current_charge_rate()`/`get_current_discharge_rate()` (`inverter.py`, the `"charge_rate_percent" in self.base.args` branch) and `adjust_charge_rate()`/`adjust_discharge_rate()` (which write **both** keys, each gated only on key existence) interrogate whether the key exists **anywhere in the fleet's args**, not whether *this* inverter's slot is set — and `get_arg()` on a `None` slot applies the caller's default quietly (`userinterface.py`, float branch) — so in a fleet mixing GEC percent-controlled units (3-phase `GIV-3HY` has no `battery_charge_power` watts register; `automatic_config()` then sets `charge_rate_percent` and `build_entities()` leaves per-device `None` slots, deleting `charge_rate` when no device has the register) with watts-controlled units, a percent slot that is `None` reads quietly as 100% → `battery_rate_max_raw`, and every rate write for the power-mode sibling lands on a missing entity (`Warn: ... No entity_id for charge_rate to write ...` + `record_status(had_errors=True)`, so "Read-Only with Errors" too). The low-power rate search, which steps down relative to the read-back, then restarts from the maximum every cycle and never converges — #3311's fault extended to mixed fleets (the single-inverter shape is in the low-power symptom row). PR #4645 (open, for #3311) creates its per-slot rate dummies but does not touch these four gates — the #4908 battery-sizing read (`get_arg("charge_rate", indirect=False, index=self.id)` before falling back, inverter.py:583) is the per-entry pattern the gates lack. One API-shape trap on the site endpoint (`GE_API_SITE`, `site/{uuid}`, added for PR #4978): the published OpenAPI spec types `limits.import`/`limits.export` as a string with a null example and never shows a populated one, so the shape had to be learned from live accounts. A populated limit is `{'enabled': bool, 'power': {'watts': int, 'amps': float}}`, and **`enabled` is the thing that matters** - a site describes its connection's declared capacity in exactly the same structure as a curtailment, marked disabled, so `power.watts` alone tells you nothing about whether anything is being restricted. Site 64744 gave `{'import': {'enabled': False, 'power': {'watts': 46000, 'amps': 200}}, 'export': {'enabled': True, 'power': {'watts': 4500, 'amps': 19.6}}}` - a 200A supply whose export really is curtailed to 4.5kW - while site 46714's disabled 6kW export is its declared capacity and no restriction at all. A fleet survey confirmed the flag across accounts, so only an enabled limit is applied; an enabled zero is a real zero-export connection. A site with no limit reports a null import/export. For a fleet survey use `GET /v1/site`, the list endpoint, which returns every site's `limits` and the inverters under it (with `info.max_discharge_rate`) in one response - no second call per site. Two GEC triage tools and one clobber trap (GH#5017). The component publishes an entity for every `/settings` entry with no name filter (`async_get_inverter_settings()`/`publish_registers()`, `regname_to_ha()` is plain lowercasing), so **absence of an entity in the reporter's debug yaml is proof the API never listed the register** — "the app can control it" does not imply the settings API exposes it, because the app/GivTCP write via local control paths rather than the `/settings` list (a GIV-3HY-20 had slot 1/2 lower-SoC registers absent while 3..10 existed). Caveat: the settings list is fetched once per process start (`register_list` cache) and only the parsed flags are logged, so the debug yaml is the only observable. To capture the raw register list, `python3 apps/predbat/gecloud.py --api-key <key> --write-entity number.probe_nothing 0` makes `test_gecloud_direct()` print the full "Available entities/registers" list with raw cloud names and setting IDs and performs no write — but the harness's startup pass also runs `enable_default_options()` against the real inverter (floors reset, unused windows zeroed), so say so when asking a user to run it. Clobber trap: the missing-feature branch `set_arg("discharge_target_soc", None)` *deletes* the key, including an explicit apps.yaml entry the user wrote; `set_arg_auto(..., overwrite=False)` (component_base.py) is the in-repo pattern for letting an explicit value win — check the `has_*` detection branch on any "automatic config deleted my setting" report. The `inverter_mode` half of this class was fixed in PR #5059 (`885c637d`) — it now binds via `set_arg_auto(..., overwrite=False)` like `export_limit` — but the other missing-feature deletes are still plain `set_arg(..., None)` on main: `pause_mode`, `pause_start_time`, `pause_end_time`, `discharge_target_soc`, `charge_rate_percent`, `discharge_rate_percent`, `givtcp_rest`. A companion test-fidelity trap (GH#5056, verified on main): the component test mocks (`MockBase.set_arg` in `test_ge_cloud.py`; same shape in `test_ohme.py` and `test_alphaess_api.py`, whose mock `set_arg_auto` also writes unconditionally) store the value instead of mirroring the real `set_arg()`'s None-deletes, and their `args_from_apps_yaml` is empty so `set_arg_auto()` falls through to the plain path — so the "feature not detected" assertions (`config_args.get(...) is None`) pass identically whether the code stored None or deleted the key, and a green suite cannot distinguish fixed from unfixed. Any test for this class must populate `args_from_apps_yaml` and assert the manual value survives — #5059's Test 10 in `test_ge_cloud.py` is now the in-repo precedent. And the deeper half of GH#4909 (still live): the 3-phase GEC class exposes **no** eco/demand/mode register in `inverter/{sn}/settings` — verified by enumerating the `predbat_gecloud_*` entities in the reporter's debug dump — yet the `GEC` def sets `has_ge_eco_toggle: True` unconditionally (`config.py`) and auto-config maps `inverter_mode` via `build_entities("switch", ["enable_eco_mode"])` (gecloud.py), which emits nothing when the register is missing, so `adjust_inverter_mode()` logs `No entity_id for ECO Toggle` and returns without writing every plan cycle and freeze export silently no-ops (force-discharge paths work fine). Fix wrinkle for the maintainer: the flag is one per-inverter-type bool while `build_entities` works per-device. The freeze-export half of the same class (GH#5082, follow-up to GH#4909, code-verified on main): `inv_has_timed_pause` is probed at runtime (inverter.py flips it False when the `pause_mode` entity is absent/unavailable) but `inv_support_discharge_freeze` is read only from the static `INVERTER_DEF` entry (`config.py` sets it True for GEC), so `execute.py` never force-disables `set_export_freeze` for the eco-less/pause-less 3-phase class and a freeze-export plan can never be executed. Check both flags on any "freeze silently didn't work on GEC" report - and do not grep only for `No entity_id for ECO Toggle`: that warning comes from the eco branch, while freeze export on this class fails primarily through the pause/rate branch, so the eco warning being absent says nothing about the freeze path. Fix direction: mirror the `inv_has_timed_pause` presence-probe; the manual-freeze-export override path already degrades correctly when `set_export_freeze` is False (plan.py drops to demand). Hardware-reported on the GIV-3HY class: `charge_power_rate` limits AC (grid) charging only - `battery_power` stays at the full discharge figure while the charge register reads 1% - so the `adjust_charge_rate(0)` fallback in the freeze branch is a no-op for PV charging there; note `charge_discharge_with_rate` is False for GEC, so the first `adjust_charge_rate(0)` in each branch is skipped and the write only happens via the `has_timed_pause`-else fallback. Fix precedent for building a freeze from registers the device actually has: `inv_support_feedin_first` + Fox Cloud freeze export (PR #5038); the GIV-3HY exposes `enable_force_discharge` + `discharge_down_to_percent` + `battery_reserve_percent`, the raw material for the #4909/#5082 option-2 freeze. And since #5056 a manual `inverter_mode` apps.yaml override is silently deleted by automatic config, so "just map the eco toggle manually" is not currently viable either. The neighbouring **charge-side** gap (GH#5040: `scheduled_charge_enable` had no `enable_force_charge` candidate, so a 3-phase GEC that gates timed grid charge behind both charge switches logged real charge states while importing nothing) is **fixed in PR #5042** (`a7121135`, v9.0.2): auto-config now binds `scheduled_charge_enable` to `enable_force_charge` with `ac_charge_enable`/`enable_ac_charge` as fallbacks, and `enable_default_options()` holds `enable_ac_charge` on as a static enable when the force register exists. Keep the mechanism for pre-v9.0.2 logs, where the signature is a 3-phase GEC showing plan charge states against flat grid power with no warning anywhere. The #5042 gate itself had a second gap (**GH#5269, fixed in PR #5270, merged 2026-09-27** — keep the pre-#5270 signature): `enable_ac_charge` was written in exactly one place, `enable_default_options()` — first cycle after start-up, then once per 24h (`default_options_stamp`) — while Predbat's own `scheduled_charge_enable` write (`switch_event()`) checked nothing about the gate, so any external writer (an Axle VPP clean-up, the GE app, another integration) could clear `enable_ac_charge` and Predbat re-asserted it only on that 24h pass or a restart; "restarted and it worked" is part of the pre-fix signature, as is `enable_force_charge` on with `Charging target …%` for hours, SoC flat and no error. #5270 re-asserts the gate from `switch_event()` when a force-charge write succeeds (`ensure_ac_charge_gate`, with Axle's clean-up read as read-only for the 24h pass and a binding guard), so the "gate cleared between cache refreshes" residual window is the remaining maintainer call on that fix. So "3-phase GEC plans a charge, status says Charging, battery imports nothing" now has **two** signatures: pre-v9.0.2 = never bound (#5040), v9.0.2+ pre-#5270 = externally cleared and not re-asserted (#5269); on a post-#5270 system check whether the force switch Predbat drove is actually the `enable_force_charge` register. GE Cloud EMS plants (GH#5103, **fixed in PR #5109, merged 2026-09-24** — keep the mechanism for pre-#5109 logs): with an EMS discovered `polling_mode` is set False (`gecloud.py`), and the settings refresh used to re-read each battery inverter's `/settings` only on the first tick of the process — so the AC3 registers, including the DC-discharge slot windows, were read once and published stale for the rest of the run, while live status/meter polling kept looking normal. #5109 re-reads settings hourly (`SETTINGS_SLOW_REFRESH_SECONDS`, `gecloud.py`), refreshes the EMS and gateway devices every cycle, and runs `check_ems_inverter_slots()` on every snapshot — which now *warns* when a battery inverter's slot 1 is not the full-day window (the #3781 rule: `Inverter X slot 1 is not 00:00-23:59 ... it will override the EMS and can stop charging or discharging early`), once per episode — recorded in `ems_slot_warned` so a standing misconfiguration does not inflate the error counter on every refresh, so the non-00:00–23:59 slot 1 fault is a visible warning on current main and silent only pre-#5109 (pre-fix signature: plan/status look right but the batteries hold 0 W past a fixed wall-clock time every night). Under EMS auto-config Predbat still writes mode/schedule-enable/rates to the AC3s. Nuance: the startup read itself can still be skipped when the storage settings cache is under 10 minutes old (`settings_from_cache`), so even a restart is not guaranteed to re-snapshot the registers. **The option-validation parser used to crash-loop the whole component (GH#5217, fixed in PR #5218, merged 2026-09-26 — keep the signature for pre-#5218 logs):** `select_event()` and `publish_registers()` both `split("(")` a cloud `Value must be one of: (...)` string, so an option label containing `(` raised `ValueError: too many values to unpack (expected 2)` — the component does not die (`ComponentBase.start()` catches it), it *crash-loops*: `api_started` never set, automatic config never runs, no plan, `Error: GECloudDirect: too many values to unpack (expected 2)` every cycle. #5218 added the module-level `parse_validation_options()` (`gecloud.py`): split on the first `(` and strip only the final `)` (so inner brackets in labels survive), and `None` for a string with no `(` triggers a warning and falls back to the setting's `in:` validation-rule options instead of raising — the paren-less guard is required, not optional, because `split("(", 1)` alone fails the other direction. Which GE Cloud setting actually returns a multi-`(` validation string was never captured (the storage cache saved at the settings write would be the fixture to ask for). **`refresh_discovery()` is not device re-discovery, and GE Cloud re-discovers hourly since PR #5295 (GH#5294, merged 2026-09-29 - the symbols below were read against the pre-fix tree):** `ComponentBase.refresh_discovery()` only rebuilds the capability-catalogue *report* from data already in hand (a component opts in via `build_discovery()`) and never calls the component's API - the *similarly named* `refresh_devices()` is the thing that calls it. Pre-#5295 that device discovery (`async_get_devices()`, EV chargers, EMS/gateway selection, one-shot automatic config) ran exactly once inside `if first:` and `first` flips off permanently after the first successful run, so on any "GE Cloud didn't pick up my new inverter/charger" or "removed inverter still shows data" report a restart was the only mechanism - and a removed device kept its last good SoC/power feeding the plan (`merge_non_null()` hands back the previous reading on nulls and failed polls) and kept having registers written to. **Post-#5295:** `refresh_devices()` re-reads the device list hourly (`DEVICE_REFRESH_SECONDS`, 60*60, `gecloud.py`; a multiple of 60 because `run()` is called once a minute, and a cycle that finds a change polls and reads settings whatever else is due), `select_poll_devices()`/`apply_devices()` decide what is polled from the fresh list, and adopting a changed set drops every per-device store - `status`, `meter`, `info`, `settings`, `pending_writes`, `register_list`, the EV-charger stores, `ems_slot_warned` and `register_entity_map` - so a removed device stops publishing and being written to. The review round also: the change signature includes `battery_meters`, so a CT rewiring re-runs automatic config; a failed register-list fetch is retried on the next settings read (previously stored as `None` and never fetched again - every later read raised `TypeError`, newly reachable from rediscovery); a device read that would leave zero battery inverters is not adopted (the warning says restart if the hardware really was removed; charger-only sites stay quiet); `ge_cloud_data` returns to its pre-EMS value when the EMS leaves; the EMS slot-override warning re-arms when the EMS changes; and default options for a device discovered while read-only is set stay pending across cycles, applied once read-only ends. Caveats that survive the fix: the 5-day `last_updated` skip inside `async_get_devices()` treats a device silent over 5 days as non-functional wherever that runs - the hourly re-read included - and `merge_non_null()` still hands a *polled* device its last good SoC/power on nulls and failed polls. In-tree fix precedents (GE Cloud itself now among them): Fox re-fetches its device list every 24h (`FOX_REFRESH_STATIC`), SolaX gates plant/device-info re-reads with `data_is_due`, and `num_inverters` is re-read by the core every cycle so a re-run automatic config takes effect next plan. **The "disable" writes on the unused numbered slots leave them live (GH#5371, reporter field log from a GIV-3HY-11 Beta site, code-verified on main):** `enable_default_options()` - run at startup, once per 24h and on newly-found devices, gated only by `read_only_now()` so manual-config GEC sites get the resets too - writes every unused AC-charge and DC-discharge slot 2-10's **times** to `00:00` "to disable" (`gecloud.py`, the numbered-slot branch of the limit/time resets), and on 3-phase GIV-3HY hardware `00:00-00:00` is **live** 00:00:00-00:00:59 (minute bounds), so every "disabled" unused slot is live for one minute past midnight; with force charge on at that minute (a planned charge window spanning midnight, or the v9.1.0 stuck-on case) the unused slots fire at full rate toward their 100% upper limit (discharge mirror: full rate toward the 4% lower floor). The same pass overwrites user-set spare-slot times (the 03:00 workaround) once per pass, per the reporter's inverter-settings history log. Fix direction (maintainer's call): have the **limits** carry the disable instead (unused slots' upper→4%/reserve floor, lower→100%); the constraint is that the two generic limit branches (`*_lower_soc_percent_limit`→4%, `_upper_soc_percent_limit`/`ac_charge_upper_percent_limit`→100%) also match the numbered slots and would write straight back on the next pass, so the fix must special-case slots 2-10 inside those branches - and #5017's outcome could later drive exports through slot 3 on GIV-3HY, so the "unused" set needs a guard there. `test_ge_cloud.py`'s 00:00-reset tests stay valid under this; the fix needs numbered-slot limit assertions added. | `ge_cloud` | | |||
| | Teslemetry / Powerwall (`teslemetry.py`) | Battery model is inferred from site `nameplate_power / battery_count`. A nameplate fallback combined with `inverter_hybrid: True` once produced a false 5 kW inverter limit and spurious morning export. Tariff writes push a whole TOU schedule every cycle, so a setting changed by hand in the Tesla app is reverted on the next cycle (GH#4600, GH#4610). Three later findings. `build_tariff()`/`_render_side` carve a *single* ON_PEAK interval priced with one scalar (`teslemetry.py:1117`/`:1036`/`:1074`), so no intra-window price gradient can exist and Tesla's own TBC is free to defer the whole export to the end of the window; the no-rate-data fallback branch also skips the boost entirely (GH#4887). The charge path sends no rate at all - `evaluate_schedule` (`teslemetry.py:539`) asserts mode `backup` plus reserve = charge target plus grid charging - so a slow charge ramp is Tesla firmware, not a Predbat write bug (GH#4892); Tesla now snaps a backup reserve of 81-99% down to 80% while Predbat still forwards any 0-100 target. The site_info limit mapping was reworked in PR #5276 (GH#5275, merged 2026-09-28): `inverter_limit` comes from `nameplate_power` (the Powerwall's own AC rating; `max_site_meter_power_ac` is the site's supply limit at the meter, not the inverter's), `export_limit` from `min_site_meter_power_ac` (kW, possibly fractional, with the ±1e9 "no limit" sentinel skipped and 0 published as a real 0 W limit), `inverter_limit_charge` at **5 kW per battery unit** capped at nameplate (Tesla reports no usable charge rating — a Powerwall 3 lists only expansion packs with every rating zero, and fleet data fits the rule), `soc_max` from the gateway's `nameplate_energy_watts` before the `battery_count` estimate, and `inverter_hybrid` now defaults from the Powerwall model (Powerwall 3 on, every other model off) with a `teslemetry_hybrid` override for a PW3 beside an existing string inverter. All of those are wired with `set_arg_auto(overwrite=False)`, so **an apps.yaml value wins** — on a pre-#5276 version `automatic_config()` overwrote a manually set `battery_rate_max` whenever `teslemetry_automatic` was on, which was the standing "my override does nothing" answer on this component. Since PR #4976 there is a Predbat-side lever for exactly that slow ramp: `teslemetry_tbc_control` — **on by default since PR #5188** (GH#5186; `DEFAULT_TBC_CONTROL = True` in `teslemetry.py`, mirrored in `COMPONENT_LIST`, with `teslemetry_tbc_control: False` as the opt-out) — switches `evaluate_schedule()` to `evaluate_schedule_tbc()`, which pushes a **signal tariff** (`build_signal_tariff()` - fixed 0/50/100p bands over the committed charge and export windows) so Tesla's own optimiser runs the charge and reaches the full rate reserve-driven charging cannot; mode goes to `autonomous` in every state, reserve becomes an actual reserve rather than a charge signal, and `_settable_reserve()` maps requests onto reserves the Powerwall honours - an 81-99% request now rounds **up** to 100 rather than being forwarded raw into the snap-to-80 band. The same PR stopped `plan.py` planning a manual freeze export on inverters that cannot do it. **Consequences of the default flip:** a Teslemetry user who never set the key is on the signal tariff with autonomous mode, so "the Tesla app shows 0p/50p/100p instead of my rates" or "my charge target isn't honoured" is the default path working, not a bug; and the 81-99% `set_reserve_min` limitation becomes default-on behaviour with it. (`MockTeslemetryAPI` still defaults `tbc_control = False` on purpose, so a green teslemetry test run exercises the real-rate path unless a test opts in.) And a separate scoping fact from the GH#5186 triage: `teslemetry_automatic` gates only `automatic_config()` — the scheduler emulator (`sync_tariff()` + `assert_device_state(evaluate_schedule(...))`) runs for every non-read-only user with no `automatic` check, so "Predbat changed my Tesla tariff/mode but I never turned on automatic" is that scoping, not a bug; `set_read_only` is the only switch that stops the writes. A related pricing bug in the same `build_tariff()` family was fixed in PR #4977: an export window ending at midnight priced the whole of tomorrow at peak. And `optimization_strategy: "economics"` *is* pushed with `tariff_content_v2` on every `set_tariff()`, unconditionally, since v8.49.0 / PR #4603 - a request to "add" it is asking for something already shipped (GH#4918). **GH#5157** (reporter's evidence, not independently probed — Powerwall 2, fw 26.26.4): the unit sat in the idle branch of `evaluate_schedule` and simply stopped acting on a standing device tuple for ~4h while `site_info` read back the *correct* configuration — drift invisible to every field the API exposes, with only a Predbat restart recovering it; the stall state is the one branch Predbat legitimately holds for hours, which is why transition-based self-heal never fires. A "Powerwall plateaued / stopped discharging until I restarted Predbat" report maps here first. **Implemented on main** (2026-09-19): `run()` re-asserts the whole device tuple — export rule, grid charging, reserve, mode, not the tariff — every `FORCED_ASSERT_SECONDS` (2h) with the write-on-change dedupe bypassed (`force=True`), the timer advancing only on a fully successful forced assert; the Info line `Teslemetry control drift-correction is transition-based ..., backed by a forced re-assert of the full device tuple every 120 minutes` names it, so on current main the stall is bounded at ~2h. **Freeze export is fully implemented in the planner and disabled for TESLA at exactly one point (GH#5225, enhancement):** `INVERTER_DEF["TESLA"]` declares `support_discharge_freeze: False` (`config.py`), read into `inv_support_discharge_freeze` (`inverter.py`), whose only consumer is the first-inverter lockstep block in `execute.py` that force-disables `set_export_freeze`/`set_export_freeze_only` (`Note: Inverter does not support discharge freeze - disabled`) — `EXPORT_MODE_FREEZE` never enters the export ladder, and PR #4976 additionally drops manual freeze-export windows to demand with a Warn. **Flipping the flag alone is not enough:** the component must also map the freeze-target discharge window to a device-side hold, or the plan's freeze assumption fails on the device — the non-TBC `evaluate_schedule()` writes the *raw* discharge target as the reserve, so a 99 target lands in the 81-99 band Tesla silently snaps to 80 (`_settable_reserve()` exists for exactly that and the non-TBC path doesn't route through it), while the default-TBC `evaluate_schedule_tbc()` discharge branch yields `pv_only` with the standing reserve but no hold — the battery still serves house load and drifts down. The device primitive exists in-tree: the TBC charge-hold tuple (`pv_only` + reserve 100 + grid charging off + autonomous) holds the battery while PV surplus exports, but a freeze *export* hold must sit at the current SoC (reserve at/above SoC through `_settable_reserve()`), not 100 — reserve 100 lets solar recharge the battery instead of exporting the surplus. Every `INVERTER_DEF` entry with `support_discharge_freeze: False` (the cloud-emulator types: SunsynkCloud, AlphaESSCloud, DeyeCloud, SolaxCloud, SolisCloud…) shares this two-part requirement — capability flag **plus** device-side freeze mapping — so enabling freeze export on any of them is a two-file change, not a one-line flag flip; each component's schedule emulator needs its own hold tuple designed against what its hardware honours (*suspected*, not verified per component). | `teslemetry` | | |||
| | Sunsynk / DEYE (`sunsynk.py`, `deye.py`) | Freeze export is gated by the per-slot power register (`sellTime{n}Pac` on Sunsynk), confirmed on live hardware — setting the energy mode alone had no effect, and with slot power at zero the battery still charged. `read_only` was ignored by the reconcile loops until `_is_read_only()` gated `_reconcile_control()` (GH#4436). DEYE cloud telemetry keys are one hardcoded spelling per metric — `DEYE_TELEMETRY_KEYS["pv_power"] = "TotalSolarPower"` (`deye_const.py`), confirmed against a single live 3-phase hybrid — and a SUN-8K-SG05LP1-EU-AM2-P instead exposes `TotalDCInputPower` + `DCPowerPV1/2/3`, neither anywhere in the tree. Because `pv_power` is in `DEYE_TELEMETRY_REQUIRED`, the miss fires the `device/latest missing expected keys [...] - telemetry will read zero` warning every cycle and the Cloud PV sensor publishes 0.0 while a manual `pv_power` arg to a local sensor may still protect the planner. Reproduced by swapping the test fixture's single PV key (`tests/test_deye_api.py` `LIVE_DATA_LIST`). Whether the alternate key is unit-equivalent (vs summing `DCPowerPV1-3`) needs a live capture from an affected model — suspected, not verified. CONFIRMED live (Sunsynk 2211093089, 2026-09-19, via `sunsynk.py --tou-test`) that the settings object exposes the TOU register block a SECOND time under unrelated names, so several keys that read like independent settings are the same memory at a different scale: `volt1`-`volt4` are `sellTime3`-`sellTime6` as minutes-since-midnight / 50, `volt5`-`volt10` are `sellTime1Pac`-`sellTime6Pac` / 10, and `volt11`, `volt12`, `current1`-`current4` are `sellTime1Volt`-`sellTime6Volt` x 10 — a contiguous 16-value window, matched 16/16 in both the before and after reads of one write. Two consequences. It is independent proof a TOU write reached the real registers rather than a cloud-side echo, which is the cheapest hardware verification available. And it is a trap: anything that wrote `volt*`/`current*` would silently corrupt the charge programme. Predbat is safe today only because `SUNSYNK_SYSTEM_MODE_FIELDS` excludes them, so treat that exclusion as load-bearing rather than incidental. The alias does NOT extend to what the write payload must contain — `time{n}On` (capital O) is a derived echo of `time{n}on` and is correctly excluded via `SUNSYNK_DERIVED_SLOT_FIELDS`. **GH#5138**: the (pre-#5360 wording) `control cache is X minutes old (limit 15)` forced-rewrite check is **startup-only** - it lives in `restore_state()`, called only from `run()`'s `if first:` block - so a reporter reading `limit 15` as "rechecks every 15 minutes" is wrong; it never runs again after the first cycle. The issue's core premise (idle slots never clear `sellTime{n}En`) was disproved: every slot `_owned_payload` write carries an explicit sell flag, idle slots are written with `sell: 0`, and the TOU build places a sell-0 baseline segment at each window's end (probe-verified; a `sellTime5En: 1` read-back just after an export window can be *correct*). The real gap it exposed - a write the cloud API acknowledged but the dongle never collected was trusted forever, because the owned-field change gate suppresses identical re-sends and `note_settle` only warned - is **fixed in PR #5142 (merged 2026-09-19)**: sustained settle divergence now clears `applied_payload[sn]` so the next write cycle re-applies. Keep the mechanism for pre-#5142 logs, where a stuck export slot needed a restart to clear. No debug yaml was ever attached, so the reporter's exact overrun is unconfirmed; the `has not applied Predbat's settings after N settings polls` warning is the tell. Two component-side traps since. **PR #5150** (merged 2026-09-19): `control_active` is now persisted and restored alongside `applied_payload` under the same 15-minute bound (`SUNSYNK_RESTORE_MAX_CONTROL`/`DEYE_RESTORE_MAX_CONTROL`), so a restart **inside** the bound no longer strands an armed inverter in silence; on the upgrade path a cache carrying `applied_payload` with no `control_active` key infers the missing half from the payload keys — a safe lower bound, since `applied_payload[sn]` is written only by `apply_settings`/`apply_dynamic_control`, whose production callers arm `control_active` first (the CLI paths apply with `force=True` and never save). **PR #5360 (merged 2026-10-05, unreleased at the time of writing, fixes GH#5349 below) has since split the two halves into separate caches with separate bounds:** `applied_payload` keeps the 15-minute bound (`SUNSYNK_RESTORE_MAX_CONTROL`/`DEYE_RESTORE_MAX_CONTROL`) while `control_active` gets 8 hours (`SUNSYNK_RESTORE_MAX_CONTROL_ACTIVE`/`DEYE_RESTORE_MAX_CONTROL_ACTIVE`, in a cache of its own, with a migration path from the pre-#5360 combined cache), and the restore log line splits to match - `Info: Sunsynk control payload cache is X minutes old (limit 15), forcing a rewrite` drops only the payload cache; a new `Info: Sunsynk control ownership cache is X minutes old (limit 480), requiring a fresh write` is the one that drops the ownership half. And the in-code comment on the Sunsynk write-button handler claiming Predbat "presses this on every cycle" is wrong about frequency: both press sites in `inverter.py` are change-gated (target SoC presses only when `current_soc != soc`, the export window only when `schedule_changed`), and the one unconditional post-restart re-commit is `is_hm_format`-only, which excludes these types' `HH:MM:SS` — so after a restart with the plan already matching the inverter, nothing is pressed for hours. Read the press gates in `inverter.py` before using that comment to dismiss a "component stopped writing after a restart" report. **GH#5349 (2026-10-02, fixed in PR #5360, merged 2026-10-05 - keep the mechanism for pre-#5360 logs) joined the two halves end to end:** on a pre-#5360 build an HA outage restarted Predbat with the (single) control cache 35.9 minutes old, restore dropped both `applied_payload` and `control_active`, and **nothing performed the forced rewrite on its own** - `_reconcile_control()` gates on `control_active`, `number_event` reaches Predbat only as in-memory `update_local_schedule()` updates (no apply), and both press sites stayed change-gated - so zero settings POSTs fired from 00:59 to 03:02 (counted from the reporter's full-API-logging log) while the hold re-armed every cycle and the inverter's idle-cap-5 programme drained ~9 kWh into the EV until a plan change finally pressed the write-button at 03:02. #5360 closes it by keeping `control_active` for 8 hours (see above), so the reconcile path can own the re-apply within that window. Reading the "forcing a rewrite" line as if a rewrite follows is still the trap - it is the notice that the payload cache was **dropped**; a "holds lost for hours after an HA blip / battery drained while Predbat showed holds armed" report on a pre-#5360 (v9.3.5-) build maps here, and on post-#5360 builds the `has not applied Predbat's settings after N settings polls` settle path is the remaining backstop. Device-visible hold legs on these types (same log): the TOU slot cap is the only one — a hold is `cap = SoC+1` in the programme (cap 65 held the battery at 64% while the car drew from grid; cap 5 drained it toward the inverter floor), and the `discharge_rate 0` entity write is symbolic on this type, so a "wrote 0 to discharge_rate but the battery drained" report reads the cap, not the entity. Also normal for this type: Sunsynk TOU charge windows cannot cross midnight (`can_span_midnight: False`) — a 23:00–00:30 window is written 23:00–23:59 and re-rolled to 00:00–00:30 at midnight (log-confirmed; not a bug). **GH#5156** (padding truncating any TOU window crossing 04:00/08:00/12:00, `build_tou_slots()` — now shared by both components in `tou_schedule.py`) is **fixed**: padding slots now carry the state of the slot they follow and sit just after it, an inert interval that cannot end a window early (`_padding_segments()` documents the issue). The pre-fix tell was "Deye stops charging at 00:00/04:00/08:00/12:00/16:00/20:00 while the Plan page still shows charging", freshly generated each cycle — not a stale default slot. **GH#5193 (cloud component, load telemetry):** on Sunsynk M3.3.8.9 the `totalPower` field (`load_power`, `SUNSYNK_TELEMETRY`) read 0–100 W through a whole overnight cycling stretch while the battery was active — including mode-2 ("Limited to Home") stretches — and read plausibly the adjacent morning with the battery idle, so the collapse correlates with the battery being active, not cleanly with the work mode; what gates it is unresolved (suspected; the reporter's manual A/B blamed the mode flip, the log's mode-2 stretches say something else does too — a controlled live test on the affected firmware is the only settle). `dailyUsed` (`load_today`) kept counting at a plausible coarse rate through the same stretch, so a balance-derived load remains feasible — and `fill_load_from_power()` is the repair that gets nothing while `totalPower` is zero. Predbat's own export control writes the whole-system `sysWorkMode` to `selling_first` for every planned export window (`derive_control_state()`, applied in the settings payload), and the component auto-wires both load args through `set_arg_auto()`'s default `overwrite=True`, so a manual apps.yaml override does NOT win — only `sunsynk_automatic: False` opts out. The in-file docstring on main records the mode/battery-export reading plus the live counter-evidence (11.1 kWh exported in a day under "Limited to Home" with `solarSell` on; a separate live test showed battery export under mode 2 with the per-slot sell flag), so the docstring's "the mode governs battery export" claim is DEYE-inferred and not settled — a control-side alternative (stay in mode 2, drive `sellTime{n}En`) stays open. The component logs every API request/response in full in `predbat.log`, so a whole Sunsynk-cloud investigation can run from the log alone; when mining logged JSON widen the field width before trusting a truncated number (`0.4` prints as `0.` under a 14-char `substr`). **Automatic config maps a battery-side current into `battery_rate_max`, and `inverter_limit` does not bound the written rate (GH#5238, code-read on main 2026-09-25/29):** `battery_rate_max()` derives watts from `chargeCurrentLimit`/`maxChargeCurrentLimit` × nominal pack voltage (`SUNSYNK_CHARGE_CURRENT_FIELDS`, first-positive-wins — a battery/BMS-side limit; GH#5238's 280 A BMS derived 14.3 kW against an 8 kW inverter), `automatic_config()` maps it to `battery_rate_max` and `ratePower` to `inverter_limit` but **never sets `inverter_limit_charge`/`inverter_limit_discharge`**, and `inverter.py` defaults both of those to `battery_rate_max_raw` when unset — so `battery_rate_max_charge = min(raw, raw) = raw`, and that is the per-slot power the plan writes. `prediction.py` clamps only *predicted* flow to `inverter_limit`; nothing feeds `inverter_limit` into the written rate. `deye.py`'s `battery_rate_max()` docstring states the same wrong assumption outright ("inverter_limit constrains the AC side separately" while deriving from `maxChargeCurrent`), and its `automatic_config()` has the same two-arg shape — so treat any "automatic config shows/writes an impossible rate" report for a cloud component through this lens first, and a fix has to map `inverter_limit_charge`/`_discharge` (to `min(ratePower, derived battery rate)`); deriving the true inverter-side current setting needs a telemetry mapping Sunsynk does not currently expose. Workaround semantics: `inverter_limit_charge`/`inverter_limit_discharge` are safe apps.yaml overrides under `sunsynk_automatic` (the component never sets them), while `battery_rate_max` is not — `set_arg_auto(overwrite=True)` clobbers an apps.yaml value every cycle. | `sunsynk_control`, `deye_control` | | |||
| | Sunsynk / DEYE (`sunsynk.py`, `deye.py`) | Freeze export is gated by the per-slot power register (`sellTime{n}Pac` on Sunsynk), confirmed on live hardware — setting the energy mode alone had no effect, and with slot power at zero the battery still charged. `read_only` was ignored by the reconcile loops until `_is_read_only()` gated `_reconcile_control()` (GH#4436). DEYE cloud telemetry keys are one hardcoded spelling per metric — `DEYE_TELEMETRY_KEYS["pv_power"] = "TotalSolarPower"` (`deye_const.py`), confirmed against a single live 3-phase hybrid — and a SUN-8K-SG05LP1-EU-AM2-P instead exposes `TotalDCInputPower` + `DCPowerPV1/2/3`, neither anywhere in the tree. Because `pv_power` is in `DEYE_TELEMETRY_REQUIRED`, the miss fires the `device/latest missing expected keys [...] - telemetry will read zero` warning every cycle and the Cloud PV sensor publishes 0.0 while a manual `pv_power` arg to a local sensor may still protect the planner. Reproduced by swapping the test fixture's single PV key (`tests/test_deye_api.py` `LIVE_DATA_LIST`). Whether the alternate key is unit-equivalent (vs summing `DCPowerPV1-3`) needs a live capture from an affected model — suspected, not verified. CONFIRMED live (Sunsynk 2211093089, 2026-09-19, via `sunsynk.py --tou-test`) that the settings object exposes the TOU register block a SECOND time under unrelated names, so several keys that read like independent settings are the same memory at a different scale: `volt1`-`volt4` are `sellTime3`-`sellTime6` as minutes-since-midnight / 50, `volt5`-`volt10` are `sellTime1Pac`-`sellTime6Pac` / 10, and `volt11`, `volt12`, `current1`-`current4` are `sellTime1Volt`-`sellTime6Volt` x 10 — a contiguous 16-value window, matched 16/16 in both the before and after reads of one write. Two consequences. It is independent proof a TOU write reached the real registers rather than a cloud-side echo, which is the cheapest hardware verification available. And it is a trap: anything that wrote `volt*`/`current*` would silently corrupt the charge programme. Predbat is safe today only because `SUNSYNK_SYSTEM_MODE_FIELDS` excludes them, so treat that exclusion as load-bearing rather than incidental. The alias does NOT extend to what the write payload must contain — `time{n}On` (capital O) is a derived echo of `time{n}on` and is correctly excluded via `SUNSYNK_DERIVED_SLOT_FIELDS`. **GH#5138**: the `control cache is X minutes old (limit 15)` forced-rewrite check is **startup-only** - it lives in `restore_state()`, called only from `run()`'s `if first:` block - so a reporter reading `limit 15` as "rechecks every 15 minutes" is wrong; it never runs again after the first cycle. The issue's core premise (idle slots never clear `sellTime{n}En`) was disproved: every slot `_owned_payload` write carries an explicit sell flag, idle slots are written with `sell: 0`, and the TOU build places a sell-0 baseline segment at each window's end (probe-verified; a `sellTime5En: 1` read-back just after an export window can be *correct*). The real gap it exposed - a write the cloud API acknowledged but the dongle never collected was trusted forever, because the owned-field change gate suppresses identical re-sends and `note_settle` only warned - is **fixed in PR #5142 (merged 2026-09-19)**: sustained settle divergence now clears `applied_payload[sn]` so the next write cycle re-applies. Keep the mechanism for pre-#5142 logs, where a stuck export slot needed a restart to clear. No debug yaml was ever attached, so the reporter's exact overrun is unconfirmed; the `has not applied Predbat's settings after N settings polls` warning is the tell. Two component-side traps since. **PR #5150** (merged 2026-09-19): `control_active` is now persisted and restored alongside `applied_payload`; **PR #5360 (merged 2026-10-05, fixes GH#5349) then split the bounds — keep the single-15-minute-bound reading for pre-#5360 (≤ v9.3.5) logs** — with `applied_payload` restoring only when its cache is ≤15 minutes old (`SUNSYNK_RESTORE_MAX_CONTROL`/`DEYE_RESTORE_MAX_CONTROL`) and `control_active` (the reconcile gate) when ≤ **8 hours** old (`SUNSYNK_RESTORE_MAX_CONTROL_ACTIVE`/`DEYE_RESTORE_MAX_CONTROL_ACTIVE`), so a restart **inside** the bound no longer strands an armed inverter in silence; on the upgrade path a cache carrying `applied_payload` with no `control_active` key infers the missing half from the payload keys — a safe lower bound, since `applied_payload[sn]` is written only by `apply_settings`/`apply_dynamic_control`, whose production callers arm `control_active` first (the CLI paths apply with `force=True` and never save). And the in-code comment on the Sunsynk write-button handler claiming Predbat "presses this on every cycle" is wrong about frequency: both press sites in `inverter.py` are change-gated (target SoC presses only when `current_soc != soc`, the export window only when `schedule_changed`), and the one unconditional post-restart re-commit is `is_hm_format`-only, which excludes these types' `HH:MM:SS` — so after a restart with the plan already matching the inverter, nothing is pressed for hours. Read the press gates in `inverter.py` before using that comment to dismiss a "component stopped writing after a restart" report. **GH#5349 (live, 2026-10-02) joins the two halves end to end:** an HA outage restarted Predbat with the control cache 35.9 minutes old, restore logged `Info: Sunsynk control cache is 35.9 minutes old (limit 15), forcing a rewrite` and dropped both halves — but nothing performs that rewrite on its own: `_reconcile_control()` gates on `control_active`, `number_event` reaches Predbat only as in-memory `update_local_schedule()` updates (no apply), and both press sites stayed change-gated, so **zero settings POSTs fired from 00:59 to 03:02** (counted from the reporter's full-API-logging log) while Predbat re-armed the hold every 5-minute cycle (reserve chasing SoC+1) and the inverter ran its 00:59 programme's idle-cap-5 slots, draining ~9 kWh (82% → 24%) into the EV until a charge-window plan change finally pressed the button at 03:02 — recovery then ran #5142's settle detection (`Warn: Sunsynk ... has not applied Predbat's settings after 4 settings polls`, fired at 03:59) and re-applied. Reading the "forcing a rewrite" line as if a rewrite follows is the trap: it is the notice that the cache was **dropped**. So a "holds lost for hours after an HA blip / battery drained while Predbat showed holds armed" report maps here on **pre-#5360 (≤ v9.3.5)** builds; since PR #5360 the ownership cache restores up to 8 hours old (`_restore_control_state()` re-sets `control_active` from the stored list), so a restart inside 8h re-arms the reconcile gate and reconcile re-applies the programme — keep the always-lost reading for pre-#5360 logs Device-visible hold legs on these types (same log): the TOU slot cap is the only one — a hold is `cap = SoC+1` in the programme (cap 65 held the battery at 64% while the car drew from grid; cap 5 drained it toward the inverter floor), and the `discharge_rate 0` entity write is symbolic on this type, so a "wrote 0 to discharge_rate but the battery drained" report reads the cap, not the entity. Also normal for this type: Sunsynk TOU charge windows cannot cross midnight (`can_span_midnight: False`) — a 23:00–00:30 window is written 23:00–23:59 and re-rolled to 00:00–00:30 at midnight (log-confirmed; not a bug). **GH#5156** (padding truncating any TOU window crossing 04:00/08:00/12:00, `build_tou_slots()` — now shared by both components in `tou_schedule.py`) is **fixed**: padding slots now carry the state of the slot they follow and sit just after it, an inert interval that cannot end a window early (`_padding_segments()` documents the issue). The pre-fix tell was "Deye stops charging at 00:00/04:00/08:00/12:00/16:00/20:00 while the Plan page still shows charging", freshly generated each cycle — not a stale default slot. **GH#5193 (cloud component, load telemetry):** on Sunsynk M3.3.8.9 the `totalPower` field (`load_power`, `SUNSYNK_TELEMETRY`) read 0–100 W through a whole overnight cycling stretch while the battery was active — including mode-2 ("Limited to Home") stretches — and read plausibly the adjacent morning with the battery idle, so the collapse correlates with the battery being active, not cleanly with the work mode; what gates it is unresolved (suspected; the reporter's manual A/B blamed the mode flip, the log's mode-2 stretches say something else does too — a controlled live test on the affected firmware is the only settle). `dailyUsed` (`load_today`) kept counting at a plausible coarse rate through the same stretch, so a balance-derived load remains feasible — and `fill_load_from_power()` is the repair that gets nothing while `totalPower` is zero. Predbat's own export control writes the whole-system `sysWorkMode` to `selling_first` for every planned export window (`derive_control_state()`, applied in the settings payload), and the component auto-wires both load args through `set_arg_auto()`'s default `overwrite=True`, so a manual apps.yaml override does NOT win — only `sunsynk_automatic: False` opts out. The in-file docstring on main records the mode/battery-export reading plus the live counter-evidence (11.1 kWh exported in a day under "Limited to Home" with `solarSell` on; a separate live test showed battery export under mode 2 with the per-slot sell flag), so the docstring's "the mode governs battery export" claim is DEYE-inferred and not settled — a control-side alternative (stay in mode 2, drive `sellTime{n}En`) stays open. The component logs every API request/response in full in `predbat.log`, so a whole Sunsynk-cloud investigation can run from the log alone; when mining logged JSON widen the field width before trusting a truncated number (`0.4` prints as `0.` under a 14-char `substr`). **Automatic config maps a battery-side current into `battery_rate_max`, and `inverter_limit` does not bound the written rate (GH#5238, code-read on main 2026-09-25/29):** `battery_rate_max()` derives watts from `chargeCurrentLimit`/`maxChargeCurrentLimit` × nominal pack voltage (`SUNSYNK_CHARGE_CURRENT_FIELDS`, first-positive-wins — a battery/BMS-side limit; GH#5238's 280 A BMS derived 14.3 kW against an 8 kW inverter), `automatic_config()` maps it to `battery_rate_max` and `ratePower` to `inverter_limit` but **never sets `inverter_limit_charge`/`inverter_limit_discharge`**, and `inverter.py` defaults both of those to `battery_rate_max_raw` when unset — so `battery_rate_max_charge = min(raw, raw) = raw`, and that is the per-slot power the plan writes. `prediction.py` clamps only *predicted* flow to `inverter_limit`; nothing feeds `inverter_limit` into the written rate. `deye.py`'s `battery_rate_max()` docstring states the same wrong assumption outright ("inverter_limit constrains the AC side separately" while deriving from `maxChargeCurrent`), and its `automatic_config()` has the same two-arg shape — so treat any "automatic config shows/writes an impossible rate" report for a cloud component through this lens first, and a fix has to map `inverter_limit_charge`/`_discharge` (to `min(ratePower, derived battery rate)`); deriving the true inverter-side current setting needs a telemetry mapping Sunsynk does not currently expose. Workaround semantics: `inverter_limit_charge`/`inverter_limit_discharge` are safe apps.yaml overrides under `sunsynk_automatic` (the component never sets them), while `battery_rate_max` is not — `set_arg_auto(overwrite=True)` clobbers an apps.yaml value every cycle. | `sunsynk_control`, `deye_control` | | |||
| @@ -113,13 +113,13 @@ Grep for the named symbol rather than trusting a line number. | |||
| | HA write/verify (`ha.py`, `inverter.py`) | `get_state(refresh=True)` is a no-op in a normal HA add-on install: it only re-reads when `not self.ha_key`, and `ha_key` is set in that case, so verification reads the websocket cache, never a fresh value (`ha.py:798`, since PR #2342). Separately, `write_and_poll_value()` treats `domain == "sensor"` as Predbat-owned and POSTs `/api/states/<entity>` directly (`inverter.py:2155`, `ha.py:1071-1077`) instead of calling the integration. Probed empirically across all four write-path/domain combinations (GH#4738): a control entity that resolves to a `sensor.*` domain by mistake gets a direct state overwrite that reads back as success, with zero corresponding lines in the real integration's log. `call_service_wrapper()`'s return value used to be discarded at every `inverter.py` write site, so a rejected HA service call (e.g. a Modbus "Illegal Function" error) never reached the verify logic. That is no longer true everywhere: PR #4878 made `call_service_template()` check it (`inverter.py:2817`) and log "was not accepted, it will be retried next cycle". The other eleven `call_service_wrapper()` call sites in that file still discard it, so check the specific write path before repeating the general claim. Later triage extended this row rather than replacing it. `write_and_poll_switch()` builds its service name as `domain + "/turn_..."` straight from the entity's own domain with no validation (`inverter.py:2102`), and `adjust_inverter_mode()` routes every `has_ge_eco_toggle` inverter through it - so an `inverter_mode` pointed at a `select.*` entity produces `select.turn_on`, an HA-invalid service retried 10x at 10s per attempt, and the string coercion just below (`inverter.py:2110-2111`) maps any select state to False, so the force-export direction reports success having written nothing (GH#4909, still live — though on 3-phase GEC the real problem is one stage deeper: no eco register exists at all, and the write path is skipped with `No entity_id for ECO Toggle`; see the GE Cloud row). `adjust_force_export`/`adjust_charge_window` format their times at plan precision with no snapping (`TIME_FORMAT_HMS`, `inverter.py:2608`/`:2615`), so against an integration whose select only offers 15-minute options (Solar Assistant/Deye) Predbat writes e.g. `20:55` and `write_and_poll_option` retries the impossible value 10x every cycle; nothing anywhere reads a select's `options` attribute, and `charge_time_entity_is_option` only decides *how* an entity is written, never which values are legal. The fix precedent is already in tree - AlphaESS's `snap_time_grid()` (`alphaess_const.py:215`), snap start forward and end backward with a collapse check (GH#4947). A second, independent way plan-precision times fail on the same select path: `write_and_poll_option()` only strips the seconds from an 8-char `HH:MM:SS` write when the *previous* state is a healthy 5-char `HH:MM:SS` read — the read feeding it returns `None` for an entity missing from the state cache (`ha.py:817`) or the literal `"unknown"`/`"unavailable"` when degraded (`ha.py:815`), either skips the strip and the raw `HH:MM:SS` goes to `select_option`, which HA rejects; all 10 retries re-read and fail identically, and the log reads `didn't complete got unknown` (GH#5009, probe-verified on main). That degraded-read shape can also be **permanent**: an SA slot select can report `unknown` for days — every write read-back `unknown`, zero verified writes, across an SA rebuild and both native-API and MQTT transports — so both symptoms (read path `unable to read Export window - ... returned no data` every cycle via `time_string_to_stamp("unknown")` → `None`, and the write path above) fire continuously; state reporting varies by SA backend (GH#5214). **A user edit of `config.py`'s INVERTER_DEF `charge_time_format` to anything ≠ exactly `"HH:MM:SS"` is a masking workaround, not a fix (GH#5214):** the `!= "HH:MM:SS"` branch (`inverter.py`) swaps apps.yaml entities for Predbat's own `sensor.predbat_{type}_{id}_*` dummies — reads parse Predbat's own echo and writes become direct `set_state` POSTs that never reach the inverter — so the log goes quiet while SA window control is silently severed. Tells, all observed in #5214's attachments: a `Creating dummy entity sensor.predbat_{TYPE}_{id}_charge_start_time` line in the log (`create_entity()` only logs when the entity is missing from HA state, so its presence proves the ≠ branch ran); the debug yaml's live `args` naming dummy ids while `args_from_apps_yaml` still lists the real `select.*` entities; and warnings stopping after a user restart then resuming after an addon update (which overwrites the edited `config.py`, wiping it). Also: pre-#3533 SA shipped `charge_time_format: "S"` (dummy time entities, no SA select wiring), so "SA time warnings started after updating" can mean the user crossed the #3533 template wiring rather than a format regression. The fix that serves both is reading the select's `options` attribute — nothing in the codebase does today. Six of the eight `adjust_*` writers discard the write helper's boolean and fire `call_notify()`/`mqtt_message()` regardless, and `rest_setReserve()` has the same gap (GH#4845). `call_service_template()` used to record its dedup hash *before* the call, so a silently failed `select_option` was skipped as "previously called" on every later cycle; fixed (it now records only on success and drops the record on failure), though it still deliberately returns True so callers cannot downgrade a freeze into a stop (GH#4876). From that same report, a false-alarm class worth recognising: a `didn't complete got X` where X is exactly the *previous* cycle's target, on an integration that republishes its entities slowly, is the verify window reading HA's cache - the write had already landed by the next cycle. That window is arithmetic, not a constant: up to `INVERTER_MAX_RETRY` (10) writes, each polled through one `inv_write_and_poll_sleep` budget with a doubling read interval - **~40s on GS, ~100s on GE/GEC/GEE** (`write_and_poll_sleep` is 10 for those types, 4 for GS). **Per-type since PR #5297 (merged 2026-09-29):** `INVERTER_DEF[type]["write_max_retry"]`/`["write_backoff"]` (consumed by `_write_attempts()`/`_write_backoff_result()`), and currently only `GWMQTT` deviates - 3 attempts, 10s apart - plus a per-control degraded state for those types: a write of the *same* target failing `INVERTER_WRITE_BACKOFF_FAILURES` (2) times in a row drops to one attempt per `INVERTER_WRITE_DEGRADED_INTERVAL` (300s) until a write verifies, the read-back matches or a different target arrives (full ladder restored at once); a degraded control still reads back, logs and records the failure every call - nothing is skipped silently. Every other type keeps 10 attempts and its existing sleep. A settling bounce that outlasts it is a second false-alarm shape (GH#5130): a HA `number.*` entity can step through intermediates (0 → a float → the settled int) for tens of seconds after a timed-slot write (~44s observed on solax_modbus), so a `didn't complete got <float>` whose value sits *between* the old and target values is a settling read-back, not a failed write - it self-heals next cycle when the initial read matches. The bounce reads feed only `value_matched()` (keep polling vs rewrite) and only the final read reaches the control ledger (`record_write` on match, `clear` on failure), so the worst case is a redundant same-value rewrite plus the false warning; the in-repo precedent for re-reading after settling is Solis Cloud's `verify_settle_seconds` re-read. And the discharge-stop fallback (GH#5094, still live): `adjust_charge_immediate()` issues a "stop discharge" service step before the charge/freeze step, and when `discharge_stop_service` is not configured it falls back to `charge_stop_service` with `domain="discharge"` - a documented fallback dating to #1614. On Tesla service-hook setups `charge_stop_service` maps to `self_consumption` + backup reserve 0, which on a Powerwall is **active discharge to load** (the EV charger counts as load), not a stop - so every freeze/hold cycle Predbat sends "discharge normally" and then re-commands "hold" ~2s later, and Tesla occasionally applies the first and drops the second, so the battery discharges into the car until the next 5-minute cycle. Verified from the reporter's log: the exact pair fires from the carHolding branch ("Disabling battery discharge whilst car 0 is charging" → `adjust_charge_immediate(soc_percent, freeze=True)`); the reporter had commented out `discharge_stop_service` (and `discharge_start_service`) when disabling export control, which is what exposed the fallback. Workaround: define `discharge_stop_service` in apps.yaml with commands that actually stop discharge (for a no-export setup, the same commands as `charge_freeze_service`). Caveat on the reporter's own `repeat: False` idea: enabling the service dedup means accepted calls are not re-sent (see the GH#4876 entry above - HA accepts the call but Tesla firmware can still drop it), so dropped freeze commands would never be retried. Both this and the fixed export clobber below stem from the same property of the Tesla template set: `charge_stop_service` and the freeze/discharge templates all write the same `operation_mode` select, and the templates mean opposite things on this hardware. **A sibling of the same family, over the reserve register rather than the mode selects (GH#5300, triaged 2026-09-29 against d951201e, reporter on a hand-built apps.yaml):** inside one 5-minute pass the hook charge (`adjust_charge_immediate()` issues `charge_freeze_service`/`charge_start_service` via `call_service_template`, inverter.py) and `execute.py`'s reserve reset (`if self.set_reserve_enable and resetReserve: inverter.adjust_reserve(0)`) both touch the Powerwall's reserve and the reset has **no isCharging guard** - `resetReserve` initialises True whenever `set_charge_window or set_export_window` and is cleared only by the freeze / hold-charging / car / iBoost hold branches - while `adjust_reserve()` floors at `reserve_percent` and writes through `write_and_poll_value()`, so the reset always ends up holding the register, against hook writes that are fire-and-forget. A service hook that uses the reserve register as its charge signal loses that race on every charge-window cycle. The shipped template is immune by two mechanisms, both worth checking before triaging any "Tesla reserve overwritten" report: `templates/tesla_powerwall.yaml` sets `has_reserve_soc: False` in the `inverter:` block (`fetch_inverter_data()` then force-disables `set_reserve_enable`/`set_reserve_hold`, logging `Note: Inverter does not support reserve - disabling reserve functions`), and with no `reserve:` arg wired Predbat dummies the arg (`create_missing_arg`/`create_entity`, inverter.py) so `adjust_reserve` writes land on a Predbat placeholder - the Sigenergy dummy-arg shape again. Discriminator for real-vs-dummy reserve wiring: the `Inverter N Current Reserve is X% ... and new target is Y%` and `Wrote X to reserve, successfully now Y` lines name the register, not the entity - a non-zero current read means the `reserve:` arg resolves to a real wired entity; a dummy reads 0 and at an equal target prints `already at target` instead. Dump-config tells from the same report: a `set_reserve_enable` switch showing `value: null` in a debug dump can still resolve True (expert-mode-switched item, hidden and entity not created while expert mode is off), and unknown keys in the dump's `args:` mean a hand-built config - do not assume the shipped template. | `inverter` | | |||
| | GE Cloud (`gecloud.py`) | Gateway fields can come back null. `merge_non_null` stops nulls overwriting good values, and the publish path guards null containers — GH#4656 was a null crash in that area. `number_event` clamps an out-of-range write silently and does not report the clamped value back, while `write_and_poll_value()` keeps comparing against the original pre-clamp target - a permanent false `had_errors` and an unbounded retry (GH#4826). PR #4828 clamped inside `adjust_reserve()` only; the shared write helper still has no min/max awareness and the other `inverter.py` write sites still pass unclamped targets (GH#4831). The error-code path has since been reworked (`9560c61a`, `d6e5998c`) after GH#4896 showed `success: false` nulled `data` before the code branch could read it, so codes GivEnergy documents as never succeeding on a repeat (-3/-4/-7) were retried the full budget and `message` was never surfaced. Separately, **fixed in PR #4954 (merged 2026-09-06)** - keep the mechanism for anyone holding an older log: for `GE`/`GEC`/`GEE` the max battery rate was taken solely from the `charge_rate` entity's `max` attribute, and the `elif "battery_rate_max"` branch below it was unreachable for those types. Percentage-rated models (the 3-phase units) have no absolute charge power register, so `ge_cloud_automatic` left `charge_rate` unset and the attribute read returned the 2600 W default; both the correct rate GECloud writes into `battery_rate_max` and the user's own apps.yaml value went unread, and every rate was clamped to 2600 W. On those models it also corrupted the writes, since the percentage registers are set as `new_rate / battery_rate_max_raw * 100` against a denominator 3.8x too small. The fix falls back to `battery_rate_max` only when `charge_rate` resolves to nothing (GH#4908). GH#4198 is the same code shape on SolaX and is not covered by that fix. A model-string parser gap sits above that path (GH#5136): **the integer-rating half was fixed in PR #5293 (merged 2026-09-30, v9.3.3)** — `get_max_inverter_rate_from_model()` now parses an integer segment straight after the `3HY` token (`GIV-3HY-11` → 11 kW) *before* the decimal pass, so a later decimal segment cannot hide it; it also guards a null model, strips trailing punctuation (`GIV-HY-8.0-G3-HV.`) and warns readably on an unparseable rating ("using max charge rate instead - set inverter_limit in apps.yaml"); keep the pre-#5293 signature (decimal-only match, so an integer-rated `GIV-3HY-11` fell back to `max_charge_rate` — which the GE Cloud API can change independently, 11000 → 9984 W observed). **Still live:** `publish_info()` reads only `max_charge_rate`, never the `max_discharge_rate` in the same payload, and `battery_rate_max` is bound to the `_max_charge_rate` entity — a model whose discharge rating differs keeps the wrong rate. Distinct from GH#4908 (the absent-`charge_rate` 2600 W default). Start on any "GEC inverter rate is wrong" report by checking the model string for a decimal point; the tests now cover the integer-3HY cases too. `automatic_config()` binds `inverter_limit` to the resulting `_max_inverter_rate` sensors and `prediction.py` clips PV against `inverter_limit`, so the error reaches the plan. **Mixed fleets: the rate read/write gates test key existence, not per-slot state (GH#5359, probe-verified on main b161949d via `tools/triage_test.sh`):** `get_current_charge_rate()`/`get_current_discharge_rate()` (`inverter.py`, the `"charge_rate_percent" in self.base.args` branch) and `adjust_charge_rate()`/`adjust_discharge_rate()` (which write **both** keys, each gated only on key existence) interrogate whether the key exists **anywhere in the fleet's args**, not whether *this* inverter's slot is set — and `get_arg()` on a `None` slot applies the caller's default quietly (`userinterface.py`, float branch) — so in a fleet mixing GEC percent-controlled units (3-phase `GIV-3HY` has no `battery_charge_power` watts register; `automatic_config()` then sets `charge_rate_percent` and `build_entities()` leaves per-device `None` slots, deleting `charge_rate` when no device has the register) with watts-controlled units, a percent slot that is `None` reads quietly as 100% → `battery_rate_max_raw`, and every rate write for the power-mode sibling lands on a missing entity (`Warn: ... No entity_id for charge_rate to write ...` + `record_status(had_errors=True)`, so "Read-Only with Errors" too). The low-power rate search, which steps down relative to the read-back, then restarts from the maximum every cycle and never converges — #3311's fault extended to mixed fleets (the single-inverter shape is in the low-power symptom row). PR #4645 (open, for #3311) creates its per-slot rate dummies but does not touch these four gates — the #4908 battery-sizing read (`get_arg("charge_rate", indirect=False, index=self.id)` before falling back, inverter.py:583) is the per-entry pattern the gates lack. One API-shape trap on the site endpoint (`GE_API_SITE`, `site/{uuid}`, added for PR #4978): the published OpenAPI spec types `limits.import`/`limits.export` as a string with a null example and never shows a populated one, so the shape had to be learned from live accounts. A populated limit is `{'enabled': bool, 'power': {'watts': int, 'amps': float}}`, and **`enabled` is the thing that matters** - a site describes its connection's declared capacity in exactly the same structure as a curtailment, marked disabled, so `power.watts` alone tells you nothing about whether anything is being restricted. Site 64744 gave `{'import': {'enabled': False, 'power': {'watts': 46000, 'amps': 200}}, 'export': {'enabled': True, 'power': {'watts': 4500, 'amps': 19.6}}}` - a 200A supply whose export really is curtailed to 4.5kW - while site 46714's disabled 6kW export is its declared capacity and no restriction at all. A fleet survey confirmed the flag across accounts, so only an enabled limit is applied; an enabled zero is a real zero-export connection. A site with no limit reports a null import/export. For a fleet survey use `GET /v1/site`, the list endpoint, which returns every site's `limits` and the inverters under it (with `info.max_discharge_rate`) in one response - no second call per site. Two GEC triage tools and one clobber trap (GH#5017). The component publishes an entity for every `/settings` entry with no name filter (`async_get_inverter_settings()`/`publish_registers()`, `regname_to_ha()` is plain lowercasing), so **absence of an entity in the reporter's debug yaml is proof the API never listed the register** — "the app can control it" does not imply the settings API exposes it, because the app/GivTCP write via local control paths rather than the `/settings` list (a GIV-3HY-20 had slot 1/2 lower-SoC registers absent while 3..10 existed). Caveat: the settings list is fetched once per process start (`register_list` cache) and only the parsed flags are logged, so the debug yaml is the only observable. To capture the raw register list, `python3 apps/predbat/gecloud.py --api-key <key> --write-entity number.probe_nothing 0` makes `test_gecloud_direct()` print the full "Available entities/registers" list with raw cloud names and setting IDs and performs no write — but the harness's startup pass also runs `enable_default_options()` against the real inverter (floors reset, unused windows zeroed), so say so when asking a user to run it. Clobber trap: the missing-feature branch `set_arg("discharge_target_soc", None)` *deletes* the key, including an explicit apps.yaml entry the user wrote; `set_arg_auto(..., overwrite=False)` (component_base.py) is the in-repo pattern for letting an explicit value win — check the `has_*` detection branch on any "automatic config deleted my setting" report. The `inverter_mode` half of this class was fixed in PR #5059 (`885c637d`) — it now binds via `set_arg_auto(..., overwrite=False)` like `export_limit` — but the other missing-feature deletes are still plain `set_arg(..., None)` on main: `pause_mode`, `pause_start_time`, `pause_end_time`, `discharge_target_soc`, `charge_rate_percent`, `discharge_rate_percent`, `givtcp_rest`. A companion test-fidelity trap (GH#5056, verified on main): the component test mocks (`MockBase.set_arg` in `test_ge_cloud.py`; same shape in `test_ohme.py` and `test_alphaess_api.py`, whose mock `set_arg_auto` also writes unconditionally) store the value instead of mirroring the real `set_arg()`'s None-deletes, and their `args_from_apps_yaml` is empty so `set_arg_auto()` falls through to the plain path — so the "feature not detected" assertions (`config_args.get(...) is None`) pass identically whether the code stored None or deleted the key, and a green suite cannot distinguish fixed from unfixed. Any test for this class must populate `args_from_apps_yaml` and assert the manual value survives — #5059's Test 10 in `test_ge_cloud.py` is now the in-repo precedent. And the deeper half of GH#4909 (still live): the 3-phase GEC class exposes **no** eco/demand/mode register in `inverter/{sn}/settings` — verified by enumerating the `predbat_gecloud_*` entities in the reporter's debug dump — yet the `GEC` def sets `has_ge_eco_toggle: True` unconditionally (`config.py`) and auto-config maps `inverter_mode` via `build_entities("switch", ["enable_eco_mode"])` (gecloud.py), which emits nothing when the register is missing, so `adjust_inverter_mode()` logs `No entity_id for ECO Toggle` and returns without writing every plan cycle and freeze export silently no-ops (force-discharge paths work fine). Fix wrinkle for the maintainer: the flag is one per-inverter-type bool while `build_entities` works per-device. The freeze-export half of the same class (GH#5082, follow-up to GH#4909, code-verified on main): `inv_has_timed_pause` is probed at runtime (inverter.py flips it False when the `pause_mode` entity is absent/unavailable) but `inv_support_discharge_freeze` is read only from the static `INVERTER_DEF` entry (`config.py` sets it True for GEC), so `execute.py` never force-disables `set_export_freeze` for the eco-less/pause-less 3-phase class and a freeze-export plan can never be executed. Check both flags on any "freeze silently didn't work on GEC" report - and do not grep only for `No entity_id for ECO Toggle`: that warning comes from the eco branch, while freeze export on this class fails primarily through the pause/rate branch, so the eco warning being absent says nothing about the freeze path. Fix direction: mirror the `inv_has_timed_pause` presence-probe; the manual-freeze-export override path already degrades correctly when `set_export_freeze` is False (plan.py drops to demand). Hardware-reported on the GIV-3HY class: `charge_power_rate` limits AC (grid) charging only - `battery_power` stays at the full discharge figure while the charge register reads 1% - so the `adjust_charge_rate(0)` fallback in the freeze branch is a no-op for PV charging there; note `charge_discharge_with_rate` is False for GEC, so the first `adjust_charge_rate(0)` in each branch is skipped and the write only happens via the `has_timed_pause`-else fallback. Fix precedent for building a freeze from registers the device actually has: `inv_support_feedin_first` + Fox Cloud freeze export (PR #5038); the GIV-3HY exposes `enable_force_discharge` + `discharge_down_to_percent` + `battery_reserve_percent`, the raw material for the #4909/#5082 option-2 freeze. And since #5056 a manual `inverter_mode` apps.yaml override is silently deleted by automatic config, so "just map the eco toggle manually" is not currently viable either. The neighbouring **charge-side** gap (GH#5040: `scheduled_charge_enable` had no `enable_force_charge` candidate, so a 3-phase GEC that gates timed grid charge behind both charge switches logged real charge states while importing nothing) is **fixed in PR #5042** (`a7121135`, v9.0.2): auto-config now binds `scheduled_charge_enable` to `enable_force_charge` with `ac_charge_enable`/`enable_ac_charge` as fallbacks, and `enable_default_options()` holds `enable_ac_charge` on as a static enable when the force register exists. Keep the mechanism for pre-v9.0.2 logs, where the signature is a 3-phase GEC showing plan charge states against flat grid power with no warning anywhere. The #5042 gate itself had a second gap (**GH#5269, fixed in PR #5270, merged 2026-09-27** — keep the pre-#5270 signature): `enable_ac_charge` was written in exactly one place, `enable_default_options()` — first cycle after start-up, then once per 24h (`default_options_stamp`) — while Predbat's own `scheduled_charge_enable` write (`switch_event()`) checked nothing about the gate, so any external writer (an Axle VPP clean-up, the GE app, another integration) could clear `enable_ac_charge` and Predbat re-asserted it only on that 24h pass or a restart; "restarted and it worked" is part of the pre-fix signature, as is `enable_force_charge` on with `Charging target …%` for hours, SoC flat and no error. #5270 re-asserts the gate from `switch_event()` when a force-charge write succeeds (`ensure_ac_charge_gate`, with Axle's clean-up read as read-only for the 24h pass and a binding guard), so the "gate cleared between cache refreshes" residual window is the remaining maintainer call on that fix. So "3-phase GEC plans a charge, status says Charging, battery imports nothing" now has **two** signatures: pre-v9.0.2 = never bound (#5040), v9.0.2+ pre-#5270 = externally cleared and not re-asserted (#5269); on a post-#5270 system check whether the force switch Predbat drove is actually the `enable_force_charge` register. GE Cloud EMS plants (GH#5103, **fixed in PR #5109, merged 2026-09-24** — keep the mechanism for pre-#5109 logs): with an EMS discovered `polling_mode` is set False (`gecloud.py`), and the settings refresh used to re-read each battery inverter's `/settings` only on the first tick of the process — so the AC3 registers, including the DC-discharge slot windows, were read once and published stale for the rest of the run, while live status/meter polling kept looking normal. #5109 re-reads settings hourly (`SETTINGS_SLOW_REFRESH_SECONDS`, `gecloud.py`), refreshes the EMS and gateway devices every cycle, and runs `check_ems_inverter_slots()` on every snapshot — which now *warns* when a battery inverter's slot 1 is not the full-day window (the #3781 rule: `Inverter X slot 1 is not 00:00-23:59 ... it will override the EMS and can stop charging or discharging early`), once per episode — recorded in `ems_slot_warned` so a standing misconfiguration does not inflate the error counter on every refresh, so the non-00:00–23:59 slot 1 fault is a visible warning on current main and silent only pre-#5109 (pre-fix signature: plan/status look right but the batteries hold 0 W past a fixed wall-clock time every night). Under EMS auto-config Predbat still writes mode/schedule-enable/rates to the AC3s. Nuance: the startup read itself can still be skipped when the storage settings cache is under 10 minutes old (`settings_from_cache`), so even a restart is not guaranteed to re-snapshot the registers. **The option-validation parser used to crash-loop the whole component (GH#5217, fixed in PR #5218, merged 2026-09-26 — keep the signature for pre-#5218 logs):** `select_event()` and `publish_registers()` both `split("(")` a cloud `Value must be one of: (...)` string, so an option label containing `(` raised `ValueError: too many values to unpack (expected 2)` — the component does not die (`ComponentBase.start()` catches it), it *crash-loops*: `api_started` never set, automatic config never runs, no plan, `Error: GECloudDirect: too many values to unpack (expected 2)` every cycle. #5218 added the module-level `parse_validation_options()` (`gecloud.py`): split on the first `(` and strip only the final `)` (so inner brackets in labels survive), and `None` for a string with no `(` triggers a warning and falls back to the setting's `in:` validation-rule options instead of raising — the paren-less guard is required, not optional, because `split("(", 1)` alone fails the other direction. Which GE Cloud setting actually returns a multi-`(` validation string was never captured (the storage cache saved at the settings write would be the fixture to ask for). **`refresh_discovery()` is not device re-discovery, and GE Cloud re-discovers hourly since PR #5295 (GH#5294, merged 2026-09-29 - the symbols below were read against the pre-fix tree):** `ComponentBase.refresh_discovery()` only rebuilds the capability-catalogue *report* from data already in hand (a component opts in via `build_discovery()`) and never calls the component's API - the *similarly named* `refresh_devices()` is the thing that calls it. Pre-#5295 that device discovery (`async_get_devices()`, EV chargers, EMS/gateway selection, one-shot automatic config) ran exactly once inside `if first:` and `first` flips off permanently after the first successful run, so on any "GE Cloud didn't pick up my new inverter/charger" or "removed inverter still shows data" report a restart was the only mechanism - and a removed device kept its last good SoC/power feeding the plan (`merge_non_null()` hands back the previous reading on nulls and failed polls) and kept having registers written to. **Post-#5295:** `refresh_devices()` re-reads the device list hourly (`DEVICE_REFRESH_SECONDS`, 60*60, `gecloud.py`; a multiple of 60 because `run()` is called once a minute, and a cycle that finds a change polls and reads settings whatever else is due), `select_poll_devices()`/`apply_devices()` decide what is polled from the fresh list, and adopting a changed set drops every per-device store - `status`, `meter`, `info`, `settings`, `pending_writes`, `register_list`, the EV-charger stores, `ems_slot_warned` and `register_entity_map` - so a removed device stops publishing and being written to. The review round also: the change signature includes `battery_meters`, so a CT rewiring re-runs automatic config; a failed register-list fetch is retried on the next settings read (previously stored as `None` and never fetched again - every later read raised `TypeError`, newly reachable from rediscovery); a device read that would leave zero battery inverters is not adopted (the warning says restart if the hardware really was removed; charger-only sites stay quiet); `ge_cloud_data` returns to its pre-EMS value when the EMS leaves; the EMS slot-override warning re-arms when the EMS changes; and default options for a device discovered while read-only is set stay pending across cycles, applied once read-only ends. Caveats that survive the fix: the 5-day `last_updated` skip inside `async_get_devices()` treats a device silent over 5 days as non-functional wherever that runs - the hourly re-read included - and `merge_non_null()` still hands a *polled* device its last good SoC/power on nulls and failed polls. In-tree fix precedents (GE Cloud itself now among them): Fox re-fetches its device list every 24h (`FOX_REFRESH_STATIC`), SolaX gates plant/device-info re-reads with `data_is_due`, and `num_inverters` is re-read by the core every cycle so a re-run automatic config takes effect next plan. **The "disable" writes on the unused numbered slots leave them live (GH#5371, reporter field log from a GIV-3HY-11 Beta site, code-verified on main):** `enable_default_options()` - run at startup, once per 24h and on newly-found devices, gated only by `read_only_now()` so manual-config GEC sites get the resets too - writes every unused AC-charge and DC-discharge slot 2-10's **times** to `00:00` "to disable" (`gecloud.py`, the numbered-slot branch of the limit/time resets), and on 3-phase GIV-3HY hardware `00:00-00:00` is **live** 00:00:00-00:00:59 (minute bounds), so every "disabled" unused slot is live for one minute past midnight; with force charge on at that minute (a planned charge window spanning midnight, or the v9.1.0 stuck-on case) the unused slots fire at full rate toward their 100% upper limit (discharge mirror: full rate toward the 4% lower floor). The same pass overwrites user-set spare-slot times (the 03:00 workaround) once per pass, per the reporter's inverter-settings history log. Fix direction (maintainer's call): have the **limits** carry the disable instead (unused slots' upper→4%/reserve floor, lower→100%); the constraint is that the two generic limit branches (`*_lower_soc_percent_limit`→4%, `_upper_soc_percent_limit`/`ac_charge_upper_percent_limit`→100%) also match the numbered slots and would write straight back on the next pass, so the fix must special-case slots 2-10 inside those branches - and #5017's outcome could later drive exports through slot 3 on GIV-3HY, so the "unused" set needs a guard there. `test_ge_cloud.py`'s 00:00-reset tests stay valid under this; the fix needs numbered-slot limit assertions added. | `ge_cloud` | | |||
| | Teslemetry / Powerwall (`teslemetry.py`) | Battery model is inferred from site `nameplate_power / battery_count`. A nameplate fallback combined with `inverter_hybrid: True` once produced a false 5 kW inverter limit and spurious morning export. Tariff writes push a whole TOU schedule every cycle, so a setting changed by hand in the Tesla app is reverted on the next cycle (GH#4600, GH#4610). Three later findings. `build_tariff()`/`_render_side` carve a *single* ON_PEAK interval priced with one scalar (`teslemetry.py:1117`/`:1036`/`:1074`), so no intra-window price gradient can exist and Tesla's own TBC is free to defer the whole export to the end of the window; the no-rate-data fallback branch also skips the boost entirely (GH#4887). The charge path sends no rate at all - `evaluate_schedule` (`teslemetry.py:539`) asserts mode `backup` plus reserve = charge target plus grid charging - so a slow charge ramp is Tesla firmware, not a Predbat write bug (GH#4892); Tesla now snaps a backup reserve of 81-99% down to 80% while Predbat still forwards any 0-100 target. The site_info limit mapping was reworked in PR #5276 (GH#5275, merged 2026-09-28): `inverter_limit` comes from `nameplate_power` (the Powerwall's own AC rating; `max_site_meter_power_ac` is the site's supply limit at the meter, not the inverter's), `export_limit` from `min_site_meter_power_ac` (kW, possibly fractional, with the ±1e9 "no limit" sentinel skipped and 0 published as a real 0 W limit), `inverter_limit_charge` at **5 kW per battery unit** capped at nameplate (Tesla reports no usable charge rating — a Powerwall 3 lists only expansion packs with every rating zero, and fleet data fits the rule), `soc_max` from the gateway's `nameplate_energy_watts` before the `battery_count` estimate, and `inverter_hybrid` now defaults from the Powerwall model (Powerwall 3 on, every other model off) with a `teslemetry_hybrid` override for a PW3 beside an existing string inverter. All of those are wired with `set_arg_auto(overwrite=False)`, so **an apps.yaml value wins** — on a pre-#5276 version `automatic_config()` overwrote a manually set `battery_rate_max` whenever `teslemetry_automatic` was on, which was the standing "my override does nothing" answer on this component. Since PR #4976 there is a Predbat-side lever for exactly that slow ramp: `teslemetry_tbc_control` — **on by default since PR #5188** (GH#5186; `DEFAULT_TBC_CONTROL = True` in `teslemetry.py`, mirrored in `COMPONENT_LIST`, with `teslemetry_tbc_control: False` as the opt-out) — switches `evaluate_schedule()` to `evaluate_schedule_tbc()`, which pushes a **signal tariff** (`build_signal_tariff()` - fixed 0/50/100p bands over the committed charge and export windows) so Tesla's own optimiser runs the charge and reaches the full rate reserve-driven charging cannot; mode goes to `autonomous` in every state, reserve becomes an actual reserve rather than a charge signal, and `_settable_reserve()` maps requests onto reserves the Powerwall honours - an 81-99% request now rounds **up** to 100 rather than being forwarded raw into the snap-to-80 band. The same PR stopped `plan.py` planning a manual freeze export on inverters that cannot do it. **Consequences of the default flip:** a Teslemetry user who never set the key is on the signal tariff with autonomous mode, so "the Tesla app shows 0p/50p/100p instead of my rates" or "my charge target isn't honoured" is the default path working, not a bug; and the 81-99% `set_reserve_min` limitation becomes default-on behaviour with it. (`MockTeslemetryAPI` still defaults `tbc_control = False` on purpose, so a green teslemetry test run exercises the real-rate path unless a test opts in.) And a separate scoping fact from the GH#5186 triage: `teslemetry_automatic` gates only `automatic_config()` — the scheduler emulator (`sync_tariff()` + `assert_device_state(evaluate_schedule(...))`) runs for every non-read-only user with no `automatic` check, so "Predbat changed my Tesla tariff/mode but I never turned on automatic" is that scoping, not a bug; `set_read_only` is the only switch that stops the writes. A related pricing bug in the same `build_tariff()` family was fixed in PR #4977: an export window ending at midnight priced the whole of tomorrow at peak. And `optimization_strategy: "economics"` *is* pushed with `tariff_content_v2` on every `set_tariff()`, unconditionally, since v8.49.0 / PR #4603 - a request to "add" it is asking for something already shipped (GH#4918). **GH#5157** (reporter's evidence, not independently probed — Powerwall 2, fw 26.26.4): the unit sat in the idle branch of `evaluate_schedule` and simply stopped acting on a standing device tuple for ~4h while `site_info` read back the *correct* configuration — drift invisible to every field the API exposes, with only a Predbat restart recovering it; the stall state is the one branch Predbat legitimately holds for hours, which is why transition-based self-heal never fires. A "Powerwall plateaued / stopped discharging until I restarted Predbat" report maps here first. **Implemented on main** (2026-09-19): `run()` re-asserts the whole device tuple — export rule, grid charging, reserve, mode, not the tariff — every `FORCED_ASSERT_SECONDS` (2h) with the write-on-change dedupe bypassed (`force=True`), the timer advancing only on a fully successful forced assert; the Info line `Teslemetry control drift-correction is transition-based ..., backed by a forced re-assert of the full device tuple every 120 minutes` names it, so on current main the stall is bounded at ~2h. **Freeze export is fully implemented in the planner and disabled for TESLA at exactly one point (GH#5225, enhancement):** `INVERTER_DEF["TESLA"]` declares `support_discharge_freeze: False` (`config.py`), read into `inv_support_discharge_freeze` (`inverter.py`), whose only consumer is the first-inverter lockstep block in `execute.py` that force-disables `set_export_freeze`/`set_export_freeze_only` (`Note: Inverter does not support discharge freeze - disabled`) — `EXPORT_MODE_FREEZE` never enters the export ladder, and PR #4976 additionally drops manual freeze-export windows to demand with a Warn. **Flipping the flag alone is not enough:** the component must also map the freeze-target discharge window to a device-side hold, or the plan's freeze assumption fails on the device — the non-TBC `evaluate_schedule()` writes the *raw* discharge target as the reserve, so a 99 target lands in the 81-99 band Tesla silently snaps to 80 (`_settable_reserve()` exists for exactly that and the non-TBC path doesn't route through it), while the default-TBC `evaluate_schedule_tbc()` discharge branch yields `pv_only` with the standing reserve but no hold — the battery still serves house load and drifts down. The device primitive exists in-tree: the TBC charge-hold tuple (`pv_only` + reserve 100 + grid charging off + autonomous) holds the battery while PV surplus exports, but a freeze *export* hold must sit at the current SoC (reserve at/above SoC through `_settable_reserve()`), not 100 — reserve 100 lets solar recharge the battery instead of exporting the surplus. Every `INVERTER_DEF` entry with `support_discharge_freeze: False` (the cloud-emulator types: SunsynkCloud, AlphaESSCloud, DeyeCloud, SolaxCloud, SolisCloud…) shares this two-part requirement — capability flag **plus** device-side freeze mapping — so enabling freeze export on any of them is a two-file change, not a one-line flag flip; each component's schedule emulator needs its own hold tuple designed against what its hardware honours (*suspected*, not verified per component). | `teslemetry` | | |||
| | Sunsynk / DEYE (`sunsynk.py`, `deye.py`) | Freeze export is gated by the per-slot power register (`sellTime{n}Pac` on Sunsynk), confirmed on live hardware — setting the energy mode alone had no effect, and with slot power at zero the battery still charged. `read_only` was ignored by the reconcile loops until `_is_read_only()` gated `_reconcile_control()` (GH#4436). DEYE cloud telemetry keys are one hardcoded spelling per metric — `DEYE_TELEMETRY_KEYS["pv_power"] = "TotalSolarPower"` (`deye_const.py`), confirmed against a single live 3-phase hybrid — and a SUN-8K-SG05LP1-EU-AM2-P instead exposes `TotalDCInputPower` + `DCPowerPV1/2/3`, neither anywhere in the tree. Because `pv_power` is in `DEYE_TELEMETRY_REQUIRED`, the miss fires the `device/latest missing expected keys [...] - telemetry will read zero` warning every cycle and the Cloud PV sensor publishes 0.0 while a manual `pv_power` arg to a local sensor may still protect the planner. Reproduced by swapping the test fixture's single PV key (`tests/test_deye_api.py` `LIVE_DATA_LIST`). Whether the alternate key is unit-equivalent (vs summing `DCPowerPV1-3`) needs a live capture from an affected model — suspected, not verified. CONFIRMED live (Sunsynk 2211093089, 2026-09-19, via `sunsynk.py --tou-test`) that the settings object exposes the TOU register block a SECOND time under unrelated names, so several keys that read like independent settings are the same memory at a different scale: `volt1`-`volt4` are `sellTime3`-`sellTime6` as minutes-since-midnight / 50, `volt5`-`volt10` are `sellTime1Pac`-`sellTime6Pac` / 10, and `volt11`, `volt12`, `current1`-`current4` are `sellTime1Volt`-`sellTime6Volt` x 10 — a contiguous 16-value window, matched 16/16 in both the before and after reads of one write. Two consequences. It is independent proof a TOU write reached the real registers rather than a cloud-side echo, which is the cheapest hardware verification available. And it is a trap: anything that wrote `volt*`/`current*` would silently corrupt the charge programme. Predbat is safe today only because `SUNSYNK_SYSTEM_MODE_FIELDS` excludes them, so treat that exclusion as load-bearing rather than incidental. The alias does NOT extend to what the write payload must contain — `time{n}On` (capital O) is a derived echo of `time{n}on` and is correctly excluded via `SUNSYNK_DERIVED_SLOT_FIELDS`. **GH#5138**: the (pre-#5360 wording) `control cache is X minutes old (limit 15)` forced-rewrite check is **startup-only** - it lives in `restore_state()`, called only from `run()`'s `if first:` block - so a reporter reading `limit 15` as "rechecks every 15 minutes" is wrong; it never runs again after the first cycle. The issue's core premise (idle slots never clear `sellTime{n}En`) was disproved: every slot `_owned_payload` write carries an explicit sell flag, idle slots are written with `sell: 0`, and the TOU build places a sell-0 baseline segment at each window's end (probe-verified; a `sellTime5En: 1` read-back just after an export window can be *correct*). The real gap it exposed - a write the cloud API acknowledged but the dongle never collected was trusted forever, because the owned-field change gate suppresses identical re-sends and `note_settle` only warned - is **fixed in PR #5142 (merged 2026-09-19)**: sustained settle divergence now clears `applied_payload[sn]` so the next write cycle re-applies. Keep the mechanism for pre-#5142 logs, where a stuck export slot needed a restart to clear. No debug yaml was ever attached, so the reporter's exact overrun is unconfirmed; the `has not applied Predbat's settings after N settings polls` warning is the tell. Two component-side traps since. **PR #5150** (merged 2026-09-19): `control_active` is now persisted and restored alongside `applied_payload` under the same 15-minute bound (`SUNSYNK_RESTORE_MAX_CONTROL`/`DEYE_RESTORE_MAX_CONTROL`), so a restart **inside** the bound no longer strands an armed inverter in silence; on the upgrade path a cache carrying `applied_payload` with no `control_active` key infers the missing half from the payload keys — a safe lower bound, since `applied_payload[sn]` is written only by `apply_settings`/`apply_dynamic_control`, whose production callers arm `control_active` first (the CLI paths apply with `force=True` and never save). **PR #5360 (merged 2026-10-05, unreleased at the time of writing, fixes GH#5349 below) has since split the two halves into separate caches with separate bounds:** `applied_payload` keeps the 15-minute bound (`SUNSYNK_RESTORE_MAX_CONTROL`/`DEYE_RESTORE_MAX_CONTROL`) while `control_active` gets 8 hours (`SUNSYNK_RESTORE_MAX_CONTROL_ACTIVE`/`DEYE_RESTORE_MAX_CONTROL_ACTIVE`, in a cache of its own, with a migration path from the pre-#5360 combined cache), and the restore log line splits to match - `Info: Sunsynk control payload cache is X minutes old (limit 15), forcing a rewrite` drops only the payload cache; a new `Info: Sunsynk control ownership cache is X minutes old (limit 480), requiring a fresh write` is the one that drops the ownership half. And the in-code comment on the Sunsynk write-button handler claiming Predbat "presses this on every cycle" is wrong about frequency: both press sites in `inverter.py` are change-gated (target SoC presses only when `current_soc != soc`, the export window only when `schedule_changed`), and the one unconditional post-restart re-commit is `is_hm_format`-only, which excludes these types' `HH:MM:SS` — so after a restart with the plan already matching the inverter, nothing is pressed for hours. Read the press gates in `inverter.py` before using that comment to dismiss a "component stopped writing after a restart" report. **GH#5349 (2026-10-02, fixed in PR #5360, merged 2026-10-05 - keep the mechanism for pre-#5360 logs) joined the two halves end to end:** on a pre-#5360 build an HA outage restarted Predbat with the (single) control cache 35.9 minutes old, restore dropped both `applied_payload` and `control_active`, and **nothing performed the forced rewrite on its own** - `_reconcile_control()` gates on `control_active`, `number_event` reaches Predbat only as in-memory `update_local_schedule()` updates (no apply), and both press sites stayed change-gated - so zero settings POSTs fired from 00:59 to 03:02 (counted from the reporter's full-API-logging log) while the hold re-armed every cycle and the inverter's idle-cap-5 programme drained ~9 kWh into the EV until a plan change finally pressed the write-button at 03:02. #5360 closes it by keeping `control_active` for 8 hours (see above), so the reconcile path can own the re-apply within that window. Reading the "forcing a rewrite" line as if a rewrite follows is still the trap - it is the notice that the payload cache was **dropped**; a "holds lost for hours after an HA blip / battery drained while Predbat showed holds armed" report on a pre-#5360 (v9.3.5-) build maps here, and on post-#5360 builds the `has not applied Predbat's settings after N settings polls` settle path is the remaining backstop. Device-visible hold legs on these types (same log): the TOU slot cap is the only one — a hold is `cap = SoC+1` in the programme (cap 65 held the battery at 64% while the car drew from grid; cap 5 drained it toward the inverter floor), and the `discharge_rate 0` entity write is symbolic on this type, so a "wrote 0 to discharge_rate but the battery drained" report reads the cap, not the entity. Also normal for this type: Sunsynk TOU charge windows cannot cross midnight (`can_span_midnight: False`) — a 23:00–00:30 window is written 23:00–23:59 and re-rolled to 00:00–00:30 at midnight (log-confirmed; not a bug). **GH#5156** (padding truncating any TOU window crossing 04:00/08:00/12:00, `build_tou_slots()` — now shared by both components in `tou_schedule.py`) is **fixed**: padding slots now carry the state of the slot they follow and sit just after it, an inert interval that cannot end a window early (`_padding_segments()` documents the issue). The pre-fix tell was "Deye stops charging at 00:00/04:00/08:00/12:00/16:00/20:00 while the Plan page still shows charging", freshly generated each cycle — not a stale default slot. **GH#5193 (cloud component, load telemetry):** on Sunsynk M3.3.8.9 the `totalPower` field (`load_power`, `SUNSYNK_TELEMETRY`) read 0–100 W through a whole overnight cycling stretch while the battery was active — including mode-2 ("Limited to Home") stretches — and read plausibly the adjacent morning with the battery idle, so the collapse correlates with the battery being active, not cleanly with the work mode; what gates it is unresolved (suspected; the reporter's manual A/B blamed the mode flip, the log's mode-2 stretches say something else does too — a controlled live test on the affected firmware is the only settle). `dailyUsed` (`load_today`) kept counting at a plausible coarse rate through the same stretch, so a balance-derived load remains feasible — and `fill_load_from_power()` is the repair that gets nothing while `totalPower` is zero. Predbat's own export control writes the whole-system `sysWorkMode` to `selling_first` for every planned export window (`derive_control_state()`, applied in the settings payload), and the component auto-wires both load args through `set_arg_auto()`'s default `overwrite=True`, so a manual apps.yaml override does NOT win — only `sunsynk_automatic: False` opts out. The in-file docstring on main records the mode/battery-export reading plus the live counter-evidence (11.1 kWh exported in a day under "Limited to Home" with `solarSell` on; a separate live test showed battery export under mode 2 with the per-slot sell flag), so the docstring's "the mode governs battery export" claim is DEYE-inferred and not settled — a control-side alternative (stay in mode 2, drive `sellTime{n}En`) stays open. The component logs every API request/response in full in `predbat.log`, so a whole Sunsynk-cloud investigation can run from the log alone; when mining logged JSON widen the field width before trusting a truncated number (`0.4` prints as `0.` under a 14-char `substr`). **Automatic config maps a battery-side current into `battery_rate_max`, and `inverter_limit` does not bound the written rate (GH#5238, code-read on main 2026-09-25/29):** `battery_rate_max()` derives watts from `chargeCurrentLimit`/`maxChargeCurrentLimit` × nominal pack voltage (`SUNSYNK_CHARGE_CURRENT_FIELDS`, first-positive-wins — a battery/BMS-side limit; GH#5238's 280 A BMS derived 14.3 kW against an 8 kW inverter), `automatic_config()` maps it to `battery_rate_max` and `ratePower` to `inverter_limit` but **never sets `inverter_limit_charge`/`inverter_limit_discharge`**, and `inverter.py` defaults both of those to `battery_rate_max_raw` when unset — so `battery_rate_max_charge = min(raw, raw) = raw`, and that is the per-slot power the plan writes. `prediction.py` clamps only *predicted* flow to `inverter_limit`; nothing feeds `inverter_limit` into the written rate. `deye.py`'s `battery_rate_max()` docstring states the same wrong assumption outright ("inverter_limit constrains the AC side separately" while deriving from `maxChargeCurrent`), and its `automatic_config()` has the same two-arg shape — so treat any "automatic config shows/writes an impossible rate" report for a cloud component through this lens first, and a fix has to map `inverter_limit_charge`/`_discharge` (to `min(ratePower, derived battery rate)`); deriving the true inverter-side current setting needs a telemetry mapping Sunsynk does not currently expose. Workaround semantics: `inverter_limit_charge`/`inverter_limit_discharge` are safe apps.yaml overrides under `sunsynk_automatic` (the component never sets them), while `battery_rate_max` is not — `set_arg_auto(overwrite=True)` clobbers an apps.yaml value every cycle. | `sunsynk_control`, `deye_control` | | |||
| | Sunsynk / DEYE (`sunsynk.py`, `deye.py`) | Freeze export is gated by the per-slot power register (`sellTime{n}Pac` on Sunsynk), confirmed on live hardware — setting the energy mode alone had no effect, and with slot power at zero the battery still charged. `read_only` was ignored by the reconcile loops until `_is_read_only()` gated `_reconcile_control()` (GH#4436). DEYE cloud telemetry keys are one hardcoded spelling per metric — `DEYE_TELEMETRY_KEYS["pv_power"] = "TotalSolarPower"` (`deye_const.py`), confirmed against a single live 3-phase hybrid — and a SUN-8K-SG05LP1-EU-AM2-P instead exposes `TotalDCInputPower` + `DCPowerPV1/2/3`, neither anywhere in the tree. Because `pv_power` is in `DEYE_TELEMETRY_REQUIRED`, the miss fires the `device/latest missing expected keys [...] - telemetry will read zero` warning every cycle and the Cloud PV sensor publishes 0.0 while a manual `pv_power` arg to a local sensor may still protect the planner. Reproduced by swapping the test fixture's single PV key (`tests/test_deye_api.py` `LIVE_DATA_LIST`). Whether the alternate key is unit-equivalent (vs summing `DCPowerPV1-3`) needs a live capture from an affected model — suspected, not verified. CONFIRMED live (Sunsynk 2211093089, 2026-09-19, via `sunsynk.py --tou-test`) that the settings object exposes the TOU register block a SECOND time under unrelated names, so several keys that read like independent settings are the same memory at a different scale: `volt1`-`volt4` are `sellTime3`-`sellTime6` as minutes-since-midnight / 50, `volt5`-`volt10` are `sellTime1Pac`-`sellTime6Pac` / 10, and `volt11`, `volt12`, `current1`-`current4` are `sellTime1Volt`-`sellTime6Volt` x 10 — a contiguous 16-value window, matched 16/16 in both the before and after reads of one write. Two consequences. It is independent proof a TOU write reached the real registers rather than a cloud-side echo, which is the cheapest hardware verification available. And it is a trap: anything that wrote `volt*`/`current*` would silently corrupt the charge programme. Predbat is safe today only because `SUNSYNK_SYSTEM_MODE_FIELDS` excludes them, so treat that exclusion as load-bearing rather than incidental. The alias does NOT extend to what the write payload must contain — `time{n}On` (capital O) is a derived echo of `time{n}on` and is correctly excluded via `SUNSYNK_DERIVED_SLOT_FIELDS`. **GH#5138**: the `control cache is X minutes old (limit 15)` forced-rewrite check is **startup-only** - it lives in `restore_state()`, called only from `run()`'s `if first:` block - so a reporter reading `limit 15` as "rechecks every 15 minutes" is wrong; it never runs again after the first cycle. The issue's core premise (idle slots never clear `sellTime{n}En`) was disproved: every slot `_owned_payload` write carries an explicit sell flag, idle slots are written with `sell: 0`, and the TOU build places a sell-0 baseline segment at each window's end (probe-verified; a `sellTime5En: 1` read-back just after an export window can be *correct*). The real gap it exposed - a write the cloud API acknowledged but the dongle never collected was trusted forever, because the owned-field change gate suppresses identical re-sends and `note_settle` only warned - is **fixed in PR #5142 (merged 2026-09-19)**: sustained settle divergence now clears `applied_payload[sn]` so the next write cycle re-applies. Keep the mechanism for pre-#5142 logs, where a stuck export slot needed a restart to clear. No debug yaml was ever attached, so the reporter's exact overrun is unconfirmed; the `has not applied Predbat's settings after N settings polls` warning is the tell. Two component-side traps since. **PR #5150** (merged 2026-09-19): `control_active` is now persisted and restored alongside `applied_payload`; **PR #5360 (merged 2026-10-05, fixes GH#5349) then split the bounds — keep the single-15-minute-bound reading for pre-#5360 (≤ v9.3.5) logs** — with `applied_payload` restoring only when its cache is ≤15 minutes old (`SUNSYNK_RESTORE_MAX_CONTROL`/`DEYE_RESTORE_MAX_CONTROL`) and `control_active` (the reconcile gate) when ≤ **8 hours** old (`SUNSYNK_RESTORE_MAX_CONTROL_ACTIVE`/`DEYE_RESTORE_MAX_CONTROL_ACTIVE`), so a restart **inside** the bound no longer strands an armed inverter in silence; on the upgrade path a cache carrying `applied_payload` with no `control_active` key infers the missing half from the payload keys — a safe lower bound, since `applied_payload[sn]` is written only by `apply_settings`/`apply_dynamic_control`, whose production callers arm `control_active` first (the CLI paths apply with `force=True` and never save). And the in-code comment on the Sunsynk write-button handler claiming Predbat "presses this on every cycle" is wrong about frequency: both press sites in `inverter.py` are change-gated (target SoC presses only when `current_soc != soc`, the export window only when `schedule_changed`), and the one unconditional post-restart re-commit is `is_hm_format`-only, which excludes these types' `HH:MM:SS` — so after a restart with the plan already matching the inverter, nothing is pressed for hours. Read the press gates in `inverter.py` before using that comment to dismiss a "component stopped writing after a restart" report. **GH#5349 (live, 2026-10-02) joins the two halves end to end:** an HA outage restarted Predbat with the control cache 35.9 minutes old, restore logged `Info: Sunsynk control cache is 35.9 minutes old (limit 15), forcing a rewrite` and dropped both halves — but nothing performs that rewrite on its own: `_reconcile_control()` gates on `control_active`, `number_event` reaches Predbat only as in-memory `update_local_schedule()` updates (no apply), and both press sites stayed change-gated, so **zero settings POSTs fired from 00:59 to 03:02** (counted from the reporter's full-API-logging log) while Predbat re-armed the hold every 5-minute cycle (reserve chasing SoC+1) and the inverter ran its 00:59 programme's idle-cap-5 slots, draining ~9 kWh (82% → 24%) into the EV until a charge-window plan change finally pressed the button at 03:02 — recovery then ran #5142's settle detection (`Warn: Sunsynk ... has not applied Predbat's settings after 4 settings polls`, fired at 03:59) and re-applied. Reading the "forcing a rewrite" line as if a rewrite follows is the trap: it is the notice that the cache was **dropped**. So a "holds lost for hours after an HA blip / battery drained while Predbat showed holds armed" report maps here on **pre-#5360 (≤ v9.3.5)** builds; since PR #5360 the ownership cache restores up to 8 hours old (`_restore_control_state()` re-sets `control_active` from the stored list), so a restart inside 8h re-arms the reconcile gate and reconcile re-applies the programme — keep the always-lost reading for pre-#5360 logs Device-visible hold legs on these types (same log): the TOU slot cap is the only one — a hold is `cap = SoC+1` in the programme (cap 65 held the battery at 64% while the car drew from grid; cap 5 drained it toward the inverter floor), and the `discharge_rate 0` entity write is symbolic on this type, so a "wrote 0 to discharge_rate but the battery drained" report reads the cap, not the entity. Also normal for this type: Sunsynk TOU charge windows cannot cross midnight (`can_span_midnight: False`) — a 23:00–00:30 window is written 23:00–23:59 and re-rolled to 00:00–00:30 at midnight (log-confirmed; not a bug). **GH#5156** (padding truncating any TOU window crossing 04:00/08:00/12:00, `build_tou_slots()` — now shared by both components in `tou_schedule.py`) is **fixed**: padding slots now carry the state of the slot they follow and sit just after it, an inert interval that cannot end a window early (`_padding_segments()` documents the issue). The pre-fix tell was "Deye stops charging at 00:00/04:00/08:00/12:00/16:00/20:00 while the Plan page still shows charging", freshly generated each cycle — not a stale default slot. **GH#5193 (cloud component, load telemetry):** on Sunsynk M3.3.8.9 the `totalPower` field (`load_power`, `SUNSYNK_TELEMETRY`) read 0–100 W through a whole overnight cycling stretch while the battery was active — including mode-2 ("Limited to Home") stretches — and read plausibly the adjacent morning with the battery idle, so the collapse correlates with the battery being active, not cleanly with the work mode; what gates it is unresolved (suspected; the reporter's manual A/B blamed the mode flip, the log's mode-2 stretches say something else does too — a controlled live test on the affected firmware is the only settle). `dailyUsed` (`load_today`) kept counting at a plausible coarse rate through the same stretch, so a balance-derived load remains feasible — and `fill_load_from_power()` is the repair that gets nothing while `totalPower` is zero. Predbat's own export control writes the whole-system `sysWorkMode` to `selling_first` for every planned export window (`derive_control_state()`, applied in the settings payload), and the component auto-wires both load args through `set_arg_auto()`'s default `overwrite=True`, so a manual apps.yaml override does NOT win — only `sunsynk_automatic: False` opts out. The in-file docstring on main records the mode/battery-export reading plus the live counter-evidence (11.1 kWh exported in a day under "Limited to Home" with `solarSell` on; a separate live test showed battery export under mode 2 with the per-slot sell flag), so the docstring's "the mode governs battery export" claim is DEYE-inferred and not settled — a control-side alternative (stay in mode 2, drive `sellTime{n}En`) stays open. The component logs every API request/response in full in `predbat.log`, so a whole Sunsynk-cloud investigation can run from the log alone; when mining logged JSON widen the field width before trusting a truncated number (`0.4` prints as `0.` under a 14-char `substr`). **Automatic config maps a battery-side current into `battery_rate_max`, and `inverter_limit` does not bound the written rate (GH#5238, code-read on main 2026-09-25/29):** `battery_rate_max()` derives watts from `chargeCurrentLimit`/`maxChargeCurrentLimit` × nominal pack voltage (`SUNSYNK_CHARGE_CURRENT_FIELDS`, first-positive-wins — a battery/BMS-side limit; GH#5238's 280 A BMS derived 14.3 kW against an 8 kW inverter), `automatic_config()` maps it to `battery_rate_max` and `ratePower` to `inverter_limit` but **never sets `inverter_limit_charge`/`inverter_limit_discharge`**, and `inverter.py` defaults both of those to `battery_rate_max_raw` when unset — so `battery_rate_max_charge = min(raw, raw) = raw`, and that is the per-slot power the plan writes. `prediction.py` clamps only *predicted* flow to `inverter_limit`; nothing feeds `inverter_limit` into the written rate. `deye.py`'s `battery_rate_max()` docstring states the same wrong assumption outright ("inverter_limit constrains the AC side separately" while deriving from `maxChargeCurrent`), and its `automatic_config()` has the same two-arg shape — so treat any "automatic config shows/writes an impossible rate" report for a cloud component through this lens first, and a fix has to map `inverter_limit_charge`/`_discharge` (to `min(ratePower, derived battery rate)`); deriving the true inverter-side current setting needs a telemetry mapping Sunsynk does not currently expose. Workaround semantics: `inverter_limit_charge`/`inverter_limit_discharge` are safe apps.yaml overrides under `sunsynk_automatic` (the component never sets them), while `battery_rate_max` is not — `set_arg_auto(overwrite=True)` clobbers an apps.yaml value every cycle. | `sunsynk_control`, `deye_control` | | |||
| @@ -113,13 +113,13 @@ Grep for the named symbol rather than trusting a line number. | |||
| | HA write/verify (`ha.py`, `inverter.py`) | `get_state(refresh=True)` is a no-op in a normal HA add-on install: it only re-reads when `not self.ha_key`, and `ha_key` is set in that case, so verification reads the websocket cache, never a fresh value (`ha.py:798`, since PR #2342). Separately, `write_and_poll_value()` treats `domain == "sensor"` as Predbat-owned and POSTs `/api/states/<entity>` directly (`inverter.py:2155`, `ha.py:1071-1077`) instead of calling the integration. Probed empirically across all four write-path/domain combinations (GH#4738): a control entity that resolves to a `sensor.*` domain by mistake gets a direct state overwrite that reads back as success, with zero corresponding lines in the real integration's log. `call_service_wrapper()`'s return value used to be discarded at every `inverter.py` write site, so a rejected HA service call (e.g. a Modbus "Illegal Function" error) never reached the verify logic. That is no longer true everywhere: PR #4878 made `call_service_template()` check it (`inverter.py:2817`) and log "was not accepted, it will be retried next cycle". The other eleven `call_service_wrapper()` call sites in that file still discard it, so check the specific write path before repeating the general claim. Later triage extended this row rather than replacing it. `write_and_poll_switch()` builds its service name as `domain + "/turn_..."` straight from the entity's own domain with no validation (`inverter.py:2102`), and `adjust_inverter_mode()` routes every `has_ge_eco_toggle` inverter through it - so an `inverter_mode` pointed at a `select.*` entity produces `select.turn_on`, an HA-invalid service retried 10x at 10s per attempt, and the string coercion just below (`inverter.py:2110-2111`) maps any select state to False, so the force-export direction reports success having written nothing (GH#4909, still live — though on 3-phase GEC the real problem is one stage deeper: no eco register exists at all, and the write path is skipped with `No entity_id for ECO Toggle`; see the GE Cloud row). `adjust_force_export`/`adjust_charge_window` format their times at plan precision with no snapping (`TIME_FORMAT_HMS`, `inverter.py:2608`/`:2615`), so against an integration whose select only offers 15-minute options (Solar Assistant/Deye) Predbat writes e.g. `20:55` and `write_and_poll_option` retries the impossible value 10x every cycle; nothing anywhere reads a select's `options` attribute, and `charge_time_entity_is_option` only decides *how* an entity is written, never which values are legal. The fix precedent is already in tree - AlphaESS's `snap_time_grid()` (`alphaess_const.py:215`), snap start forward and end backward with a collapse check (GH#4947). A second, independent way plan-precision times fail on the same select path: `write_and_poll_option()` only strips the seconds from an 8-char `HH:MM:SS` write when the *previous* state is a healthy 5-char `HH:MM:SS` read — the read feeding it returns `None` for an entity missing from the state cache (`ha.py:817`) or the literal `"unknown"`/`"unavailable"` when degraded (`ha.py:815`), either skips the strip and the raw `HH:MM:SS` goes to `select_option`, which HA rejects; all 10 retries re-read and fail identically, and the log reads `didn't complete got unknown` (GH#5009, probe-verified on main). That degraded-read shape can also be **permanent**: an SA slot select can report `unknown` for days — every write read-back `unknown`, zero verified writes, across an SA rebuild and both native-API and MQTT transports — so both symptoms (read path `unable to read Export window - ... returned no data` every cycle via `time_string_to_stamp("unknown")` → `None`, and the write path above) fire continuously; state reporting varies by SA backend (GH#5214). **A user edit of `config.py`'s INVERTER_DEF `charge_time_format` to anything ≠ exactly `"HH:MM:SS"` is a masking workaround, not a fix (GH#5214):** the `!= "HH:MM:SS"` branch (`inverter.py`) swaps apps.yaml entities for Predbat's own `sensor.predbat_{type}_{id}_*` dummies — reads parse Predbat's own echo and writes become direct `set_state` POSTs that never reach the inverter — so the log goes quiet while SA window control is silently severed. Tells, all observed in #5214's attachments: a `Creating dummy entity sensor.predbat_{TYPE}_{id}_charge_start_time` line in the log (`create_entity()` only logs when the entity is missing from HA state, so its presence proves the ≠ branch ran); the debug yaml's live `args` naming dummy ids while `args_from_apps_yaml` still lists the real `select.*` entities; and warnings stopping after a user restart then resuming after an addon update (which overwrites the edited `config.py`, wiping it). Also: pre-#3533 SA shipped `charge_time_format: "S"` (dummy time entities, no SA select wiring), so "SA time warnings started after updating" can mean the user crossed the #3533 template wiring rather than a format regression. The fix that serves both is reading the select's `options` attribute — nothing in the codebase does today. Six of the eight `adjust_*` writers discard the write helper's boolean and fire `call_notify()`/`mqtt_message()` regardless, and `rest_setReserve()` has the same gap (GH#4845). `call_service_template()` used to record its dedup hash *before* the call, so a silently failed `select_option` was skipped as "previously called" on every later cycle; fixed (it now records only on success and drops the record on failure), though it still deliberately returns True so callers cannot downgrade a freeze into a stop (GH#4876). From that same report, a false-alarm class worth recognising: a `didn't complete got X` where X is exactly the *previous* cycle's target, on an integration that republishes its entities slowly, is the verify window reading HA's cache - the write had already landed by the next cycle. That window is arithmetic, not a constant: up to `INVERTER_MAX_RETRY` (10) writes, each polled through one `inv_write_and_poll_sleep` budget with a doubling read interval - **~40s on GS, ~100s on GE/GEC/GEE** (`write_and_poll_sleep` is 10 for those types, 4 for GS). **Per-type since PR #5297 (merged 2026-09-29):** `INVERTER_DEF[type]["write_max_retry"]`/`["write_backoff"]` (consumed by `_write_attempts()`/`_write_backoff_result()`), and currently only `GWMQTT` deviates - 3 attempts, 10s apart - plus a per-control degraded state for those types: a write of the *same* target failing `INVERTER_WRITE_BACKOFF_FAILURES` (2) times in a row drops to one attempt per `INVERTER_WRITE_DEGRADED_INTERVAL` (300s) until a write verifies, the read-back matches or a different target arrives (full ladder restored at once); a degraded control still reads back, logs and records the failure every call - nothing is skipped silently. Every other type keeps 10 attempts and its existing sleep. A settling bounce that outlasts it is a second false-alarm shape (GH#5130): a HA `number.*` entity can step through intermediates (0 → a float → the settled int) for tens of seconds after a timed-slot write (~44s observed on solax_modbus), so a `didn't complete got <float>` whose value sits *between* the old and target values is a settling read-back, not a failed write - it self-heals next cycle when the initial read matches. The bounce reads feed only `value_matched()` (keep polling vs rewrite) and only the final read reaches the control ledger (`record_write` on match, `clear` on failure), so the worst case is a redundant same-value rewrite plus the false warning; the in-repo precedent for re-reading after settling is Solis Cloud's `verify_settle_seconds` re-read. And the discharge-stop fallback (GH#5094, still live): `adjust_charge_immediate()` issues a "stop discharge" service step before the charge/freeze step, and when `discharge_stop_service` is not configured it falls back to `charge_stop_service` with `domain="discharge"` - a documented fallback dating to #1614. On Tesla service-hook setups `charge_stop_service` maps to `self_consumption` + backup reserve 0, which on a Powerwall is **active discharge to load** (the EV charger counts as load), not a stop - so every freeze/hold cycle Predbat sends "discharge normally" and then re-commands "hold" ~2s later, and Tesla occasionally applies the first and drops the second, so the battery discharges into the car until the next 5-minute cycle. Verified from the reporter's log: the exact pair fires from the carHolding branch ("Disabling battery discharge whilst car 0 is charging" → `adjust_charge_immediate(soc_percent, freeze=True)`); the reporter had commented out `discharge_stop_service` (and `discharge_start_service`) when disabling export control, which is what exposed the fallback. Workaround: define `discharge_stop_service` in apps.yaml with commands that actually stop discharge (for a no-export setup, the same commands as `charge_freeze_service`). Caveat on the reporter's own `repeat: False` idea: enabling the service dedup means accepted calls are not re-sent (see the GH#4876 entry above - HA accepts the call but Tesla firmware can still drop it), so dropped freeze commands would never be retried. Both this and the fixed export clobber below stem from the same property of the Tesla template set: `charge_stop_service` and the freeze/discharge templates all write the same `operation_mode` select, and the templates mean opposite things on this hardware. **A sibling of the same family, over the reserve register rather than the mode selects (GH#5300, triaged 2026-09-29 against d951201e, reporter on a hand-built apps.yaml):** inside one 5-minute pass the hook charge (`adjust_charge_immediate()` issues `charge_freeze_service`/`charge_start_service` via `call_service_template`, inverter.py) and `execute.py`'s reserve reset (`if self.set_reserve_enable and resetReserve: inverter.adjust_reserve(0)`) both touch the Powerwall's reserve and the reset has **no isCharging guard** - `resetReserve` initialises True whenever `set_charge_window or set_export_window` and is cleared only by the freeze / hold-charging / car / iBoost hold branches - while `adjust_reserve()` floors at `reserve_percent` and writes through `write_and_poll_value()`, so the reset always ends up holding the register, against hook writes that are fire-and-forget. A service hook that uses the reserve register as its charge signal loses that race on every charge-window cycle. The shipped template is immune by two mechanisms, both worth checking before triaging any "Tesla reserve overwritten" report: `templates/tesla_powerwall.yaml` sets `has_reserve_soc: False` in the `inverter:` block (`fetch_inverter_data()` then force-disables `set_reserve_enable`/`set_reserve_hold`, logging `Note: Inverter does not support reserve - disabling reserve functions`), and with no `reserve:` arg wired Predbat dummies the arg (`create_missing_arg`/`create_entity`, inverter.py) so `adjust_reserve` writes land on a Predbat placeholder - the Sigenergy dummy-arg shape again. Discriminator for real-vs-dummy reserve wiring: the `Inverter N Current Reserve is X% ... and new target is Y%` and `Wrote X to reserve, successfully now Y` lines name the register, not the entity - a non-zero current read means the `reserve:` arg resolves to a real wired entity; a dummy reads 0 and at an equal target prints `already at target` instead. Dump-config tells from the same report: a `set_reserve_enable` switch showing `value: null` in a debug dump can still resolve True (expert-mode-switched item, hidden and entity not created while expert mode is off), and unknown keys in the dump's `args:` mean a hand-built config - do not assume the shipped template. | `inverter` | | |||
| | GE Cloud (`gecloud.py`) | Gateway fields can come back null. `merge_non_null` stops nulls overwriting good values, and the publish path guards null containers — GH#4656 was a null crash in that area. `number_event` clamps an out-of-range write silently and does not report the clamped value back, while `write_and_poll_value()` keeps comparing against the original pre-clamp target - a permanent false `had_errors` and an unbounded retry (GH#4826). PR #4828 clamped inside `adjust_reserve()` only; the shared write helper still has no min/max awareness and the other `inverter.py` write sites still pass unclamped targets (GH#4831). The error-code path has since been reworked (`9560c61a`, `d6e5998c`) after GH#4896 showed `success: false` nulled `data` before the code branch could read it, so codes GivEnergy documents as never succeeding on a repeat (-3/-4/-7) were retried the full budget and `message` was never surfaced. Separately, **fixed in PR #4954 (merged 2026-09-06)** - keep the mechanism for anyone holding an older log: for `GE`/`GEC`/`GEE` the max battery rate was taken solely from the `charge_rate` entity's `max` attribute, and the `elif "battery_rate_max"` branch below it was unreachable for those types. Percentage-rated models (the 3-phase units) have no absolute charge power register, so `ge_cloud_automatic` left `charge_rate` unset and the attribute read returned the 2600 W default; both the correct rate GECloud writes into `battery_rate_max` and the user's own apps.yaml value went unread, and every rate was clamped to 2600 W. On those models it also corrupted the writes, since the percentage registers are set as `new_rate / battery_rate_max_raw * 100` against a denominator 3.8x too small. The fix falls back to `battery_rate_max` only when `charge_rate` resolves to nothing (GH#4908). GH#4198 is the same code shape on SolaX and is not covered by that fix. A model-string parser gap sits above that path (GH#5136): **the integer-rating half was fixed in PR #5293 (merged 2026-09-30, v9.3.3)** — `get_max_inverter_rate_from_model()` now parses an integer segment straight after the `3HY` token (`GIV-3HY-11` → 11 kW) *before* the decimal pass, so a later decimal segment cannot hide it; it also guards a null model, strips trailing punctuation (`GIV-HY-8.0-G3-HV.`) and warns readably on an unparseable rating ("using max charge rate instead - set inverter_limit in apps.yaml"); keep the pre-#5293 signature (decimal-only match, so an integer-rated `GIV-3HY-11` fell back to `max_charge_rate` — which the GE Cloud API can change independently, 11000 → 9984 W observed). **Still live:** `publish_info()` reads only `max_charge_rate`, never the `max_discharge_rate` in the same payload, and `battery_rate_max` is bound to the `_max_charge_rate` entity — a model whose discharge rating differs keeps the wrong rate. Distinct from GH#4908 (the absent-`charge_rate` 2600 W default). Start on any "GEC inverter rate is wrong" report by checking the model string for a decimal point; the tests now cover the integer-3HY cases too. `automatic_config()` binds `inverter_limit` to the resulting `_max_inverter_rate` sensors and `prediction.py` clips PV against `inverter_limit`, so the error reaches the plan. **Mixed fleets: the rate read/write gates test key existence, not per-slot state (GH#5359, probe-verified on main b161949d via `tools/triage_test.sh`):** `get_current_charge_rate()`/`get_current_discharge_rate()` (`inverter.py`, the `"charge_rate_percent" in self.base.args` branch) and `adjust_charge_rate()`/`adjust_discharge_rate()` (which write **both** keys, each gated only on key existence) interrogate whether the key exists **anywhere in the fleet's args**, not whether *this* inverter's slot is set — and `get_arg()` on a `None` slot applies the caller's default quietly (`userinterface.py`, float branch) — so in a fleet mixing GEC percent-controlled units (3-phase `GIV-3HY` has no `battery_charge_power` watts register; `automatic_config()` then sets `charge_rate_percent` and `build_entities()` leaves per-device `None` slots, deleting `charge_rate` when no device has the register) with watts-controlled units, a percent slot that is `None` reads quietly as 100% → `battery_rate_max_raw`, and every rate write for the power-mode sibling lands on a missing entity (`Warn: ... No entity_id for charge_rate to write ...` + `record_status(had_errors=True)`, so "Read-Only with Errors" too). The low-power rate search, which steps down relative to the read-back, then restarts from the maximum every cycle and never converges — #3311's fault extended to mixed fleets (the single-inverter shape is in the low-power symptom row). PR #4645 (open, for #3311) creates its per-slot rate dummies but does not touch these four gates — the #4908 battery-sizing read (`get_arg("charge_rate", indirect=False, index=self.id)` before falling back, inverter.py:583) is the per-entry pattern the gates lack. One API-shape trap on the site endpoint (`GE_API_SITE`, `site/{uuid}`, added for PR #4978): the published OpenAPI spec types `limits.import`/`limits.export` as a string with a null example and never shows a populated one, so the shape had to be learned from live accounts. A populated limit is `{'enabled': bool, 'power': {'watts': int, 'amps': float}}`, and **`enabled` is the thing that matters** - a site describes its connection's declared capacity in exactly the same structure as a curtailment, marked disabled, so `power.watts` alone tells you nothing about whether anything is being restricted. Site 64744 gave `{'import': {'enabled': False, 'power': {'watts': 46000, 'amps': 200}}, 'export': {'enabled': True, 'power': {'watts': 4500, 'amps': 19.6}}}` - a 200A supply whose export really is curtailed to 4.5kW - while site 46714's disabled 6kW export is its declared capacity and no restriction at all. A fleet survey confirmed the flag across accounts, so only an enabled limit is applied; an enabled zero is a real zero-export connection. A site with no limit reports a null import/export. For a fleet survey use `GET /v1/site`, the list endpoint, which returns every site's `limits` and the inverters under it (with `info.max_discharge_rate`) in one response - no second call per site. Two GEC triage tools and one clobber trap (GH#5017). The component publishes an entity for every `/settings` entry with no name filter (`async_get_inverter_settings()`/`publish_registers()`, `regname_to_ha()` is plain lowercasing), so **absence of an entity in the reporter's debug yaml is proof the API never listed the register** — "the app can control it" does not imply the settings API exposes it, because the app/GivTCP write via local control paths rather than the `/settings` list (a GIV-3HY-20 had slot 1/2 lower-SoC registers absent while 3..10 existed). Caveat: the settings list is fetched once per process start (`register_list` cache) and only the parsed flags are logged, so the debug yaml is the only observable. To capture the raw register list, `python3 apps/predbat/gecloud.py --api-key <key> --write-entity number.probe_nothing 0` makes `test_gecloud_direct()` print the full "Available entities/registers" list with raw cloud names and setting IDs and performs no write — but the harness's startup pass also runs `enable_default_options()` against the real inverter (floors reset, unused windows zeroed), so say so when asking a user to run it. Clobber trap: the missing-feature branch `set_arg("discharge_target_soc", None)` *deletes* the key, including an explicit apps.yaml entry the user wrote; `set_arg_auto(..., overwrite=False)` (component_base.py) is the in-repo pattern for letting an explicit value win — check the `has_*` detection branch on any "automatic config deleted my setting" report. The `inverter_mode` half of this class was fixed in PR #5059 (`885c637d`) — it now binds via `set_arg_auto(..., overwrite=False)` like `export_limit` — but the other missing-feature deletes are still plain `set_arg(..., None)` on main: `pause_mode`, `pause_start_time`, `pause_end_time`, `discharge_target_soc`, `charge_rate_percent`, `discharge_rate_percent`, `givtcp_rest`. A companion test-fidelity trap (GH#5056, verified on main): the component test mocks (`MockBase.set_arg` in `test_ge_cloud.py`; same shape in `test_ohme.py` and `test_alphaess_api.py`, whose mock `set_arg_auto` also writes unconditionally) store the value instead of mirroring the real `set_arg()`'s None-deletes, and their `args_from_apps_yaml` is empty so `set_arg_auto()` falls through to the plain path — so the "feature not detected" assertions (`config_args.get(...) is None`) pass identically whether the code stored None or deleted the key, and a green suite cannot distinguish fixed from unfixed. Any test for this class must populate `args_from_apps_yaml` and assert the manual value survives — #5059's Test 10 in `test_ge_cloud.py` is now the in-repo precedent. And the deeper half of GH#4909 (still live): the 3-phase GEC class exposes **no** eco/demand/mode register in `inverter/{sn}/settings` — verified by enumerating the `predbat_gecloud_*` entities in the reporter's debug dump — yet the `GEC` def sets `has_ge_eco_toggle: True` unconditionally (`config.py`) and auto-config maps `inverter_mode` via `build_entities("switch", ["enable_eco_mode"])` (gecloud.py), which emits nothing when the register is missing, so `adjust_inverter_mode()` logs `No entity_id for ECO Toggle` and returns without writing every plan cycle and freeze export silently no-ops (force-discharge paths work fine). Fix wrinkle for the maintainer: the flag is one per-inverter-type bool while `build_entities` works per-device. The freeze-export half of the same class (GH#5082, follow-up to GH#4909, code-verified on main): `inv_has_timed_pause` is probed at runtime (inverter.py flips it False when the `pause_mode` entity is absent/unavailable) but `inv_support_discharge_freeze` is read only from the static `INVERTER_DEF` entry (`config.py` sets it True for GEC), so `execute.py` never force-disables `set_export_freeze` for the eco-less/pause-less 3-phase class and a freeze-export plan can never be executed. Check both flags on any "freeze silently didn't work on GEC" report - and do not grep only for `No entity_id for ECO Toggle`: that warning comes from the eco branch, while freeze export on this class fails primarily through the pause/rate branch, so the eco warning being absent says nothing about the freeze path. Fix direction: mirror the `inv_has_timed_pause` presence-probe; the manual-freeze-export override path already degrades correctly when `set_export_freeze` is False (plan.py drops to demand). Hardware-reported on the GIV-3HY class: `charge_power_rate` limits AC (grid) charging only - `battery_power` stays at the full discharge figure while the charge register reads 1% - so the `adjust_charge_rate(0)` fallback in the freeze branch is a no-op for PV charging there; note `charge_discharge_with_rate` is False for GEC, so the first `adjust_charge_rate(0)` in each branch is skipped and the write only happens via the `has_timed_pause`-else fallback. Fix precedent for building a freeze from registers the device actually has: `inv_support_feedin_first` + Fox Cloud freeze export (PR #5038); the GIV-3HY exposes `enable_force_discharge` + `discharge_down_to_percent` + `battery_reserve_percent`, the raw material for the #4909/#5082 option-2 freeze. And since #5056 a manual `inverter_mode` apps.yaml override is silently deleted by automatic config, so "just map the eco toggle manually" is not currently viable either. The neighbouring **charge-side** gap (GH#5040: `scheduled_charge_enable` had no `enable_force_charge` candidate, so a 3-phase GEC that gates timed grid charge behind both charge switches logged real charge states while importing nothing) is **fixed in PR #5042** (`a7121135`, v9.0.2): auto-config now binds `scheduled_charge_enable` to `enable_force_charge` with `ac_charge_enable`/`enable_ac_charge` as fallbacks, and `enable_default_options()` holds `enable_ac_charge` on as a static enable when the force register exists. Keep the mechanism for pre-v9.0.2 logs, where the signature is a 3-phase GEC showing plan charge states against flat grid power with no warning anywhere. The #5042 gate itself had a second gap (**GH#5269, fixed in PR #5270, merged 2026-09-27** — keep the pre-#5270 signature): `enable_ac_charge` was written in exactly one place, `enable_default_options()` — first cycle after start-up, then once per 24h (`default_options_stamp`) — while Predbat's own `scheduled_charge_enable` write (`switch_event()`) checked nothing about the gate, so any external writer (an Axle VPP clean-up, the GE app, another integration) could clear `enable_ac_charge` and Predbat re-asserted it only on that 24h pass or a restart; "restarted and it worked" is part of the pre-fix signature, as is `enable_force_charge` on with `Charging target …%` for hours, SoC flat and no error. #5270 re-asserts the gate from `switch_event()` when a force-charge write succeeds (`ensure_ac_charge_gate`, with Axle's clean-up read as read-only for the 24h pass and a binding guard), so the "gate cleared between cache refreshes" residual window is the remaining maintainer call on that fix. So "3-phase GEC plans a charge, status says Charging, battery imports nothing" now has **two** signatures: pre-v9.0.2 = never bound (#5040), v9.0.2+ pre-#5270 = externally cleared and not re-asserted (#5269); on a post-#5270 system check whether the force switch Predbat drove is actually the `enable_force_charge` register. GE Cloud EMS plants (GH#5103, **fixed in PR #5109, merged 2026-09-24** — keep the mechanism for pre-#5109 logs): with an EMS discovered `polling_mode` is set False (`gecloud.py`), and the settings refresh used to re-read each battery inverter's `/settings` only on the first tick of the process — so the AC3 registers, including the DC-discharge slot windows, were read once and published stale for the rest of the run, while live status/meter polling kept looking normal. #5109 re-reads settings hourly (`SETTINGS_SLOW_REFRESH_SECONDS`, `gecloud.py`), refreshes the EMS and gateway devices every cycle, and runs `check_ems_inverter_slots()` on every snapshot — which now *warns* when a battery inverter's slot 1 is not the full-day window (the #3781 rule: `Inverter X slot 1 is not 00:00-23:59 ... it will override the EMS and can stop charging or discharging early`), once per episode — recorded in `ems_slot_warned` so a standing misconfiguration does not inflate the error counter on every refresh, so the non-00:00–23:59 slot 1 fault is a visible warning on current main and silent only pre-#5109 (pre-fix signature: plan/status look right but the batteries hold 0 W past a fixed wall-clock time every night). Under EMS auto-config Predbat still writes mode/schedule-enable/rates to the AC3s. Nuance: the startup read itself can still be skipped when the storage settings cache is under 10 minutes old (`settings_from_cache`), so even a restart is not guaranteed to re-snapshot the registers. **The option-validation parser used to crash-loop the whole component (GH#5217, fixed in PR #5218, merged 2026-09-26 — keep the signature for pre-#5218 logs):** `select_event()` and `publish_registers()` both `split("(")` a cloud `Value must be one of: (...)` string, so an option label containing `(` raised `ValueError: too many values to unpack (expected 2)` — the component does not die (`ComponentBase.start()` catches it), it *crash-loops*: `api_started` never set, automatic config never runs, no plan, `Error: GECloudDirect: too many values to unpack (expected 2)` every cycle. #5218 added the module-level `parse_validation_options()` (`gecloud.py`): split on the first `(` and strip only the final `)` (so inner brackets in labels survive), and `None` for a string with no `(` triggers a warning and falls back to the setting's `in:` validation-rule options instead of raising — the paren-less guard is required, not optional, because `split("(", 1)` alone fails the other direction. Which GE Cloud setting actually returns a multi-`(` validation string was never captured (the storage cache saved at the settings write would be the fixture to ask for). **`refresh_discovery()` is not device re-discovery, and GE Cloud re-discovers hourly since PR #5295 (GH#5294, merged 2026-09-29 - the symbols below were read against the pre-fix tree):** `ComponentBase.refresh_discovery()` only rebuilds the capability-catalogue *report* from data already in hand (a component opts in via `build_discovery()`) and never calls the component's API - the *similarly named* `refresh_devices()` is the thing that calls it. Pre-#5295 that device discovery (`async_get_devices()`, EV chargers, EMS/gateway selection, one-shot automatic config) ran exactly once inside `if first:` and `first` flips off permanently after the first successful run, so on any "GE Cloud didn't pick up my new inverter/charger" or "removed inverter still shows data" report a restart was the only mechanism - and a removed device kept its last good SoC/power feeding the plan (`merge_non_null()` hands back the previous reading on nulls and failed polls) and kept having registers written to. **Post-#5295:** `refresh_devices()` re-reads the device list hourly (`DEVICE_REFRESH_SECONDS`, 60*60, `gecloud.py`; a multiple of 60 because `run()` is called once a minute, and a cycle that finds a change polls and reads settings whatever else is due), `select_poll_devices()`/`apply_devices()` decide what is polled from the fresh list, and adopting a changed set drops every per-device store - `status`, `meter`, `info`, `settings`, `pending_writes`, `register_list`, the EV-charger stores, `ems_slot_warned` and `register_entity_map` - so a removed device stops publishing and being written to. The review round also: the change signature includes `battery_meters`, so a CT rewiring re-runs automatic config; a failed register-list fetch is retried on the next settings read (previously stored as `None` and never fetched again - every later read raised `TypeError`, newly reachable from rediscovery); a device read that would leave zero battery inverters is not adopted (the warning says restart if the hardware really was removed; charger-only sites stay quiet); `ge_cloud_data` returns to its pre-EMS value when the EMS leaves; the EMS slot-override warning re-arms when the EMS changes; and default options for a device discovered while read-only is set stay pending across cycles, applied once read-only ends. Caveats that survive the fix: the 5-day `last_updated` skip inside `async_get_devices()` treats a device silent over 5 days as non-functional wherever that runs - the hourly re-read included - and `merge_non_null()` still hands a *polled* device its last good SoC/power on nulls and failed polls. In-tree fix precedents (GE Cloud itself now among them): Fox re-fetches its device list every 24h (`FOX_REFRESH_STATIC`), SolaX gates plant/device-info re-reads with `data_is_due`, and `num_inverters` is re-read by the core every cycle so a re-run automatic config takes effect next plan. **The "disable" writes on the unused numbered slots leave them live (GH#5371, reporter field log from a GIV-3HY-11 Beta site, code-verified on main):** `enable_default_options()` - run at startup, once per 24h and on newly-found devices, gated only by `read_only_now()` so manual-config GEC sites get the resets too - writes every unused AC-charge and DC-discharge slot 2-10's **times** to `00:00` "to disable" (`gecloud.py`, the numbered-slot branch of the limit/time resets), and on 3-phase GIV-3HY hardware `00:00-00:00` is **live** 00:00:00-00:00:59 (minute bounds), so every "disabled" unused slot is live for one minute past midnight; with force charge on at that minute (a planned charge window spanning midnight, or the v9.1.0 stuck-on case) the unused slots fire at full rate toward their 100% upper limit (discharge mirror: full rate toward the 4% lower floor). The same pass overwrites user-set spare-slot times (the 03:00 workaround) once per pass, per the reporter's inverter-settings history log. Fix direction (maintainer's call): have the **limits** carry the disable instead (unused slots' upper→4%/reserve floor, lower→100%); the constraint is that the two generic limit branches (`*_lower_soc_percent_limit`→4%, `_upper_soc_percent_limit`/`ac_charge_upper_percent_limit`→100%) also match the numbered slots and would write straight back on the next pass, so the fix must special-case slots 2-10 inside those branches - and #5017's outcome could later drive exports through slot 3 on GIV-3HY, so the "unused" set needs a guard there. `test_ge_cloud.py`'s 00:00-reset tests stay valid under this; the fix needs numbered-slot limit assertions added. | `ge_cloud` | | |||
| | Teslemetry / Powerwall (`teslemetry.py`) | Battery model is inferred from site `nameplate_power / battery_count`. A nameplate fallback combined with `inverter_hybrid: True` once produced a false 5 kW inverter limit and spurious morning export. Tariff writes push a whole TOU schedule every cycle, so a setting changed by hand in the Tesla app is reverted on the next cycle (GH#4600, GH#4610). Three later findings. `build_tariff()`/`_render_side` carve a *single* ON_PEAK interval priced with one scalar (`teslemetry.py:1117`/`:1036`/`:1074`), so no intra-window price gradient can exist and Tesla's own TBC is free to defer the whole export to the end of the window; the no-rate-data fallback branch also skips the boost entirely (GH#4887). The charge path sends no rate at all - `evaluate_schedule` (`teslemetry.py:539`) asserts mode `backup` plus reserve = charge target plus grid charging - so a slow charge ramp is Tesla firmware, not a Predbat write bug (GH#4892); Tesla now snaps a backup reserve of 81-99% down to 80% while Predbat still forwards any 0-100 target. The site_info limit mapping was reworked in PR #5276 (GH#5275, merged 2026-09-28): `inverter_limit` comes from `nameplate_power` (the Powerwall's own AC rating; `max_site_meter_power_ac` is the site's supply limit at the meter, not the inverter's), `export_limit` from `min_site_meter_power_ac` (kW, possibly fractional, with the ±1e9 "no limit" sentinel skipped and 0 published as a real 0 W limit), `inverter_limit_charge` at **5 kW per battery unit** capped at nameplate (Tesla reports no usable charge rating — a Powerwall 3 lists only expansion packs with every rating zero, and fleet data fits the rule), `soc_max` from the gateway's `nameplate_energy_watts` before the `battery_count` estimate, and `inverter_hybrid` now defaults from the Powerwall model (Powerwall 3 on, every other model off) with a `teslemetry_hybrid` override for a PW3 beside an existing string inverter. All of those are wired with `set_arg_auto(overwrite=False)`, so **an apps.yaml value wins** — on a pre-#5276 version `automatic_config()` overwrote a manually set `battery_rate_max` whenever `teslemetry_automatic` was on, which was the standing "my override does nothing" answer on this component. Since PR #4976 there is a Predbat-side lever for exactly that slow ramp: `teslemetry_tbc_control` — **on by default since PR #5188** (GH#5186; `DEFAULT_TBC_CONTROL = True` in `teslemetry.py`, mirrored in `COMPONENT_LIST`, with `teslemetry_tbc_control: False` as the opt-out) — switches `evaluate_schedule()` to `evaluate_schedule_tbc()`, which pushes a **signal tariff** (`build_signal_tariff()` - fixed 0/50/100p bands over the committed charge and export windows) so Tesla's own optimiser runs the charge and reaches the full rate reserve-driven charging cannot; mode goes to `autonomous` in every state, reserve becomes an actual reserve rather than a charge signal, and `_settable_reserve()` maps requests onto reserves the Powerwall honours - an 81-99% request now rounds **up** to 100 rather than being forwarded raw into the snap-to-80 band. The same PR stopped `plan.py` planning a manual freeze export on inverters that cannot do it. **Consequences of the default flip:** a Teslemetry user who never set the key is on the signal tariff with autonomous mode, so "the Tesla app shows 0p/50p/100p instead of my rates" or "my charge target isn't honoured" is the default path working, not a bug; and the 81-99% `set_reserve_min` limitation becomes default-on behaviour with it. (`MockTeslemetryAPI` still defaults `tbc_control = False` on purpose, so a green teslemetry test run exercises the real-rate path unless a test opts in.) And a separate scoping fact from the GH#5186 triage: `teslemetry_automatic` gates only `automatic_config()` — the scheduler emulator (`sync_tariff()` + `assert_device_state(evaluate_schedule(...))`) runs for every non-read-only user with no `automatic` check, so "Predbat changed my Tesla tariff/mode but I never turned on automatic" is that scoping, not a bug; `set_read_only` is the only switch that stops the writes. A related pricing bug in the same `build_tariff()` family was fixed in PR #4977: an export window ending at midnight priced the whole of tomorrow at peak. And `optimization_strategy: "economics"` *is* pushed with `tariff_content_v2` on every `set_tariff()`, unconditionally, since v8.49.0 / PR #4603 - a request to "add" it is asking for something already shipped (GH#4918). **GH#5157** (reporter's evidence, not independently probed — Powerwall 2, fw 26.26.4): the unit sat in the idle branch of `evaluate_schedule` and simply stopped acting on a standing device tuple for ~4h while `site_info` read back the *correct* configuration — drift invisible to every field the API exposes, with only a Predbat restart recovering it; the stall state is the one branch Predbat legitimately holds for hours, which is why transition-based self-heal never fires. A "Powerwall plateaued / stopped discharging until I restarted Predbat" report maps here first. **Implemented on main** (2026-09-19): `run()` re-asserts the whole device tuple — export rule, grid charging, reserve, mode, not the tariff — every `FORCED_ASSERT_SECONDS` (2h) with the write-on-change dedupe bypassed (`force=True`), the timer advancing only on a fully successful forced assert; the Info line `Teslemetry control drift-correction is transition-based ..., backed by a forced re-assert of the full device tuple every 120 minutes` names it, so on current main the stall is bounded at ~2h. **Freeze export is fully implemented in the planner and disabled for TESLA at exactly one point (GH#5225, enhancement):** `INVERTER_DEF["TESLA"]` declares `support_discharge_freeze: False` (`config.py`), read into `inv_support_discharge_freeze` (`inverter.py`), whose only consumer is the first-inverter lockstep block in `execute.py` that force-disables `set_export_freeze`/`set_export_freeze_only` (`Note: Inverter does not support discharge freeze - disabled`) — `EXPORT_MODE_FREEZE` never enters the export ladder, and PR #4976 additionally drops manual freeze-export windows to demand with a Warn. **Flipping the flag alone is not enough:** the component must also map the freeze-target discharge window to a device-side hold, or the plan's freeze assumption fails on the device — the non-TBC `evaluate_schedule()` writes the *raw* discharge target as the reserve, so a 99 target lands in the 81-99 band Tesla silently snaps to 80 (`_settable_reserve()` exists for exactly that and the non-TBC path doesn't route through it), while the default-TBC `evaluate_schedule_tbc()` discharge branch yields `pv_only` with the standing reserve but no hold — the battery still serves house load and drifts down. The device primitive exists in-tree: the TBC charge-hold tuple (`pv_only` + reserve 100 + grid charging off + autonomous) holds the battery while PV surplus exports, but a freeze *export* hold must sit at the current SoC (reserve at/above SoC through `_settable_reserve()`), not 100 — reserve 100 lets solar recharge the battery instead of exporting the surplus. Every `INVERTER_DEF` entry with `support_discharge_freeze: False` (the cloud-emulator types: SunsynkCloud, AlphaESSCloud, DeyeCloud, SolaxCloud, SolisCloud…) shares this two-part requirement — capability flag **plus** device-side freeze mapping — so enabling freeze export on any of them is a two-file change, not a one-line flag flip; each component's schedule emulator needs its own hold tuple designed against what its hardware honours (*suspected*, not verified per component). | `teslemetry` | | |||
| | Sunsynk / DEYE (`sunsynk.py`, `deye.py`) | Freeze export is gated by the per-slot power register (`sellTime{n}Pac` on Sunsynk), confirmed on live hardware — setting the energy mode alone had no effect, and with slot power at zero the battery still charged. `read_only` was ignored by the reconcile loops until `_is_read_only()` gated `_reconcile_control()` (GH#4436). DEYE cloud telemetry keys are one hardcoded spelling per metric — `DEYE_TELEMETRY_KEYS["pv_power"] = "TotalSolarPower"` (`deye_const.py`), confirmed against a single live 3-phase hybrid — and a SUN-8K-SG05LP1-EU-AM2-P instead exposes `TotalDCInputPower` + `DCPowerPV1/2/3`, neither anywhere in the tree. Because `pv_power` is in `DEYE_TELEMETRY_REQUIRED`, the miss fires the `device/latest missing expected keys [...] - telemetry will read zero` warning every cycle and the Cloud PV sensor publishes 0.0 while a manual `pv_power` arg to a local sensor may still protect the planner. Reproduced by swapping the test fixture's single PV key (`tests/test_deye_api.py` `LIVE_DATA_LIST`). Whether the alternate key is unit-equivalent (vs summing `DCPowerPV1-3`) needs a live capture from an affected model — suspected, not verified. CONFIRMED live (Sunsynk 2211093089, 2026-09-19, via `sunsynk.py --tou-test`) that the settings object exposes the TOU register block a SECOND time under unrelated names, so several keys that read like independent settings are the same memory at a different scale: `volt1`-`volt4` are `sellTime3`-`sellTime6` as minutes-since-midnight / 50, `volt5`-`volt10` are `sellTime1Pac`-`sellTime6Pac` / 10, and `volt11`, `volt12`, `current1`-`current4` are `sellTime1Volt`-`sellTime6Volt` x 10 — a contiguous 16-value window, matched 16/16 in both the before and after reads of one write. Two consequences. It is independent proof a TOU write reached the real registers rather than a cloud-side echo, which is the cheapest hardware verification available. And it is a trap: anything that wrote `volt*`/`current*` would silently corrupt the charge programme. Predbat is safe today only because `SUNSYNK_SYSTEM_MODE_FIELDS` excludes them, so treat that exclusion as load-bearing rather than incidental. The alias does NOT extend to what the write payload must contain — `time{n}On` (capital O) is a derived echo of `time{n}on` and is correctly excluded via `SUNSYNK_DERIVED_SLOT_FIELDS`. **GH#5138**: the (pre-#5360 wording) `control cache is X minutes old (limit 15)` forced-rewrite check is **startup-only** - it lives in `restore_state()`, called only from `run()`'s `if first:` block - so a reporter reading `limit 15` as "rechecks every 15 minutes" is wrong; it never runs again after the first cycle. The issue's core premise (idle slots never clear `sellTime{n}En`) was disproved: every slot `_owned_payload` write carries an explicit sell flag, idle slots are written with `sell: 0`, and the TOU build places a sell-0 baseline segment at each window's end (probe-verified; a `sellTime5En: 1` read-back just after an export window can be *correct*). The real gap it exposed - a write the cloud API acknowledged but the dongle never collected was trusted forever, because the owned-field change gate suppresses identical re-sends and `note_settle` only warned - is **fixed in PR #5142 (merged 2026-09-19)**: sustained settle divergence now clears `applied_payload[sn]` so the next write cycle re-applies. Keep the mechanism for pre-#5142 logs, where a stuck export slot needed a restart to clear. No debug yaml was ever attached, so the reporter's exact overrun is unconfirmed; the `has not applied Predbat's settings after N settings polls` warning is the tell. Two component-side traps since. **PR #5150** (merged 2026-09-19): `control_active` is now persisted and restored alongside `applied_payload` under the same 15-minute bound (`SUNSYNK_RESTORE_MAX_CONTROL`/`DEYE_RESTORE_MAX_CONTROL`), so a restart **inside** the bound no longer strands an armed inverter in silence; on the upgrade path a cache carrying `applied_payload` with no `control_active` key infers the missing half from the payload keys — a safe lower bound, since `applied_payload[sn]` is written only by `apply_settings`/`apply_dynamic_control`, whose production callers arm `control_active` first (the CLI paths apply with `force=True` and never save). **PR #5360 (merged 2026-10-05, unreleased at the time of writing, fixes GH#5349 below) has since split the two halves into separate caches with separate bounds:** `applied_payload` keeps the 15-minute bound (`SUNSYNK_RESTORE_MAX_CONTROL`/`DEYE_RESTORE_MAX_CONTROL`) while `control_active` gets 8 hours (`SUNSYNK_RESTORE_MAX_CONTROL_ACTIVE`/`DEYE_RESTORE_MAX_CONTROL_ACTIVE`, in a cache of its own, with a migration path from the pre-#5360 combined cache), and the restore log line splits to match - `Info: Sunsynk control payload cache is X minutes old (limit 15), forcing a rewrite` drops only the payload cache; a new `Info: Sunsynk control ownership cache is X minutes old (limit 480), requiring a fresh write` is the one that drops the ownership half. And the in-code comment on the Sunsynk write-button handler claiming Predbat "presses this on every cycle" is wrong about frequency: both press sites in `inverter.py` are change-gated (target SoC presses only when `current_soc != soc`, the export window only when `schedule_changed`), and the one unconditional post-restart re-commit is `is_hm_format`-only, which excludes these types' `HH:MM:SS` — so after a restart with the plan already matching the inverter, nothing is pressed for hours. Read the press gates in `inverter.py` before using that comment to dismiss a "component stopped writing after a restart" report. **GH#5349 (2026-10-02, fixed in PR #5360, merged 2026-10-05 - keep the mechanism for pre-#5360 logs) joined the two halves end to end:** on a pre-#5360 build an HA outage restarted Predbat with the (single) control cache 35.9 minutes old, restore dropped both `applied_payload` and `control_active`, and **nothing performed the forced rewrite on its own** - `_reconcile_control()` gates on `control_active`, `number_event` reaches Predbat only as in-memory `update_local_schedule()` updates (no apply), and both press sites stayed change-gated - so zero settings POSTs fired from 00:59 to 03:02 (counted from the reporter's full-API-logging log) while the hold re-armed every cycle and the inverter's idle-cap-5 programme drained ~9 kWh into the EV until a plan change finally pressed the write-button at 03:02. #5360 closes it by keeping `control_active` for 8 hours (see above), so the reconcile path can own the re-apply within that window. Reading the "forcing a rewrite" line as if a rewrite follows is still the trap - it is the notice that the payload cache was **dropped**; a "holds lost for hours after an HA blip / battery drained while Predbat showed holds armed" report on a pre-#5360 (v9.3.5-) build maps here, and on post-#5360 builds the `has not applied Predbat's settings after N settings polls` settle path is the remaining backstop. Device-visible hold legs on these types (same log): the TOU slot cap is the only one — a hold is `cap = SoC+1` in the programme (cap 65 held the battery at 64% while the car drew from grid; cap 5 drained it toward the inverter floor), and the `discharge_rate 0` entity write is symbolic on this type, so a "wrote 0 to discharge_rate but the battery drained" report reads the cap, not the entity. Also normal for this type: Sunsynk TOU charge windows cannot cross midnight (`can_span_midnight: False`) — a 23:00–00:30 window is written 23:00–23:59 and re-rolled to 00:00–00:30 at midnight (log-confirmed; not a bug). **GH#5156** (padding truncating any TOU window crossing 04:00/08:00/12:00, `build_tou_slots()` — now shared by both components in `tou_schedule.py`) is **fixed**: padding slots now carry the state of the slot they follow and sit just after it, an inert interval that cannot end a window early (`_padding_segments()` documents the issue). The pre-fix tell was "Deye stops charging at 00:00/04:00/08:00/12:00/16:00/20:00 while the Plan page still shows charging", freshly generated each cycle — not a stale default slot. **GH#5193 (cloud component, load telemetry):** on Sunsynk M3.3.8.9 the `totalPower` field (`load_power`, `SUNSYNK_TELEMETRY`) read 0–100 W through a whole overnight cycling stretch while the battery was active — including mode-2 ("Limited to Home") stretches — and read plausibly the adjacent morning with the battery idle, so the collapse correlates with the battery being active, not cleanly with the work mode; what gates it is unresolved (suspected; the reporter's manual A/B blamed the mode flip, the log's mode-2 stretches say something else does too — a controlled live test on the affected firmware is the only settle). `dailyUsed` (`load_today`) kept counting at a plausible coarse rate through the same stretch, so a balance-derived load remains feasible — and `fill_load_from_power()` is the repair that gets nothing while `totalPower` is zero. Predbat's own export control writes the whole-system `sysWorkMode` to `selling_first` for every planned export window (`derive_control_state()`, applied in the settings payload), and the component auto-wires both load args through `set_arg_auto()`'s default `overwrite=True`, so a manual apps.yaml override does NOT win — only `sunsynk_automatic: False` opts out. The in-file docstring on main records the mode/battery-export reading plus the live counter-evidence (11.1 kWh exported in a day under "Limited to Home" with `solarSell` on; a separate live test showed battery export under mode 2 with the per-slot sell flag), so the docstring's "the mode governs battery export" claim is DEYE-inferred and not settled — a control-side alternative (stay in mode 2, drive `sellTime{n}En`) stays open. The component logs every API request/response in full in `predbat.log`, so a whole Sunsynk-cloud investigation can run from the log alone; when mining logged JSON widen the field width before trusting a truncated number (`0.4` prints as `0.` under a 14-char `substr`). **Automatic config maps a battery-side current into `battery_rate_max`, and `inverter_limit` does not bound the written rate (GH#5238, code-read on main 2026-09-25/29):** `battery_rate_max()` derives watts from `chargeCurrentLimit`/`maxChargeCurrentLimit` × nominal pack voltage (`SUNSYNK_CHARGE_CURRENT_FIELDS`, first-positive-wins — a battery/BMS-side limit; GH#5238's 280 A BMS derived 14.3 kW against an 8 kW inverter), `automatic_config()` maps it to `battery_rate_max` and `ratePower` to `inverter_limit` but **never sets `inverter_limit_charge`/`inverter_limit_discharge`**, and `inverter.py` defaults both of those to `battery_rate_max_raw` when unset — so `battery_rate_max_charge = min(raw, raw) = raw`, and that is the per-slot power the plan writes. `prediction.py` clamps only *predicted* flow to `inverter_limit`; nothing feeds `inverter_limit` into the written rate. `deye.py`'s `battery_rate_max()` docstring states the same wrong assumption outright ("inverter_limit constrains the AC side separately" while deriving from `maxChargeCurrent`), and its `automatic_config()` has the same two-arg shape — so treat any "automatic config shows/writes an impossible rate" report for a cloud component through this lens first, and a fix has to map `inverter_limit_charge`/`_discharge` (to `min(ratePower, derived battery rate)`); deriving the true inverter-side current setting needs a telemetry mapping Sunsynk does not currently expose. Workaround semantics: `inverter_limit_charge`/`inverter_limit_discharge` are safe apps.yaml overrides under `sunsynk_automatic` (the component never sets them), while `battery_rate_max` is not — `set_arg_auto(overwrite=True)` clobbers an apps.yaml value every cycle. | `sunsynk_control`, `deye_control` | | |||
| | Sunsynk / DEYE (`sunsynk.py`, `deye.py`) | Freeze export is gated by the per-slot power register (`sellTime{n}Pac` on Sunsynk), confirmed on live hardware — setting the energy mode alone had no effect, and with slot power at zero the battery still charged. `read_only` was ignored by the reconcile loops until `_is_read_only()` gated `_reconcile_control()` (GH#4436). DEYE cloud telemetry keys are one hardcoded spelling per metric — `DEYE_TELEMETRY_KEYS["pv_power"] = "TotalSolarPower"` (`deye_const.py`), confirmed against a single live 3-phase hybrid — and a SUN-8K-SG05LP1-EU-AM2-P instead exposes `TotalDCInputPower` + `DCPowerPV1/2/3`, neither anywhere in the tree. Because `pv_power` is in `DEYE_TELEMETRY_REQUIRED`, the miss fires the `device/latest missing expected keys [...] - telemetry will read zero` warning every cycle and the Cloud PV sensor publishes 0.0 while a manual `pv_power` arg to a local sensor may still protect the planner. Reproduced by swapping the test fixture's single PV key (`tests/test_deye_api.py` `LIVE_DATA_LIST`). Whether the alternate key is unit-equivalent (vs summing `DCPowerPV1-3`) needs a live capture from an affected model — suspected, not verified. CONFIRMED live (Sunsynk 2211093089, 2026-09-19, via `sunsynk.py --tou-test`) that the settings object exposes the TOU register block a SECOND time under unrelated names, so several keys that read like independent settings are the same memory at a different scale: `volt1`-`volt4` are `sellTime3`-`sellTime6` as minutes-since-midnight / 50, `volt5`-`volt10` are `sellTime1Pac`-`sellTime6Pac` / 10, and `volt11`, `volt12`, `current1`-`current4` are `sellTime1Volt`-`sellTime6Volt` x 10 — a contiguous 16-value window, matched 16/16 in both the before and after reads of one write. Two consequences. It is independent proof a TOU write reached the real registers rather than a cloud-side echo, which is the cheapest hardware verification available. And it is a trap: anything that wrote `volt*`/`current*` would silently corrupt the charge programme. Predbat is safe today only because `SUNSYNK_SYSTEM_MODE_FIELDS` excludes them, so treat that exclusion as load-bearing rather than incidental. The alias does NOT extend to what the write payload must contain — `time{n}On` (capital O) is a derived echo of `time{n}on` and is correctly excluded via `SUNSYNK_DERIVED_SLOT_FIELDS`. **GH#5138**: the `control cache is X minutes old (limit 15)` forced-rewrite check is **startup-only** - it lives in `restore_state()`, called only from `run()`'s `if first:` block - so a reporter reading `limit 15` as "rechecks every 15 minutes" is wrong; it never runs again after the first cycle. The issue's core premise (idle slots never clear `sellTime{n}En`) was disproved: every slot `_owned_payload` write carries an explicit sell flag, idle slots are written with `sell: 0`, and the TOU build places a sell-0 baseline segment at each window's end (probe-verified; a `sellTime5En: 1` read-back just after an export window can be *correct*). The real gap it exposed - a write the cloud API acknowledged but the dongle never collected was trusted forever, because the owned-field change gate suppresses identical re-sends and `note_settle` only warned - is **fixed in PR #5142 (merged 2026-09-19)**: sustained settle divergence now clears `applied_payload[sn]` so the next write cycle re-applies. Keep the mechanism for pre-#5142 logs, where a stuck export slot needed a restart to clear. No debug yaml was ever attached, so the reporter's exact overrun is unconfirmed; the `has not applied Predbat's settings after N settings polls` warning is the tell. Two component-side traps since. **PR #5150** (merged 2026-09-19): `control_active` is now persisted and restored alongside `applied_payload`; **PR #5360 (merged 2026-10-05, fixes GH#5349) then split the bounds — keep the single-15-minute-bound reading for pre-#5360 (≤ v9.3.5) logs** — with `applied_payload` restoring only when its cache is ≤15 minutes old (`SUNSYNK_RESTORE_MAX_CONTROL`/`DEYE_RESTORE_MAX_CONTROL`) and `control_active` (the reconcile gate) when ≤ **8 hours** old (`SUNSYNK_RESTORE_MAX_CONTROL_ACTIVE`/`DEYE_RESTORE_MAX_CONTROL_ACTIVE`), so a restart **inside** the bound no longer strands an armed inverter in silence; on the upgrade path a cache carrying `applied_payload` with no `control_active` key infers the missing half from the payload keys — a safe lower bound, since `applied_payload[sn]` is written only by `apply_settings`/`apply_dynamic_control`, whose production callers arm `control_active` first (the CLI paths apply with `force=True` and never save). And the in-code comment on the Sunsynk write-button handler claiming Predbat "presses this on every cycle" is wrong about frequency: both press sites in `inverter.py` are change-gated (target SoC presses only when `current_soc != soc`, the export window only when `schedule_changed`), and the one unconditional post-restart re-commit is `is_hm_format`-only, which excludes these types' `HH:MM:SS` — so after a restart with the plan already matching the inverter, nothing is pressed for hours. Read the press gates in `inverter.py` before using that comment to dismiss a "component stopped writing after a restart" report. **GH#5349 (live, 2026-10-02) joins the two halves end to end:** an HA outage restarted Predbat with the control cache 35.9 minutes old, restore logged `Info: Sunsynk control cache is 35.9 minutes old (limit 15), forcing a rewrite` and dropped both halves — but nothing performs that rewrite on its own: `_reconcile_control()` gates on `control_active`, `number_event` reaches Predbat only as in-memory `update_local_schedule()` updates (no apply), and both press sites stayed change-gated, so **zero settings POSTs fired from 00:59 to 03:02** (counted from the reporter's full-API-logging log) while Predbat re-armed the hold every 5-minute cycle (reserve chasing SoC+1) and the inverter ran its 00:59 programme's idle-cap-5 slots, draining ~9 kWh (82% → 24%) into the EV until a charge-window plan change finally pressed the button at 03:02 — recovery then ran #5142's settle detection (`Warn: Sunsynk ... has not applied Predbat's settings after 4 settings polls`, fired at 03:59) and re-applied. Reading the "forcing a rewrite" line as if a rewrite follows is the trap: it is the notice that the cache was **dropped**. So a "holds lost for hours after an HA blip / battery drained while Predbat showed holds armed" report maps here on **pre-#5360 (≤ v9.3.5)** builds; since PR #5360 the ownership cache restores up to 8 hours old (`_restore_control_state()` re-sets `control_active` from the stored list), so a restart inside 8h re-arms the reconcile gate and reconcile re-applies the programme — keep the always-lost reading for pre-#5360 logs Device-visible hold legs on these types (same log): the TOU slot cap is the only one — a hold is `cap = SoC+1` in the programme (cap 65 held the battery at 64% while the car drew from grid; cap 5 drained it toward the inverter floor), and the `discharge_rate 0` entity write is symbolic on this type, so a "wrote 0 to discharge_rate but the battery drained" report reads the cap, not the entity. Also normal for this type: Sunsynk TOU charge windows cannot cross midnight (`can_span_midnight: False`) — a 23:00–00:30 window is written 23:00–23:59 and re-rolled to 00:00–00:30 at midnight (log-confirmed; not a bug). **GH#5156** (padding truncating any TOU window crossing 04:00/08:00/12:00, `build_tou_slots()` — now shared by both components in `tou_schedule.py`) is **fixed**: padding slots now carry the state of the slot they follow and sit just after it, an inert interval that cannot end a window early (`_padding_segments()` documents the issue). The pre-fix tell was "Deye stops charging at 00:00/04:00/08:00/12:00/16:00/20:00 while the Plan page still shows charging", freshly generated each cycle — not a stale default slot. **GH#5193 (cloud component, load telemetry):** on Sunsynk M3.3.8.9 the `totalPower` field (`load_power`, `SUNSYNK_TELEMETRY`) read 0–100 W through a whole overnight cycling stretch while the battery was active — including mode-2 ("Limited to Home") stretches — and read plausibly the adjacent morning with the battery idle, so the collapse correlates with the battery being active, not cleanly with the work mode; what gates it is unresolved (suspected; the reporter's manual A/B blamed the mode flip, the log's mode-2 stretches say something else does too — a controlled live test on the affected firmware is the only settle). `dailyUsed` (`load_today`) kept counting at a plausible coarse rate through the same stretch, so a balance-derived load remains feasible — and `fill_load_from_power()` is the repair that gets nothing while `totalPower` is zero. Predbat's own export control writes the whole-system `sysWorkMode` to `selling_first` for every planned export window (`derive_control_state()`, applied in the settings payload), and the component auto-wires both load args through `set_arg_auto()`'s default `overwrite=True`, so a manual apps.yaml override does NOT win — only `sunsynk_automatic: False` opts out. The in-file docstring on main records the mode/battery-export reading plus the live counter-evidence (11.1 kWh exported in a day under "Limited to Home" with `solarSell` on; a separate live test showed battery export under mode 2 with the per-slot sell flag), so the docstring's "the mode governs battery export" claim is DEYE-inferred and not settled — a control-side alternative (stay in mode 2, drive `sellTime{n}En`) stays open. The component logs every API request/response in full in `predbat.log`, so a whole Sunsynk-cloud investigation can run from the log alone; when mining logged JSON widen the field width before trusting a truncated number (`0.4` prints as `0.` under a 14-char `substr`). **Automatic config maps a battery-side current into `battery_rate_max`, and `inverter_limit` does not bound the written rate (GH#5238, code-read on main 2026-09-25/29):** `battery_rate_max()` derives watts from `chargeCurrentLimit`/`maxChargeCurrentLimit` × nominal pack voltage (`SUNSYNK_CHARGE_CURRENT_FIELDS`, first-positive-wins — a battery/BMS-side limit; GH#5238's 280 A BMS derived 14.3 kW against an 8 kW inverter), `automatic_config()` maps it to `battery_rate_max` and `ratePower` to `inverter_limit` but **never sets `inverter_limit_charge`/`inverter_limit_discharge`**, and `inverter.py` defaults both of those to `battery_rate_max_raw` when unset — so `battery_rate_max_charge = min(raw, raw) = raw`, and that is the per-slot power the plan writes. `prediction.py` clamps only *predicted* flow to `inverter_limit`; nothing feeds `inverter_limit` into the written rate. `deye.py`'s `battery_rate_max()` docstring states the same wrong assumption outright ("inverter_limit constrains the AC side separately" while deriving from `maxChargeCurrent`), and its `automatic_config()` has the same two-arg shape — so treat any "automatic config shows/writes an impossible rate" report for a cloud component through this lens first, and a fix has to map `inverter_limit_charge`/`_discharge` (to `min(ratePower, derived battery rate)`); deriving the true inverter-side current setting needs a telemetry mapping Sunsynk does not currently expose. Workaround semantics: `inverter_limit_charge`/`inverter_limit_discharge` are safe apps.yaml overrides under `sunsynk_automatic` (the component never sets them), while `battery_rate_max` is not — `set_arg_auto(overwrite=True)` clobbers an apps.yaml value every cycle. | `sunsynk_control`, `deye_control` | | |||
| | Grid sign / arrow direction | `grid_power_invert` is owned by some integrations and not others. With two systems configured, one integration setting it `True` bleeds into the other's entities and inverts the arrows. The fix is an explicit `False` in the automatic config of both. | `sunsynk_config`, `teslemetry` | | ||
| | Enphase (`enphase.py`) | Unofficial Enlighten endpoints. Accounts with MFA cannot log in at all. Discharge-to-grid schedules are required for export control. Writes need a double-submit CSRF token or return 403. Using the Enphase app at the same time can trip session limits. | `enphase_api` | | ||
| | myenergi (`myenergi.py`) | `myenergi_automatic_zappi` (PR #4997) gates the Zappi half of automatic config; with it off, Zappis stay monitor-only and `control_active` is never set. `release_zappis()` has exactly one caller — `control_tick()` — reached only under `if self.control_active:` in `run()`, and `control_active` is latched at the first tick: every `enable_control()` refusal (zappi_control → automatic → automatic_zappi → enable_controls) returns *before* setting it, and the gate re-runs only when a fresh instance starts. So after a component restart with any prerequisite off, a Zappi already held in 'Stopped' stays Stopped and the `switch.*_myenergi_zappi_control` entity is not even republished (it is gated on `control_active` too) — the symptom for a future report is "car won't charge after I turned off Predbat" with a Zappi. Note `control_tick()` itself *does* release on read-only mode and on the control switch being turned off; it is the config-gate half that strands. Since PR #5150 (merged 2026-09-19) sunsynk/deye instead persist `control_active` across a restart (and re-infer it from a pre-upgrade cache), so a restart cannot strand an already-armed inverter there — the myenergi strand is the opposite direction (the gate never latching in the first place) and remains. Two adjacent lifecycle facts: published entities are **never removed** — `dashboard_item()`/`set_state()` are upsert-only (`output.py`, `ha.py` POST `/api/states`), so when a gate stops `publish_data()` publishing a switch the old entity lingers frozen at its last state until HA restarts, and there is no entity-removal path anywhere in the codebase; and `set_arg`/`set_arg_auto` writes survive a component-only restart, because `Components.restart()` stops and re-creates only the instance and never resets the shared `base.args` from apps.yaml — auto-wired values (e.g. myenergi's `car_charging_*`) persist until a full process restart. Distinguish the two restarts when checking arg lifecycle. | `myenergi` | | ||
| | Wallbox (`wallbox.py`) | Component landed on main in PR #5410 (merged 2026-10-05, unreleased at the time of writing). Cloud API reimplemented from the Home Assistant `wallbox` integration and the `wallbox` PyPI library, over aiohttp. Findings from the first live runs (5 Oct 2026, a Pulsar Plus on firmware 6.7.43): sign in works with `User-Agent: Predbat`. **A charger run by an OCPP backend** (here Octopus, for Intelligent Octopus Go) reports `config_data.operation_mode: "ocpp"`, sits in status 209 Locked, and an API unlock (`PUT v2/charger/<id>` `{"locked": 0}`) is accepted but has no effect - so "the lock switch flips back" on such a charger is the backend, not a bug. On that locked charger a pause returned **HTTP 403** and a resume **HTTP 409**, from an account whose profile is super-admin: 403 on a control does *not* prove missing admin rights, whatever the HA integration assumes. `held_by_lock()` therefore sends neither while locked, and `held_by_ocpp()` keeps plan-led control off such a charger. `GET v3/chargers/<id>/ocpp-configuration` returns the backend address and the charge point credentials - **its reply contains a password, so never paste `--get` output unredacted**; no OCPP on/off write call is known. `locked` arrives as `1`/`0`, not a boolean, and `state_of_charge` is always null (a Type 2 connector cannot report it). Charger N is car N through `car_order`, which is numeric and append-only, so a status failure or a charger added later cannot shift it. Not yet verified on hardware when this was written: pause/resume on an unlocked, charging, non-OCPP charger; the real status ids for charging and paused; whether a 120s poll stays clear of HTTP 429. `python3 wallbox.py --username <email> --raw` is the capture tool (it prompts for the password). Release bookkeeping: `paused_by_predbat` and `schedule_pending` are stored through Storage *before* a pause is sent, a record is dropped only on a fresh status that settles it (unplugged, or connected and no longer paused), and each charger's control step is isolated in `per_charger()` so one charger's failure cannot block another - if "a charger stayed paused after control was turned off" is reported, read `release_one()` first. | | ||
| | Gateway MQTT (`gateway.py`) | Control writes are MQTT commands the hub acknowledges. **The ack design arrived with PR #5220 and was refined by PR #5231 (both merged 2026-09-26)** — both postdate every earlier gateway log, so keep a publish-per-call reading for pre-#5220 logs: `_subscribe_acks()` subscribes to `predbat/devices/<id>/ack/+`, tolerating a broker that refuses it (a single warn via `_ack_subscribe_warned`; without the subscription or before any ack, `_send_control()` publishes exactly as before); once acks are seen, an identical command (same entity, command, payload) is published once per `_COMMAND_ACK_WINDOW` (30s), re-sent once after the unanswered window, and if that re-send is also unanswered `_acks_seen` drops so writes fall back to publish-every-call until telemetry confirms; `_process_ack()` matches any tracked id of the current value, a refusal outranks an ok (a multi-unit dispatch acks once per unit), and replay errors are handled; ids come from a clock-seeded monotonic counter (`_next_command_id()`, `PBAT<n>`), so they never restart at `PBAT1` after a restart, and the kept-id list (`_COMMAND_ACK_IDS_KEPT`) is pruned only after the new send is out, with an ack that arrives during a failing publish still counting. **PR #5172 is a separate, still-open implementation of the same feature** (`_subscribe_command_acks`, `uuid4().hex` ids, typed outcomes threaded through service dispatch/HTTP/inverter verifier) — its symbols are not on main until it rebases, so do not start a gateway-ack triage from its names. **Two gaps around serial-less and empty status, probed on main 2026-09-25 (GH#5227, enhancement — probed with temporary tests in `test_gateway.py`, reverted after):** (1) a sole slot publishing `serial=""` (shipped firmware 1.0.0 publishes every slot, including a GivEnergy slot whose serial discovery failed) is bound as the control target: `_needs_reconfigure()` treats `""` as a newly discovered inverter, `_needs_reconfigure()` treats `""` as a newly discovered inverter and auto-config binds it — note the last-resort branch that used to fall back to `candidate_aios or list(all_inverters)` was removed in `eaef6e61` (2026-10-04), which now defers auto-config entirely with a warn when no battery-capable telemetry has arrived (`_auto_configured` stays False so `_needs_reconfigure()` retries); an empty-serial slot that does report battery telemetry is still bound, so the trap survives on that shape, and the result is empty-suffix entities (`select.predbat_gateway__charge_slot1_start`) and commands addressed to `""`, which the firmware rejects (`dongle_serial required`) — a real fleet incident on 2026-09-16 (~22 min of failed commands); an empty-serial guard in `_needs_reconfigure()`/`automatic_config()` would close it, and #5227's proposed `dongle_count` deferral does *not* cover this state (`dongle_count == len(inverters)` when the empty slot is the only one). (2) `if len(status.inverters) == 0: return` (`gateway.py`) fires **before** `_inject_entities()` (EV chargers, gateway-online) and before `_last_telemetry_time`/`update_success_timestamp()` — on a hub where all GivEnergy slots are withheld (post-predbat-gateway#335, e.g. a single-inverter hub), every status message is dropped: EV data freezes and the component fails the 60-minute staleness test (`components.py`). Symptom pointer: "gateway EV sensors froze / gateway component unhealthy while the hub is up" → this early return. Removals staying bound and reappearance triggering re-config are already the behaviour (probed). **Probe trap:** the topology branch in `automatic_config()` depends on the *whole* visible set — a probe that adds a Gateway alongside the `""` slot drops the `""` entry via the battery-presence filter (`aios` requires `battery.ByteSize() > 0`) so it never reaches the last-resort branch; construct the exact visible set the scenario implies, and note the filter silently hides data-less slots from the count in several branches (the same mechanism can make a Gateway+2-AIO fleet collapse to AIO-direct control). Existing precedent for topology probes: `TestGatewayUnitControlBinding` (`test_gateway.py`). | `gateway` | | ||
| | Octopus (`octopus.py`, `fetch.py`) | Intelligent Go tariffs are detected via `is_intelligent_go_tariff()`, and IOG-prefixed tariffs must be skipped when updating intelligent devices. Saving-session auto-join rebinding regressed when `joined_events` was empty (GH#4573). `octopus_slots_signature()` deliberately omits the time-drifting fields of active dispatch slots so a replan is not forced every cycle. `car_charging_threshold` is a strict fallback gated on `not self.car_charging_energy` (`fetch.py:228`, and `load_ml_component.py:348-361`) — it never runs as a second filter alongside a real `car_charging_energy` sensor (GH#4717). Saving-session reporting credits the full saving rate to every minute of the session on both rate tables (`load_saving_slot()`, `octopus.py:2786`); the slot dict has no baseline field to subtract (GH#2090) — a complaint that a saving session's reported total looks inflated starts here, not in a rate-fetch bug. A tariff with no `standard_unit_rates` link (IOG-TOU, GO) goes down `async_get_day_night_rates()`, which infers the off-peak window from 7 days of measurement TOU labels by plurality vote. On IOG those labels include ad-hoc dispatch slots, so a bonus slot recurring on 4+ of 7 nights became a permanent nightly cheap window and Predbat charged into it at the day rate (PR #4854 skips the inference for IOG). A "cheap slot Octopus has never heard of" report where the dispatch feeds are *empty* is this, not phantom dispatches — check the log for `Using off-peak windows [...] from measurement TOU labels`. TOU labels are UTC instants, so windows derived from them must be re-anchored for a local wall-clock tariff or they drift an hour at DST. Free-session slots have their own family of gates, separate from the saving-session ones and each found the hard way. `octopus_free_session` events used to be dropped when `code` was null, which is exactly how Octopus publishes auto-joined Weekend Happy Hours - fixed, the gate is now `start and end` and the log falls back to the event id (GH#4835). The free/saving-session args name **event** entities (`attribute="events"`/`"joined_events"`, `octopus.py`), and the BottlecapDave integration exposes Octoplus sessions as calendar + event pairs of which only the event entity carries those state attributes - the calendars have none at all, and both sides ship **disabled by default** in the integration. "The documented sensor name does not exist" plus a proposal to point at the `calendar.` twin is almost always the disabled-default trap, not a rename (GH#5370, verified against the integration's source): enable the event entity; the calendar twin cannot back these args. Matching calendar/event names differ by the `_events` suffix, so a pattern built from one domain's names mistranslates, and the deprecated pre-v17 names are scheduled for removal in January 2027. `load_free_slot()` bounded itself with `start_minutes < self.forecast_minutes` while rate minutes are indexed from `midnight_utc`, so any event more than `forecast_minutes` past midnight was dropped with no log line at all - fixed in `3bacc6e8`, the gate and the end clamp now both use `forecast_minutes + minutes_now` like `load_saving_slot()` (GH#4931). In the same function the start/end range was only updated on a successful decode while the apply block ran unconditionally, so an undecodable slot re-applied its rate over the *previous* slot's minute range (PR #4935). The join side has its own: the `joined_events` guard still ends in `saving_rate > 0` (`octopus.py:3542`), so `octopoints_per_kwh: 0` - a genuine free hour - yields no slot of any kind; probe-verified (0 gives nothing, 500 gives a saving slot, null gives nothing), and `git blame` puts that guard in `1b8c9136`, the fix for null-rate sessions (GH#3079), so it is an oversight rather than a deliberate exclusion (GH#4851). On dispatches, `rate_add_io_slots()`'s `location` check used to apply to *completed* dispatches too, and `rate_import` is rebuilt every cycle, so a retroactive AT_HOME to AWAY relabel silently un-stamped the cheap rate and `today_cost()` re-priced the whole day at the day rate (GH#4946) - **fixed in PR #4957**, which added `dispatch_billed_off_peak()` (`octopus.py:2977`): a completed dispatch is billed off-peak regardless of location, a straddling one keeps the location test, and the midday budget cap still applies. Keep the mechanism in mind when reading a log from before that merge, where the whole day reprices at the day rate. A neighbouring cap bug had no entry here at all: the daily low-rate slot budget was keyed on the *loop* minute rather than the slot start, so a window straddling noon drew a fresh 12-slot budget at 12:00 and stamped the afternoon cheap (GH#4950, **fixed in PR #4951**). The midday boundary itself is deliberate (`337db867`); only the keying was wrong. Worth knowing because "a cheap slot at an hour Octopus never offered" has at least three distinct causes in this row alone. Compare has its own rate-fetch gap: `download_octopus_rates_func()` (`octopus.py:2725`) reads only `standard-unit-rates`, and the newer IOG-SMB-FIX products are `four_rate_ev` - that endpoint answers 200 with empty results and the rates live on `day-unit-rates`/`night-unit-rates`. The main OctopusAPI component already auto-detects that product shape; compare never got the same treatment (GH#4921, probed against the live API). Lastly, `{dno_region}` in a tariff URL is substituted by `resolve_arg`'s `.format(**self.args)` (`userinterface.py:106-116`), so a missing `-` before the placeholder glues the region letter onto the product code and yields a plausible-looking 404 - check the literal URL in apps.yaml before believing a tariff has been withdrawn. Two later additions to the free/saving-session picture, one of them a correction. **eventType is carried only by the legacy `savingSessions` query path — the flexibility feed drops it (GH#4548, re-verified on main 2026-09-29 by reading `async_get_flexibility_events()`):** that function extracts only `code`/`startAt`/`endAt` from `customerFlexibilityCampaignEvents` and maps every saving event into `joinedEvents` with **no eventType**, so on the Direct path with an MPAN the joined-event loop's free-slot branch (`event_type == "WEEKEND_HAPPY_HOUR"`) can never fire and a joined Happy Hour falls through to the rewarded-saving-slot branch whenever `octopus_saving_session_rate` is set above 0. The legacy query carries eventType (the `savingSessions` GraphQL request names it and its map stores it) and is reached on the Direct path only as the flexibility path's own fallback (no MPAN, or the flexibility API returned no saving events). eventType remains the only sound discriminator between a Power Down saving session and a free Power Up/Happy Hour — the field GH#4851's `saving_rate > 0` problem needed and did not have — but *which query path served the events* decides whether you have it: "free Power Up priced as a paid saving session" on the flexibility path is first a question of provenance, and waiting for the BottlecapDave API before building on the newer feed is deliberate, not an oversight. The Direct join mutation is likewise still the legacy `joinSavingSessionsEvent`. And a genuinely counter-intuitive ordering constraint, worth reading before touching that function: Weekend Happy Hours are now skipped from `available_events` (they cannot be joined through the API - Octopus allocates them or the user books on the website), but **the skip has to sit after the reward/code/type maps are populated**, because those maps are built from the same events list and a joined Happy Hour looks its own type up there. Skip too early and the joined event has no type, takes the injected default reward, and the planner prices a free hour as an **80p/kWh saving session** (`c0fb4e9c`; the test fails if the skip is moved above the maps). Two rate-provenance reports from mid-September. **GH#5012** (car unplugged, plan still charged the house battery in the phantom cheap window): `octopus_intelligent_ignore_unplugged` correctly removed the planned dispatches, but the cheap price came from the integration's own rate sensor, not Predbat's stamping — parse the debug yaml and compare, per suspect minute, `rate_import_base` vs `rate_import_no_io` vs `io_adjusted`: a cheap price present in base and no_io with `io_adjusted` empty is the integration's rate sensor; present only after no_io is Predbat's `rate_add_io_slots()` stamping (#4516/#4950 family); `io_adjusted` populated means the minutes were flagged as adjusted — but **since PR #5304 (v9.3.3) Predbat's own `rate_add_io_slots()` flags the minutes it lowers too** (it used to write no marker at all; it mirrors the integration's `is_intelligent_adjusted`, never the fixed off-peak, time over the daily cap, or a cancelled car), so a populated `io_adjusted` no longer discriminates the integration's stamp from Predbat's own; the base-vs-`no_io` comparison still does, and `rate_replicate()` still refuses to copy `io_adjusted`-flagged minutes into future days. Since PR #5396 (merged 2026-10-05, unreleased at the time of writing) a minute is not marked `io_adjusted` at all when the dispatch price is within `IO_RATE_TOLERANCE` (0.01p) of what it replaced - the unrounded tariff's 5.2314p off-peak receiving a 5.23p dispatch is dp2 rounding, not a dispatch (GH#5392). This attributes "integration feeds the wrong price" vs "Predbat stamps the wrong price" in one step. Nothing reverts `io_adjusted`-flagged minutes when the car is unplugged + ignore_unplugged is on — that fix would be an enhancement, blocked in practice by the integration not flagging stale adjusted entries (`io_adjusted` was empty in this dump). **`io_adjusted` itself was for a while wiped by the export/gas fetch (GH#5286, fixed in PR #5290, merged 2026-09-28):** `fetch_octopus_rates()` replaced `self.io_adjusted` on every call, so the export and gas fetches that follow the import fetch reset it to `{}` whenever `metric_octopus_export`/`metric_octopus_gas` were set — regression from #2826 dropping the old "only when adjust_key is set" guard — and with no markers left, `dynamic_load_car_strip_feed_rates()` had nothing to strip, so a car cancelled out of a dispatch still left it priced cheap and the house battery planned into it. The fix makes `self.io_adjusted` replaced only when the fetch carries an `adjust_key`; keep the mechanism for pre-#5290 logs. A companion fix (same PR) stops a compared tariff inheriting the live tariff's dispatch markers — each compared tariff now starts with none, and one left on the live import rates gets a copy. A user who instead wants the house battery limited to minutes the car actually charges has no clean knob (GH#5065): `octopus_intelligent_charging` off does **not** stop the stamping — the switch gates only car planning and vehicle prefs, planned slots are collected into `self.octopus_slots` regardless (gated only by `octopus_intelligent_ignore_unplugged`, which covers unplugged, not plugged-in-but-deferred) and are consumed unconditionally by `rate_add_io_slots()`. `octopus_slot_max: 0` is not selective either — the cap is applied in `load_octopus_slots()` as well as `rate_add_io_slots()`, so it removes the car's charging slots too. The only complete workaround is unsetting `octopus_intelligent_slot`, which loses completed-slot tracking and Octopus car planning with it. **GH#5018** (tariff switched mid-day; tomorrow's export rates stayed on the old tariff and Nordpool estimates never appeared): Predbat re-reads Octopus rate events from HA every fetch cycle (`fetch_octopus_rates`), so stale export rates are the HA integration still serving the old contract — reload the integration. Two Predbat-side traps in the same report: `futurerate` only fills *missing* minutes (the `if minute not in rates` gate in fetch.py), so stale-but-present rates always win over Nordpool estimates; and `futurerate_adjust_auto` re-runs at every FutureRate init (one per fetch cycle) and persists via `set_arg`, so mid-switch it can persist `False` over the user's manual `futurerate_adjust_export: true` — log signature `FutureRate: No futurerate adjustment enabled, skipping futurerate analysis` repeating every cycle. The debug yaml does **not** contain the Octopus rate events (grep for `day_rates` comes up empty), so replays can't reproduce integration-served rate data; use the log's `Export rates: min/max/average` lines as the provenance check (identical min/max across days = static served data, and a fixed tariff has a fixed shape while a variable one doesn't). `self.mpan` is the **import** MPAN only — `async_find_tariffs()` sets it once from the first active import agreement's `meterPoint` and never overwrites it; an account with export has import and export as separate agreements with different MPANs, and the export one is retained nowhere (PR #4972 review). The saving-session/free-electricity GraphQL queries use `self.mpan` deliberately because those campaigns are import-side; any feature that needs to identify a *meter* cannot take `self.mpan` (PR #4972, merged 2026-09-19, adds `self.tariffs[direction]["mpan"]`). Symptom: two things that should describe different supply points coming out identical — that is this, not a deduplication bug. **GH#5144** (fixed in PR #5145): the REST tariff endpoints return overlapping `DIRECT_DEBIT`/`NON_DIRECT_DEBIT` rows for the same validity window and `minute_data()` writes each row over its range, so whichever row came last in the response won — and the order is not stable across periods, so the displayed rate could flip between variants from one period to the next ("always the higher rate" was an artefact of that ordering, not a property of the bug). `filter_payment_method()` (`utils.py`) now keeps one variant at the parse point on the component, day/night, annual and minute-data paths — preferring `DIRECT_DEBIT`, keeping rows with no `payment_method` (Agile) untouched, and leaving single-variant tariffs unchanged; null `payment_method` is the common case, so any future filter must keep nulls. **The daily cheap-slot cap is derived per account but enforced per car (GH#5215, semantics unresolved):** `get_octopus_slot_max()` (`octopus.py`) takes no `car_n` — it resolves the cap from the *account's* import tariff code via `has_six_hour_cap()` (matches `IOG-SMB` → 12) or a single apps.yaml integer — while both enforcement counters are locals (`slots_per_day` in `rate_add_io_slots()` and in `load_octopus_slots()`), and both callers run once per car, so each car draws a fresh budget: up to `octopus_slot_max × num_cars` cheap half-hours priced per day. Do **not** assume the docs' per-car sentence is simply wrong: the derivation is account-level but Octopus's own blog says "*Your car gets up to 6 hours of off-peak charging per day*" (quoted in GH#4830, the multi-car confusion thread), so the code is internally inconsistent and the intended semantics is genuinely open. Exposure is invisible outside IOG-SMB — uncapped tariffs default `octopus_slot_max` to 48 — so only capped multi-car installs can see the doubling; existing tests encode the per-car behaviour, and `octopus_slot_max` is read without `index=` so per-car configuration does not exist either way. **The IOG slot-confirmation strip removes the house's cheap rate too when a car's dispatch is cancelled (GH#5335, with the #5317 family - code chain on main 57ec7bf1):** with `octopus_intelligent_dynamic` on (default), `dynamic_load_car_check()` (`plan.py`) cancels every slot of a car that sits inside a started dispatch but is not seen charging after the confirmation grace (log: `car 0 is in a dispatch but not charging, cancelling its slots`), and `dynamic_load_car_strip_feed_rates()` (`octopus.py`) re-prices the house's view of those minutes back to `rate_max_base` when the cheapness came from the integration feed, **exempting the fixed IOG band** (`OCTOPUS_NIGHT_RATE_WINDOWS["iog"]` = 23:30–05:30) — so a house battery that had planned into the dispatch loses its cheap stamp as well, and PV10 re-prices the minutes at `rate_max` outright (prediction.py's `dispatch_gone` line, `minute > 30`). Version tell: the strip is v9.3.2+ code — a reporter's deliberate mid-log downgrade left the A/B in one `predbat.log`: v9.3.3 logged `Octopus Intelligent: removed the dispatch rate from 355 minutes of cars [0] which are not charging` while v9.3.1 kept the 6.57p dispatch rate (`Charging target 2%-100%`); workaround (semantics read, not live-tested): `octopus_intelligent_dynamic` off = no confirmation and no strip, ≈9.3.1 behaviour at the cost of #5229's low-load protection. Check the car side first, though: Predbat must *see* the car charging to confirm the slot, and a `plug_status` string (`eco`/`boost`) that never equals `car_charging_now_response: charging` leaves the car "not charging" through a real charge — check the sensor's own history before blaming the planner. **#5316 is the mid-dispatch variant, fixed in PR #5319 (merged 2026-10-03) — keep the pre-#5319 signature:** a car that stops part-way through a running dispatch half hour used to have the rest of that half hour re-priced at the day rate; the strip paths (`rate_add_io_slots()`, `dynamic_load_car_strip_feed_rates()`) now start from `dynamic_load_car_strip_from()` (`plan.py`) — the end of the half hour the car was last seen charging in, which is billed off-peak in full by Octopus — and the confirmation is never cleared, only outlived. Review-round refinements ride along: a sensor reading confirms a half hour only from 2 minutes into it, and the grace clock is not kept across a restart (saved state is judged on the skewed clock). The bounce symptom itself — the battery flipping Charge↔Demand while a car charges in bursts — is the supervision working as coded (GH#5390, log-verified): a non-"charging" reading counts after `DYNAMIC_LOAD_CAR_START_MINUTES` (3 min) inside the dispatch, the cheap dispatch rate is stripped from the car's still-future slots (house plan re-prices those minutes) and it resumes on the next "charging" reading — ground-truth with the hourly `Last hour: ... car X kWh` log lines against Octopus's own per-slot amounts before calling it a bug. **The completed-dispatch cheap stamp lives only as long as the integration's dispatch feed carries the session (GH#5413, reporter log + yaml, 2026-10-05):** `rate_add_io_slots()` stamps completed dispatches deliberately (`dispatch_billed_off_peak()` exempts `end_minutes <= minutes_now`, and the fetch merges `completed_dispatches` unconditionally), but the integration withdrawing the dispatches when a session closes removes the stamp retroactively (`io_adjusted` reads empty, `rate_import`/`rate_max` all back at the day rate hours later) and the plan-History re-render derives past minutes from the **current** rate tables (`history_to_future_rates(self.rate_import, ...)`, and `today_cost()` re-prices today-so-far), so the flip is the display of the un-stamped arrays - no persistence of applied rates exists (open GH#2785, PR #3340 parked); the narrower fix is persisting the stamped/completed minutes. A tell from the same log worth keeping: those midday dispatches were visible only from their own start minute, so a "cheap slot Octopus never offered" question on an *ad-hoc* dispatch is different from the overnight band, which is visible hours ahead. **Octopus Intelligent devices freeze in place once the account leaves an Intelligent tariff (GH#5412, probe-verified on main 2026-10-05, still live):** `async_update_intelligent_devices()` returns before polling when the import tariffCode is not Intelligent, so the live-set pruning never runs off-IOG and everything built while on the Intelligent tariff persists - `automatic_config()` wires from `self.intelligent_devices` tariff-blind, the storage cache round-trips the devices, `fetch_sensor_data_car_planning()` keeps taking the Intelligent branch and rebuilding `self.octopus_slots` from the frozen entities' dispatch attributes every cycle, and `rate_add_io_slots()` keeps stamping completed dispatches (with the ~96h look-back) - the Ohme half flips `octopus_intelligent_wanted()` false on the new tariff but `charger_slots_wanted()` refuses while `octopus_intelligent_slot` still points at the frozen Octopus entity, so the #5401 charger-schedule mode stays blocked until the wiring is cleared by hand. #5405's owner re-wire (`car_slots_released_to_us()`) treats the not-refreshed device list as a live constraint on purpose - it refuses to re-wire off an Intelligent tariff, which is the same freeze acknowledged, not removed. **A related clobber to read before any "my manual octopus_intelligent_slot keeps reverting" report:** with `octopus_automatic: true`, `set_arg()` overwrites unconditionally and `automatic_config()` re-wires whenever the device dict is non-empty, so a user's own apps.yaml entity is replaced on the first run after every restart; since #5405 only the *empty-set clearing* respects foreign wiring (it checks the wiring is still what Octopus itself last wrote) - "the user is not affected" holds only under `octopus_automatic: false`. **Weekend Happy Hour / Power Up booking is not implemented (GH#5404, enhancement, 2026-10-05):** Predbat reads only the booked/allocated side (the free-session `events` attribute and `joined_events` with `event_type` WEEKEND_HAPPY_HOUR → `octopus_free_slots`); `available_events` is consumed only by the Power Down auto-join loop (`join_octoplus_power_down_session_event` plus the deprecated saving-session fallback, #4593) and WHH entries never reach it - they are skipped at the source (cannot be joined through the API - Octopus allocates them or the user books on the website) and Power Up entries ride in `available_events` at 0 octopoints, skipped by the min-octopoints guard; no WHH join service exists anywhere. If a join half is ever built, the saving-session auto-join block is the template and Power Up needs a slot *choice* among 2-3 candidates, with an explicit rule for weekend slots released Thursday that partly sit beyond the 48h horizon; the `events` attribute carries both available (code set) and auto-joined (`code` null) entries and the free-session path zero-rates them all regardless of booking state. | `octopus_*`, `saving_session*` | | ||
| | Octopus (`octopus.py`, `fetch.py`) | Intelligent Go tariffs are detected via `is_intelligent_go_tariff()`, and IOG-prefixed tariffs must be skipped when updating intelligent devices. Saving-session auto-join rebinding regressed when `joined_events` was empty (GH#4573). `octopus_slots_signature()` deliberately omits the time-drifting fields of active dispatch slots so a replan is not forced every cycle. `car_charging_threshold` is a strict fallback gated on `not self.car_charging_energy` (`fetch.py:228`, and `load_ml_component.py:348-361`) — it never runs as a second filter alongside a real `car_charging_energy` sensor (GH#4717). Saving-session reporting credits the full saving rate to every minute of the session on both rate tables (`load_saving_slot()`, `octopus.py:2786`); the slot dict has no baseline field to subtract (GH#2090) — a complaint that a saving session's reported total looks inflated starts here, not in a rate-fetch bug. A tariff with no `standard_unit_rates` link (IOG-TOU, GO) goes down `async_get_day_night_rates()`, which infers the off-peak window from 7 days of measurement TOU labels by plurality vote. On IOG those labels include ad-hoc dispatch slots, so a bonus slot recurring on 4+ of 7 nights became a permanent nightly cheap window and Predbat charged into it at the day rate (PR #4854 skips the inference for IOG). A "cheap slot Octopus has never heard of" report where the dispatch feeds are *empty* is this, not phantom dispatches — check the log for `Using off-peak windows [...] from measurement TOU labels`. TOU labels are UTC instants, so windows derived from them must be re-anchored for a local wall-clock tariff or they drift an hour at DST. Free-session slots have their own family of gates, separate from the saving-session ones and each found the hard way. `octopus_free_session` events used to be dropped when `code` was null, which is exactly how Octopus publishes auto-joined Weekend Happy Hours - fixed, the gate is now `start and end` and the log falls back to the event id (GH#4835). The free/saving-session args name **event** entities (`attribute="events"`/`"joined_events"`, `octopus.py`), and the BottlecapDave integration exposes Octoplus sessions as calendar + event pairs of which only the event entity carries those state attributes - the calendars have none at all, and both sides ship **disabled by default** in the integration. "The documented sensor name does not exist" plus a proposal to point at the `calendar.` twin is almost always the disabled-default trap, not a rename (GH#5370, verified against the integration's source): enable the event entity; the calendar twin cannot back these args. Matching calendar/event names differ by the `_events` suffix, so a pattern built from one domain's names mistranslates, and the deprecated pre-v17 names are scheduled for removal in January 2027. `load_free_slot()` bounded itself with `start_minutes < self.forecast_minutes` while rate minutes are indexed from `midnight_utc`, so any event more than `forecast_minutes` past midnight was dropped with no log line at all - fixed in `3bacc6e8`, the gate and the end clamp now both use `forecast_minutes + minutes_now` like `load_saving_slot()` (GH#4931). In the same function the start/end range was only updated on a successful decode while the apply block ran unconditionally, so an undecodable slot re-applied its rate over the *previous* slot's minute range (PR #4935). The join side has its own: the `joined_events` guard still ends in `saving_rate > 0` (`octopus.py:3542`), so `octopoints_per_kwh: 0` - a genuine free hour - yields no slot of any kind; probe-verified (0 gives nothing, 500 gives a saving slot, null gives nothing), and `git blame` puts that guard in `1b8c9136`, the fix for null-rate sessions (GH#3079), so it is an oversight rather than a deliberate exclusion (GH#4851). On dispatches, `rate_add_io_slots()`'s `location` check used to apply to *completed* dispatches too, and `rate_import` is rebuilt every cycle, so a retroactive AT_HOME to AWAY relabel silently un-stamped the cheap rate and `today_cost()` re-priced the whole day at the day rate (GH#4946) - **fixed in PR #4957**, which added `dispatch_billed_off_peak()` (`octopus.py:2977`): a completed dispatch is billed off-peak regardless of location, a straddling one keeps the location test, and the midday budget cap still applies. Keep the mechanism in mind when reading a log from before that merge, where the whole day reprices at the day rate. A neighbouring cap bug had no entry here at all: the daily low-rate slot budget was keyed on the *loop* minute rather than the slot start, so a window straddling noon drew a fresh 12-slot budget at 12:00 and stamped the afternoon cheap (GH#4950, **fixed in PR #4951**). The midday boundary itself is deliberate (`337db867`); only the keying was wrong. Worth knowing because "a cheap slot at an hour Octopus never offered" has at least three distinct causes in this row alone. Compare has its own rate-fetch gap: `download_octopus_rates_func()` (`octopus.py:2725`) reads only `standard-unit-rates`, and the newer IOG-SMB-FIX products are `four_rate_ev` - that endpoint answers 200 with empty results and the rates live on `day-unit-rates`/`night-unit-rates`. The main OctopusAPI component already auto-detects that product shape; compare never got the same treatment (GH#4921, probed against the live API). Lastly, `{dno_region}` in a tariff URL is substituted by `resolve_arg`'s `.format(**self.args)` (`userinterface.py:106-116`), so a missing `-` before the placeholder glues the region letter onto the product code and yields a plausible-looking 404 - check the literal URL in apps.yaml before believing a tariff has been withdrawn. Two later additions to the free/saving-session picture, one of them a correction. **eventType is carried only by the legacy `savingSessions` query path — the flexibility feed drops it (GH#4548, re-verified on main 2026-09-29 by reading `async_get_flexibility_events()`):** that function extracts only `code`/`startAt`/`endAt` from `customerFlexibilityCampaignEvents` and maps every saving event into `joinedEvents` with **no eventType**, so on the Direct path with an MPAN the joined-event loop's free-slot branch (`event_type == "WEEKEND_HAPPY_HOUR"`) can never fire and a joined Happy Hour falls through to the rewarded-saving-slot branch whenever `octopus_saving_session_rate` is set above 0. The legacy query carries eventType (the `savingSessions` GraphQL request names it and its map stores it) and is reached on the Direct path only as the flexibility path's own fallback (no MPAN, or the flexibility API returned no saving events). eventType remains the only sound discriminator between a Power Down saving session and a free Power Up/Happy Hour — the field GH#4851's `saving_rate > 0` problem needed and did not have — but *which query path served the events* decides whether you have it: "free Power Up priced as a paid saving session" on the flexibility path is first a question of provenance, and waiting for the BottlecapDave API before building on the newer feed is deliberate, not an oversight. The Direct join mutation is likewise still the legacy `joinSavingSessionsEvent`. And a genuinely counter-intuitive ordering constraint, worth reading before touching that function: Weekend Happy Hours are now skipped from `available_events` (they cannot be joined through the API - Octopus allocates them or the user books on the website), but **the skip has to sit after the reward/code/type maps are populated**, because those maps are built from the same events list and a joined Happy Hour looks its own type up there. Skip too early and the joined event has no type, takes the injected default reward, and the planner prices a free hour as an **80p/kWh saving session** (`c0fb4e9c`; the test fails if the skip is moved above the maps). Two rate-provenance reports from mid-September. **GH#5012** (car unplugged, plan still charged the house battery in the phantom cheap window): `octopus_intelligent_ignore_unplugged` correctly removed the planned dispatches, but the cheap price came from the integration's own rate sensor, not Predbat's stamping — parse the debug yaml and compare, per suspect minute, `rate_import_base` vs `rate_import_no_io` vs `io_adjusted`: a cheap price present in base and no_io with `io_adjusted` empty is the integration's rate sensor; present only after no_io is Predbat's `rate_add_io_slots()` stamping (#4516/#4950 family); `io_adjusted` populated means the minutes were flagged as adjusted — but **since PR #5304 (v9.3.3) Predbat's own `rate_add_io_slots()` flags the minutes it lowers too** (it used to write no marker at all; it mirrors the integration's `is_intelligent_adjusted`, never the fixed off-peak, time over the daily cap, or a cancelled car), so a populated `io_adjusted` no longer discriminates the integration's stamp from Predbat's own; the base-vs-`no_io` comparison still does, and `rate_replicate()` still refuses to copy `io_adjusted`-flagged minutes into future days. This attributes "integration feeds the wrong price" vs "Predbat stamps the wrong price" in one step. Nothing reverts `io_adjusted`-flagged minutes when the car is unplugged + ignore_unplugged is on — that fix would be an enhancement, blocked in practice by the integration not flagging stale adjusted entries (`io_adjusted` was empty in this dump). **`io_adjusted` itself was for a while wiped by the export/gas fetch (GH#5286, fixed in PR #5290, merged 2026-09-28):** `fetch_octopus_rates()` replaced `self.io_adjusted` on every call, so the export and gas fetches that follow the import fetch reset it to `{}` whenever `metric_octopus_export`/`metric_octopus_gas` were set — regression from #2826 dropping the old "only when adjust_key is set" guard — and with no markers left, `dynamic_load_car_strip_feed_rates()` had nothing to strip, so a car cancelled out of a dispatch still left it priced cheap and the house battery planned into it. The fix makes `self.io_adjusted` replaced only when the fetch carries an `adjust_key`; keep the mechanism for pre-#5290 logs. A companion fix (same PR) stops a compared tariff inheriting the live tariff's dispatch markers — each compared tariff now starts with none, and one left on the live import rates gets a copy. A user who instead wants the house battery limited to minutes the car actually charges has no clean knob (GH#5065): `octopus_intelligent_charging` off does **not** stop the stamping — the switch gates only car planning and vehicle prefs, planned slots are collected into `self.octopus_slots` regardless (gated only by `octopus_intelligent_ignore_unplugged`, which covers unplugged, not plugged-in-but-deferred) and are mostly consumed unconditionally by `rate_add_io_slots()` — since PR #5403 (v9.3.6) the expert `octopus_intelligent_consider_full` switch (default False) does supply car-needless future dispatch minutes (`octopus_surplus_minutes()`) that `rate_add_io_slots()` skips (octopus.py, the `minute in self.octopus_surplus` guard), but the gate deliberately cannot withhold the current half hour (`octopus_surplus_from()`: the car may already have charged in it) and the switch is off by default, so stamping remains the default path (GH#5424 symptom row above). `octopus_slot_max: 0` is not selective either — the cap is applied in `load_octopus_slots()` as well as `rate_add_io_slots()`, so it removes the car's charging slots too. The only complete workaround is unsetting `octopus_intelligent_slot`, which loses completed-slot tracking and Octopus car planning with it. **GH#5018** (tariff switched mid-day; tomorrow's export rates stayed on the old tariff and Nordpool estimates never appeared): Predbat re-reads Octopus rate events from HA every fetch cycle (`fetch_octopus_rates`), so stale export rates are the HA integration still serving the old contract — reload the integration. Two Predbat-side traps in the same report: `futurerate` only fills *missing* minutes (the `if minute not in rates` gate in fetch.py), so stale-but-present rates always win over Nordpool estimates; and `futurerate_adjust_auto` re-runs at every FutureRate init (one per fetch cycle) and persists via `set_arg`, so mid-switch it can persist `False` over the user's manual `futurerate_adjust_export: true` — log signature `FutureRate: No futurerate adjustment enabled, skipping futurerate analysis` repeating every cycle. The debug yaml does **not** contain the Octopus rate events (grep for `day_rates` comes up empty), so replays can't reproduce integration-served rate data; use the log's `Export rates: min/max/average` lines as the provenance check (identical min/max across days = static served data, and a fixed tariff has a fixed shape while a variable one doesn't). `self.mpan` is the **import** MPAN only — `async_find_tariffs()` sets it once from the first active import agreement's `meterPoint` and never overwrites it; an account with export has import and export as separate agreements with different MPANs, and the export one is retained nowhere (PR #4972 review). The saving-session/free-electricity GraphQL queries use `self.mpan` deliberately because those campaigns are import-side; any feature that needs to identify a *meter* cannot take `self.mpan` (PR #4972, merged 2026-09-19, adds `self.tariffs[direction]["mpan"]`). Symptom: two things that should describe different supply points coming out identical — that is this, not a deduplication bug. **GH#5144** (fixed in PR #5145): the REST tariff endpoints return overlapping `DIRECT_DEBIT`/`NON_DIRECT_DEBIT` rows for the same validity window and `minute_data()` writes each row over its range, so whichever row came last in the response won — and the order is not stable across periods, so the displayed rate could flip between variants from one period to the next ("always the higher rate" was an artefact of that ordering, not a property of the bug). `filter_payment_method()` (`utils.py`) now keeps one variant at the parse point on the component, day/night, annual and minute-data paths — preferring `DIRECT_DEBIT`, keeping rows with no `payment_method` (Agile) untouched, and leaving single-variant tariffs unchanged; null `payment_method` is the common case, so any future filter must keep nulls. **The daily cheap-slot cap is derived per account but enforced per car (GH#5215, semantics unresolved):** `get_octopus_slot_max()` (`octopus.py`) takes no `car_n` — it resolves the cap from the *account's* import tariff code via `has_six_hour_cap()` (matches `IOG-SMB` → 12) or a single apps.yaml integer — while both enforcement counters are locals (`slots_per_day` in `rate_add_io_slots()` and in `load_octopus_slots()`), and both callers run once per car, so each car draws a fresh budget: up to `octopus_slot_max × num_cars` cheap half-hours priced per day. Do **not** assume the docs' per-car sentence is simply wrong: the derivation is account-level but Octopus's own blog says "*Your car gets up to 6 hours of off-peak charging per day*" (quoted in GH#4830, the multi-car confusion thread), so the code is internally inconsistent and the intended semantics is genuinely open. Exposure is invisible outside IOG-SMB — uncapped tariffs default `octopus_slot_max` to 48 — so only capped multi-car installs can see the doubling; existing tests encode the per-car behaviour, and `octopus_slot_max` is read without `index=` so per-car configuration does not exist either way. **The IOG slot-confirmation strip removes the house's cheap rate too when a car's dispatch is cancelled (GH#5335, with the #5317 family - code chain on main 57ec7bf1):** with `octopus_intelligent_dynamic` on (default), `dynamic_load_car_check()` (`plan.py`) cancels every slot of a car that sits inside a started dispatch but is not seen charging after the confirmation grace (log: `car 0 is in a dispatch but not charging, cancelling its slots`), and `dynamic_load_car_strip_feed_rates()` (`octopus.py`) re-prices the house's view of those minutes back to `rate_max_base` when the cheapness came from the integration feed, **exempting the fixed IOG band** (`OCTOPUS_NIGHT_RATE_WINDOWS["iog"]` = 23:30–05:30) — so a house battery that had planned into the dispatch loses its cheap stamp as well, and PV10 re-prices the minutes at `rate_max` outright (prediction.py's `dispatch_gone` line, `minute > 30`). Version tell: the strip is v9.3.2+ code — a reporter's deliberate mid-log downgrade left the A/B in one `predbat.log`: v9.3.3 logged `Octopus Intelligent: removed the dispatch rate from 355 minutes of cars [0] which are not charging` while v9.3.1 kept the 6.57p dispatch rate (`Charging target 2%-100%`); workaround (semantics read, not live-tested): `octopus_intelligent_dynamic` off = no confirmation and no strip, ≈9.3.1 behaviour at the cost of #5229's low-load protection. Check the car side first, though: Predbat must *see* the car charging to confirm the slot, and a `plug_status` string (`eco`/`boost`) that never equals `car_charging_now_response: charging` leaves the car "not charging" through a real charge — check the sensor's own history before blaming the planner. **#5316 is the mid-dispatch variant, fixed in PR #5319 (merged 2026-10-03) — keep the pre-#5319 signature:** a car that stops part-way through a running dispatch half hour used to have the rest of that half hour re-priced at the day rate; the strip paths (`rate_add_io_slots()`, `dynamic_load_car_strip_feed_rates()`) now start from `dynamic_load_car_strip_from()` (`plan.py`) — the end of the half hour the car was last seen charging in, which is billed off-peak in full by Octopus — and the confirmation is never cleared, only outlived. Review-round refinements ride along: a sensor reading confirms a half hour only from 2 minutes into it, and the grace clock is not kept across a restart (saved state is judged on the skewed clock). The bounce symptom itself — the battery flipping Charge↔Demand while a car charges in bursts — is the supervision working as coded (GH#5390, log-verified): a non-"charging" reading counts after `DYNAMIC_LOAD_CAR_START_MINUTES` (3 min) inside the dispatch, the cheap dispatch rate is stripped from the car's still-future slots (house plan re-prices those minutes) and it resumes on the next "charging" reading — ground-truth with the hourly `Last hour: ... car X kWh` log lines against Octopus's own per-slot amounts before calling it a bug. | `octopus_*`, `saving_session*` | |
| @@ -133,7 +133,7 @@ Grep for the named symbol rather than trusting a line number. | |||
| | Savings & metrics (`output.py`, `predbat.py`) | `savings_total_predbat` accumulates the **unadjusted** `saving` (`predbat.py:1183`, fed from `self.savings_today_predbat = saving` in `output.py`) while `savings_yesterday_predbat` publishes `saving_adjusted` (`output.py:3380`) — the two sensors answer different questions and can disagree in sign on the same day (confirmed from a reporter's dump: `saving_real: +86.14p` vs `saving_adjusted: -25.66p`, GH#3894). Both are still current on `main`. Separately, the battery-value adjustment bills the SoC **level** at day-end against the counterfactual baseline rather than the **change** in SoC over the day — a day that force-exports through midnight can be energy-neutral yet still get charged the full baseline-vs-actual SoC gap as if it were lost value. | none | | |||
| | GivTCP REST (`inverter.py`) | **Structurally stale as written, and left here for the mechanism only:** PR #4864 moved REST handling out into `givtcp.py`/`givtcp_rest.py`, so `update_status()` (now `inverter.py:1333`) no longer reads `Power.Power` at `inverter.py:1435` at all. What survives is the same trap one layer up - the component's auto-config claims the power keys unless `givtcp_rest_power_ignore` is set, and it now logs an Info line when you opt out (`givtcp.py:766-767`). PR #4959 also lets an apps.yaml-named energy sensor win over auto-configuration for the history-read keys. Historically, with `givtcp_rest` configured `update_status()` read PV/Grid/Load power straight out of the REST `Power.Power` block; the apps.yaml entity lists - including any `0` placeholders put there deliberately to zero a duplicate reading - are only consulted on the non-REST `else` branch, and `execute.py` then sums every inverter's REST readings. On a hybrid + AIO pair that presents as the AIO's hybrid-fed PV port counted as solar at night, and both units' shared-CT grid readings summed (~7.1 kW shown for ~3.6 kW of real export). The per-inverter `givtcp_rest_power_ignore: true` restores the apps.yaml lists and is already documented in `docs/apps-yaml.md` - the gap is that nothing warns when a `0` placeholder is silently bypassed (GH#4883). Two v9.0.x notes since the refactor. **GH#4993 (still live on main, b8996659):** the component's required `rest_urls` arg is resolved straight from `givtcp_rest` (`components.py`) and the stock `config/apps.yaml` ships `givtcp_rest:` uncommented with example URLs, while the registry's `"inverter": True` flag is documentation-only and nothing reads it - so every install using the template, GivEnergy or not, starts a GivTCP REST component that fails discovery (`num_entities: 0`), hammers two dead URLs and shows "GivTCP REST: Error / Never updated" in the Components panel. Discovered inverters stay at zero so `automatic_config()` skips and no Predbat args get hijacked - the damage is log spam and panel error, not wrong control. Workaround: comment out the whole `givtcp_rest:` block, and any uncommented `givtcp_automatic:` line with it, because leaving that set while `givtcp_rest` is absent trips the `Warn: Skipping GivTCP REST interface, missing required configuration: givtcp_rest` gate. **GH#4984 (fixed by the refactor, keep for older logs):** `Warn: Inverter N REST failed to setDischargeRate to <X> got <X>` where *got equals the requested rate* is a zero verification tolerance, not a failed write - pre-#4864 the read-back tolerance was sized from `battery_rate_max_discharge`/`charge`, which an `inverter_limit_discharge`/`inverter_limit_charge` API override of 0 (users reach for it as "manual rate 0"; it is in `CONFIG_API_OVERRIDE`) drives to 0 against a strict `<`, so an exact read-back fails, burns the 5 `INVERTER_MAX_RETRY_REST` posts (~2s apart, the 4-5 runs users see in the GivTCP log) and flags the whole run "Demand with Errors". Only fires when something else set the real rate away from the target first, otherwise `adjust_discharge_rate`'s change-gate skips the write. The refactor re-sized the tolerance from `write_tolerance_watts()` - the max rate GivTCP itself reports (`Invertor_Max_Bat_Rate`), falling back to 2600W - and the entity write path uses `<=`, so an exact match passes; the charge-rate variant #2882 (still open) does not match this trap's signature — it is a ~1 kW read-back miss (3600 written, 2560 got), not got==requested — and maps instead to the GH#5386 family appended below. **GH#5101 (still live):** `initialize()` builds one `InverterRestState(id=n, rest_api=url)` per `givtcp_rest` entry with no URL-shape validation (`givtcp.py`), so a YAML mapping indented into the list during an apps.yaml edit becomes `rest_api=<dict>` and `read_data()`'s first line (`url = inverter.rest_api + "/" + api`, `givtcp_rest.py`) raises `TypeError: unsupported operand type(s) for +: 'dict' and 'str'`, caught by `ComponentBase.start()` and logged with no index or URL. Signature: the `discovered N inverter(s) from M configured REST endpoint(s)` line never appears anywhere in the log (discovery settles only after the poll loop completes), and the malformed entry itself produces no `Errno 22` retries because it dies before `get_data()` — valid-but-dead string entries ahead of it produce the full ladder, so Errno-22 count = 5 attempts × completed poll cycles. The component never reports started; the main loop keeps working off the user's own apps.yaml entities. The whole class is new with the v9 component — v8.55 read `givtcp_rest` with `index=self.id`, so stray extra entries were inert on single-inverter installs. Also from GH#5099: nothing in the repo sets `battery_calibration` automatically — the component publishes the sensor from GivTCP's own detection but expects an apps.yaml mapping — and Predbat reads the arg's state as calibrating only when it is literally `on`/`On`/`true`/`True` (`inverter.py`), while GivTCP's detection is `Battery_Calibration != "Off"` (`givtcp_rest.py`); anyone wiring a multi-valued select into `battery_calibration` must reconcile the two. and because `refresh_config()` re-samples the arg every cycle (the objects persist since PR #5126, but the per-cycle re-read survives — see the args trap in "Traps when investigating"), `in_calibration` is re-sampled per cycle, not init-only. Another manual-vs-auto split (GH#5132): the `discharge_target_soc` write is the force-export hardware backstop - always `int(self.reserve_percent)`, never the plan's per-window export limit (that floor is software-only in `execute.py`) - and the #4517 unsupported-model guard (`DISCHARGE_TARGET_UNSUPPORTED_MODELS`/`_TYPES`, givtcp.py) runs only in the **auto-config** path, where it stops Predbat publishing the entity at all. A user on the **manual** entity-list path gets the entity from the GivTCP add-on instead, so the guard never engages: on an AIO whose add-on write handler for `number.givtcp_*_discharge_target_soc_1` is a silent no-op (diagnosed live - manual `number.set_value` did nothing and produced zero GivTCP log lines), Predbat warned `didn't complete got 4.0` every cycle for 14h. The write is skipped when the arg is absent by design, so **removing `discharge_target_soc` from apps.yaml is the first workaround on any version and either path**. Setup tell: manual-path apps.yaml lists `discharge_target_soc: - number.givtcp_*`; auto-config users don't. (Version trap from the same issue: the issue body said v8.54.3, the attached log's own version lines said v9.0.3 - the log wins.) **GH#5178 (enhancement, live on main):** whenever `givtcp_rest` is configured the component publishes its **full** entity surface unconditionally — ~44 entities per inverter — regardless of whether the GivTCP HA integration already provides equivalents; deliberate, so REST-only setups have entities at all. A "Predbat created N duplicate GivTCP entities" report maps here and is a feature request: the count is checkable as (GIVTCP_SENSORS + GIVTCP_CONTROLS − per-fleet withheld) × inverter count (44×3 = 132 in #5178, matched), the user-side workaround is an HA recorder exclusion glob `*.predbat_givtcp_*` plus hiding (safe — the four history keys keep the user's own sensors, USER_WINS), and `docs/components.md` has no GivTCP REST section yet. Related live gap (code-read, #5178's reporter's debug yaml): `automatic_config()` claims `discharge_target_soc` gated on rest_v3 alone (`givtcp.py`), while `publish_data()` additionally withholds the entity for `DISCHARGE_TARGET_UNSUPPORTED_MODELS`/`_TYPES` — on an unsupported-model fleet the arg points at `number.predbat_givtcp_N_discharge_target_soc` entities that are never created; benign so far (inverter.py leaves an unreadable discharge target alone, `No current discharge target to read`), fix shape = consult the same unsupported-model set or `published_discovery` like the discovery keys do. **GH#5209 (fixed in PR #5216; mechanism kept for pre-#5216 logs):** pre-#5216 `automatic_config()` filled every per-inverter arg list **positionally** from `discovered`, so an endpoint down at the discovery pass shifted every later endpoint down one slot, and `rediscover()`'s deliberate append-only recovery turned the shift into a rotation on recovery — recovery did not heal. Writes route by the index embedded in the entity id (`_parse_entity`), so the misroute reaches hardware; log signature `Inverter 1 current charge rate is 3000W and new target is 2600W` paired with `GivTCP: Inverter 2 set charge rate 2600 via REST successful` alternating each cycle, plus `battery_calibration ... has 2 entries, expected 3` / `Out of range index 2` for claimed-but-user-unconfigured keys (`_keep_configured_tail()` returned the short list unchanged when `_configured_value()` was None — only those keys warned while the user's own apps.yaml lists got their tail preserved). Debug-yaml diagnosis: any `predbat_givtcp_<n>_*` entry whose list position is not `<n>`. Workarounds at any version: restart Predbat once every endpoint answers, or `givtcp_automatic: False`. Design note on the fix: at startup a dead leading endpoint cannot be told apart from a leading placeholder URL, and #5216 chooses identity-by-index — `givtcp_rest: [dead, live]` becomes two inverters, not one (`num_inverters` cannot arbitrate; the GivTCP template tells REST users to delete it). **One design rule left by #5216's own development:** during the PR's cleanup it was found that the re-probe adoption pass judged every `published_discovery` gate before the adopted endpoint had published anything — `run()` calls `publish_data()`, then `rediscover()` appends the newly answering index, then `automatic_config()` re-runs because `discovered != configured_for`, so each `all(key in self.published_discovery.get(n, set()) for n in discovered)` gate failed on the adoption cycle and discovery-gated keys (`soc_max`, `battery_calibration`, `inverter_limit`, …) were skipped or handed back while the gates reading `rest_data` directly (`rest_v3`, `pause_mode_supported`, …) judged correctly. The merged PR re-publishes after a fleet-growing `rediscover()` (`givtcp.py`, the `if rediscover:` block) and adds a claim hand-back (`self.claimed_from`), and that ordering is the rule for anyone touching the path: **any gate over `published_discovery` must not be judged in the cycle where `rediscover()` appended an index.** On pre-#5216 builds (no hand-back, no wait) a *tail* endpoint adopted late never has its discovery keys claimed at all — suspected, unverified against a build without the PR — so a "late GivTCP inverter shows 8 kWh / no calibration sensor until restart" report on an older build maps here. **A missing inverter-details block silently stales the published sensors and fakes a clock-skew alarm (GH#5334, code-read on main 57ec7bf1):** `inverter_details()` (givtcp_rest.py) has no log and returns `{}` when `Invertor_Details` is empty (normal on v3) and `raw.invertor.serial_number` is null, which is exactly the Gateway/EMS shape upstream omits from `/readData` (britkat1980/giv_tcp#597 is the upstream fix, unmerged at triage time); `publish_data()` then gates each detail-block sensor on presence — `inverter_time`, `soc_max`, `battery_rate_max`, `inverter_limit` — so HA keeps the entity's *last* state frozen and stale looks identical to live, while `serial_number` itself is published unconditionally: **the discriminating tell is the serial sensor reading unknown while inverter_time stays frozen**. Predbat reads that frozen `inverter_time` and `check_clock_skew()` (inverter.py) crosses the ≥30-min restart threshold every cycle — repeating `Warn: Inverter time is <old>, Predbat computer time <now>, this is <growing> minutes skewed` and `Warn: Inverter control auto restart trigger: Clock skew >= 30 minutes command []` (empty `command` = no `auto_restart` configured) with the inverter clock actually fine — not the clock, not HA time sync. Fix shapes discussed, maintainer's call: a per-cycle warn when the details block resolves empty; a fallback lookup over top-level dict blocks for `Invertor_Serial_Number`/`Invertor_Time` (unambiguous only at exactly one candidate); or the cheapest anti-misdiagnosis — publish an explicit `unknown`/`unavailable` `inverter_time` instead of skipping, which `Inverter` already treats as "no reading" and skips skew detection for without a restart trigger. Any "Predbat-published entity looks frozen but claims to be live" report on a REST-backed component is a candidate for this same `if value:` publish-gate class. **GH#5386 (2026-10-04, open) — a read-back miss larger than the REST verify tolerance never converges:** the REST verify compares within `write_tolerance_watts()/12` (charge) and `/25` (discharge), where `write_tolerance_watts()` is the max rate GivTCP itself reports (`Invertor_Max_Bat_Rate`, 2600 W fallback); the reporter's 6000 W write read back 5100 while GivTCP's own log said the POST succeeded, so every ~2s retry and every cycle re-warns, and the entity-level deadband (`rate_tolerances()`'s one-step `fuzzy_below`) cannot cover a ~9-step miss either. Predbat's REST mirror entities **are** the read-back, so the debug yaml alone (mirror state vs the target) proves non-convergence without GivTCP logs. Why the register sits at 5100 is open — a stale cached Control read vs a firmware/BMS cap (the mirror's own max attribute says 6000, inconsistent with a pure cap) — and the suspected fix shape (accept GivTCP's POST success, a Solis-style `verify_settle_seconds` re-read, or sizing the tolerance to the firmware cap) is untested. Family so far: #5324 (exactly one rounding step; fixed by PR #5348's `fuzzy_below`), #2882 (~1 kW miss, open), #5386 (900 W miss, open). | `inverter` | | |||
| | Compare (`compare.py`) | `apply_hardware_overrides()` overrode four attributes and not `battery_rate_max_export`, which is the one the export prediction path actually uses (`prediction.py:906`), so an `override_battery_rate_max_discharge_kw` left force-export slots pinned at the real hardware rate - probe-verified against the reporter's debug yaml, fixed in PR #4897 with an explicit fifth key (GH#4895). `battery_rate_max_export` itself is `min(inverter_limit_export, battery_rate_max_raw)` (`inverter.py:431`), and the prediction still clamps export draw at the un-overridden `inverter_limit`, so a "model a bigger inverter" scenario needs `override_inverter_limit_kw` as well or it is inert. A negative "True cost" alongside zero import is **not** phantom export revenue: compare reports `metric_end - metric_start`, and `compute_metric()` credits the end-of-scenario battery at the *replacement import* rate (`plan.py:1769`), deliberately ignoring the export rate - so a scenario ending 25 kWh fuller on free PV scores negative by construction. Likewise a non-zero Export column under `rates_export: 0` is forced PV-clipping export, not a planned export slot; banning export outright is a missing feature (GH#2446), not a compare bug (GH#4881, confirmed twice, the second time against the reporter's own detailed plans). GH#2033 (bumped 2026-09-18, code-verified): the table's Import and Export columns are whole-horizon totals, not plan-slot sums — `run_prediction()` accumulates `import_kwh_battery`/`import_kwh_house`/`export_kwh` for every modelled minute of grid flow and seeds `export_kwh` from `export_today_now`, so PV export outside slots, scenario-plan arbitrage and today-so-far export all count, and a planned discharge slot exports regardless of load vs solar. Deliberate: compare/annual pass `include_manual_api=False` to `basic_rates()` so live manual_api overrides never leak into simulated tariffs, while a tariff's own `rates_import`/`rates_export` replaces the live rates wholesale (no `prev` passed) — per-tariff `rates_*_override` blocks are the workaround; and #2033's "identical friendly names" premise is contradicted by the code (`"Compare " + name`), so duplicate names likely come from duplicate `name:` values in `compare_list`. GH#5133 (fixed on **open PR #5143, unmerged** - keep the mechanism for logs on stock main): `publish_data()` built the entity id by plain concatenation with no slug sanitising, so a `compare_list` id containing `/` produced `POST /api/states/predbat.compare_tariff_IGO/Prime` - and that 404 is the route not matching, not a missing entity. The warns arrive **in pairs** - `set_state()` does the POST and then a read-back `update_state()` GET, and both warn - so two identical 404 warns per cycle anywhere on `/api/states/...` means one bad write, not two problems. And `comparisons.yaml` was never pruned against `compare_list`, so a renamed or deleted tariff id kept republishing for as long as the file survived: the bad id existed only in the persisted yaml (the reporter's current apps.yaml looked fine), so grepping the attached config proves nothing - ask for `comparisons.yaml`, delete the stale entry and restart. The PR adds `tariff_entity_slug()` and `prune_comparisons()`. From the same PR's review (still unmerged, so observations about stock main): the tree has four ad-hoc entity-id slugify helpers with different semantics - `gateway.py`'s `_ev_suffix` drops non-`[a-z0-9_]` characters, `sigenergy.py`'s `_system_slug` folds only `-`, web.py's `re.sub` neither collapses runs nor strips, the PR's `tariff_entity_slug` collapses and strips - and `dashboard_item()` validates nothing, so on any "invalid entity id / 404 on publish" report check which slugify helper built the id; none caps length, and HA rejects object ids over 64 characters. A history lookup that passes an unknown entity id returns `None` silently - a wasted round-trip, **not** a 404 - so don't accept "it 404s" about the history path. With `compare_list` commented out, stored tariffs are republished **once per Predbat start** (only `load_yaml` reaches `publish_data` without the `compare_list` early return), so the tell for "sensors for a tariff I deleted keep coming back" is a restart, not the 5-minute cycle; and stored compare results are looked up by the raw `compare_list` id everywhere (`run_all`'s prior-SoC carry-forward, `select_best`, web.py's Compare page), so a fix that normalises tariff identity must *move* the stored entry to the configured id - keeping the old key preserved nothing, because nothing looked it up under the new id. **GH#5180 (code-read on main, still live):** the /compare tab's `Existing` badge is broken by any event stamped into the live rate tables at the moment compare runs — `Compare.run_all()` snapshots its baseline from the live `self.pb.rate_import`/`rate_export` (`compare.py:598-599`), which by then carry the IO/saving/free/Axle stamps, while `fetch_rates()` refetches the compared tariff's plain rate card and never re-applies any event — so the minute compare differs at every event minute and `result["existing_tariff"]` goes False, withholding the badge (web.py) for that whole run. Compare fires daily at midnight or on the `compare_active` switch, so an event active at that moment is enough. Cost figures are unaffected: every scenario runs on its own refetched plain card. In-tree fix baselines already exist: `rate_import_no_io` (also excludes manual overrides — but the compared refetch never applies manual rates either, so override users already fail this comparison today; the new base makes that consistent rather than opening a gap) and `rate_export_base` (comment says saving sessions and overrides stay out of it). `test_compare` has zero setup for saving/free/IO slots and never asserts `existing_tariff` — a green compare test says nothing about the event-active path. Suspected, not verified: the `run_all()` finally block restores everything it saved **except** `rate_import`/`rate_export`, so the live tables may hold the last compared tariff's rates until the next `fetch_sensor_data()` rebuild — if "the live plan used a different tariff's rates right after running a comparison" is reported, start there. | `compare` | | |||
| | Car charging (`plan.py`, `fetch.py`, `execute.py`) | `car_charge_slot_kwh()` returns the raw slot kWh with no limit awareness and feeds the HTML Car kWh column, the JSON plan, the status sentence and the `car_charging_slot` attributes, while `prediction.py:799` and `prediction_kernel.cpp:827` clamp unconditionally - so "car kWh is displayed but the cost never moves" is a display-vs-model disagreement, not a planning bug. The *rate* side of beyond-cap IOG energy is already handled (`car_charge_slot_rate`/`car_rate_premium`); only the volume side is untrimmed, and `octopus_intelligent_consider_full` (default False, expert-hidden) is the only thing that trims it (GH#4888). The manual car SoC is prediction-fed and never a measurement: `predbat.py` exposes `car_charging_soc_next`, which `prediction.py` sets from the modelled first-step car SoC, so it never resets on its own (GH#4889). `update_car_charging_power()` (`execute.py`) sums *every* entity listed under `car_charging_power` - that list describes chargers, not cars, so two per-car template sensors reading one shared charger are added together; the summing is confirmed, the reporter's doubled figure was not (GH#4879). Per-car rate config pre-#5383: `car_charging_rate` was read by suffixed name as `float(get_arg("car_charging_rate" + postfix))` (`fetch.py`), so an apps.yaml **list** raised `float(list)` — a `TypeError` every main-loop cycle while the car fell back to 7.4 kW — and a fresh item (the HA input_number not yet created) had `load_user_config()` seed `item["default"] = self.args[name]` with no type validation, letting the invalid seed survive (`userinterface.py`; a comma-string value such as `car_charging_rate: "11.0, 11.0"` hits the same `float()` — suspected, not reproduced). **Fixed in PR #5383 (merged 2026-10-04, unreleased at the time of writing, post-v9.3.5) — keep the pre-#5383 mechanism for older logs:** `car_list_arg()` (`userinterface.py`) now splits a base-key list across the per-car slots (`car_charging_rate: [11.0, 6.5]` → car 0 11.0 / car 1 6.5), a per-car suffixed scalar (`car_charging_rate_1: 3.6`) wins over its list slice, and a list on a per-car suffix is ignored in favour of the base list's slice (warned when it stands alone) — `test_fetch_config_options.py` pins all three. The list-vs-postfix asymmetry is closed: `car_charging_limit`/`car_charging_battery_size` had always accepted lists (read with `index=car_n`) and `car_charging_rate` now accepts them. The `car_charging_slots` refresh gate that checked only `car_charging_planned` now also checks `car_charging_now` (`fetch.py:1337`, GH#4795 / PR #4796). **GH#4967 is now fixed (PR #4971, commit `4a045e07`) - the mechanism is kept for anyone reading a pre-#4971 log.** The prediction used to clamp modelled car load at the real `car_charging_limit` unconditionally, via an identical line in both `prediction.py` and `prediction_kernel.cpp`, with the discharge hold below each gated on `car_load_scale > 0` - so once the modelled car filled part-way through a slot the hold released for the rest of the window, regardless of the `octopus_intelligent_consider_full` switch, which never reached `predict()` at all (its only live uses were the read, the `False` default and the gated trim inside `load_octopus_slots()`). The fix routes the prediction through a model-facing `car_charging_limit_model` instead: with `octopus_intelligent_consider_full` off (the default) cars carrying IOG slots get `CAR_CHARGING_LIMIT_UNCAPPED`, so the fill clamp is deliberately inert and the hold releases only when the modelled car actually fills, while the real `car_charging_limit` is left untouched for `execute.py`'s "car already charged" decision, `plan_car_charging()` and `load_octopus_slots()` (it is taken **by reference** by `Prediction`, which is why the fix assigns a separate value rather than mutating it). Both engines take the model limit from the same attribute so they cannot diverge here, `update_car_manual_soc()` caps the manual car SoC write-back at the real limit because the modelled SoC can now overshoot, and `annual.py`/`compare.py` reset the attribute so an override cannot leak into their re-planning; `test_multi_car_iog.py` now asserts the switch's effect on the prediction. One interaction to re-check when the GH#4952 Ohme `watts x hours` overestimate is fixed: with consider_full off the model limit is uncapped for IOG-slot cars, so the fill clamp no longer bounds modelled car load for them either. The History view's separate reconstruction of car slots from the car energy sensor had its own faked-clock bug — GH#5004, under "The shared clock" above, fixed in PR #5025 (v9.0.2). The "Hold for car" discharge hold has **two different gate conditions** (GH#5146): live execution (`execute.py`'s carHolding block) requires an active car slot with `kwh > 0`, the car not already at limit, and skips entirely while an export window is executing (`if not isExporting:`), while the plan model (`prediction.py`, `discharge_rate_now = battery_rate_min`) holds on `(car_load_scale > 0) and (not car_charging_from_battery) and set_charge_window` — no live state, no kwh check, and `set_charge_window` is the plan's charge-window flag, not "this minute is in one". So the plan can hold in slots the live code charges through and vice versa: verify a "plan says X, status says Y" report against the right gate — and since PR #5147 the plan-table display *does* take `hold_for_car` from the prediction's own record (`predict_car_hold_best`, shown for at least half a slot on Demand rows), so a display disagreement is a version question, not a gate question. The export-window exemption is deliberate and test-codified (`discharge_car_full_bat2` in `test_execute.py` asserts export + car slot + the switch off → Exporting, no pause), so it is not a #2380 regression; if the reporter has a working `car_charging_now` sensor the overlapping export window is dropped on the next replan, so *sustained* discharge means the now-slot was never created — on pre-#5245 builds a numeric power sensor read as "not charging", but since PR #5245/#5267 `car_charging_now` can *be* a charging power sensor (a number in watts counts as charging from `CAR_CHARGING_NOW_POWER_W`, `car_charging_now_value()` in `fetch.py`), so check the version before reading a power sensor as absent evidence. Read-only users cannot see the status sensor's "Hold for car" at all — `predbat.status` is forced to "Read-Only" first (`execute.py`). **"Hold for car" is the hold working as designed, and there is no native EV-SoC or price gate anywhere (GH#4572, read on main 57ec7bf1):** the hold fires when `set_charge_window` is on and `car_charging_from_battery` is off (config.py) whenever a car is charging now or inside a planned slot; it stops the battery *feeding the car* (pause mode, else rate 0) and never blocks the car charging from the grid, so "battery idle while the EV charges on PV-then-grid" is the intended steady state and the charger's start/stop is outside the hold's scope. The full car config surface (`car_charging_energy_scale`/`_threshold`/`_rate`/`_loss`/`_hold`, `car_energy_reported_load`, `_manual_soc(_kwh)`, `_plan_smart`, `_plan_max_price`, `_from_battery`, `_plan_time`) has **no parameter gating charging on the EV's SoC and no enforceable price threshold** — `car_charging_soc`/`car_charging_limit` in apps.yaml are the car's *input* sensors, not thresholds — so "charge the EV only when X" is an enhancement ask; the maintainer-side answer is external HA automation, and the in-tree tooling direction is open PR #3791 (`predbat.solar_surplus_power` = `min(max(0, grid + car_power - max(0, battery)), max(0, pv))` + `binary_sensor.predbat_force_export_slot`, sensor-only after being pared back, still unmerged with an owner review round outstanding 2026-10-02). Two slot-selection facts from October 2026: the smart car planner ranks slots by **import price only** — `plan_car_charging()` reads `window["average"]`, while each `low_rates` window already carries an `export` average (`rate_scan_window(..., alt_rates=self.rate_export)`, `fetch.py`) that only `plan_iboost_smart()` consumes — so a cheap import band overlapping daylight is mis-ranked exactly when the export price beats it, and extra car kWh served from surplus PV costs the band's export price, not its import price (GH#5384, enhancement). And a `re:` config arg matches the **first** matching entity only — `resolve_arg_re()` breaks on the first hit (`userinterface.py`) — so a `car_charging_now: re:(sensor.wallbox_portal_status_description|sensor.myenergi_zappi_[0-9a-z]+_plug_status)`alternation consults exactly one detection sensor and the other integration's is never read (GH#5390, dump-verified: the resolved args carried a single plug_status entity); an alternation does not combine sensors, name one entity per arg. **`car_charging_plan_time` caps the non-IOG car plan horizon at the next ready time (GH#1172, code-verified on main 2026-10-05):** `plan_car_charging()` clips every low-rate window at `end = min(window["end"], ready_minutes)` with a past ready time wrapped +24h, and windows starting past the deadline fail `end <= start` and are dropped - so the horizon is never more than ~24h even though `low_rates` is scanned from minute 0 with tomorrow's cheap windows already in it. The select ships only 00:00-23:55 (no "off"/null option; unparseable falls back to 07:00 with a warning), so no sentinel disables the deadline; IOG cars bypass it entirely (ready time overwritten by `octopus_ready_time`, slots from dispatches). GH#1172 (remove the deadline) and GH#3890 (future-date dropdown keeping one) are complementary, partly opposed completions - link both before closing either. **Every car's`plan_details` car sentence, and every car's `planned` sensor attribute, has a display-side reading worth knowing (GH#3017/#5407, verified on main):** `short_textual_plan()`'s "Your car is currently charging." fires when`car_charge_slot_kwh(minutes_now, minutes_now + 5) > 0` and never consults `car_charging_now` (the rest of that section is likewise plan-derived) - and `publish_car_plan()` builds **one** `plan` list ahead of the per-car loop and publishes that same list object as the `planned` attribute of *every* car's `binary_sensor.predbat_car_charging_slot{postfix}`; a second Zappi/EVC under Predbat-led control parses its own sensor's`planned`(`refresh_car_windows()`,`refresh_evc_car_windows()`) and charges in car 0's windows as well as its own. Single-car installs are unaffected, which is why it went unreported; whether the real HA entity's attributes are serialised per publish instant was not verified (in-process stores only), and the agreed fix direction is moving the list inside the loop with a two-car assertion that the *existing* probe (`planned[0]`only) cannot make. **`octopus_charge_limit`reads a charger's "% to add" target as an absolute SoC (GH#3034, verified on main 2026-10-05; same family GH#3060):** the arg has one read path (`get_arg(..., index=car_n)` → `× car_charging_battery_size / 100` → `min()` into `car_charging_limit`) and no config item expresses "target is % to add", so a charger-linked device's target reads as absolute SoC and`execute.py`'s "Car N is already charged, ignoring additional charging slot" check (deliberately the real limit, see #4967 above) skips the dispatch - while`load_octopus_slots()`still keeps Octopus's kWh (`octopus_intelligent_consider_full`off is the default, so PR #5403 changes nothing here - only the hold/slot decision distorts, the dispatch energy is not trimmed by it). Integration-side semantics corroborated in-thread only. Fix shape: a per-car absolute-vs-%-to-add mode switch (the reporter's own proposal); workaround = template sensor computing SoC + add% capped. **`octopus_intelligent_consider_full`, when on, now also withholds the cheap rate from future dispatch minutes no car needs (PR #5403, merged 2026-10-05, unreleased at the time of writing):**`octopus_surplus_minutes()` rounds unneeded minutes out to half hours outside the fixed 23:30-05:30 band, `rate_add_io_slots()`skips stamping them and the feed-side strip removes the discount; the plan is re-requested when the surplus set changes (`octopus_surplus_changed()`). Behaviour is unchanged with it off - so the "cheap rate missing in the back of a dispatch" report that arrives with consider_full on maps here before being called a stamping bug (it was #4482's ask). | `octopus_*`, `car_charging` | | |||
| | Car charging (`plan.py`, `fetch.py`, `execute.py`) | `car_charge_slot_kwh()` returns the raw slot kWh with no limit awareness and feeds the HTML Car kWh column, the JSON plan, the status sentence and the `car_charging_slot` attributes, while `prediction.py:799` and `prediction_kernel.cpp:827` clamp unconditionally - so "car kWh is displayed but the cost never moves" is a display-vs-model disagreement, not a planning bug. The *rate* side of beyond-cap IOG energy is already handled (`car_charge_slot_rate`/`car_rate_premium`); only the volume side is untrimmed, and `octopus_intelligent_consider_full` (default False, expert-hidden) is the only thing that trims it (GH#4888). The manual car SoC is prediction-fed and never a measurement: `predbat.py` exposes `car_charging_soc_next`, which `prediction.py` sets from the modelled first-step car SoC, so it never resets on its own (GH#4889). `update_car_charging_power()` (`execute.py`) sums *every* entity listed under `car_charging_power` - that list describes chargers, not cars, so two per-car template sensors reading one shared charger are added together; the summing is confirmed, the reporter's doubled figure was not (GH#4879). Per-car rate config pre-#5383: `car_charging_rate` was read by suffixed name as `float(get_arg("car_charging_rate" + postfix))` (`fetch.py`), so an apps.yaml **list** raised `float(list)` — a `TypeError` every main-loop cycle while the car fell back to 7.4 kW — and a fresh item (the HA input_number not yet created) had `load_user_config()` seed `item["default"] = self.args[name]` with no type validation, letting the invalid seed survive (`userinterface.py`; a comma-string value such as `car_charging_rate: "11.0, 11.0"` hits the same `float()` — suspected, not reproduced). **Fixed in PR #5383 (merged 2026-10-04, unreleased at the time of writing, post-v9.3.5) — keep the pre-#5383 mechanism for older logs:** `car_list_arg()` (`userinterface.py`) now splits a base-key list across the per-car slots (`car_charging_rate: [11.0, 6.5]` → car 0 11.0 / car 1 6.5), a per-car suffixed scalar (`car_charging_rate_1: 3.6`) wins over its list slice, and a list on a per-car suffix is ignored in favour of the base list's slice (warned when it stands alone) — `test_fetch_config_options.py` pins all three. The list-vs-postfix asymmetry is closed: `car_charging_limit`/`car_charging_battery_size` had always accepted lists (read with `index=car_n`) and `car_charging_rate` now accepts them. The `car_charging_slots` refresh gate that checked only `car_charging_planned` now also checks `car_charging_now` (`fetch.py:1337`, GH#4795 / PR #4796). **GH#4967 is now fixed (PR #4971, commit `4a045e07`) - the mechanism is kept for anyone reading a pre-#4971 log.** The prediction used to clamp modelled car load at the real `car_charging_limit` unconditionally, via an identical line in both `prediction.py` and `prediction_kernel.cpp`, with the discharge hold below each gated on `car_load_scale > 0` - so once the modelled car filled part-way through a slot the hold released for the rest of the window, regardless of the `octopus_intelligent_consider_full` switch, which never reached `predict()` at all (its only live uses were the read, the `False` default and the gated trim inside `load_octopus_slots()`). The fix routes the prediction through a model-facing `car_charging_limit_model` instead: with `octopus_intelligent_consider_full` off (the default) cars carrying IOG slots get `CAR_CHARGING_LIMIT_UNCAPPED`, so the fill clamp is deliberately inert and the hold releases only when the modelled car actually fills, while the real `car_charging_limit` is left untouched for `execute.py`'s "car already charged" decision, `plan_car_charging()` and `load_octopus_slots()` (it is taken **by reference** by `Prediction`, which is why the fix assigns a separate value rather than mutating it). Both engines take the model limit from the same attribute so they cannot diverge here, `update_car_manual_soc()` caps the manual car SoC write-back at the real limit because the modelled SoC can now overshoot, and `annual.py`/`compare.py` reset the attribute so an override cannot leak into their re-planning; `test_multi_car_iog.py` now asserts the switch's effect on the prediction. One interaction to re-check when the GH#4952 Ohme `watts x hours` overestimate is fixed: with consider_full off the model limit is uncapped for IOG-slot cars, so the fill clamp no longer bounds modelled car load for them either. The History view's separate reconstruction of car slots from the car energy sensor had its own faked-clock bug — GH#5004, under "The shared clock" above, fixed in PR #5025 (v9.0.2). The "Hold for car" discharge hold has **two different gate conditions** (GH#5146): live execution (`execute.py`'s carHolding block) requires an active car slot with `kwh > 0`, the car not already at limit, and skips entirely while an export window is executing (`if not isExporting:`), while the plan model (`prediction.py`, `discharge_rate_now = battery_rate_min`) holds on `(car_load_scale > 0) and (not car_charging_from_battery) and set_charge_window` — no live state, no kwh check, and `set_charge_window` is the plan's charge-window flag, not "this minute is in one". So the plan can hold in slots the live code charges through and vice versa: verify a "plan says X, status says Y" report against the right gate — and since PR #5147 the plan-table display *does* take `hold_for_car` from the prediction's own record (`predict_car_hold_best`, shown for at least half a slot on Demand rows), so a display disagreement is a version question, not a gate question. The export-window exemption is deliberate and test-codified (`discharge_car_full_bat2` in `test_execute.py` asserts export + car slot + the switch off → Exporting, no pause), so it is not a #2380 regression; if the reporter has a working `car_charging_now` sensor the overlapping export window is dropped on the next replan, so *sustained* discharge means the now-slot was never created — on pre-#5245 builds a numeric power sensor read as "not charging", but since PR #5245/#5267 `car_charging_now` can *be* a charging power sensor (a number in watts counts as charging from `CAR_CHARGING_NOW_POWER_W`, `car_charging_now_value()` in `fetch.py`), so check the version before reading a power sensor as absent evidence. Read-only users cannot see the status sensor's "Hold for car" at all — `predbat.status` is forced to "Read-Only" first (`execute.py`). **"Hold for car" is the hold working as designed, and there is no native EV-SoC or price gate anywhere (GH#4572, read on main 57ec7bf1):** the hold fires when `set_charge_window` is on and `car_charging_from_battery` is off (config.py) whenever a car is charging now or inside a planned slot; it stops the battery *feeding the car* (pause mode, else rate 0) and never blocks the car charging from the grid, so "battery idle while the EV charges on PV-then-grid" is the intended steady state and the charger's start/stop is outside the hold's scope. The full car config surface (`car_charging_energy_scale`/`_threshold`/`_rate`/`_loss`/`_hold`, `car_energy_reported_load`, `_manual_soc(_kwh)`, `_plan_smart`, `_plan_max_price`, `_from_battery`, `_plan_time`) has **no parameter gating charging on the EV's SoC and no enforceable price threshold** — `car_charging_soc`/`car_charging_limit` in apps.yaml are the car's *input* sensors, not thresholds — so "charge the EV only when X" is an enhancement ask; the maintainer-side answer is external HA automation, and the in-tree tooling direction is open PR #3791 (`predbat.solar_surplus_power` = `min(max(0, grid + car_power - max(0, battery)), max(0, pv))` + `binary_sensor.predbat_force_export_slot`, sensor-only after being pared back, still unmerged with an owner review round outstanding 2026-10-02). Two slot-selection facts from October 2026: the smart car planner ranks slots by **import price only** — `plan_car_charging()` reads `window["average"]`, while each `low_rates` window already carries an `export` average (`rate_scan_window(..., alt_rates=self.rate_export)`, `fetch.py`) that only `plan_iboost_smart()` consumes — so a cheap import band overlapping daylight is mis-ranked exactly when the export price beats it, and extra car kWh served from surplus PV costs the band's export price, not its import price (GH#5384, enhancement). And a `re:` config arg matches the **first** matching entity only — `resolve_arg_re()` breaks on the first hit (`userinterface.py`) — so a `car_charging_now: re:(sensor.wallbox_portal_status_description|sensor.myenergi_zappi_[0-9a-z]+_plug_status)` alternation consults exactly one detection sensor and the other integration's is never read (GH#5390, dump-verified: the resolved args carried a single plug_status entity); an alternation does not combine sensors, name one entity per arg. **GE "Charging, Hold for car" stall at the reserve (GH#5419, verified from the reporter's own predbat.log/GivTCP write log/debug yaml, 2026-10-06):** the live hold writes `discharge_rate = 0` with no isCharging guard (execute.py's carHolding block — the reserve bump at the same branch deliberately sits out charging, #3899) — refs verified exact on main `82bee43e`, and`git diff v9.3.1..HEAD` leaves the block untouched, so not a regression. Fault state: charge window enabled + target/rate read back correct + reserve floor + **discharge rate 0 + SoC exactly at the reserve** — a GE inverter (GIV-HY3.6 via GivTCP REST) declines to grid-charge, and charges normally within ~1 min of the hold's rate-0 being restored every time; the plan manufactured the collision by exporting down to the reserve immediately before the hold began. Suspected, not verified: the inverter-side rule itself (GE firmware won't grid-charge at SoC ≤ reserve with discharge disabled; a firmware OTA cannot be ruled out). Fix direction flagged to the maintainer: skip the rate-0 hold while isCharging, symmetric to the reserve skip — residual risk: in a dead charge window the inverter keeps its normal discharge rate with only the reserve floor preventing battery→car feed, a written register on GE, not on every inverter type. | `octopus_*`, `car_charging` | | |||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
docs(debug-journal): fold in the 2026-10-06 queue slice (5 candidates); correct the Sunsynk control-cache bounds (PR #5360) and the IOG car-need-gate reading (PR #5403)
Folded in
gh api repos/<other-org>/<repo>/contents/...is denied by the triage runner's permission mode — go straight to WebFetch; andraw.githubusercontent.com/.../main/...404s when the repo's default branch isn'tmain— fetch the landing page first (it answers the default-branch question directly), then the raw file on that branch. Re-verified today: the EDF integration repo the issue cited hasdevelopas its default branch. The candidate deliberately deferred Kraken: applicableRates fallback treats exc-VAT prices as inc-VAT #5417's VAT finding to PR fix(kraken): scale exc-VAT applicableRates prices to inc-VAT from the agreement #5418's own journal row; I confirmed that row exists only in the open PR's diff (not on main), so nothing is duplicated here, and I did not add a Kraken-row pointer to avoid a textual collision for when fix(kraken): scale exc-VAT applicableRates prices to inc-VAT from the agreement #5418 merges.discharge_rate = 0with no isCharging guard (execute.py's carHolding block) while the reserve bump at the same branch deliberately sits out charging (Inverter writes big increase low charge mode #3899). Verified on main — the candidate's execute.py:799-800 and :807-809 refs match current main exactly, andgit diff v9.3.1..HEADleaves the block untouched (not a regression). The candidate's firmware-side rule stays marked suspected, not verified, per the candidate. The "reporter table timestamps are HA-history samples; re-derive the trajectory fromrecord_statuslines" trap went into the attachment-forensics bullet.homeassistant.helpers.service) are HA-core log lines that never appear inpredbat.log— verified on Startup Race Condition - switch.predbat_set_reserve_enable Entity Not Ready #5420's attached 50k-line log (0 matches; no ERROR/WARNING lines at all). (2) The split-issue check folded into thegh issue list --searchbullet: before asking a reporter to open a split issue, search their other issues (GH#5420's reserve=100 symptom already had GH#5300, same reporter).*_todayaccumulators falsely fail validation in rollover windows. New symptom-table row (next to the custom-prefix-validation row):validate_config()(predbat.py:1532) reads live entity states, anunavailable/unknownread fails the float check as a string while a missing entity errors separately,transient_okexists only forcar_charging_energy/car_charging_power(config.py:2728-2729 — the four*_todayitems at config.py:2637-2649 lack it), validation timing is driven by the 8-hourCONFIG_REFRESH_PERIODplusupdate_pendingtriggers (nothing midnight-specific), the probe-verified fix direction, and the fixture trap (~28-32 baselinearg_errors). All of the candidate's line refs verified exact on main.octopus_surplus_from()=(minutes_now // 30 + 1) * 30(octopus.py:3940) with the carve-out documented in its docstring,rate_add_io_slots()skips onlyminute in self.octopus_surplus(octopus.py:3865), the 3+2 min dynamic-load grace (const.py:33-35), the trust-off stale-not-cancelled trap at plan.py:534, the car-side "already charged" skip at execute.py:785, and the overnight-band exclusion (in_iog_fixed_window). Every code claim in the candidate verified line-exact on main.Existing entries corrected (re-check against merges since the last fold)
applied_payload≤15 min (SUNSYNK_RESTORE_MAX_CONTROL),control_active≤8 h (SUNSYNK_RESTORE_MAX_CONTROL_ACTIVE/DEYE_RESTORE_MAX_CONTROL_ACTIVE), verified insunsynk.py_restore_control_state(). A restart <8 h after an HA blip now restores ownership and reconcile re-applies; the "maps here even on a fix(sunsynk,deye): persist control_active across a restart #5150+ version" reading is pre-fix(sunsynk/deye): dont expire control_active after 15 minutes (fix #… #5360 only.rate_add_io_slots()" stale since PR Don't trust Intelligent slots the car won't need (consider_full) #5403 (7cad36e, merged 2026-10-05):octopus_intelligent_consider_full(expert, default False) now supplies car-needless future dispatch minutes thatrate_add_io_slots()skips; the current half hour still stamps (GH#5424 row). Reworded to "no fully-working knob"/"mostly unconditionally" with the carve-out stated.Dropped: none.
Gate: cspell Passed, cspell dictionary sorter Passed, markdownlint-fix Passed (one whitespace-only normalization,
git diff --checkclean). The file-scoped hook run and./run_all --quick's test portion were not run — the runner's permission mode deniesrun_pre_commit/ghhere; changes are docs-only, and the docs-only bar in the journal's flow is cspell + markdownlint.Not merged by me — a human merge is the review gate on this file, per the flow.