Symptom
Every morning the House Mode flow wakes Sleeping → Home and the notification/log reason reads morning activity (lights). In ~3.5 weeks of logs, 34 of 35 wakes are (lights) and one is (dimmer) — the landing motion sensor has never once been the credited trigger, even though walking onto the landing is what physically starts the sequence.
This is misleading (the landing light is motion-controlled, so "activated by light" is technically true but hides the real cause) and, more importantly, fragile: on a bright/high-lux morning where the landing light stays off, the motion-based wake won't fire and the house only wakes once some other light/dimmer/TV happens to change — noticeably later on some days.
Root cause
Input-path asymmetry into the Mode engine function:
- Motion (
presence + indoor server-state-changed, incl. binary_sensor.landing_motion_sensor_occupancy) is routed through a ha-get-entities node before reaching the engine — a full-state round-trip that exists so the Away evaluation always runs on a fresh snapshot.
- Lights (
all lights (activity), incl. light.landing) go directly into the engine with no round-trip.
So although the motion sensor fires first, the light's state-change reaches the engine first (it skips the get-entities hop). The engine flips to Home and logs (lights); when the delayed motion event arrives, emitMode early-returns because the mode already changed. Motion is never credited.
Notes
- The engine watches HA websocket state only (
server-state-changed) — it does not subscribe to MQTT, so motion sensors carry the full Zigbee→MQTT→HA→WS→NR latency plus the extra get-entities hop, giving them the worst-case arrival time of any input.
- The engine's activity-path reason label also emits the topic word (
lights) rather than the entity id, because the entity id isn't threaded through on that path — so it can't even name which light.
Possible fixes (to discuss)
- Give the presence/indoor input a direct fast-path to the engine for the morning-wake decision (keep the get-entities round-trip only where the Away logic genuinely needs the fresh snapshot), so motion wins the race.
- Prefer/attribute motion when an indoor sensor turned on within the same short window as the wake, so the reason is honest.
- Thread the triggering entity id through the activity path so the reason names the actual light instead of the generic topic word.
Symptom
Every morning the House Mode flow wakes
Sleeping → Homeand the notification/log reason readsmorning activity (lights). In ~3.5 weeks of logs, 34 of 35 wakes are(lights)and one is(dimmer)— the landing motion sensor has never once been the credited trigger, even though walking onto the landing is what physically starts the sequence.This is misleading (the landing light is motion-controlled, so "activated by light" is technically true but hides the real cause) and, more importantly, fragile: on a bright/high-lux morning where the landing light stays off, the motion-based wake won't fire and the house only wakes once some other light/dimmer/TV happens to change — noticeably later on some days.
Root cause
Input-path asymmetry into the
Mode enginefunction:presence + indoorserver-state-changed, incl.binary_sensor.landing_motion_sensor_occupancy) is routed through aha-get-entitiesnode before reaching the engine — a full-state round-trip that exists so the Away evaluation always runs on a fresh snapshot.all lights (activity), incl.light.landing) go directly into the engine with no round-trip.So although the motion sensor fires first, the light's state-change reaches the engine first (it skips the get-entities hop). The engine flips to
Homeand logs(lights); when the delayed motion event arrives,emitModeearly-returns because the mode already changed. Motion is never credited.Notes
server-state-changed) — it does not subscribe to MQTT, so motion sensors carry the full Zigbee→MQTT→HA→WS→NR latency plus the extra get-entities hop, giving them the worst-case arrival time of any input.lights) rather than the entity id, because the entity id isn't threaded through on that path — so it can't even name which light.Possible fixes (to discuss)