Using “Helpers” to improve automation logic

Configuration
1

This post is about a technique for organizing automations I’ve developed over the years, first with other systems and now with Home Assistant.

I’m not claiming originality here: I’m sure many of you already use this or a similar pattern. And I’m definitely not calling this a “best practice”, but rather a logical way of thinking about and organizing automations that works for me. Different people think about this type of thing in different ways - and that’s fine! But for folk who’s brains work similar to mine, at least in this context, perhaps this technique will be helpful to you.

The whole deal in a nutshell is to logically separate the Activation of an event from the Work taken due to the event. You do this by creating “Helper” (Configuration → Automations & Scenes → Helpers) toggle or button entities for certain key events or conditions, and then using those entities elsewhere in your automations.

Here’s an example. Let’s say you want a set of things to happen when it gets dark. So you write automations (or use Node Red like I do) so that when the sun sets a bunch of lights turn on.

This works great, until you want to be able to have your “dark” automations happen based on a new sensor that reports luminance instead of only at the time of sunset. Now you need to edit all the automations to handle this different input. If you’re not careful, it can get complex really fast.

My approach simplifies this by doing the following.

  1. Create a Helper of type Toggle (Input Boolean), called “Its Dark Outside”.
  2. Have one section of your automation (or Node Red flow) devoted to the Activation: the situations that would cause this virtual condition to become true and false. For example, True at sunset, False at sunrise. And/or True when your luminance sensor is < 2, False when >= 2, etc. Have this automation end with setting the “Its Dark Outside” entity to True or False.
  3. Have a separate automation (or Node Red flow) devoted to the Work: the things you want to happen when the event takes place, regardless of what triggered the event. This is where you set your lights to turn on when the “Its Dark Outside” helper entity becomes True.

Why do this? A main reason is ease of maintenance. 99% of the time, I find myself editing automations to either change the triggering of an event (I’ve got this new weather station that I want to use to tell the system whether it’s dark outside) or to change the event’s actions (I’ve got a new light that I want to turn on whenever it becomes dark.)

Another reason is that its easy to use these helper entities in other automations. In my security automations, I can easily add a check to see if “Its Dark Outside” is true, and branch my logic accordingly.

Another one of these that’s been really helpful with my automations is “Bedtime”, an Input Button. When I started out, I set the Activation portion of this based on a timer at 11:30 PM. And for the Work automation, I turn off a set of lights whenever “Bedtime” happens.

Over the years, this has evolved so that the Activation is now either the clock or my pressing a z-wave button beside my bed. And on the Work side, I’ve added switches that control holiday lights, so these now also turn off at bedtime. At least if the Toggle Helper “Holiday Time” is also True.

Other virtual states/events I currently use include:

  • Pre-Wake - things like adjusting thermostats prior to actual wakeup events
  • Wakeup - lights, coffee maker, etc
  • Between Bedtime and Wakeup - Really helpful combined with interior motion detectors
  • Holiday Time - Manually set; Facilitates controls for exterior Halloween and Christmas lights

(By the way, I initially used Toggle (Input Boolean) for all of these, but have recently changed a few of them over to the new Input Button format.)

I’m sure you will have others that work for your particular situations: “Leave for Work”, “Prepare for Arrival from Work”, “Its Hot Outside”, “It’s Icy Outside”, “No One Is Home”… The whole point is to use Helpers to improve your automation logic and simplify ongoing maintenance and the evolution of your home automations.

2 Likes
2

I’m not sure that I follow. In fact, I am a little confused by the example. I know it is dark outside because sun.elevation < 0 so it seems a little redundant to make an input_boolean for this.

But perhaps this is a wording gap, and perhaps ‘virtual sensor’ for the purpose of triggering makes more sense?

Eg. I swap out motion sensors all the time and instead of editing the automation trigger I use a template sensor that does nothing more than provide a standard entity name for all automations being triggered by motion and all I need to edit a single template.

3

Certainly it becomes dark when the sun is below the horizon. But also when there is heavy overcast such as during a thunderstorm. I have lights that I like to turn on in both of those situations.

To your point – is it redundant? Yeah, it is in many ways. All I’m saying is that over the years I’ve found the logical separation of Activation and Work enabled by this redundancy to be very helpful in automation maintenance and improvement.

1 Like
4

Oh I definitely agree that separating can be useful. I guess I was confused about the approach.

It hasn’t quite clicked why one would strictly use a input_boolean versus a binary template sensor.

Going back to the shortform escape; sun.elevation < 0 or sensor.outdoor_lux < 200 makes a lot of sense to me with the binary_sensor as a trigger. No need to toggle a helper.

I have very few automations triggering from a helper. I have a lot triggering from binary_sensors. Perhaps I am bias.

1 Like
5

I follow your logic and see some minor advantage. However, I recently did exactly your scenario quite easily without it.

I replaced my stand-alone Lux sensor with a sensor output from a recently purchased weather station.

It took no time at all to find and replace all instances of the use of the old Lux sensor. Modern text editors are great at this.