So… I’ve created a very simple automation as you’ll see below. I write my automations via YAML which is never a problem. But for some reason, this single automation never triggers even once.
---
alias: Holiday Shopping Notification
description: >-
Checks daily if I plan to go shopping the next day. It will
send a notification, if there's a holiday on that day so I
can do the shopping before that.
id: 019a67f2-b6fc-7993-971c-90f8d11ae491
mode: single
triggers:
- trigger: time
at: "07:00:00"
conditions:
- condition: template
value_template: |-
{% from "calendar.jinja" import event_is_coming_up %}
{% set calendar_entity = "sensor.calendar_events_tomorrow" %}
{% set events = state_attr(calendar_entity, "data") %}
{# check upcoming event by the name #}
{{ bool(event_is_coming_up(events, "Einkaufen")) }}
- condition: template
value_template: |-
{% from "calendar.jinja" import has_regional_holiday %}
{% set calendar_entity = "sensor.calendar_events_tomorrow" %}
{% set events = state_attr(calendar_entity, "data") %}
{# check upcoming event by the description #}
{{ bool(has_regional_holiday(events)) }}
actions:
- action: script.send_notification
data:
platform: [pc, smartphone]
message: >-
Be aware that there's a holiday tomorrow when you want
to go shopping. You might want to go today instead :)
In the UI it shows “disabled” when I click on the trigger which might be a visual bug but still suspicious:
I’ve tried various things like different triggers or stripping the automation down but nothing worked so far. No logs are written for this. Copying the automation into the UI, the trigger is not marked disabled but I haven’t tested if it triggers that way.
Click on the disabled trigger then in the edit window hit the three dot drop down and re-enable it. In my case it says disable because the trigger is enabled.
Unfortunately, I can’t do that as I’ve created the automation via YAML and not the UI. That’s why it’s so weird. I didn’t disable the trigger in my YAML…
Creating automations entirely without UI will not let you edit them, that has always been the case afaik. I just create them locally and push them onto my HA when I’m done. They are loaded via the configuration.yaml
They are not though. I don’t want them migrated to the UI, that’s not the problem. I’ve always created them this way and it has always worked expect this one new automation doesn’t trigger for some reason.
Alot of that automation looks like crap but it’s possible it all exists, do you actually have calendar.jinja? do you actually have a script that excepts platform as a list of strings? Sorry for being so abrupt, but it looks like AI generated junk and it’s hard to tell otherwise.
Also, how are you including that automation via yaml? Can you share your include in configuration.yaml.
What @andarotajo is saying is true. You cannot edit yaml included automations in the UI. You’re confusing using yaml through the UI with true Yaml outside the UI. @andarotajo is referring to yaml outside the UI which cannot be edited if it’s not included through automations.yaml file. This is how I manage my automations. Yaml through the UI still resides in automations.yaml and can be edited both inside and outside HA.
i.e.
#Can be edited in the UI and outside the UI. But HA ultimately
# controls the order and comments (by removing them).
automation: !include automations.yaml
# Cannot be edited at all in the UI. Untouched by HA, just read.
automation extra: !include_dir_merge_list automation
# or
automation <any key you want>: !include_dir_merge_list <any folder>
Not sure why it’s “crap” but all the references exist. I have a custom template named calendar.jinja and my notification script accepts a list of targets. This automation is managed no different than any of the other 50 or so automations I have which work:
configuration.yaml
homeassistant:
# load all packages
packages: !include_dir_named "integrations"
And the automation is in a subfolder inside the automations folder. The automation loads fine and all, I can test the conditions and haven’t gotten any repairs or other errors for this.
I called it crap cause it looked AI generated. Again, its hard to tell these days what AI hallucinates. The automation looks advanced, and usually AI comes up with that stuff.
You have an id with it, is the whole automation disabled via the UI? I.e. is it turned off? You’ll have to back out to the main automation page to see that.
The automation or rather entity of it is enabled. What I find weird with the disabled trigger is that it only shows disabled when I click on the trigger to open the new side view.
I think usually disabling a trigger etc. shows it directly over the trigger no?
If you include an automation via True yaml only, then all triggers show disabled. I confirmed this by just going through all my automations, they all show every trigger as disabled.
It will definitely trigger, the UI just says it’s disabled. To see if it triggers, you’ll need to set the time to a minute from now (reload automations) and just wait.
Yeah the test is not for the visual bug but the automation itself. We now know it’s a UI bug so I don’t see any reason for the automation not to trigger.
I just confirmed that the via UI duplicated automation did trigger. I’ll try changing the time on my original automation next to something in the next minutes.
