WTH no declarative automations?

Archive Month of "What the heck?!" (2020)
1

I recently wrote an automation for controlling a two-speed kitchen fan depending on humidity. Here is what I had to write:

  • If the first threshold was reached, but not the second, turn on the first speed.
  • If the second threshold was reached, turn on the second speed.
  • If the second threshold is no longer active, but the first one is, turn on the first speed.
  • If the first threshold is no longer active, turn off the fan completely.

What I would like to write:

  • The first speed is turned on if and only if the first threshold is active and not the second.
  • The second speed is turned on if and only if the second threshold is active.

What the hell?!?

The event-driven method is powerful, but itā€™s tedious and can easily introduce errors. Declarative automations would be easier to write and easier to keep correct.

2

This can be done easily with two automations, each with a single numeric state trigger.

Cramming it all into the one automation is not always best.

1 Like
3

One detail I didnā€™t include: I wanted to have hysteresis, so that small changes in humidity did not make the fan go dancing. I didnā€™t find a way to do that with numeric state triggers, so I went with threshold sensors.

So alternative title for this post could be, ā€œWTH no hysteresis for numeric state triggers?ā€. But actually the problem still stands, as I could want more complex automations than a simple numeric trigger. For example: turn on the fan if and only if the humidity threshold is reached or the particulate sensor threshold is reached or the fan switch is on.

1 Like
4

Usually if I find myself writing complex triggers like that I stop and move the logic to one or more template sensors instead. That way triggers can be simple and state-driven rather then dependent on the exact order state changes occurred in.

So in your case you could create a template sensor that is ā€œfan stateā€ and capture your logic in there. Then the actual state of your fan state sensor would be off, low, high. This way your automation can just be based on this sensor:

Trigger when sensor.fan_state changes
If sensor.fan_state = ā€˜highā€™ set fan to high
if sensor.fan_state = ā€˜lowā€™ set fan to low
otherwise set fan off

5

Did you need more functionality than the Numeric State Triggerā€™s for option?

automation:
  trigger:
    platform: numeric_state
    entity_id: sensor.temperature
    above: 17
    below: 25
    for:
      seconds: 2
1 Like
6

Hello there! I also found declarative way more simple for automation description, so Iā€™ve made custom package for myself and even published it to community.

If you are interested - topic is here (but it hasnā€™t drawn much attention from community)

Not sure if itā€™s ready for your case, but I can help if you give more info about control objects in your setup. Looks like your case is similar to test led in my setup (hass-lights-control/example_config/example1/lights_control_with_annotations.yaml at e3b5e4c987c7c991260ba41f84944cd9c70c86f2 Ā· Godhart/hass-lights-control Ā· GitHub)

7

Here is detailed description to control ON state depending on sensorā€™s value or time:

Even though Iā€™ve made this component for controlling lights, it can handle some other things as well.