Hey all, I’ve got an automation which I’m almost happy with. Nothing special but it’s for activating lights on motion (certain time of day), turning off after certain time of no motion etc.
The one issue I have is that if the lights start to dim, if motion is detected during that action, the lights do not come back on. Presumably that is due to the lux levels already being high. I’m finding myself having to stay still for a few seconds, wait for the lights to turn off and then move about
How would you go about tackling this? If I could detect that the lights are turning off (i.e. automation is still running), I could potentially ignore the lux value and turn the lights on anyway?
you should grab the trace and see exactly what’s happening… don’t presume.
since you have the off case transition and you have restart, another possible reason is that you have a condition that the light must be off… but if you are transitioning, perhaps the light is still considered on? look at the trace and see for sure.
it sounds like you understand the problem. If the lights are fading, the light level is likely high enough for the automation to think the room is bright enough and not turn the lights back on.
I think I would use a toggle helper (input boolean), called something like ‘lights are fading’, which is true when the lights are fading, and false afterwards.
Toggle the helper either side of the fading command, so on just before the fade, and off afterwards.
Then have a new condition in the automation, based on whether or not fading is true.If fading is true, ignore the lux level.
However, this all assumes the automation waits synchronously for the lights to transition before going to the next step… I’m not sure if it does or not.
UPDATE:- I dont think a light delay does hold up the automation, so you might have to put in a matching ‘wait’ to hold it up artificially.
Thank you so much!
I had no idea there was such a feature as traces. It looks very powerful so I will take a look at that after I’ve had the same problem.
I prefer to have many simple automations (my rule is - with some exceptions of course - that each automation normally only does one thing) so my paradigm is a little different… I just find that many simple automations make troublshooting MUCH easier rather than something ‘monolithic’ that tends to get more and more complex. (So, I also have automations that call some generic scripts that are used by many automations, etc., to reduce code redundancy.)
I have dedicated timers that when they are stated, turn the lights on, and when they are cancelled or finished, turn the lights off. My motion sensor simply (re)start the timer every time it detects motion. If a timer is already active and motion is detected, telling the time to “start” just has it continue being active but reset to the beginning of the duration. Works VERY well with cheaper motion sensors such a PIR - even if people are not moving, the lights will only go off X minutes AFTER motion was last detected. (If you are in a room where you sit and read for long period of time, just lengthen the timer.)
The only issue I have found with this is if someone turns off a wall light switch (which cancels the timer that then turns off the lights) and then walks out of the room, their subsequent walking out of the room (if motion is sensed) would restart the tmer which would then turn the lights back on. So for each of those scenarios, If motion is detected, only restart the timer for the lights IF the wall light switch had not been turned off MANUALLY within the last 5 minutes.
To each his own. Of course I have enriched the above with input numbers which represent the timer lengths that can be adjusted as a slider on a dashboard, and also drop-downs to enable to disable all automation for any specfific room (which really doesn’t disable the automations (which can also be done in code), but the automation logic checks the value of the drop-downs (which have two values: “Enabled” and “Disabled”))…