I do not understand. I did use the function to turn of the lights, so the “Zone became inactive for xxminutes” is the only one i did use. Maybe i do not explain it good enough, can you give it a try @Peter_Kawa ? I do not have many more ways to explain it, but i guess you get the issue, so can you give it a try?
I can only tell you my case. Never. Only homey firmware updates do that.
I do make efforts in all flows to avoid where I can to trigger at the same time as other flows.
unfortunately i had to restart the HP23 every day, when they had the Silicon Labs ZigBee issue, now i restart the HP23 every 3 day, to keep the RAM and CPU usage low. It is not as good on the HP23 as on the HP19.
The picture below shows that several messages “zone becomes active” are followed by one “zone becomes inactive. The first messages are triggered by a motion sensor, the latter ones by a contact sensor.
My zone becomes inactive after 1 minute. The time between motion on and off is set to 1 minute. I might have to set zone-inactivity to 2 minutes to give the motion sensor time enough to detect another motion.
@Peter_Kawa when in the dark, maybe you can log if motion is detected?
Even if the Homey never reboots, it is required to make a fail save system!
1 Like
Even if you are asking @Peter_Kawa , can i ask you to log “The zone been inactive for xxminutes” instead? With a zone you frequentely enter aftert he zone has been marked as “inactive” for the first time. I have now logged that, but i am qurios of you findings. What HP versiong are you running?
That has been logged in the picture. See the few messages “zone garderobe inactief”. When the door opens whilst the zone is inactive, the zone becomes active as expected. What do you expect to see in the log? 2 or more inactive messages? I cannot reproduce that.
I will add som extra flows and logging and distinct between lamp on/off and zone active/inactive.
By the way, Peter can get into the dark because the motion sensor did not send “motion detected”. As he has the problem, he is the only one to do some research.
My Homey Pro 2023 is on 11.0.0
The logging of 5 flows:
- on activity detected switch on lamp
- is inactive for 2 minutes switch off lamp
- on activity detected make log entry
- on inactive detected make log entry
- on inactive for 1 minute make log entry
Als messages show up as expected. The delay of the motion sensor is set to 1 minute.
The question is: After the motion detector has sent “no motion detected” how fast can it detect motion?
Thank you @Rmb , My findings in my logging now, is like your’s, I find that disturbing, when my experience without the logging is different. The logging confirmes that the timer start at new again when the zone sais that is no movement.
*The first message is “Zone active”, the one you can not see in the “snip”.
When i implenteded the check of “zone active” after the “zone inactivity XXminutes” everything was solved. There has to be a culprit somewhere. I do not understand this. When i have been in the Zone again, and it is active in app, the lights turned off because the floe said “so”.
I think you should also log the messages of the motion sensor to be sure.
That could be, but then it would also fail with the ‘zone is inactive’ trigger + external timer option added. And that was just my perfect solution to the issue.
And it was not a consequent “left in the dark” scenario, it just happened sometimes, at the most inconvenient times, and of course I did not log it back then. 
Well, OK, I’ll setup a test flow for myself as well, maybe it reveals something.
Now I changed the zone inactivity to 2 minutes, I will first wait to see if I “get into the dark”
I do not think it is neccesary because i am pretty sure what i triggered now, but i will do in a test flow.
I think i will start logging to syslog with the different actions in all of my zones. Something is off, and i think it is Homey 
Well, in one zone I use a motion and a contact sensor. And I notices that the contact sensor reacts always and faster, compared to the motion sensor.
I will add extra flows for logging events from the motion sensor.
In the Zone of my choose now, it is 2 motions sensors from Fibaro, so it is not that simple that it is a mismatch between contact and motion. But i appreciate more logging, because something is off with the “built in” Zone card.
Here are my measurements. I do not see where Homey fails (but I do not have the issue).
Homey: HP2023
Measurements are approximate.
Sensor: Hue motion sensor on Matter
I did this three times.
Test 1: 4% CPU load. Memory usage around 440MB
Test 2: 2% CPU load. Memory usage around 440MB
Test 3: 2% CPU load. Memory usage around 440MB
Results: Test 1/Test 2/Test 3
Tested with both Simple flows and Advanced flows.
- Zone activity is 71/79/159ms after sensor motion arrives to Homey. This is the time it takes for Homey to process.
- Motion sensor turns to inactive after 10s. Zone inactivity is 109/150/108ms later.
- Zone inactive for 1 min is set after 1 minute and 2ms/7ms/5ms: this is a very short time as there is no sensor processing, just the zone timer.
For comparison (very similar):
Sensor: Hue motion sensor on Philips Hue app
- Zone activity is 95/78/127ms after sensor motion arrives to Homey.
- Zone inactivity is 98/95/84ms after the sensor inactivity.
- Zone inactive for 1 min is set after 1 minute and 4ms/3ms/4ms
Every time the light is switched off in my zone “Hal first floor” after 2 minutes of inactivity, there is a logging “Zone Garderobe is INactive for 1 minute.
Quite strange. Anyway, a zone cannot get inactive when it is inactive.
I will restart Homey.
Edit: after restart, the same thing is happening. It will not happen when I switch on and of the lamp by clicking on the tile.
It’s two different zones right?
- Hal
- Garderobe
What’s their relationship in the devices hierarchy?
Can you move them and test again?
The hierarchy is
- House
- Halls
- Garderobe
- Hal 1 floor
- Halls
For now I am done testing. This is getting to weird. I will have a look some day. I will be watching what is going on.
Edit: wrong trigger on log flows, so my mistake. I will get some more sleep.
It’s very hard to test for. We need an actual case to work with.
My guess is that it’s CPU related or that it may have been fixed already by Athom. I’ll ask Athom.
If we find a case we should also not forget to check if the person is using simple/advanced flows which defines the way THEN cards are run (concurrently/sequentially).
