Best practices to keep automations readable

Configuration
1

Hello all,

In new to Home Assistant, I understand the basics of Automations and I have a programming background.

I want to automate garden lights:

  • During week day on at 6 o’clock, off at 7 o’clock of off at sunrise

  • On at sunset, off at 22 o’clock during weekdays, during weekend 23 o o’clock.

  • Always off at not home, or back on when home and above triggers are satisfied.

  • Only on when cloudy, partlycloudy, sunny.

Yes triggers:
6, 7, 22, 23 o’clock (weekdays / weekend)
sun.elevation rising
sun.elevation falling (= one value trigger with above and below value, or two?)
presence detection
Weather

Okay, now we need a switch condition, so that’s action?
You see a lot of or’s and and’s in this situation.
It is very difficult to have te complete overview.
I also hate to specify for example elevation 5.0 at two of more separate places without being a variable. You will forget to change all those values so it should be a constant.

What is the best approach? How such a simple things can be so a mess.
Should I consider Node-Red?

Please some reccomendations.

2

The closest analog to a switch condition in HA automations is the Choose action.

You can define your own variables in scripts and automations as well as access ones that are built-in like Trigger variables through the use of Templating.

3

Move to Node Red, you won’t regret it. Miles better than YAML in that regard and other regards.

image
image2365×511 106 KB

4

It’s quite difficult to begin with but it is probably worth it.
I guess Automations are good for very simple things.
I hate Javascript anyway :wink:

It also consumes considerable amounts of RAM.

5

And complex things. Several of my automations have multiple triggers and a lengthy choose statement.

Interestingly, the most convoluted is a Goodnight script because it has to navigate through several decisions successfully, handling each failure scenario gracefully (doors left open, door lock that fails to lock, etc), before it can announce “Good night”.

6

I don’t know a thing about javascript and use NR extensively in my pi4, not a single problem in performance. It’s not difficult, in fact it’s way easier than yaml. You are right about that, very often the simplest automations are simpler to build in yaml. The deeper you go, the more NR shines.

7

Who doesn’t?
It’s like the people that design toilets and place the toilet paper behind you.
There is just no logic to it (both JS and the toilet paper).

But luckily you don’t need that much JavaScript in Node red.
Most of the time it’s just parsing strings and/or replacing things and that can usually be googled in an hour or two :wink:

8

pyscript.

9

Is that… a complete overview? I feel like the number of nodes you would have to double click on to figure out what is going on would make my hand hurt. And I’d probably forget what I saw 5 nodes ago a lot.

I actually just recently finished migrating all my automation from Node RED into HA automations. I was a heavy user for about 2 years (actually pretty printed my flows.json file before i began, 36k lines). There’s a few left but its like 95% HA automations now with no loss of capabilities. I can’t really imagine ever going back though.

Mainly because of traces. Can’t tell you the number of times something broke because of some weird edge case and I’d spend like 2 hours trying to figure out what happened. Looking at history in HA, the little bit of status information, opening and closing nodes, scattering inject and debug nodes around, etc. Now hours has become minutes. Pop open the trace, see exactly what the context was at the start of the automation and every step of the way up to the point where it broke. Fix it and move on.

Can even fix it from my phone now! Node RED on mobile is really not a thing so that was a nice bonus.

10

I know the flow by heart so there’s no need to double click to know what’s in there plus I work in a 12’’ screen, I need to do that. Besides that, the majority of those nodes, the hidden ones, are irrelevant.

I went exactly the other way arround for the same reason when traces didn’t exist, I moved 95%+ of my automations to NR mainly because of debugging and deploying/restarting. I haven’t had any debugging headaches since, I always debug my flows in minutes. Surprising to hear that.

1 Like
11

Oh me too. Debugging difficulties drove me to Node RED in the first place as well. I mean two years ago there were so many issues:

  1. No choose
  2. No repeat
  3. No traces
  4. No templates in most service data unless the service explicitly supported them
  5. No variables

I mucked around for a bit but found the entire thing so frustrating that Node RED was a revelation. But a lot has changed since then. Very few things that Node RED can do and HA can’t. And judging by the PRs that popped into 2022.5 so far Frenck seems determined to eliminate all of them.

Debugging in NR is solid as long as a) you’re able to recreate the message and b) recreating the message is enough. The more places you look out at HA state (or other globals) in your flow the harder it is to recreate sequences of events without excessive changes.

HA traces make that a total non-factor. It’s like in Node RED if every time a flow ran you could see exactly the nodes it went through and exactly how the message object changed along the way. Idk I definitely find that easier, I don’t generally need to try and recreate anything anymore.

1 Like
12

NR is very much dependent on whether you’re a visual person or not. I’m not. For me, any NR flow that isn’t the most simplistic one looks like a complete mess. The example flow you posted, honestly, if I’d see such a thing in my automations, it would make me delete NR right away without ever looking back.

I’m a code person. Give me code. Not messy spaghetti graphs with weird curvy lines all over the place :slight_smile:

2 Likes
13

You two are really persuading me. I’m gonna try move my most complex flows to yaml just for fun. Perhaps that’ll change my mind.

14

God no, not YAML ! Pyscript. Link above :slight_smile:

15

You can also rather than using the sun use light sensors pointed outside such as an aeotec Multisensor 6 or 7 that’s mains powered so you’re not concerned with the number of transmissions it will do in a day and use that for controlling lights outside.

Measuring the light outside I have found to be far more accurate than trying to use the sun. You just have to determine what the measurements mean such as is 80lx bright outside for you or 100? I use 3 light sensors facing different sides of the house to capture the difference.

I use it for controlling lights outside, inside, and opening and closing 13 shades. All of the logic is handled via the UI using choose and repeat for the shades to ensure they open/close although with the new sonoff zigbee dongle repeat is probably not necessary anymore for any of my automations.

1 Like
16

I do need to check out node red.

I tend to write very short automations and link them together via input_numbers and input_booleans to to create more complex automations. As an example putting the house in away mode, Rather than one giant automation - I do the following

  • input_boolean.away_mode and a binary_sensor,away_mode mapping to the input_boolean
  • each package that cares about away mode
    • defines it’s own binary_sensor._away_mode deriving from the global perhaps with a On delay or Off delay
    • one or more automations that trigger off the packages away mode

This way I can keep the logic for away mode in each package. For example, each thermostat, movement sensors, heated mattress pad, water heater, etc, Which makes it very modular and easy to add a new device in without risking breaking all the stuff that already works,

Taking one step further, I define the package+automation once for each device type and then replicate using scripts with simple string substitution (e.g. sed) to generate the final config. This provides consistency and speed when adding new functionality or adding another device. In a way I’m creating classes and objects,

17

That’s an interesting idea. Why the input helpers though instead of just firing events? Like the automation does this:

action:
  - event: home_away_mode_change
    event_data:
      state: 'on'

And then other automations in other packages can just listen for that:

trigger:
  - platform: event
    event_type: home_away_mode_change
    event_data:
      state: 'on'

You can also make it into a sensor if you want so if there’s an issue you can see how the state changed in history:

template:
  trigger:
    platform: event
    event_type: home_away_mode_change
  binary_sensor:
    name: Home away mode
    state: "{{ trigger.event.data.state == 'on' }}"
    device_class: occupancy

Seems like you would have a whole lot of entities with the same state otherwise.

18

In my opinion the main benefit of Node red is how easy you can set up variables and transfer them in between different automations with flow variabls.
I use them quite a lot because it means I don’t need to make one big spagetti mess, the flow variables share data between the automations.

Something I noticed recently is that the HA automations GUI doesn’t like large automations. My browser goes unresponsive when I load my NS panel automations. Switching between GUI and yaml mode also takes a long time.
But yaml automations has come a long way for sure. Still not there completely for me. I still appreciate the way Node red can do so much more than yaml.
Yaml always have that one field that is not templatable and it ruins the whole thing, in Node red the messages are always easy to change and therefor you can get the automation to behave the way you want.
And integrate things that in yaml would create separate entities, like http request for example.

19

That’s an interesting idea that I had not considered. I like it and can see how that is a simplification. Thank you!

1 Like
20

I was and am a staunch node-red supporter, but as HASS has built a better gui around yaml automations, and included more features in them, I’ve been moving more of my simpler automations over to HASS. Things like timed lights, battery level reporting, and simple state-based changes (e.g. keeping the TV and the light behind the TV in state-sync). Node-red is still in use for more complicated automations or features that HASS just doesn’t have (for example, rate limiting AQI updates to 1 every 15 minutes even though the sensor updates every 30s to 2 minutes).

Further, node-red is nearly impossible to use properly on a mobile phone, and that’s where my wife and I interact with all this the most. We’re both software engineers, but we do home automation stuff for fun, and keeping things accessible and easy is part of that fun.

I think moving the simpler automations into HASS has increased their readability. Especially with trigger IDs used for branching logic in the same automation.