Wow, that’s pretty good… I should use templates more often.
I’ll replace it with that and see how it goes. Thanks heaps.
If it works (and you find out the automation wasn’t actually unreliable, it just did what you asked, but you asked for the wrong thing – computers are funny that way), then change the topic title. 
You can check an actual trigger by manually changing the state. In the developer tools go to the states tab and select the entity you want to test. The current state will be shown, you can manually type in another value and hit enter to test an automation.
1 Like
After a good run with the entire automation moved in to the one big template trigger, I started moving the things back out in to conditions (as I didn’t actually want to cause a trigger on most of them).
Unfortunately since doing that I’m running in to the issue of automations not triggering when I expect them to.
Since then I’ve tested:
- Confirming that all conditions are met
- Clicking the ‘trigger’ button in the web ui - this works
- Manually setting the state of the sensor monitored by the trigger - this doesn’t work
- Disabling and reenabling the automation in the web ui - this works the next time the sensor changes
- Restarting home assistant - this works the next time the temperature changes
I do have debug logging enabled now, and in home-assistant.log I see the sensor change but that’s it. There’s no log for the automation being triggered or anything else related.
I am back to having conditions based on numeric_state, but only conditions, the trigger is still a template.
Any ideas?
- id: '100020'
alias: Bedroom AC - Room too hot
trigger:
- platform: template
value_template: '{{ states(''sensor.inside_temperature_bed_room_inside_temperature'')|float
> 23 }}'
condition:
- condition: state
entity_id: climate.bed_room
state: 'off'
- condition: or
conditions:
- condition: state
entity_id: device_tracker.f4f524db85c5
state: home
- condition: state
entity_id: device_tracker.a028eda246f6
state: home
- condition: or
conditions:
- above: '20'
condition: numeric_state
entity_id: sensor.outside_temperature_bed_room_outside_temperature
- above: '70'
condition: numeric_state
entity_id: sensor.bom_brisbane_relative_humidity
A template trigger will fire the fist time the template evaluates to true. (And, remember, the template is only evaluated when one of the referenced entities changes.) After that it must evaluate to false, and then back to true for it to trigger again. If you’re expecting it to trigger every time sensor.inside_temperature_bed_room_inside_temperature changes and its value is above 23, then your expectation is wrong. The way you have the trigger written it is effectively the same as a numeric_state trigger.
Thanks Phil,
Unfortunately that was what I was expecting… I’ll have a think about how I can restructure the automation to work around that.
Maybe you should explain what you are expecting. And what behaviour it is that is unexpected. I read the whole thread but I can’t figure it out?
I guess I could just trigger every minute and put all the numeric_states in conditions?
Can I ask why this technique is cringy? I do something similar in a couple of places and it seems to work well enough? In the Template Sensor docs it recommends doing something similar to update the sensor on a regular basis. Wouldn’t creating a trigger like this essentially the same thing? What would an alternative technique be?
Here’s one example from my configuration. It sends out a push notification every 15 minutes until the buster_medication_active boolean gets turned off. Is there a better way to do this?
trigger:
# run every 15 minutes
- platform: time_pattern
minutes: '/15'
condition:
- condition: and
conditions:
# only run when silent mode is off
- condition: state
entity_id: input_boolean.silent_mode
state: 'off'
# only run if schedule automation is enabled
- condition: state
entity_id: input_boolean.schedule_automation
state: 'on'
# only run if buster medication is enabled
- condition: state
entity_id: input_boolean.buster_medication_enabled
state: 'on'
# only run if buster medication is active
- condition: state
entity_id: input_boolean.buster_medication_active
state: 'on'
Pro tip: Sometimes an automation needs more than one trigger.
Think about what you are attempting to automate. What you want to happen is usually easy to figure out. Determining when it’s supposed to happen can be the challenging part. Do I want it to happen when I arrive home or when the temperature exceeds a threshold or either of them? The answer to that question can determine if you place the test in the trigger or in the condition or even in both.
1 Like
Because, more often than not, the real-world task to be automated has identifiable events that can serve as triggers:
- activating a given state
- exceeding a threshold
- reaching a given time
Event-based automations are inherently efficient; they only trigger when the desired events occur.
Polling-based automations are less efficient because they trigger even when the desired events are not occurring.
The usual rebuttal is that the host machine is more than capable of polling frequently. Sure, but that implies the universal solution for an inefficient design pattern is more CPU horsepower … which is, to put it diplomatically, a bad practice (‘my code is not bloated, your hardware is too slow’).
2 Likes
conditions: - above: '20' condition: numeric_state entity_id: sensor.outside_temperature_bed_room_outside_temperature - above: '70' condition: numeric_state entity_id: sensor.bom_brisbane_relative_humidity
Why are you checking the numeric values against strings? (e.g., in the above: and below entries? I think you should be checking against integer values 20 and 70. This looks suspicious; maybe the condition tries to convert those bits of data to integers to do the comparison, but I’ve never tried to use strings myself…
That’s a bad example. It’s time based because the point is to send periodic reminders. Also the last example for the template sensor is a bad example, too, because it’s for a template that is supposed to be changing based on time advancing.
As @123 just said, most automations are meant to have something happen when something else happens. E.g., turn on a light when a door opens; turn on the heat when someone gets home; dim the lights at 10:00 PM. All of those are events and they should be used for the trigger. Not a time period trigger that then requires a condition or conditions to see if the actions should be run. Not only is that less efficient, it can cause unneeded delay in running the actions.
So, again, in general, if you find yourself writing an automation that uses a time pattern trigger and a bunch of conditions, ask yourself, is that really how I should be deciding when to run the actions? Or should I be using trigger(s) that monitor for certain events?
This is perfectly fine. The strings will be converted to numbers before the comparison is made (just like the state of the entity, which is also always a string.) It’s certainly clearer to use numbers instead of string representations of numbers, but it doesn’t matter.
You may wish to consider using the Alert integration.
- Create a Template Binary Sensor that reports
'on'only when all four of those input_booleans are'on'. - Create an Alert that monitors the state of that Template Binary Sensor. Set the Alert’s
repeatto15and it will notify you every fifteen minutes.
The Alert can be configured to allow for custom repeat patterns (like at 5 minutes, then at 15 minutes, then at 45 minutes) and the ability to acknowledge and dismiss the Alert’s notification.
Alert is quite flexible except for the fact it does not support templating so that’s why I suggested you create the Template Binary Sensor for your input_booleans. Just a thought, it might also work for a group of input_booleans.
I was using alerts for some system monitoring things a while back and ended up getting rid of them and making my own automations. It was so long ago I can’t remember exactly what it was that made me change them but I think I just found my automations more flexible or something like that.
At the end of the day in terms of system resources used isn’t an alert doing the same thing.]? Running on a time based interval based on conditions? Is there something about alerts that makes them inherently more efficient than custom automations that do the same thing? Other than the dynamic notification times if you need them on the surface I don’t see any advantages or anything an alert does that I can’t do in my own automation. Am I missing something?
In my example, that’s how you do it then? So basically if there is another more logical way to trigger an automation besides a time based trigger, use it. That is more or less how I’ve approached all my automations, so I only use time pattern trigger in a couple of places all very similar to my posted example.
I do have a template sensor I created that I update using the time sensor that reports any sensors that have a state of unavailable. I’ve put some thought into this now and can’t really think of a better way to do it. How resource intensive is updating a sensor like this? Is this poor practice?
No. The Alert is monitoring an entity’s state-changes. This is not polling (i.e. “running on a time-based interval”) but event-based (where the event is a change in the entity’s state).