fix: prevent transient Zigbee off-state from cancelling adaptation

[florianhorner]

Summary

Fixes #1449 — lights turning off immediately (~680ms) after being turned on, particularly with Zigbee devices like FUT035Z and separate_turn_on_commands=True.

Root cause

When a Zigbee device briefly reports an off state during a turn-on transition (common with MiBoxer/FUT controllers), the state_changed_event_listener's on→off branch at line 2539 unconditionally called reset(), which cancelled the in-flight adaptation task. The off→on branch had an is_proactively_adapting guard (line 2557) but the on→off branch did not.

Additionally, just_turned_off() had a context-equality check (line 2760, added in #696) that fired before _off_to_on_state_event_is_from_turn_on, causing false positives when both events shared a context ID inherited from the same service call chain.

Changes

1. Add is_proactively_adapting guard to the on→off branch — Transient off states during proactive adaptation now skip reset() (preserving the adaptation task) while still recording on_to_off_event to prevent stale state.

2. Reorder and tighten just_turned_off() checks — _off_to_on_state_event_is_from_turn_on now runs before the context-equality check, so real light.turn_on calls are never misclassified as phantom events. The context-equality check now also requires a matching turn_off_event, preventing false positives from inherited Zigbee context IDs while preserving the original Bail adapting if on event equals off event context #696 protection.

3. Fix truthiness bug in _split_service_call_data — Changed if service_data.get(attribute) to if service_data.get(attribute) is not None so brightness=0 is no longer silently dropped from split service data.

Analysis

This fix was validated by 8 independent code reviews across 4 different AI models (Claude Opus, OpenAI Codex/o3, Perplexity Deep Research, adversarial agents). The Perplexity thread with the full analysis is available here for reference: https://www.perplexity.ai/search/i-m-analyzing-a-confirmed-bug-UNxwI3FaRouo_nwUM6mymw

How to verify

Users experiencing #1449 should look for this new debug log line when the transient off is handled correctly:

Detected an 'on' → 'off' event for '<light>' with context.id='<id>' during proactive adaptation, skipping reset

The absence of Cancelled ongoing brightness adaptation calls after a turn-on confirms the fix is working.

Test plan

• Verify lights with separate_turn_on_commands=True no longer turn off intermittently after turn-on
• Verify lights with transitions still properly cancel adaptation on genuine light.turn_off calls
• Verify sleep_brightness=0 works correctly with separate_turn_on_commands=True
• Verify rapid on/off/on toggling still behaves correctly

🤖 Generated with Claude Code

[basnijholt]

Sorry it took me so long to get to this. I've been a bit overwhelmed by the number of AI-assisted PRs opened here recently, and I've also been spending nearly every spare hour on my biggest project so far, MindRoom.

I'm very supportive of using AI for coding, but many of these PRs still need careful human review because even plausible-looking changes can introduce subtle breakage. That backlog made me postpone reviewing them for a while.

I've now done a batch review with Codex / GPT-5.5 (xhigh). This comment is AI-assisted, but I've reviewed it before posting.

This looks like the right direction to me. I do not see a blocking issue in the implementation, and the _split_service_call_data change is also important because it preserves zero-valued brightness data instead of dropping it as falsey.

The one thing I would really like before merging is regression coverage. This PR touches subtle context/cancellation behavior, so tests for the transient off-state case and the zero-brightness split data case would make this much safer to carry forward.

[basnijholt]

Follow-up from a deeper Codex / GPT-5.5 (xhigh) pass.

I re-read the actual context/cancellation change and still do not see a code-level blocker. The ordering change in just_turned_off() makes sense: a real light.turn_on should win over the old same-context polling-artifact shortcut, and preserving 0 in _split_service_call_data() is also important for sleep_brightness: 0.

The missing piece is regression coverage. Could you add tests for:

1. A proactive adaptation where the device briefly reports off, verifying that the adaptation task is not cancelled/reset.
2. The existing polling-artifact case where a real turn_off still causes just_turned_off() to return True.
3. _split_service_call_data() preserving brightness: 0.

This is subtle enough that I would be much more comfortable merging it with those cases pinned down.