[Poshy163]

Three things out of the testing on #267.

1. Crash moving a schedule switch

Reported by @dragon2611 on main:

File "coordinator.py", line 1297, in stage_schedule_change
    grid_flag = int(draft["charge"].get("gridCharge", grid_flag))
TypeError: int() argument must be ... not 'NoneType'

Since #275 the entity view reports None for an enable flag nobody has answered for, and .get(key, default) returns that None rather than the default — the key is present, its value is unknown.

Reaching it needs exactly half an answer: one switch restored a usable state and the other did not. _committed_enable_flags() then returns None (it requires both), while Time Based Control Active still reads true from the side that is known — enough to enter the last-timer guard, which casts both.

The guard now runs only when both committed flags are actually known. Its or (1, 1) fallback was the same class of guess #275 removed everywhere else: assuming the other timer was on in order to decide whether this one was the last. A staged half of None is skipped rather than cast. A write still needs both flags, so a half-known pair is refused before it reaches the API.

2. Dead mappings left behind

The periodic patcher still carried "cycle": "gridChargeCycle" / "cycle_field": "gridCharge" entries. Nothing has read them since those fields stopped being part of the resource, and leaving a mapping there that names the write-only pair is an invitation to send them from a read again.

3. Diagnostics that answer the question

Every question on #267 needed something the download did not carry, so it took three rounds of hand-signed API requests to establish what the integration already had in memory.

Download diagnostics now includes, per inverter:

• governing_store and periodic_read — which surface the system is on
• capabilities — the exact flags behind every unavailable control, so a locked UI explains itself
• enable_intent / enable_last_sent — the write-only pair, which nothing else can report
• periodic_snapshot and legacy_snapshot — what each store actually held, including an empty period list or a stale window the app no longer shows
• draft — what is staged, which fields are dirty, whether an Apply is in flight
• duration cooldowns and consecutive poll errors

Plus a coordinator.api section with the current call spacing and whether the fast lane is still on — worth checking now that Predbat's native integration can share the same API account.

That one file would have answered the whole report on its own: the empty dischargeTimeList, the 0/0 pair with nothing recorded, and the capability flags explaining the locked controls. Serials stay anonymised as inverter_N and credentials stay redacted.

Two README gaps from the same testing are closed too: AlphaESS will store an empty period list even though it refuses to accept one, so a system with no discharge periods cannot be written to until it has one; and installs predating the serial-prefixed rename keep IDs carrying the device name, which is why the entity names in the automation section did not match for him.

Tests

573, 100% coverage, ruff clean. Regressions for the reported crash sequence and for the half-known pair still refusing the write, plus four covering the new diagnostics sections across periodic, backup, drafted and no-store systems.

[Poshy163]

@CharlesGillanders bump, need this for b4

[CharlesGillanders]

@Poshy163 What permission changes need to be made so that you can run your own reviews? I'm a roadblock too often at the moment.

[Poshy163]

What permission changes need to be made so that you can run your own reviews

Not quite sure, as i think we looked into this before and we needed this repo to be apart of an org

the only way would be to (from what i understand, and i had to ask AI for this, coz i wasnt too sure how it applied to individuals

this by the looks gives my the bypass for the review, but the CI still needs to pass