My last rendition of my Home Assistant Configuration (which you can read about here) was left in a rather obnoxious state. My wife isn’t particularly good about checking her notifications regularly, so while I was at work, I would get a notification every 10 minutes for a while, until my wife finally realized she should open or close the windows. Additionally, I had effectively made the buttons on the thermostat useless, since Home Assistant would reset it every 10 minutes. I needed a better way.
My first attempt at this was to try and make use of the built-in triggers and conditions as much as possible. I’m now convinced that best practice is to make use of templates as much as possible for anything even remotely complicated. This left me with much more flexibility.
First, I converted all the times and temperatures I had hard coded into the configuration into input values that could be set from the user interface. This meant I would have to change all of my automations to use templates, but that meant I could now make adjustments to my schedule or thermostat without having to change my configuration files.
Next, I converted all of the time based triggers into template triggers. One thing I think I hadn’t quite realized was that these only trigger the actions when they become true, not continuously while they are true. Exactly what I needed to stop getting notifications constantly. Additionally, while there is a bit less built in functionality from the templates, you have the full capabilities of a programming language available. This meant I could use some better programming practices, like named intermediate variables, to make things look very similar to the state table I had come up with.
The hardest part to figure out was doing time comparisons. About the only way I could figure out how to get a time value was as a string. Luckily, they end up formatted as 24 hour time with leading zeros, so comparing them lexicographicaly works exactly as you want.
Finally, since the outside temperature sensor doesn’t have a steady up or down trend, it was possible for my condition to go from true to false to true again in a matter of minutes. Meaning, I could still get several notifications in rapid succession. However, the state trigger has a handy little
for attribute available to ensure that a sensor is a given state for a certain period of time before the action actually triggers. In order to make use of this, I moved the conditions for my notification automations into template sensors, which could then be used in the state triggers.
I still miss the type safety available in many programming languages, and the amount of testing I can do on these configuration files is effectively zero. The only real guarantee I can make is that they are valid yaml. But I think I’m getting the hang of how to really make use of this stuff. Additionally, now that the actions are only triggered for real state changes, the buttons on my thermostat are of some use again.
If you’re curious you can always check out my configuration files here.