Thanks Nick.
Yes, that is a fairly recent and huge user-unfriendly regression in the way the syntax checker works.
the older behavior was that it would give you a notification in the sidebar that there was a problem and that you needed to check the logs for the error.
now it just silently fails and disables the automation without telling you unless you happen to notice the automation not triggering and happen to see the logbook entry.
it’s unfortunate that the devs have decided that this is the desired behavior for something as important for a home automation system as automations and claiming to be user friendly that new users need know to open the logbook to even know there is an issue that needs addressed.
I really don’t get it.
1 Like
The automation editor does not let you save with those types of mistakes. And there still are errors in the logs related to these as long as you don’t restart. As soon as you restart, your previous logs are lost (Unless you look at the log history in your config folder) and the automation is already disabled (so it won’t generate the error again). The only change was the notification on the sidebar. That only affects YAML automation users who do not use the UI.
TLDR: You’ll see these errors if you use Yaml only automations in the UI, or you use the GUI UI. The errors are still in the logs but they wont be after it’s disabled and you restart.
1 Like
I was not aware of any of that, thanks @finity @petro
I rarely use the GUI to create any automations or scripts etc but I’ll keep an eye out for this in future.
The only thing I ever do after creating/editing an automation is to do a config check and if it says it’s valid then I just reload automations. I don’t restart.
the config check doesn’t give a warning/notification that there is a problem with the automation. the system just disables the automation and puts an entry in the homeassistant.log with no other indication at all that there is a problem with the automation.
I’ve had this happen multiple times in the last few months with just a simple config error.
I guess I don’t see the purpose of removing the sidebar notification.
1 Like
Same here. 100% yaml. If you test your automation with logs open, you’ll catch these errors immediately. The only reason it disables is because it was a service call error. If you mess up on an entity_id or service call data, it’ll just log the error in the logs without disabling the automation. That behavior hasn’t changed.
1 Like
The whole system was reworked, it wasn’t a “Hey lets hurt the user by not having this notification”. Contrary to your belief, many of these changes are just overlooked accidentally.
Here is an issue that I submitted 3 weeks ago for it if anyone is interested:
It’s a bit crazy that something so integral to your smart home running efficiently does not have an ‘in your face’ warning that it’s not working (disabled).
Is there a way of creating a template to list all automations/scripts that are disabled? I have one each for devices and entities in a lovelace card but I wouldn’t know how to reference all automations/scripts. It’s not as if they are a device_class or anything.
I would prefer a warning at config check as well though.
2 Likes
Ah, just found one but not yet tested it.
{{ states.automation | selectattr('state', 'eq', 'off')
| map(attribute='name') | list | join ('\n') }}
Much prefer a warning!
EDIT: Yes, it works. Better than nothing at this point. (credit for the automation here)
That’s not possible. At best the service slug can be validated, but it’s existence or not can’t be checked without the system running. This has always been a limitation of the config check. It only validates the yaml, it does not validate anything “deeper”. For that, you have to use the SSH config validation option or run the automation after reloading.
1 Like
That’s a bit off topic though, that just seems like a bug with repeat. I looked at the code, it should be failing config check for that. I only looked at the surface though. There’s a function in there that might cause oddities.
I don’t think that will catch the issue with disabled automations that we are seeing.
as far as I’ve seen the disabled automation isn’t off - it’s not even included as an automation entity at all in the states list. If you look for that automation it doesn’t even exist as far the system is concerned.
That’s how I was able to know to look in the logs in the first place because the automation didn’t trigger and when I went looking for the trace the automation didn’t show up anywhere in the system. So I just looked to see if there was anything in the log and there it was.
I’m really sorry to have to keep adding to this thread and not addressing my points to anyone in particular…
the bug report was just an example of the failure that I was seeing. it wasn’t specifically about the repeat. it was about the error in the repeat not providing an invalid config check.
there have been many examples of this not only with the repeat. And not only from me. this thread is another example of that.
you would think that it should have given an invalid config check but it didn’t. it just failed silently with only an entry in the log and disabled the automation.
that is exactly the problem.
Yes, but what you aren’t understanding is that the type of check that you want to run cannot be ran in the running home assistant. So all that config check can do is validate the yaml. It’s literally impossible for config check to find that issue. That’s why the SSH config check exists so that it can spool up a running home assistant process to do a full validation. I’m 99% sure this has been explained to you multiple times.
As it is right now currently in the system, HA knows:
- that there is a problem with an automation and that the automation needs to be disabled. it even knows which automation it is.
- it prints a notification in the homeassistant.log file of that action of disabling of the erroneous automation. and it reports which automation it is by name in the log as well.
both of those things happen with just a reloading of automations and doesn’t require a restart to find the problem and report it in the log.
based on those two things it shouldn’t be too technically challenging to also just put a persistent notification telling the user that there is an issue.
prior to the rework it would just disable all automations instead of just the problematic one so that part is better in that it only disables the offending automation.
but also before it would tell the user that all automations were disabled and direct them to the log to see what the issue was. The way it is now is a step back in user friendliness and functionality.
1 Like
Yes, you’re right, it requires a reload, which check config does not do. Hope you understand now. It’s impossible to catch what reload does with check config without reloading. Hence why the SSH check config spools up a new instance of HA to generate the errors that reloading produces without impacting the currently running system.
And that has nothing to do with what I was explaining, at all. I was explaining because you said these comments about check config.
So to recap: The check config button cannot do what you want. It is a technical limitation. That’s it. Reloading can. Yes a message would be nice. I’m fairly sure it was just forgotten. But by all means, continue to think it was done maliciously, I don’t expect any less from you.
@c0ntax: since the problem you had is solved, please take the time to mark the answer as solution, you do that by selecting the three dots under the post:
Then select the check box:
Don’t forget too while you’re down there to click the heart to like the post, as a way of saying thank you.
1 Like
No problem @Nick4 I was going to do that, I was just watching the other part of the thread unfold 
1 Like