Move scheduling onto the periodic API, with staged edits and Apply

[Poshy163]

Takes on the first half of #267: getTimeChargeBySn/setTimeChargeBySn becomes the store the integration schedules on. It stops short of the second half — the legacy two-slot endpoints are not deleted, they are demoted to a backup for accounts AlphaESS has not granted the timed charge/discharge permission to. Until that permission is handed out on request, it is the only control path those accounts have.

This supersedes the description this PR carried before, which described the first two commits only and one behaviour that has since been reversed (see Nothing is invented below).

One store per system

A definitive 6017 on the periodic read moves that inverter to the legacy backup. From then on polling, entity state, writes and the duration buttons all follow the store that mode names. The two stores are never read together, merged, or mirrored — #269 showed what mixing them costs: values the app never shows, phantom overlaps, and writes the server accepts without acting on.

A system whose periodic read works but whose write is refused fails closed rather than falling back. The app-facing periodic store still governs that inverter, and editing a store it ignores would only mislead.

Two backup-mode caveats, both from live probing: the inverter may not act on the legacy discharge store even though the write is accepted, and per-period power exists only in the periodic store, so the Power entities are unavailable there.

Edits are staged, Apply sends them

Times, cutoff SOCs, per-period power and the enable switches now stage locally. Apply Charge/Discharge Schedule sends the whole draft as one write; Discard Schedule Changes puts the remote values back. Both buttons exist only while a draft does.

That makes a plan change one API write instead of one per field, and means a half-finished edit is never sent. Polling keeps a draft visible instead of resetting an end time while the start is still being edited. A failed or conflicted Apply keeps the draft so it can be retried or discarded.

The duration buttons and the two services stay immediate, and deliberately do not consume a draft.

Safe writes

Every write reads its store fresh inside the transaction, patches only the fields it was asked for, and serialises per inverter. Periods, weekday selections and powers the two-slot entity UI cannot show all survive a write. A draft records the schedule it was based on and is refused as a conflict if the remote schedule moved underneath it.

In periodic mode there is no partial-write case — one store, one POST. Backup mode writes two stores, so a two-sided change there can half-land, and that is reported as a partial write naming what already applied. A timeout after a POST is reported as an explicitly unknown outcome, not as a failure.

Nothing is invented

A period with no valid power or cutoff is reported by name rather than filled in. In particular the poinv fallback added in 9a8d61d is reversed: the inverter's nominal rating is not a verified battery charge rate, and sending it as one is exactly the class of write that looks accepted and does something unintended. Empty period lists are refused before they reach the API, which answers 6001 for them anyway. Invalid remote data is named and blocks the write instead of being clamped.

The overlap guard stays gone. 6008 is reported with the API's own explanation and the periods that were sent.

Self-consumption locks the controls

Self Consumption and SCP are indistinguishable over the OpenAPI: both clear the enable flags and keep the windows stored. Field testing showed that writing an enable flag does not leave those modes, so while one is running every time-based control — times, cutoffs, powers, switches, duration buttons, Reset, Apply/Discard and both services — is unavailable or refused with a message naming the remedy, and the new Time Based Control Active binary sensor says why.

For the same reason Home Assistant will not author the both-flags-off state itself: afterwards it could not tell that state apart from self-consumption. Disabling the last timer belongs in the app. Polling unlocks everything automatically once a timed mode is active again, and a draft stranded by an app-side mode change is kept until then.

Automations

dragon2611 asked in #267 for a way to set the parameters and then apply them. That is what the entities plus button.press already do, so the README now documents it: the entity IDs, the choice between the immediate services and the staged surface, and the rule that an inverter should use one or the other — a service write replaces the remote schedule, so a draft staged before it will fail its next Apply as a conflict.

Predbat gets a worked example, because it already drives inverters that stage settings and then press a button: a custom inverter definition with time_button_press, the entity mapping, and the things that setup depends on — including that Predbat cannot see whether an Apply was accepted, since Home Assistant timestamps a button press before the write is attempted.

Also

• Periodic Schedule Read diagnostic sensor reports which store governs the system, and stays unknown rather than guessing while no read has succeeded.
• The services accept optional per-slot power, required when a call creates a new periodic slot, and normalise times to zero-padded quarter hours (the API answers 6001 for 9:00).
• Reset Charge/Discharge now reports unavailable on periodic systems: a periodic schedule cannot be cleared through the API, so the button could only ever fail there.
• Duration buttons retarget slot 1 only and leave everything else alone; they refuse a weekly period that does not run today rather than silently rescheduling its other weekdays.
• All calls use the fast API lane, so an app-side mode change is noticed in about a minute.

[Poshy163]

@CharlesGillanders would be good if you can approve this, going to push it as a beta 2 with reworks most of how the integration works for the new server interface/back-end