It is again this deceptively simple question of turning lights on/off based on motion sensor.
It would have been very easy if the motion sensor (Aqara P1) worked reliably, but unfortunately it does not. The kitchen has the П shape, the motion sensor is on the left side and especially when I am cutting stuff on the right one it cannot detect the motion and subsequently turns off. I guess the delay to off can be extended, which gives some time for the sensor to catch an intermittent movement, but this won't work when you just go there to fill a glass with water or something.
Thus, I am thinking of creating some logic that will vary the delay to lights off based on conditions. One way I am thinking of doing this is counting "fake light offs". A fake light off I define as when the light turns off and then quickly on in the next five seconds - this is assuming that I am still in the area and make a rapid movement to reactivate the sensor shortly after it went off. If a fake light off is detected the delay to off should be increased.
So we can start with 30s delay. If I grab a quick glass of water and go back to the sofa the light turns off in 30s, everything is cool. But if I am still in the area, but the sensor cannot detect me, the light will again go off in 30 seconds and back to on withing 5 seconds. Now I want the delay to off in this case to be, lets say 2 minutes. If the same thing happens again after two minutes, increase the delay to 5. And so on... Once the light is off and not reactivated within 5 seconds, we can reset the counter and start again with 30 seconds delay.
Another potential way of doing it is by measuring the active time. So light turns on, the longer it stays on, the longer the delay to off should be. If I am cooking for 1h I don't mind if the light needs a few minutes to turn off after that. But if I am jumping in the kitchen just for a few seconds, I want the light off as soon as I am gone.
Does what I am saying make sense? It sounds like a nice brain teaser and although I can build the logic in my head, I am still very inexpirienced with node-red and don't know which nodes will be most useful.
Well, that's a quite cool idea to solve your issue & makes for a quite cool project (!) ... but wouldn't it be way cooler to install just a second motion sensor, to cover your whole kitchen area?
The ON message, whatever that is, starts a timer in the inject node that will send an OFF after some time.
The ON message is also passed to the output by the filter, assuming the filter state isn't ON.
If a new On message arrives the filter will reject it whilst the timer in the inject node will be reset, effectivly extending the turn off delay.
Sending an Off & reset will send OFF to the output, assuming the filter state not OFF and also reset the trigger preventing it from sending additional messages.
The change node strips out 'reset' from the outgoing message and isnt strictly necessary but many node use it so dropping it is not a bad plan to protect down stream nodes.
I thought about this too, but I don't like throwing more hardware at a problem that should be solved logically. Besides, flexing my brain is one of the reasons I got interested in home automation at all. Worse comes to worse, yeah I guess a second sensor will fix the issue.
@Dyslexicbloke , @marcus-j-davies , thank you for the suggestions. I actually checked the trigger node, but I will need sometime to get my head around it. Unfortunately the sensor does not communicate each time there is an action, it basically detects and action and stays dormant in the cooldown period. But I guess I can build the logic basedon the timestamp of the initial trigger.
The range node also looks like a potential solution. From my two suggestions above, I actually like the second one more as it does not involve turning the light off and on again to detect a "fake" light off.
I will try to get this working through the weekend and update the thread if I get the wife stamp of approval.
Why not change the settings of the motion sensor - change the cool down time to be very short and then use the Trigger node to extend the message
You could also couple this the Within-time node (from the Contrib-Sun-Pos package) - so you could set a number of time ranges that match up with obvious mealtimes and have the default amount of turn on time be longer in those times (which would also be when you would likely doing meal prep) and the rest of the time you could have a shorter off time with no motion detected
@craigcurtin , Aqara sensors are notorious for their long cool down time, the older one was 90 seconds I believe, I am using the new one which can go down to 10. Anyway, I have made a rookie mistake, by not adding a delay to the moment cool down period ended.
After motion detected, the cool down period starts, during which there is no motion detected and the status of the sensor is active. Once the cool down period ends, the sensor triggers motion off and if there is additional motion it triggers back on. My mistake was not adding a delay to the cool down end period to turn off the lights, so they immediately went off the moment cool down ended unless I made a movement in that exact nanomilihypersecond to re-activate the sensor. Now I have added 10 second delay to the event:state node (home assistant), so the lights stay on for at least 10 seconds during which I can make movements to re-activate the sensor.
Works much more reliably now, but I would still like to proceed with over-engineering and over-complexing the logic more than it needs to be, just as a learning exercise. As it seems I need a lot of learning! Your idea to include also rough meal times is interesting! I was also thinking to connect all my kitchen appliances with smart plugs and work with that as well - if the cooktop and oven are turned on to keep the lights on for longer. I also want to play with the brightness as well, so if you go during the night for a glass of water the lights are at 10% brightness or so.
Aah - sounds like you have the battery operated ones
I personally would take it out of the hands of the sensor - and move the logic into NR - assuming it sends a different signal for motion detected and no motion detected.
So for all intents and purposes - ignore the no motion detected and instead every time motion is detected set a flow variable to show motion has been detected and have a seperate trigger used to countdown against it
These triggers can then be different for different times of the day or different lightl levels etc
Usually you can not use smart plugs for cooktops and Ovens as they draw too much currrent - instead you would need a circuit monitoring solution - have a look in the recent threads - there is a veyr long and informative one about this - authored by BartButenaers
Thanks for the suggestion. I did not had time to work on this during the weekend, who knew that IP67 led strips do not stick to basically anything...off topic a bit.
Btw, I have a separate breaker for the kitchen appliances, so I was actually thinking of using Shelly Pro series, like this one: Shelly Pro 1PM - All Products - Products - Shelly They state 16A and for the pro series I think they mean it. I'll check the other thread of course, tons of useful information here.
To give a bit of an update as I hate it when people post questions, get advises and do not return to answer what they have done.
So, I managed to create the algorithm to delay the turn off of the lights depending on how big the difference was between initial motion and initial lack of motion. I have done this in various ways - I think the most elegant one was with the interval node to measure the difference between two consecutive messages.
The issue is what happens when a longer delay is followed by a brief one. So lets say that I have a different lanes controlled by a switch node - depending on the time between motion on and motion off, I set additional delay for the light to stay on, for example:
30 sec between motion on/off keep the light on for 30s more, check if the motion is off and turn off the light if true
5 min between motion on/off keep the light on for 5 minutes more, check if motion is off and turn off the light if true.
So lets imagine that we fall in to the second use case and we start measuring the 5 min delay until off. If at 1.5 minutes from start of the 5 min delay another brief on/off event occurs, there will be another 30sec delay activated, thus the light can turn off in 2 minutes instead of 5. I guess the proper method here is to introduce some gate nodes that will close the flow for further input as soon as we start counting the delay to off and reopen it once it is done, but I think this was pushing it a bit too far on the complexity side and probably I would have other issues.
Anyway, it was a fun exercise, but in in the end I decided that it is not worth it to complicate it further as right now it works good enough in almost the most basic way - when the motion is off, give it 30 seconds to turn back on and if that doesn't happen turn the light off.
