I’m trying to move a bunch of automations from Node Red to native.
Recent changes in automations (and in particular some terrific improvements in the documentation, thank you!) led me to tackle this in an experimental mode.
One aspect is making me a bit nuts and wondering if I am missing something. I want (as I can by checking a box in Node Red) evaluate the trigger condition on restart so long running automations will restart also if the state condition remains true. Optionally.
This appears really awkward and duplicative. Something like this (haven’t run this code, just think it’s close):
trigger:
- platform: state
entity_id: binary_sensor.front_door
to: "on"
- platform: homeassistant
event: start
condition:
- condition: or
conditions:
- condition: template
value_template: "{{ trigger.platform == 'homeassistant' and is_state('binary_sensor.front_door', 'on') }}"
- condition: template
value_template: "{{ trigger.platform == 'state' }}"
What’s troubling is the duplication will make maintenance difficult and less readable.
Is this really the best approach in HA automations? Nothing declarative, like “recheck state” on the platform-state line?
I guess one answer is “don’t restart HA so often” but adding features, code, configuration changes… there are times when I restart it a lot.
If you want the automation to trigger whenever the binary_sensor’s state changes to on then you need the State Trigger (as shown in your example).
If you also want it to check the binary_sensor’s state on startup, then you need a Homeassistant (Start) Trigger plus a State Condition to confirm the state is on.
triggers:
- trigger: state
entity_id: binary_sensor.front_door
to: "on"
- trigger: homeassistant
event: start
conditions:
- condition: state
entity_id: binary_sensor.front_door
state: "on"
actions:
... etc ...
There’s no equivalent “checkbox” in Home Assistant.
Many of my automations include a Homeassistant Start Trigger to ensure lights and appliances are set to a sane state on startup (after a long power outage or if I am doing something that requires a full restart).
NOTE
If your binary_sensor.front_door changes state from unavailable to on on startup, then your automation doesn’t need the Homeassistant Trigger and State Condition. The State Trigger will detect the state-change from unavailable to on.
An entity’s exact behavior on startup depends on its underlying integration. On startup, some have an initial state of unavailable and others don’t.
Ah, I think you did put something a bit more concise, I don’t need to distinguish startup in the condition, just need to know that the state matches, thank you.
But I Think the bottom line is that what I had was more or less as concise as you get, the desired state condition has to be repeated in the trigger and a condition both. Right?
(Well, excepting the case where an entity might go unavailable at first, but that seems unreliable, an integration may do that now, and in a subsequent release restore the original value or avoid the unavailable state).
Correct, because what you want to do, trigger on startup and check if front door is open, is a two-step process (Homeassistant Start Trigger + State Condition).
I suppose that’s possible so the prudent choice is to, where feasible, precisely define the State Trigger’s state-change. For example, to trigger when a door is opened, I use two options from: 'off' and to: 'on' (not merely to: 'on'). This ensures no undesired triggering should the entity’s state change from unavailable to on.
Thank you for the feedback. I have many blindspots in templating, it appears in this case I may not have all the details, but I was on the right track. Thank you.
Yeah… also check boxes in Node Red, starting to rethink my idea of rehoming a lot of automation to native.