trying to modify an automation… basic ‘turn light on at 4:40am’ works fine but when I try to make it dependent on the state of the binary workday sensor it breaks.
Some relevant screensnips…
Automation before the WorkdaySensor Conditional works fine… as you can see… only entity_id data is the declaration for the switch that I’m trying to trigger.
You see that entity_id: [] on a line all by itself that is commented out? That’s what’s breaking it. And the condition line above it needs more to go with it to do anything. If you didn’t edit this manually then the automation editor must have made a mistake.
The part that’s commented out is the old, basic on@X, off@Y’ automation that was built a few weeks ago and has been working as it should since. It was built through the automation editor and aside from commenting that block out no other manual edits have been made.
(That said- if I uncomment the block and comment out the newer Test block instead HA will go back to loading both old automations without erroring… I just find it odd that, for whatever reason, the old and new conflict for some reason…)
As far as the undeclared condition in the ‘Goodnight Light’ automation… this was also built via the automation editor and has been working flawlessly as well… it doesn’t need a conditional as I want it to be turned off at the same time every night after being triggered manually… I guess I could add a conditional to it to keep it from firing if I happen to turn it off early some random evening,
An automation’s condition is optional. Representing it as an empty list effectively means “there’s no condition”.
In contrast, condition: state requires an entity_id. So the statement entity_id: [] means you’re not supplying it with any entity_ids (which results in an error message).
you need to start getting in the habit of posting code snippets instead of screen shots of code snippets.
Most people that would like to help you don’t want to have to take the time and effort of completely typing out the code by hand themselves when it would be easier to just copy/paste/alter your code.
next, that automation that you commented out is badly formatted. If the automation editor did that then that is justification for not using it. But I kind of doubt it created that code without some kind of editing.
you’ll get an error because the condition isn’t even close to being right. it’s incomplete. and the “entity_id” line after the incomplete condition statement doesn’t belong there where it is.
…with the move to a more UI-configured environment, that approach doesn’t work quite as well. The followup screenshot was more as a visual reference to supplement and show the text version of what the UI had constructed.
Then the correct thing to do is to go to the raw lovelace config editor the automations.yaml and copy/paste from there.
The empty condition in the last automation is fine. It’s superfluous but it’s fine being there. It’s the other stuff I noted above in the commented automation that was screwed up.
EDIT: removed the silly reference to lovelace since we aren’t talking about lovelace but instead the automation editor. DOH!
The problem is that currently the GUI editor doesn’t support a bunch of valid stuff… like OR conditions for instance… so you have to use the yaml for a lot of tasks. The UI editor mangles yaml as well.
I do use the UI editor on occasion for a simple new automation but for anything else yaml.
I understand all that, but if you consider the flow of… issue discovery… it was through the UI that the ‘issue’ evidenced itself? The problem wasn’t with the actual contents of the yaml, the problem arose when attempting to edit a previously constructed automation.
The way I ask for help is to report what I see. At the time, given what I was being shown… it said “entity_id” and the only place I was shown 'entity_id" on that page was the exact same syntax and device as the working version… it wasn’t until after my OP that I pushed further on and discovered… or it occurred to me, rather, to check the yaml…
again… I’m new to HASS and I’m still learning the workings and understanding where to look for the config counterparts of sections that are becoming increasingly UI-managed. …here recently it feels like it’s been a moving target. In fog.