I’m not looking to have someone find out why one of my automations aren’t firing - I want to learn it myself.
I have an automation that was working just fine in /config/automations/packages/backyard_syncd_lights.yaml that mf_social Marc helped me out with. It’s been working great and I didn’t change it.
The automations are showing up in the automations section just fine. I even disabled them, rebooted, reenabled them, renamed them in the backyard_syncd_lights.yaml file, rebooted. Nothing is working and it’s still not triggering. I made sure that the entity names have not changed at all as well.
What else can I do to track this down? Are there some logs or something I can look at?
You said the automation used to trigger but not anymore.
What changed between when it worked and now? For example, did you upgrade Home Assistant? The most recent version employs native types in templates so that might affect your automation’s trigger.
Is there any message in Configuration > Logs that is associated with the moment the automation was supposed to trigger?
Homeassistant seems daunting at the start but it works in a surprisingly simple way, so basically all the files that you include (be it with !includes or packages or whatever) all get merged into one big configuration.yaml when you boot it up. Therefore formatting has to be dead right wherever the code is, and also depending on how it’s included.
So a ‘block’ of automations that is directly in homeassistant will start with the keyword ‘automation:’ - same in a package, but in a normal !include it wouldn’t because the ‘automation:’ key is already in the configuration.yaml before the merge.
So, all of that to say:
It’s more likely that somewhere between it being in the file where it was working, to ending up in the file where it’s not that it’s a formatting issue, which may be basic indentation, or may be based on the process of merging on boot.
If it can be manually triggered, then the formatting problem is in the trigger or the condition. If it cannot, then it’s the whole merge that’s not having it.
Good luck working it out. If you can’t, then we’ll need to see your packages and includes
This is driving me insane for as simple as it is. I think that comes from not understanding enough on how things work - which bothers the hell out of me. I wish I understood more on how to troubleshoot this myself. I’ve been playing with it for hours now and aren’t getting anywhere so here is all the data. (commented out everything else to minimize troubleshooting efforts)
I have two files… configuration.yaml and automations/packages/backyard_syncd_lights.yaml
You’re so frustrated that you overlooked to answer the basic questions I posted regarding any changes and upgrades you may have made since the time the automation worked and what, if anything, is in Configuration > Logs (which answers your question ‘Are there some logs or something I can look at?’).
You also haven’t mentioned if you can manually trigger it?
Also, what is the current state of input_boolean.loop_prevention? If it’s on then the automation won’t trigger, and presuming that the only way it will go off is if that automation completes, it could be stuck.
I apologize. I overlooked your pointing to the logs and looked in the wrong place but didn’t see anything. I did not look at the Configuration->Logs, I looked at the logs from the top menu.
There are errors in this Configuration->Logs.
Here is what I have in that log:
Logger: homeassistant.components.automation.back_yard_lights_sync
Source: helpers/service.py:128
Integration: Automation (documentation, issues)
First occurred: 12:49:25 PM (2 occurrences)
Last logged: 12:49:25 PM
Back Yard Lights Sync: Error executing script. Unexpected error for call_service at pos 3: Error rendering service name template: UndefinedError: 'trigger' is undefined
While executing automation automation.back_yard_lights_sync
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/template.py", line 353, in async_render
render_result = compiled.render(kwargs)
File "/usr/local/lib/python3.8/site-packages/jinja2/environment.py", line 1090, in render
self.environment.handle_exception()
File "/usr/local/lib/python3.8/site-packages/jinja2/environment.py", line 832, in handle_exception
reraise(*rewrite_traceback_stack(source=source))
File "/usr/local/lib/python3.8/site-packages/jinja2/_compat.py", line 28, in reraise
raise value.with_traceback(tb)
File "<template>", line 1, in top-level template code
File "/usr/local/lib/python3.8/site-packages/jinja2/sandbox.py", line 407, in getattr
value = getattr(obj, attribute)
jinja2.exceptions.UndefinedError: 'trigger' is undefined
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 125, in async_prepare_call_from_config
domain_service = domain_service.async_render(variables)
File "/usr/src/homeassistant/homeassistant/helpers/template.py", line 355, in async_render
raise TemplateError(err) from err
homeassistant.exceptions.TemplateError: UndefinedError: 'trigger' is undefined
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 253, in _async_step
await getattr(
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 432, in _async_call_service_step
domain, service, service_data = async_prepare_call_from_config(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 128, in async_prepare_call_from_config
raise HomeAssistantError(
homeassistant.exceptions.HomeAssistantError: Error rendering service name template: UndefinedError: 'trigger' is undefined
Home Assistant has started!
I did not update HA… I added some things to HA but I’ve excluded all of those in the config by putting # in front of it. I also cannot manually run it. Nothing happens.
I think that error may be due to when you complied with mf_social’s request to manually trigger the automation. When you do that, the Trigger State Object doesn’t exist so where your automation’s template refers to trigger.to_state.state it will be undefined. (and that’s what the log reports).
In other words, it’s probably a red herring and unrelated to what’s ailing your automation.
You have all those other automations included with !include_dir_list automations
Therefore your ‘package’ is in a directory that is included both in the packages directory and the automation include. This is a merge conflict.
So that needs sorting out.
Then, because the automation in question has been started but not completed, the input boolean has been turned on, but not turned off. So now when you have a state change that would otherwise trigger it, the condition prevents it.
TLDR - sort out the merge conflict, turn off the input_boolean.
Turned out it was the loop prevention flag. Somehow it got turned on and not off again. I tore all sorts of stuff apart on the machine trying to figure it out. The lucky part is that I had an image of the VM and reverted to a previous snapshot. Hard lesson learned about the flags getting flipped like that. :-/
I do want to take a moment to thank each of your that took the time to reply and help me out. Greatly appreciated - thank you!
I think that your original intent was forgotten in the effort to help you with this single automation…
I’ll try to answer that.
There are a few things to remember when troubleshooting automations.
always run a config check. If that doesn’t show any errors then the automation code syntax is (pretty much) going to be fine. There are very rare occasions that I’ve seen the config checker say everything is valid but then when you restart/reload you will get a notifications that the automations can’t be loaded.
Once you reload the automations or restart HA and the automation actually shows up in your states page or automations list then you know that the yaml is valid so you can move on past that concern.
Always do a dummy check to make sure that the automation is actually turned on. Look in the states page and the automation should have a state of ‘on’. if it doesn’t then turn it on. If it’s off then the automation is disabled and will be prevented from running.
At that point there can be only three things preventing the automation from carrying out the actions: there is a problem with the logic of the trigger, the condition, or the action (or something in multiple areas but we will assume for simplicity sake that there is only one logic error).
The next thing to remember is that the config checker only checks the validity of the yaml syntax. It doesn’t (and can’t) check the logical structure of any included templates (aside from the basic structure of the required jinja2 template formatting - if/elif/else/endif, quotation marks, etc - those will also be checked by the config checker). But any errors inside your templates won’t show up anywhere until those templates are evaluated either after the trigger occurs in the case of a template in the conditions or after the conditions are satisfied in the case of the templates in the actions.
For example, if you are trying to add a string and an integer in a template the error won’t show up until that template is evaluated. then the error will be posted to the home-assistant.log file. (as a side note you should always default to looking at the home-assistant.log file and not look at the UI logs. They are getting better I guess but the home-assistant.log file will always be complete and correct). so…
always check the home-assistant.log file. If there is nothing there then you can be sure it’s going to be a problem with the top level sections: trigger, conditions or actions. At that point there are a few techniques you can use to narrow things down a bit more.
To test if it’s a problem in the actions section then you can manually execute the automation by opening it’s pop up box and hitting the execute button. If the actions run as expected then you know the problem is in the trigger or conditions. But as noted above there could be an error in any templates in the actions (like the fact that if the automation was triggered manually the “trigger” object doesn’t exist so that will cause errors and stop the actions from running). If the actions don’t run the check the logs. If there are no errors there then check the logic of the actions. There may be an improper service call being made or some other logical issue.
if the actions run fine then the next thing to check is the conditions. The best way to do that (aside from the obvious putting your eyes on them for any obvious mistakes ) is to trigger the automation from the services page in dev tools using the automation.trigger service. Then in the data section put in the entity id of the automation (entity_id: automation.whatever) and then add the option to not skip the conditions (skip_condition: false). That will check that the conditions are actually valid and will run (or not) the actions based on the evaluated status of the conditions. If the actions still run as expected then you know the conditions are fine. If not then you need to check those conditions (realizing they also suffer the same limitations if they contain trigger objects in any templates).
If all of that works as expected then the only thing left is to check that the triggers are being satisfied.
To validate any templates and ensure that they are actually returning the expected values you should get used to using the template editor in the dev tools.
You may already know some of this so apologies if so. But I figured I’d just be thorough.
I probably ought to save this post to prevent having to type all of that out again the next time somebody else asks the same question, too.
Thanks for all that. It was painful today and I wasted a lot of time on it. But, in the end, I learned a hard lesson on things to check so it wasn’t all for nothing. …and I got to exercise a snapshot on my VM since I tore everything up trying to figure it out. One click and I was back to where I started from. Such an amazing thing. Thanks again for all the info - really appreciated. This community is pretty awesome and I’m looking forward to contributing to it the more I learn.
To help prevent this from happening again, I made an automation that watches this input_boolean and it will turn it off if it has been on for 15 seconds. Since it should only be on for a few seconds, this will catch any abnormal happenings and fix it. I should add a notification to tell me if it fixed anything so I can fix the real problem and not just silently correct it.
appreciate this is an old post but wanted to reply to this post as I thought this was the most helpful in learning how to troubleshoot this item
I have also have a problem with automations not firing:
My automations switches on an aircon when the temperature exceeds an input_number figure, and switches off when the temperature is below an input_number figure
I have duplicated the same automation to apply to 2 different rooms (and changed names for appropriate sensors)
Both automations work fine but the automation for one of the rooms triggers very inconsistently (sometimes it triggers, sometimes it doesn’t). The other room automation doesn’t have this problem
I can trigger the automation for the problematic automation manually. I have checked the states of the entities and they are all clear.
Where else can I look? Please let me know what code, log, etc I should post to help diagnose
How do I use Traces to troubleshoot? There’s no indication of the automation running or errors so not sure where to beging.
The Trigger entities are indeed changing states. The funny thing is that the automation will trigger but just not consistently.
What / where are typos that I’d be looking for? As above, the automation would trigger but not consistently, and can be triggered manually - so that shows there aren’t any typos?
Also I noticed if I recreate the automation, it’d trigger but after the aircon is switched off by another automation, it doesn’t seem to trigger again. How might this be helpful in troubleshooting?
