Based on the comment below, I would like to find out if this still happens and why.
It’s not the first time you’re commenting this.
With 20+ Philips Hue motion sensors I’ve been using it for years without problems.
I need to add that I actually used the sensors with the Home Assistant Community app before moving to Matter on the HP2023
Questions for you
a. Which Homey / motion sensors/app are you using?
b. Can you reproduce it? Just to be sure it still happens on the latest Homey firmware.
Without having all the info, I can think of potential reasons why this would happen. Some may be theoretical due to my lack of knowledge about how Homey handles it. Please feel free to correct/add:
Potential cause: Polling
In case you use Philips Hue motion sensors with the Philips Hue app for Homey (PHA)
The app is polling the Hue bridge which could lead to a delayed arrival of motion to the flow, just after the zone is inactive for x minutes card triggers, while you think you just created motion and the card should not trigger.
Under Matter or with the Home Assistant Community app there is no polling. Did you test these?
Potential cause: CPU high
When ‘zone is inactive for xx minutes’ card strikes, I believe it did so a exactly on xx:00. There could be many flows starting at that time, leading to the CPU queuing the next actions.
I think I read somewhere that Athom fixed the way the card strikes (not only at xx:00, but also at 00:01 etc thereby spreading triggers in time), but I cannot find proof of that. Maybe it is only for the Homey Pro early 2023. It would mean an improvement, though it could still happen
Potential fix from @Marius_Stensrod: an additional activity check to bypass the issue
The question is still for me: why is it a fix?
a. Which Homey / motion sensors / app are you using?
b. Your fix suggests that a millisecond after the zone inactive card triggers, the zone can be tested with an AND is Active card showing activity. This should not be needed and could point to a bug in the Homey firmware. Let me know if you can still reproduce and current Homey firmware.
HP23 and HP19 /not relevant, because it happens in every zone/Aqara, Frient, Fibaro .
I think that i did not make it clear, what card i was refering too (check snip in this post). In this example, HP23 with v11.0.1-rc.2. Zone activity states active, that is why my “fix” is implemented. It is logical that the “inactive zone” card starts the timer with every report on “inactivity”, as the Homey consept is “run in parallell”. I do not consider this as a bug! So my “fix” is like this:
If i have a sensor (the only one in the zone), and it reports “no motion” after 5 minutes, then i guess that the “Zone inactive” timer starts. Let us say that i have the card to trigger on 15 minutes. Then it will trigger on 15 minutes, but when i enter the room 14 minutes after the “no movement” from the sensor, and leave again, then another timer start, for the same zone. If i do stay in the zone, and the first timer elapses to the end (the zone is active) the lights turns off 1 minute after i entered the zone again.
Thanks for starting a topic on this one.
To me, the title doesn’t reflect my experiences.
The ‘zone is inactive’ trigger works flawless here, so I think the title should be
“Zone inactive for x minutes triggers, while there is motion, leaving me in the dark”.
So here’s my setup:
2x Pro19
Sensors:
-Aqara zigbee motion + contact (per Homey, and later on per HA zigbee2mqtt),
-Sonoff zigbee contact (per HA z2m),
-DIY presence & motion wifi per ESPhome
I do not own sensors which should be polled
I encountered the fact the ‘zone was inactive for x minutes’ trigger issue when I started with Homey, say Q4 2020
After that, I did not want to do any further tests.
What’s the point tbh, when it seems not to be a generic ‘bug’ of the timed zone inactivity detection.
I keep ‘promoting’ the use the ‘zone is inactive’ trigger with use of an additional Chronograph timer, like this:
with a Pro19, the steps between the lower values are far too large, pretty useless to me;
I can only pick 1 or 5 or 10 minutes, while I like to be able to fine tune it, say 0.5, 1.5, or 3mins
with a Chronograph timer I can set a free to choose duration time from 1s. in steps of 1s.
chronograph timers survive a power outage / reboot, because they don’t just count down, they count towards a timestamp, created by timer start time + duration time. This way, your lights / devices still will be turned off after Homey has started, while there’s no activity
it’s possible to use a numeric variable as timer duration value. It’s easier to finetune, or even set different inactive times for different situations
For your information: On the device page I see al my zones and motion/contactsensors in it. I also see that a zone is active as long as one of the sensors is active.
For test purposes in one flow for “when zone becomes active” I set the lamp to 100% and than to 50%, presuming the flow runs once. However I notice the flow runs several times while the zone is active. As I see the light goes to 100% and than to 50%, probably when the sensor has detected motion again whilst the zone is still active.
That do confirme what i thought, it is the parallell. Thank you for confirming it
Edit: i read the “Zone became inactive”. But i do think that it is several timers to the same zone. Can you try it? I have experienced numerous times that the lights turns off, so i am pretty sure how it works, that is why i implemented the “fix”. But in light of the topc, it would be helpful to log the “zone became inactive” with a variable or so on, then log the time between the various reports.
Well, every time motion is detected, some system code sháll run (as you don’ t want to miss interrupts). However when motion is detected whilst the zone is active, a timer should be reset only. The user flow shall only run when the zone changes from inactive to active.
Anyway, it looks like a bad design/implementation.
I do understand your point, if the “Zone inactive” card timer is running, it should reset with every “inactive” message from the zone. But my experience is not that.
It’s just I find it a very reliable timer app, and I like the many options;
also I don’t know + I didn’t test if other timers survive power outage / reboot, but maybe other timers also do!
I use “Countdown” and have not experienced any issues. I have some timers that are running for several days, (you can say it is real countdowns so i do not forget) and after a restart it just continues.
I once asked an Athom representative if the delay in advanced flow could survive a reboot, unlike the delay in standard flow cards;
The answer was “no, that is not necessary, while Homey almost never reboots” …
I must disagree with the Athom representative. The Homey Pro have to be rebooted from time to time, like my Raspeberry pi’s. But it is nothing i have to do often.
Yeah me as well, hence the trailing dots.
How about the restarts after any firmware update for example
And how many users restart Homey on a daily / weekly base (which of course is a weird workaround for any issue)
Ps: Trailing dots and so on is not easy to understand when i guess we are speaking in different languange, and then we will have different meanings of our “typings” in the written language. But i do think we agree
