I have several simple motion detection automations some that use a condition for luminance level below X and they have been working for a long time. My automations have been running in “Single” mode and each time they are retriggered before completing generate an error which is normal. In order to get rid of the errors I switched them to “Restart”.
So what I have seen is that in “Restart” all my motion automations ignore the condition for luminance no matter where I place it in the script, at the beginning or as part of the “Choice”. Has anyone else seen this? I don’t want to open a ticket if I might be doing something wrong.
This is one of my automations it uses a different light level depending on time of day. I tried moving the luminance as a condition in the choice area but that didn’t work either.
Okay… did a bunch of playing and solved this… hope this helps someone.
Removed the illuminance from the initial requirement and moved it into the choices BUT this time I used the “And” function so Option 1 uses “Time AND Luminance” as a condition. Also moved the default action to Option 2 and the only condition there is Luminance.
So this is my new automation set to “Restart” so no more log error’s when motion is retriggered and it works perfectly again.
They’re warning messages and if you don’t want to see them, leave mode as single and set max_exceded to silent.
There are situations where it’s acceptable to disregard requests to execute a running script. In those situations, silent suppresses the warning messages.
I did switch to “Restart” but read carefully at what happened when I did… it ignored my “Luminance Condition” and I had to figure out how to have it recognized again.
Sorry… it was I who didn’t read it all… I can see how that would work but now that I know what appears to be “the proper way” to write the automation I’m thinking it’s another parameter not having to be managed but a good suggestion.
The max_exceeded: silent option was introduced shortly after scripts were enhanced with mode. It acknowledges the fact that there are situations where calling a running script is acceptable and should be ignored and not reported.
I can see where it may be useful and is good information to have for future reference. For my few relatively simple motion scripts rewriting them to eliminate the warnings was no big deal. People now have 2 options depending on their scenario. Big thanks to you for sharing!
Your revised automation, that now uses mode: restart, will cancel the wait_for _trigger every time the motion sensor triggers the automation. That doesn’t appear to work the same way as the previous version that used mode: single. Is that intentional?
Yes… Restarting the automation eliminates the error message by cancelling the previous script in the “wait for” stage. As long as motion is detected inside the wait for time window the light stays on and only one script is running not multiples. That eliminates warnings in the log telling me an instance is already running. When motion is no longer detected in the wait for time window the light is turned off and the script finishes waiting to be triggered again. Keeps the system operation much cleaner. I’ve had just my office motion detector log well over 100 warnings while reading email in the morning… not anymore. So imagine the warning entries in the log for 10 motion detectors in the house and two people home all day that no longer appear. I’d rather eliminate something when I can instead of suppressing it because I never know what else I may be covering up.
The only scenario where multiple instances would be running is if you use mode: parallel. It doesn’t happen with any of the other three modes (Script Modes)
As explained, so would have using max_exceeded: silent which was added to Home Assistant for this very purpose and doesn’t require re-designing the script which is not always feasible or practical.
Re-doing the script was easy once I understood how to use the “And” function in the Option section. Apparently when just listing Conditions in the Option area as soon as one is met the others are ignored, in my case time was met so luminance was ignored. By using the And function both conditions had to be met. I found this to be true for other automations as well so it was a lesson worth learning. My automations were pretty old, some over 2 years, and I had many of them to do various things. With the new functionality that has been available and finally having time I am rewriting almost all reducing the number by having one automation cover multiple scenario’s. For example I have a single automation for my HVAC that once was four because it was easier for me to write that way. Maybe someone else could have done it in one but my knowledge is limited so the new tools are making it easier as I learn them.
Didn’t know there wasn’t multiple instances running, good info, but none the less the warnings are gone and I can see where max_exceeded may have a place, again good information, but with my cleaner scripts I don’t need it now.
Your efforts to consolidate/streamline your automations are laudable but secondary to the root cause of the original problem which was when you mistakenly changed the mode in attempt to silence the warning messages.
There was nothing inherently wrong with the original automation; you simply wanted a means of silencing the warning messages and max_exceeded: silent is designed for that purpose.
Put yourself in the shoes of others faced with the same need to silence the warnings and being told to “Change from single to restart mode then re-design your automation/script”. That’s more work than just adding max_exceeded: silent to an existing, functional script.
I never said re-writing automations was for everyone and clearly more than once said I can see where max_exceeded has a place and for others, I’m sure it’s useful, maybe even for me in the future so again “really good to know”. Since I was consolidating automation scripts anyway I found that “I” don’t need it by writing the script “what I consider correctly” because it generates no warnings. What came from this conversation is knowledge sharing that I hope others can use who may be experiencing the same issue.