A mode toggle does not make a presence sensor send a new report. That matters when lighting depends on both occupancy and a manually selected mode.
In our bedroom, one Home Assistant automation listens to EPL Zone 1 occupancy, PC/Mac mode changes, and a fast under-bed PIR event. It runs in restart mode.
When PC or Mac mode changes, the automation runs its existing decision tree again. It reads the latest known EPL occupancy state and the current mode helpers, then selects the correct lighting branch immediately. It does not wait for another movement event.
The important distinction: homeassistant.update_entity is not a universal sensor refresh. It can update integrations that support polling, but it cannot force a Zigbee PIR or presence sensor to report right now.
One pitfall we found: this only works for helpers explicitly listed as triggers. Our current automation reacts to PC/Mac mode changes; any new sleep or assist-sleep mode needs its own deliberate transition trigger or decision path. Otherwise Home Assistant may keep the previous lighting result until the next sensor state change.
For us, “re-evaluate the current state on a mode change” is more reliable than trying to force a sensor refresh.
@li1111 This is a really solid (and very Home Assistant-realistic) way to think about presence + lighting logic: treat mode changes as first-class triggers and re-evaluate using the latest known sensor state, instead of trying to “poke” Zigbee sensors into reporting.
On the Aqara side, this aligns with how presence sensors are typically used in automations: they expose states like Presence / Absence and also duration-based conditions like “Presence for …” / “Absence for …”, which are meant to be consumed by your logic when they change—rather than being forcibly refreshed on demand. This is especially true with presence sensors like FP2/FP1, where “Absence” can inherently take a short continuous-detection window (often several seconds) before it flips, so your “decision trigger” pattern makes even more sense when modes change mid-state.
If you want to make your setup even more robust when you add new modes (sleep / assist-sleep, etc.), a practical pattern is:
Keep every mode helper as an explicit trigger (like you’re already doing)
On trigger, branch off the current occupancy state (and optionally use “Presence for/Absence for” to debounce “just left” vs “actually gone”)
Reserve motion/PIR triggers for capturing new activity, not for correcting logic after a manual state change
Also, if anyone is doing this purely inside Aqara Home (instead of HA), the recommended baseline automations are basically the same philosophy: “When Presence → turn on”, “When Absence for a period → turn off”, etc.—the decision comes from state + time, not from refreshing the sensor.
This information comes from community discussions and user experience summaries and may vary by environment. Please verify carefully.
Original post link: N/A (forum thread link not provided)