fix: BusyBarClient.set_busy_simple sends a body the device rejects

[sumitake]

Root cause

BusyBarClient.set_busy_simple (src/busybar/client.py) sent PUT /api/busy/snapshot with the BusySnapshotSimple fields flat at the top level -- the literal shape described by the device's own /openapi.yaml (BusySnapshot = the discriminated snapshot variant merged via allOf with a required busy_bar_settings, all flattened). Against a live device this body gets HTTP 400 "Failed to parse snapshot" on every call. The caller (calendar_countdown/main.py's run_once, the auto_busy=true branch) never checks set_busy_simple's bool return, so the feature silently did nothing.

Corrected shape (verified empirically against the live device, not guessed)

{
  "snapshot": {
    "type": "SIMPLE",
    "card_id": "00000000-0000-0000-0000-000000000000",
    "time_left_ms": 90000,
    "is_paused": false
  },
  "snapshot_timestamp_ms": 1785829020000
}

The snapshot variant is nested under a "snapshot" key, sibling to a top-level "snapshot_timestamp_ms" -- mirroring get_busy()'s own GET response shape -- and busy_bar_settings is not sent at all on this write path, despite the spec marking it required (the device fills its own default busy_bar_settings in, visible on the next GET).

A second finding surfaced during probing: snapshot_timestamp_ms must be a genuinely current timestamp. Reusing a stale/placeholder value (e.g. a timestamp copied from a prior GET) still returns HTTP 200 but silently no-ops the write -- the busy state does not actually change. set_busy_simple now sends int(time.time() * 1000).

Evidence

Direct on-device probing (device at 10.0.4.20, firmware 1.1.1):

$ curl -X PUT .../api/busy/snapshot -d '{"snapshot":{"type":"SIMPLE",...},"snapshot_timestamp_ms":<stale>}'
{"result":"OK"}  HTTP 200   <- but GET afterward still shows NOT_STARTED (stale timestamp silently ignored)

$ curl -X PUT .../api/busy/snapshot -d '{"snapshot":{"type":"SIMPLE",...},"snapshot_timestamp_ms":<fresh now-ms>}'
{"result":"OK"}  HTTP 200
$ curl .../api/busy/snapshot
{"snapshot":{"type":"SIMPLE","card_id":"00000000-...","is_paused":false,"time_left_ms":30000,
             "busy_bar_settings":{"theme":"busy","show_work_phase_only":false,"trigger_smart_home":true}},
 "snapshot_timestamp_ms":1785829020000}

Then ran the real calendar_countdown.main.run_once against the real device with auto_busy=true and a synthetic in-progress CalEvent (fake fetch; draw/clear no-op'd via a thin proxy to avoid touching the display, per this task's device-phase constraints):

summary: drew active 'synthetic verify event' -> drawn
GET snapshot -> type=SIMPLE, is_paused=False, time_left_ms=60000
PASS: auto_busy started a real SIMPLE session matching the synthetic event's remaining time

Device was returned to NOT_STARTED afterward (confirmed via GET) and left idle.

Tests

tests/test_client.py::test_set_busy_simple_payload rewritten to assert the nested body shape (mocking time.time for a deterministic snapshot_timestamp_ms), plus a new test_set_busy_simple_false_on_400 regression guard for the failure path.

$ TZ=UTC uv run pytest -q
........................................................................ [ 32%]
........................................................................ [ 64%]
........................................................................ [ 96%]
.......                                                                  [100%]
223 passed in 0.10s

set_busy_simple's public signature is unchanged.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: df82e512e9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Normalize the nested busy snapshot before writing

When auto_busy is enabled during an active event, the live GET shape documented here is {"snapshot": {"type": ...}, ...}, but calendar_countdown.run_once still checks busy.get("type"). It therefore treats every existing SIMPLE or other active session as absent, and now that this PUT payload is accepted, overwrites that session on every poll. Update get_busy() to return the nested snapshot or change the caller to inspect busy["snapshot"]["type"] before enabling these successful writes.

Useful? React with 👍 / 👎.