WTH can't we describe what to achieve when in automations?

Month of "What the heck?!"
1

This is basically a request for an additional automation paradigm that can be applied for many scenarios.

Example:
I want the lights in my office to be on when:

  • somebody is in my office (motion/mmwave sensor)
  • current time is between sunset and sunrise (time/sun sensor) OR when it’s raining (weather station sensor)

Current way of configuring:

  • Automation 1: if motion sensor becomes true, check if current time between sunset and sunrise or if it’s raining → switch on lights
  • Automation 2: if motion sensor becomes false → switch off lights
  • Automation 3: when current time between sunset and sunrise, check if motion is on → switch on light
  • Automation 4: when current time not anymore between sunset and sunrise, check if it’s not raining → switch off light
  • Automation 5: when it’s raining, check if motion is on → switch on light
  • Automation 6: when it’s not raining anymore, check if the time is not between sunset and sunrise and if motion is off → swich off light

Imagine having more conditions, the number of permutations will grow exponentially.

Desired way of configuring:

Automation 1:

  • Configure the triggers:
    • motion sensor is on
    • current time between sunset and sunrise OR it’s raining
  • Configure desired state:
    • lights are on
  • Configure default/counter state:
    • lights are off

You can kind of do achieve this currently by using triggers that react to all state changes and then write a template condition that combines all state requirements, but it’s complicated and tedious while I believe this the paradigm I’m proposing is close to how people think: I want the light to be one when…

2

I completely agree with your point. The current Home Assistant automation system can feel paradoxically both overly simple and overly complex simultaneously. While the UI and YAML-based configuration are great for straightforward tasks, once you start layering more conditions and triggers (like in your example), the permutations become cumbersome, and managing them can feel like unraveling spaghetti logic.

This resonates with me because I’ve had similar frustrations—especially when I compare this to some of the systems I’ve built using Arduino and custom C code. With Arduino, you can define complex behavior in a relatively straightforward, linear way, with clear control over state and logic. In-Home Assistant, though, the abstraction often adds unnecessary complexity, making truly automated behavior feel like a chore to set up.

For instance, the current paradigm of splitting logic into multiple automations works but feels unintuitive when you’re trying to think holistically about the desired behavior, as in your example: “I want the lights on when…”. The need to manually create complementary automation to “undo” or “reset” states (like turning off lights when conditions are no longer met) adds to the complexity and takes away from the feeling of true automation.

What you’re proposing—a declarative way to configure automation with desired states and counter-states—is not only more intuitive but also closer to how people naturally think about automation. I’ve often wished for something similar, where we could define higher-level state relationships without needing to manually break down every condition and trigger combination.

The irony is that platforms like Arduino, with raw programming languages, often allow for more fluid and expressive automation logic because you’re not constrained by pre-built abstractions. You can encapsulate “when X, then Y, unless Z” in a few lines of code and tweak it directly. With Home Assistant, even simple logic sometimes feels like you’re fighting against the tool rather than working with it.

I hope that as Home Assistant evolves, we see more flexibility for defining automations in ways that feel natural and powerful. Perhaps incorporating something like stateful automation builders or even a logic-flow editor that allows for nested conditions, desired outcomes, and counter-states would address this. Until then, templates and custom scripts seem to be the only way to achieve more nuanced behavior—but those aren’t beginner-friendly.

I completely understand where you’re coming from, and I hope this sparks some discussion about how Home Assistant can better align its tools with the way users think about automation. After all, if we’re here to make our homes smarter, the tools shouldn’t make us feel like we’re stuck in repetitive configuration cycles just to achieve it.

3 Likes
3

I agree with this itch, but have a different spin. I would think of it as kind of “computed states” (web developers may know what is meant). Basically I want to be able to configure:

light.foo.state := sensor.motion && (sunset <= time <= sunrise || weather == rain)
light.foo.color := sensor.motion ? "green" : "red"

So, the way I think is “this attribute/state should always be equal to the result of the following computation”. Preferably with the ability to configure multiple evaluations at the same time.

Conceptually Home Assistant should be able to do this easily with templates. Define a template, and then define a target state/attribute that should be updated with template state every time the template result changes.

4 Likes
4 
id: "foobar"
triggers:
    - platform: state
      entity_id:
      - binary_sensor.occupancy
    - platform: sun
    - platform: state
      entity_id:
      - binary_sensor.is_raining
actions:
    - choose:
      - conditions: >
          {{ state("binary_sensor.occupancy") == "on" and
                (states('binary_sensor.is_raining') == 'on' or states('sun.sun') == "below_horizon")
          }}
        sequence:
          - service: light.turn_on
            target:
              entity_id: light.the_light
      default:
        - service: light.turn_off
          target:
            entity_id: light.the_light

How simpler would you want it to be, precisely?

2 Likes
5

How simpler would you want it to be, precisely?

Well, a lot simpler to be honest!
You and I can do this, but this is not for the average user.

When the core team aims to simplify automation creation (a key item on their roadmap), I believe the goal is not to teach people how to write templates. Rather, the focus should be on developing approaches that feel intuitive to users across all skill levels, aligning closely with their natural thought processes and providing guided support in the UI to achieve this.

3 Likes
6

Thanks for the detailed reply and support for this item. I was uncertain about my ability to articulate the concept clearly but you seem to have grasped it :slight_smile:

7

Thanks! I think what you propose is one of the possible implementations. The user experience should be different though.

8 
Message malformed: Expected a dictionary @ data['actions'][0]['choose'][0]['conditions'][0]

How is that a good experience for your average Joe/Jane? Home Assistant is moving away from yaml configuration to make it easy for all users

9 
states('sun.sun') = "below_horizon")
------------------^ should be ==

Desired way of configuring:

Automation 1:

Configure the triggers:
    motion sensor is on
    current time between sunset and sunrise OR it’s raining
Configure desired state:
    lights are on
Configure default/counter state:
    lights are off

Here’s how I’d do it:

triggers:
  - trigger: state
    entity_id: binary_sensor.motion
  - trigger: state
    entity_id: binary_sensor.raining
  - trigger: state
    entity_id: sun.sun
actions:
  - action: light.turn_{{ 'on' if is_state('binary_sensor.motion', 'on') or
                                  is_state('binary_sensor.raining', 'on') or
                                  is_state('sun.sun', 'below_horizon')
                           else 'off' }}
    target:
      entity_id: light.my_light

Alternatively, create a template binary sensor helper:

{{ is_state('binary_sensor.motion', 'on') or
   is_state('binary_sensor.raining', 'on') or
   is_state('sun.sun', 'below_horizon') }}

then simply:

triggers:
  - trigger: state
    entity_id: binary_sensor.light_wanted
actions:
  - action: light.turn_{{ trigger.to_state.state }}
    target:
      entity_id: light.my_light
1 Like
10

So, for one thing, this example keeps sending turn_on/turn_off calls all the time, even if the desired on/off state hasn’t changed. This is probably inconsequential for on/off, but not applicable in the more general case, f.e. with transitions.

1 Like
11

The point was not to give exact code (obviously, I didn’t test it)
The point was to give food for thought. You can do the exact same through UI and avoid syntax errors.

12

Quote of the century: “Never assume yourself smarter than the system”
I’m sure this is internally optimized.

And it’s not “all the time”, it’s only when a relevant state changes.

13

Thank you for this suggestion. This is exactly what I have been missing in Home Assistant since the beginning. The current possibility to create automations is too much like an IFTT and is great for linear automations. When automating my roller shutters, however, I came up against limits.
I’m currently implementing this (I call it desired-state automation):

I define a template sensor that processes the state of the entities dependent on the automation and outputs a value as the desired state depending on the state.
Example: If the light outside is dark, then the shutters should be down.

This allows me to include many different sensors in the determination of a target state.

I then define a script that switches the device based on the target state.
Example: If the target state is “down”, then lower the shutters.

The automation for the roller shutters is then very simple: as soon as the value of the target status template changes, the script is called. The script then decides what to do depending on the value of the target status template.

I would like to see this type of automation also supported natively by Home Assistant. Instead of a decision tree, this would require a decision matrix that takes any number of different states into account in order to determine a target state.

1 Like
14

Remember that you only look at your own situation.
The devs need to cover all those situations and more and find a way to show it graphical and more importantly maintain it in the future.

Think about how many other sensors that have to be thought into this, like a bed sensor for when you get up at night or a lux sensor for when the sun is too faint, just to mention two more options.

And it might feel very strict, but otherwise misunderstandings will occur.

7150e5e405c46cbae6b6693adcfadac522a6db68_2_844x1000
7150e5e405c46cbae6b6693adcfadac522a6db68_2_844x1000844×1000 145 KB

4 Likes
15

It will always be the case that transferring coding principles to UI is lossy. The only lossless way to code is by actually writing code (think about all of the code-less website builders). There are several projects (Pyscript, NodeRed, AppDaemon) that attempt to do what you’re asking, but each comes with its shortfalls. Most of them provide more functionality at the cost of simplicity.

As demonstrated by several individuals, the functionality you are asking for exists.
However, it seems what you’re dissatisfied with is the UI. You’re asking for a simple UI that allows basic users to do advanced user things. It seems more practical to me that the simple UI be focused on simple user things.

Advanced functionality → advanced user → templating/YAML

16

Post an example of the YAML that would be produced by your simpler proposal.

Because once a YAML version exists, it can be created via the UI.

17

However, it seems what you’re dissatisfied with is the UI. You’re asking for a simple UI that allows basic users to do advanced user things.

It is about a different approach, a different way of thinking. And that translates to the UI indeed.

I believe there are numerous scenarios where a trigger->condition->action model is very effective. However, there are also situations where a condition->‘desired state’ approach proves more appropriate.

The desired state is maybe similar to a scene. Your goal is to describe the state itself, rather than the specific actions required to achieve it.

3 Likes
18

What you are describing here is called declarative programming and is exactly the purpose of scenes.

2 Likes
20

Very interesting way of thinking. I don’t know enough of the inner workings, but I would guess that listening for triggers is a lot less resource intensive than having to keep track of states all the time? Automations are currently set up to react immediately when a trigger occurs, and I think the core has been optimized to detect these triggers with relatively low load on the hardware. Checking all states all the time every ms might be a bit resource-intensive? Just guessing.

I think what you describe could be achieved by an automation that triggers on a time condition (e.g. every 10 seconds) and whose desired states are coded into the ‘conditions’ part of the automation? Or am I reading it wrong? That would be a simple solution with relatively little effort. You could make a separate category of automations, give these a different name but use the same underlying principles.

1 Like
21

This WTH is not about commenting your code.