Apple adaptive lighting re-asserts all enabled lights every ~15-20s — bridge state echo suspected, ~60 cmds/min permanent mesh load

[simons-plugins]

Observed (2026-08-22, live broker capture)

With adaptive lighting enabled in Apple Home on ~8 bridged lights, Apple re-asserts every light's full colour state in a round-robin sweep every ~15–20 s, continuously — observed at 21:45 BST and also running at 02:24 (caught by z2m-plugin broker-down warnings logging identical payload pairs). Per light, per cycle:

zigbee2mqtt/<light>/set {"brightness": <N>}     # N = that light's current/target level, 0–255
zigbee2mqtt/<light>/set {"color_temp": 400}     # same circadian mired for all; ramps 363→400 across the evening
zigbee2mqtt/<light>/set {"color":{"r":0,"g":0,"b":0}}   # some lights also get black RGB

Steady-state load: ~60 commands/min across the fleet, 24/7.

Why this is serious

This is the standing background load that turned two otherwise-survivable faults into coordinator meltdowns (2026-08-20 and 2026-08-22): group /set = broadcast, the coordinator allows ~15 broadcasts per ~9 s network-wide, and the sweep permanently consumes a large share. Any additional retry loop or conflict tips the mesh into Failed to send with status=BUSY for everything.

A healthy adaptive-lighting accessory receives occasional CT updates (minutes-scale ramp). A tight re-assert loop means Apple believes its writes are not taking effect — i.e. the attribute state echoed back through the bridge does not match what Apple wrote.

Attribution is solid

• HomeKitLink is not registered with Apple Home and the HA HomeKit bridge is off — Apple reaches these lights only via this bridge.
• Payload shape (separate single-property messages) identifies the autolog z2m plugin as publisher, i.e. the commands arrive as Indigo device commands.
• No Indigo schedules/triggers/action groups were firing during capture windows (event log checked).
• Control experiment: turning adaptive lighting OFF for one light (Kitchen cabinet strip) removed exactly that light from the sweep within seconds (0 commands in 45 s, previously ~3/45 s). The rest continued.

Hypotheses (in rough order)

1. Level/CT round-trip mismatch: Apple writes CurrentLevel/ColorTemperatureMireds; the dispatch lands in Indigo (percent brightness, Kelvin whiteTemperature); the state echo converts back with rounding (0–255 ↔ 0–100 %, mired ↔ K) or clamping (device Kelvin min/max) that yields a value ≠ what Apple wrote → subscription report shows a mismatch → Apple re-asserts → loop.
2. Off-light level assertion: several swept lights are OFF; Apple asserts a remembered level (including 0) while the bridge reports the off-state level differently (e.g. CurrentLevel frozen at last-on value vs 0) → permanent mismatch.
3. Stale/slow state pipeline: during the sweep the plugin logs unmatched response (set_state dev …) every ~2 s — the bridge node acks state pushes late (or they time out), so attribute state lags and subscription reports carry stale values, feeding the loop. (Possibly the same family as the Alexa stale-subscription findings.)

Observability gap to fix as part of this

ExportBridge.on_command → _apply_command logs nothing on successful dispatch — only failures. Tonight that silence was misread as "Apple is not commanding" and cost an hour of misattribution. A DEBUG line per dispatched ecosystem command (device, command, args) would have identified this loop in one grep.

Suggested diagnostics

1. Add the DEBUG dispatch logging above; capture one sweep cycle end-to-end.
2. For one adaptive light, log the Matter attribute values the bridge holds immediately after the state echo of an Apple write, and diff against the written values (level and mireds).
3. Check whether the ~15–20 s cadence matches the fabric's subscription report interval.
4. Single-light A/B: adaptive on for exactly one light, everything else off — is the loop per-light independent or fleet-synchronised?

[simons-plugins]

Cross-project corroboration + two candidate mechanisms (HAMH, 2026-08-22)

Read alongside the #282 fix design: riddix/home-assistant-matter-hub's color-control-server.ts — the closest analogue to our export colour path — never zeroes a companion channel anywhere (CT commands forward kelvin only, colour commands forward colour only), and derives Matter colorMode from the entity's own colour-mode state. That validates #282's direction, and two mechanisms in the same file map directly onto this issue's hypothesis space:

1. Optimistic write tracking — after servicing an ecosystem colour/CT write they record the written value (3 s window, ±5 tolerance) and skip stale entity echoes that would revert it; a fresh echo confirming the value clears the record. This is a shipped solution to exactly the write-vs-echo mismatch hypothesised here as the driver of the ~15–20 s adaptive re-assert loop: without it, a pre-write state echo arriving after the write makes the bridge report the old value, Apple concludes its write didn't take, and re-asserts.

2. Off-light colour staging (executeIfOff) — Apple's adaptive lighting writes CT to off lights continuously. They stage the colour instead of forwarding it (forwarding would power the light on), and merge the staged colour into the next turn-on. Relevant to the tight brightness:0 + color_temp loops captured here (Twins/Lamp): worth checking what our _set_color_temp does when the target lamp is off, and whether each forwarded write's echo feeds the loop.

Neither is built here — recorded as ranked candidates for when this issue is picked up. #282's fix (removing the zero-writes) should land first; it removes the strongest known contributor to the mismatch and moves this issue's baseline.

[simons-plugins]

Overnight measurement 2026-08-22→23 — #282's fix does NOT stop the loop; self-termination points at CT quantization

With 2026.24.6 live (zero-writes removed, wire writes verified correct) and adaptive re-enabled on nine lamps, hourly moveToColorTemperature invoke counts from the Apple fabric:

20:00 5,675   23:00 6,156   02:00 6,147   05:00 14,549   08:00 39
21:00 4,234   00:00 6,147   03:00 7,461   06:00  1,089   09:00 12
22:00 4,416   01:00 6,147   04:00 9,693   07:00  4,802

• The loop ran all night at ~6,100/hr (metronomic — 00:00/01:00/02:00 identical to the invoke), spread evenly across all nine adaptive lamps (~500/hr each in the 07:00 sample), peaked at 05:00 as the dawn ramp stacked on the re-asserts, and self-terminated ~08:00 — 39 then 12 invokes/hr since, i.e. normal adaptive cadence.
• No bridge-side event correlates with the stop — no restart, no subscription change, no session event in the 06:30–08:30 window. Apple stopped on its own.
• Conclusion 1: Ecosystem colour/CT writes emit companion zero-channel hardware commands — bulbs flash blue and flicker off, manual colour changes don't stick #282 is exonerated as the loop's engine. The companion zero-writes made the loop's effects destructive, but with them gone and every write clean on the wire, the re-assert engine persisted unchanged overnight.
• Conclusion 2: termination coinciding with the daylight ramp moving the CT target is the strongest evidence yet for the round-trip/quantization hypothesis (ranked cause 1 in this issue): if the bulb quantizes an applied CT to its own physical step and reports that, Apple sees a persistent small echo mismatch at most targets and re-asserts indefinitely — until the target lands on a value the bulb reproduces exactly, at which point the loop falls silent with no other change. Overnight target (color_temp: 400) looped; some morning target does not.
• Next measurement when this issue is picked up: log written-vs-echoed mireds per lamp for one loop cycle; a constant small delta per lamp confirms quantization, and the remedy is an echo tolerance band — cf. the HAMH optimistic-write pattern (±5, 3 s) recorded in the previous comment.

[simons-plugins]

Morning follow-up (2026-08-23) — stale-snapshot countermand observed live

New symptom: 09:38:26 — Auto Lights turned all 5 kitchen lights on (walk-in). The cabinet strip reached brightness 254/255 ON, then flipped to state OFF, brightness 255 within the same second. Auto Lights sent no off (event log clean). z2m log shows the strip also received "off/brightness 0-3" assert bursts at 08:57 and 09:27 (~30 min cadence).

Trap capture (broker, 09:40–10:03): a manual ON at 09:41 was NOT countermanded; the strip then received two assert visits of {"brightness": 255} + {"color_temp": 222} — its current state. 222 mired = 4500K = correct morning circadian value (was 400/2500K last evening), confirming the circadian writer.

Interpretation:

• The writer re-asserts a per-light snapshot. When the snapshot matches reality the visit is invisible and cadence is relaxed (~5–8 min/light this morning vs 15–20 s during last night's fights) — consistent with the echo-mismatch theory: mismatch tightens the loop.
• The 09:38 off = a stale snapshot asserted immediately after a legitimate state change (subscription report triggers re-assert before the writer refreshes its belief). Practical effect: any Auto Lights 'on' can be instantly countermanded — user walks into a dark kitchen, light flashes on for a second, goes off.
• Note: this strip had adaptive colour toggled OFF in Apple Home the previous evening (verified quiet for 45 s at the time), yet still receives brightness+CT asserts this morning — either the toggle did not fully detach the light, a second accessory exists, or on/off-level assertion is independent of the colour toggle. To be re-verified in the Home app.

The stale-countermand race elevates this from "background load" to "visibly fights the automation system". Worth reproducing under the DEBUG dispatch logging as the first diagnostic.

[simons-plugins]

Concrete round-trip mismatch found: 255 vs 254 at full brightness

Renewed capture (2026-08-23 10:18–10:38): the writer asserts {"brightness": 255} to the cabinet strip; the device reports "brightness":254 back. These can never converge:

• zigbee2mqtt's level range tops out at 254 (it clamps 255).
• The Indigo z2m plugin converts 100 % → round(100 × 2.55) = 255 on the way out.
• So a full-brightness light echoes 254 forever against a 255 write — a permanent mismatch for hypothesis (1), sustained at every full-brightness light in the sweep.

This also suggests where to look for the exact conversion chain: what Matter CurrentLevel does the bridge receive from Apple, what percent does _set_brightness(or equivalent) hand Indigo, and what does the state echo convert 254 back to (100 %? 99.6 % → rounded where?). If the bridge reports a CurrentLevel ≠ what Apple wrote, the loop is explained for the full-brightness case. The 0-brightness lights may have an analogous edge (level 0 + OFF vs remembered on-level).

Cadence note: in calm state (all snapshots matching) the sweep relaxes to ~1 visit per light per ~10 min; the 15–20 s frenzy appears only while a mismatch persists — consistent with subscription-report-triggered re-asserts.