fix(enphase): stop schedule conflicts wedging battery control

[springfall2008]

Problem

A site with more than one schedule per family (CFG/DTG/RBD) drives Predbat into a permanent HTTP 409 loop, after which it can no longer control the battery.

get_schedules() took details[0], but the Enphase cloud orders that list by updatedAt. Writing to the adopted schedule pushes it behind its sibling, so the next re-read swaps Predbat onto the sibling. Predbat then writes a window overlapping the one it set itself minutes earlier, and the cloud rejects it as CONFLICTING_SCHEDULE_*.

From a 13-hour debug log on an affected site, all 272 rejections were an overlap with a schedule Predbat was no longer tracking:

Cause	Count
Overlap with a sibling in the same family	241
Overlap with the other family's stale window	31
Unexplained	0

The clearest instance:

• 22:26:21 — writes DTG 0d1b7714 → 22:35-23:30, 200 OK
• 22:26:25 — GET returns the pair reordered; Predbat adopts 1b5b3878
• 22:31:22 — writes DTG 1b5b3878 → 22:50-23:30 → 409, against its own window from five minutes earlier

By 09:36 both families were failing on every 5-minute cycle, with the battery left running on stale windows.

Changes

• Pin the adopted schedule. Match the adopted scheduleId on re-read rather than taking the first entry, falling back to the first non-deleted one when nothing is adopted yet or the adopted schedule was removed outside Predbat.
• Own the family. Delete any other schedule in a family when in write mode — Predbat drives one window per direction, and a schedule it does not track cannot be updated or cleared but still blocks overlapping writes. Read-only mode deletes nothing.
• Retry once on conflict. Re-read schedules on a 409 and retry, so a stale cached view cannot wedge the cycle. The re-read both refreshes the id and prunes the stray sibling. A conflict surviving the re-read is a real clash and is not retried again.
• Retire windows with DELETE, not isEnabled: False. The cloud answers 200 to a disable while leaving isEnabled true and still enforcing the window — confirmed by a GET 29 minutes after a disable showing it still live. Without this, Predbat could never clear its own window and the cross-family conflicts would persist.

request_json gained an allow_empty flag so a 204/no-body DELETE counts as success.

Behaviour change worth flagging

In write mode Predbat now deletes user-created Enphase schedules it finds on the site, including ones made in the Enlighten app. This is intentional — an untracked schedule wedges battery control — and is documented in docs/components.md, with read-only mode as the escape hatch for anyone who wants to manage schedules themselves. It is not recoverable from Predbat's side, so it may deserve a release-note callout.

Testing

Nine new tests in test_enphase_api.py, written test-first. Five failed for the expected reason before the fix; three guard the edge cases the new logic must not break (fallback adoption, read-only). The ninth replays the exact production sequence above and was verified against stashed pre-fix code:

--- PRE-FIX code ---   FAIL@1722: assert written == [.../first, .../first]
--- POST-FIX code ---  PASS

./run_pre_commit passes — all 10 hooks green, full quick suite green, interrogate at 100%.

Version bumped v8.47.3 → v8.47.4.

Follow-up not addressed here

I could not tell from the log whether the duplicate schedules originated in the user's Enlighten app or from Predbat's own POST path in _write_schedule during an earlier run — the createdAt timestamps predate the capture. If it is the latter, there is a second bug still to find: something creating duplicates rather than updating in place.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR hardens Predbat’s Enphase integration to prevent schedule “family” conflicts (HTTP 409) that can permanently wedge battery control when the Enphase cloud returns multiple schedules per family and reorders them after updates.

Changes:

• Pins the adopted Enphase schedule ID per family across re-reads (order-independent), and prunes duplicate sibling schedules in write mode.
• Retries a single schedule PUT after a 409 by re-reading schedules (refreshing IDs and removing stray siblings) before retrying once.
• Switches “disable window” behavior from isEnabled: false to DELETE, and extends request_json() with allow_empty to treat 204/no-body deletes as success; adds targeted Enphase API tests and bumps version.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
docs/components.md	Documents the new “Predbat owns Enphase schedules” behavior and DELETE-based window retirement.
apps/predbat/tests/test_enphase_api.py	Adds test helpers plus new regression/edge-case tests for adopted ID pinning, sibling pruning, DELETE disable, and 409 retry behavior.
apps/predbat/predbat.py	Version bump to v8.47.4.
apps/predbat/enphase.py	Implements adopted schedule pinning, sibling pruning in write mode, single retry on 409, DELETE-based retirement, and allow_empty support for 204 responses.