You can do that.
Use an automation to monitor your system log for errors and send a notification if one occurs.
Hmm good idea, right now I have watchdogs that check if a boolean gets successfully set. Iād still like a way to set continue on error on as the default for a certain automation or integration.
Hi Tom, thatās true for sure. But, what I can echo from my own recent experience is itād be super helpful to have a way to log and notify on āmore trivialā errors instead of stopping the script entirely.
Similar to PHP, for example: The difference between āwarningsā and āfatal errorsā. One tells you somethingās not right and you should look at it while the other stops the script from continuing to execute. You can specify the default behavior for warnings to ālog and continueā instead of hard-fail.
Having a way to do that either globally or on the āwhole scriptā level would be nice.
Iāve never experienced this issue until last night. Went downstairs and everything was dark when it should not have been. Checked the logs and my light schedule had stopped because an unreliable Sengled bulb had dropped off the network. Thereās 20 other lights in the script; it would have been better to have those others go ahead and turn on as expected. Assume itās going to continue to do this until I find, order and replace those flaky bulbs. (Aside: if anyone has a suggestion for a non-proprietary-hub zigbee bulb, Iād appreciate it)
Strange thing is: Those Sengled bulbs drop off all the time; and the scripts never stopped before - odd that it decided to do it for the first time last night; havenāt updated HA or any integrations.
Just my two-cents on the issue; Iāll add the continue on error for those bulbs on the scripts that run daily until I can get the replaced.
2 Likes
Iāve been pondering this, and what Iād really love is to be able to add some error handling within an automation itself.
Be able to have a try catch block, specify if a step takes too long or doesnāt return successfully then run an alternate code path.
The only way I seem to successfully get automations to always complete is to wrap them in a parallel block and add continue_on_error everywhere.
I dont think anyone is asking to hide the problem. I have hundreds of devices utilizing multiple protocols from cloud, zwave, zigbee, Bluetooth, etc and its a pain to make sure EVERYTHING is working for automations to execute fully.
If the HA team wants HA to become more mainstream, things like this need options and proper alerts so people can know what to do and not kill the automation dead in its tracks because of one cloud device that stopped responding or timed out.
1 Like
I would suggest something like putting any automation that fails with an exception goes into the āRepairā section as an āeasyā next step? My script is brokenā¦
I sometimes notice something didnāt happen, dig into Traces, only to find something has stopped working for the last few days. Generally something going offline.
I understand Iām responsible for better exception handling in my scripts, but it would help if the automations supported some standard mechanisms for exception handling (try-catch?).
2 Likes
+1 to this, this setting should be available in the UI and there should be an automation wide on/off default setting from UI and yaml.
3 Likes
Since updating to 2024.7, continue on error seems to be ignored
One of my locks sporadically works (thanks zwave 700 issues) and as you see in this trace screenshot, it completely stopped at that point
Throwing my 2 cents in on this. This feature is absolutely necessary and the best thing to do in my opinion. Especially if you donāt actually want to spend your entire life obsessing over which device is causing loads of things not to work.
It would not hide the problem when something doesnāt work, it would actually make it much clearer! The thing I hate about the current behaviour is that when 1 thing breaks, itās not obvious which thing broke my script/automation, because maybe 5 things didnāt happen.
If I triggered a script and everything worked perfectly every time except 1 light or plug, itād be DAMN obvious which device was at fault! And I could choose to leave that device working as well as it does, or eventually fix/replace it.
But now Iām basically held hostage to spend time/money on fixing an issue or at least unnecessary effort restructuring a script to work around one device that sometimes doesnāt work right for seemingly no good reason. And in my experience, the moment I do that, something else chooses to go on strike, and itās a never ending merry go round of moving things around when in reality I couldnāt care if one thing occasionally failedā¦
1 Like
+1, out of my roughly 100 automations I would really only want 1 or 2 to stop running if it encounters an error, continue_on_error should absolutely be the default behavior, with a stop_on_error option instead.
1 Like