Keep schedule intent separate from inverter mode

Author: Poshy163

README.md

@@ -230,10 +230,8 @@ What this setup depends on:
   AlphaESS app. An unused slot is stored as start equal to end and reads as
   `unknown`, which Predbat cannot parse as a window, and no one-sided write can
   create both sides at once.
-- **Leave Scheduled Discharging on.** Predbat turns the charge enable switch off
-  while it moves a window, and Home Assistant refuses to author the
-  both-timers-off state because it is indistinguishable from a self-consumption
-  mode.
+- **Leave Scheduled Discharging on** if you do not want Predbat's temporary
+  charge-disable step to leave both schedules disabled while it moves a window.
 - **Times are rounded to the nearest 15 minutes.** Predbat reads an entity back
   after writing it and warns when the value differs, so keep
   `inverter_clock_skew_start` and `inverter_clock_skew_end` at 0 and expect that
@@ -251,9 +249,7 @@ What this setup depends on:
 - **Set both enable switches once before letting Predbat write.** The periodic
   API cannot report whether scheduled charging and discharging are on, so until
   Scheduled Charging and Scheduled Discharging have an answer every write is
-  refused — see *The enable flags are write-only* below. Recording both as off
-  additionally locks the time-based controls, since that is how the API is told
-  to run self-consumption.
+  refused — see *The enable flags are write-only* below.
 
 If you drive the services from Predbat instead, note two things about its
 service templates: falsy values are dropped before the call, so `enabled: false`
@@ -275,55 +271,58 @@ was based. If the remote schedule changes before Apply, the write is rejected
 as a conflict instead of overwriting the newer schedule. Discard the draft,
 allow fresh values to load if necessary, review them, and stage the change
 again. Immediate actions and services have no long-lived draft, but still start
-from a fresh read.
-
-The binary sensor **Time Based Control Active** reports whether any timed
-charge/discharge control is enabled in whichever store governs the system
-(either enable flag set). It turns off when the inverter runs a non-timed
-mode such as **Self Consumption (Plus)** — live probing showed those modes
-flip both enable flags to `0` while keeping the configured windows stored —
-and is unavailable while no schedule store is readable.
+from a fresh read. If one succeeds while a draft is open, untouched draft fields
+are rebased onto the new remote schedule while explicitly staged fields remain
+pending. An immediate action uses only its own arguments plus the last confirmed
+enable pair; it never consumes staged switch values before Apply.
+
+The diagnostic binary sensor **Recorded Schedule Flags Enabled** reports whether
+either flag in Home Assistant's last confirmed pair is on. Its unique ID remains
+compatible with the former **Time Based Control Active** entity so an existing
+registry entry is renamed in place. It is deliberately not a working-mode
+sensor: AlphaESS OpenAPI exposes no authoritative way to tell **Time Based
+Control** from **Self Consumption (Plus)**.
 
 ### The enable flags are write-only
 
-`gridChargeCycle` and `ctrDisCycle` decide whether scheduled charging and
-discharging run. On the periodic store they are **write-only**: probing on
-issue #267 showed `getTimeChargeBySn` answers `0` for both however the inverter
-is actually set, while `setTimeChargeBySn` acts on what it is sent.
+`gridChargeCycle` and `ctrDisCycle` are the scheduled charge/discharge intent
+sent with a periodic replacement. They are effectively **write-only**: probing
+on issue #267 showed `getTimeChargeBySn` can answer `0` for both regardless of
+the inverter's app-selected working mode, while `setTimeChargeBySn` accepts the
+explicit pair it is sent.
 
-| sent | effect on the inverter |
+| sent | recorded schedule intent |
 | --- | --- |
-| `1 / 0` | schedule active, scheduled discharging off |
-| `1 / 1` | both schedules enabled |
-| `0 / 1` | scheduled discharging only |
-| `0 / 0` | **switches the inverter to self-consumption** |
+| `1 / 0` | scheduled charging on, scheduled discharging off |
+| `1 / 1` | both schedules on |
+| `0 / 1` | scheduled charging off, scheduled discharging on |
+| `0 / 0` | both schedules off |
+
+That pair does not reveal or reliably change the app's overall working mode.
+In Self Consumption modes the cloud may still accept and retain schedule edits,
+but the inverter may not physically act on them until its mode is changed in the
+AlphaESS app.
 
 Two consequences follow, and the integration is built around them.
 
-**The read is never echoed back.** A replacement built from the read would post
-`0/0` on every write and quietly switch the inverter out of timed control.
-Snapshots therefore drop both flags, and every write sends a value that came
-from the user instead.
+**The read is never echoed back.** A replacement built from the read could post
+an invented `0/0` pair on every write. Snapshots therefore drop both flags, and
+every write sends only values that came from the user or the last confirmed pair.
 
 **The switches are the record.** *Scheduled Charging* and *Scheduled
-Discharging* are the only place that answer can live, so their published state
-is restored across restarts and handed back to the coordinator. Until both have
-an answer they read **unknown**, and a schedule write is refused with a message
-naming them rather than guessing which working mode you wanted. Editing and
-staging still work; only the write needs the answer.
-
-Once both are recorded, a request to set them to `0/0` is a real one — it is how
-the API is told to run self-consumption — so it locks the time-based controls:
-time entities, cutoff SOC and power numbers, duration buttons, Reset,
-Apply/Discard, and any service call carrying a window, cutoff or power. The two
-switches stay available so the inverter can be brought back to a timed mode from
-Home Assistant, and turning one on there is sent immediately rather than staged,
-since Apply is unavailable in that state. Home Assistant still refuses to author
-`0/0` by turning off the *last* enabled timer from a service.
-
-In legacy backup mode `gridCharge` and `ctrDis` are ordinary read-write fields
-and none of the above applies: they are read from the store, reported as-is, and
-a mode change made in the AlphaESS app is picked up on the next poll.
+Discharging* are the only place that answer can live, so a separate
+last-confirmed attribute is restored across restarts and handed back to the
+coordinator. The displayed switch can show a newer local draft without that
+draft becoming confirmed after a restart. Until both confirmed values are
+known, unrelated immediate writes are refused rather than borrowing a pending
+draft or guessing. Stage both switch choices and press Apply once to establish
+the pair.
+
+Schedule controls are gated only by whether a complete governing store can be
+read and safely replaced. A recorded `0/0` pair does not lock them, because the
+same flags and schedule contents cannot tell Home Assistant which working mode
+the AlphaESS app selected. In legacy backup mode the flags are read-write fields,
+but they still are not treated as an overall working-mode endpoint.
 
 The diagnostic sensor `Periodic Schedule Read` reports:
 
@@ -344,20 +343,24 @@ erase weekly settings, extra periods, or power values that it cannot see.
 
 **Settings → Devices & Services → AlphaESS → ⋮ → Download diagnostics** answers
 most of what a report needs, without anyone having to sign API requests by hand.
-Alongside the usual entry and entity data, the `schedule` section carries, per
-inverter:
+Alongside the usual entry and entity data, the `schedule` section carries one
+atomic completed-poll snapshot 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;
+- `capabilities` — schedule read/write capability plus the explicit fact that
+  working mode is unavailable through OpenAPI;
 - `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, and whether an Apply is in
-  flight;
+- `draft` — what was staged when that poll completed;
 - cooldowns and consecutive poll errors.
 
+`schedule_live` separately reports the current draft, dirty fields, and
+in-flight Apply state. Keeping it separate prevents a diagnostics download
+during a sequential multi-inverter poll from pretending that live transaction
+state and completed-poll data came from the same tick.
+
 The `coordinator.api` section reports the current call spacing and whether the
 fast lane is still active, which is what to check when something else is sharing
 the same API account. Serials are replaced with `inverter_1`, `inverter_2` and so
@@ -376,7 +379,7 @@ logger:
 
 Every OpenAPI request and **its full response** is then written out, along with
 each staged field, each write and the enable pair sent with it, and a line
-whenever the schedule surface locks or unlocks and what decided it. That is the
+whenever schedule capability changes and what decided it. That is the
 same information a hand-signed API request would give you, without signing one.
 Very large responses are capped rather than dropped. Requests carry no
 credentials — those live in the headers, which are not logged — but the log does
@@ -471,8 +474,7 @@ In practice the integration runs calls at 1-second spacing: live probing of
 the current server showed reads accepted at sub-second spacing without
 `6053`, and at the documented 10 seconds a two-inverter full poll took
 minutes — blocking Home Assistant startup and delaying app-side changes
-(such as a work-mode switch flipping `Time Based Control Active`) by up to
-five minutes. The documented pace remains the fallback: if the server ever
+by up to five minutes. The documented pace remains the fallback: if the server ever
 answers `6053`, that call is retried once and the session drops back to
 10-second spacing permanently.
 

custom_components/alphaess/binary_sensor.py

@@ -104,14 +104,17 @@ async def async_setup_entry(hass, entry, async_add_entities) -> None:
 
 
 class AlphaScheduleControlBinarySensor(CoordinatorEntity, BinarySensorEntity):
-    """Whether AlphaESS time-based charge/discharge control is active.
+    """Whether either recorded schedule-enable flag is on.
 
-    On when either enable flag is set in whichever schedule store governs
-    the system (periodic cycles or the legacy backup flags). Off means a
-    non-timed mode such as Self Consumption Plus is running. Unavailable
-    while no schedule store is readable.
+    The OpenAPI has no inverter working-mode endpoint. This diagnostic reports
+    only the last pair Home Assistant successfully sent/restored (or the legacy
+    flags), and must never be interpreted as Time Based Control mode.
     """
 
+    # Keep the original unique ID so an existing diagnostic entity is renamed
+    # in place instead of leaving an orphan after this semantic correction.
+    _LEGACY_UNIQUE_ID_NAME = "Time Based Control Active"
+
     def __init__(self, coordinator, serial, config, description, device_info=None):
         super().__init__(coordinator)
         self._coordinator = coordinator
@@ -128,7 +131,7 @@ def __init__(self, coordinator, serial, config, description, device_info=None):
     @property
     def is_on(self) -> bool | None:
         value = self._coordinator.data.get(self._serial, {}).get(
-            AlphaESSNames.TimeBasedControl
+            AlphaESSNames.ScheduleFlagsEnabled
         )
         return None if value is None else bool(value)
 
@@ -139,14 +142,16 @@ def available(self) -> bool:
         serial_data = self._coordinator.data.get(self._serial)
         if serial_data is None:
             return False
-        return (
-            self._coordinator.cloud_available
-            and AlphaESSNames.TimeBasedControl in serial_data
-        )
+        return self._coordinator.cloud_available and serial_data.get(
+            AlphaESSNames.ScheduleFlagsEnabled
+        ) is not None
 
     @property
     def unique_id(self):
-        return f"{self._config.entry_id}_{self._serial} - {self._name}"
+        return (
+            f"{self._config.entry_id}_{self._serial} - "
+            f"{self._LEGACY_UNIQUE_ID_NAME}"
+        )
 
     @property
     def name(self):

custom_components/alphaess/button.py

@@ -456,6 +456,13 @@ async def handle_time_restriction(last_update_dict, update_fn, update_key, movem
     @property
     def available(self) -> bool:
         """Buttons require cloud API to function."""
+        if self._key == AlphaESSNames.ButtonDiscardSchedule:
+            # Discard is entirely local. Keep the escape hatch available even
+            # if the cloud is down while edits are pending.
+            return (
+                self._coordinator.has_schedule_draft(self._serial)
+                and not self._coordinator.is_schedule_apply_in_progress(self._serial)
+            )
         if not self.coordinator.last_update_success:
             return False
         serial_data = self._coordinator.data.get(self._serial)
@@ -465,35 +472,23 @@ def available(self) -> bool:
             AlphaESSNames.evchargersn
         ) != self._ev_serial:
             return False
-        if self._key in (
-            AlphaESSNames.ButtonApplySchedule,
-            AlphaESSNames.ButtonDiscardSchedule,
-        ):
-            # In a self-consumption working mode nothing time-based can be
-            # written, so a stranded draft cannot be applied (or discarded)
-            # until the app returns the inverter to a time-based mode.
+        if self._key == AlphaESSNames.ButtonApplySchedule:
             return (
                 self._coordinator.cloud_available
                 and self._coordinator.has_schedule_draft(self._serial)
                 and not self._coordinator.is_schedule_apply_in_progress(self._serial)
-                and self._coordinator.is_time_based_control_active(self._serial)
-                is not False
             )
         if self._key == AlphaESSNames.ButtonRechargeConfig:
             # The reset clears only the legacy backup stores; on a system the
             # periodic schedule governs it could only fail, so report it as
-            # unavailable there instead. In a self-consumption mode it would
-            # silently re-enable time-based control, so it locks there too.
+            # unavailable there instead.
             return (
                 self._coordinator.cloud_available
                 and self._coordinator.can_reset_schedule(self._serial)
-                and self._coordinator.is_time_based_control_active(self._serial)
-                is not False
             )
         if getattr(self, "_movement_state", None) in ("Charge", "Discharge"):
-            # Duration buttons need a usable schedule store and active
-            # time-based control; in a self-consumption mode a press would
-            # silently re-enable timed control.
+            # Duration buttons need a usable schedule store. The OpenAPI has
+            # no authoritative working-mode read with which to gate them.
             return (
                 self._coordinator.cloud_available
                 and self._coordinator.can_modify_time_controls(self._serial)