Automating best practices?

Configuration
,
1

Hello!

I enjoy automating things in HA quite a lot and before going deeper in a project I wanted to know what’s the best practice for my use.

I’ll give one simplified example below: Home Office Mode

  1. UI solution: Automation that triggers when the presence of my work laptop has been detected and turns the Home Office input boolean on. And a second automation that turns off the input boolean when presence is gone.
  trigger:
  - entity_id: device_tracker.work_laptop
    platform: state
    to: home
  1. Template solution: Set a template sensor with a template like this:
binary_sensor:
  - platform: template
    sensors:
      home_office:
        friendly_name: "Home Office Mode"
        value_template: >-
          {{is_state("device_tracker.work_laptop", "home")}}

Then I have a few automations with time/weekday/phone triggers that only will execute if the Home Office Mode is on and some that won’t execute if I’m working, like starting the vaccum.

In this case the template seems like the easier solution and here’s what I came to ask:

What’s the best practice or recommeded solution?

Based on this I plan to create several others: Gaming Mode (will check discord/steam integration), Living Room Movie Mode (will check LG TV source), Bedroom Movie Mode (will check chromecast source) and so on…

2

Keep it simple and just use the state of the laptop as a condition, rather than creating automations and sensors that just duplicate the state of something else.

3

I also check the state of office light in the real use case, so I need to use one of the solutions.

4

Two questions you should ask yourself:

  1. Does it work?
  2. Will you remember how it works in six months?

Keep it simple and make notes. :yawning_face:

5

Both work well enough.

The automation solution has a lot of different parts and seems like more work but I’m not sure if throwing everything to templates is good for performance.

6

If you want help with a real use case then that’s what you should show us.

7

Maybe I wasn’t clear, I just want to know which of the solutions will have less performance impact or is considered a better way.

Thanks anyway.

8

From strictly a performance or reliability perspective, I think it’s unlikely that you’d ever notice a difference.

I would go with the automation route because I am leaning more towards the UI now, and you can make the automation with the UI. It’s a personal preference
You can combine the “on” and “off” automations with a choose block. The automation would also make it easier for you to add additional causes for changing your office state in the future, such as that light or your calendar.

1 Like
9

I would do the opposite. Why automate something that you can create a sensor for?

It just adds needless complexity.

1 Like
10

Like I said, it’s a personal preference. :slight_smile: You’re defining “complexity” as lines of code in the backend. I’m defining it as “something I can set in the GUI and probably never have a breaking change on.” This preference is probably partially informed by my (bad) workflow, I only modify config files from my desktop and upload them to Home Assistant via SFTP, but I edit automations/scripts/such things from any computer with a network connection.

In addition, carlos.vroque has already indicated that there might be other causes for input_boolean.home_office_mode to turn on, which will be vastly easier to do with an automation.

Or, if office mode really is only indicated by the laptop device tracker, I would go with the simplest approach of all, as mf_social proposed, and use the device tracker itself as the trigger/condition for any automations.

I love these discussions because I learn a lot, and re-evaluate how I do things (some habits are simply from how you had to do it back in the 0.4x days)!

2 Likes
11

I find it interesting that someone who “grew up” with yaml from the 0.4x days now has this to say:

I only started around the 0.6x days (a wee ankle biter by comparison) yet still much prefer YAML. Not just because that was what I started with but from a “perceived” greater control and flexibility. Whether or not that perception is true I can’t really judge. I only tried the automation editor way back then and found it horribly confusing, buggy and restrictive. I know it has improved a lot since then though.

1 Like
12

Thanks a lot for the comments and discussion. I guess I was worried about performance for nothing and this comes down to preference after all.

I started using the UI and it really is easy to get started and (at the time) required less restarts, but as I started looking intro attributes and more conditional triggers it seemed a template could simplify the situation. In the end I will go on a case by case solution depending on the complexity!

1 Like
13

I was averse to the UI editor for a while, and it does still have issues. Before I actually really used it I also wasn’t aware that you could still edit any given action with just straight yaml. But overall I’ve found it to be a better experience for me than having all of my automations in yaml.

Despite using HA for quite a while, I’m still not much of a power user. I occasionally sink my teeth into a project for fun, but most of my automations are quite simple. I still do use yaml heavily though, within the editors and for template entities. I’d be very dismayed if yaml became in some way deprecated instead of just one of two great options.

Sometime between 0.4x and 0.116 I also went from being childless to having two sons, which may inform a bit of my affinity for being able to quickly edit things from anywhere and aversion to anything that sniffs of me being able to break it. :slight_smile:

1 Like