Concept of Trigger Automation

Hi Everyone,
i’m currently migrating from IOBroker to Homeassistant. My IOBroker hardware is shut down since two days and everything is working fine so far in HA. Some automation are still missing but before going deeper on that i’d like to understand if my way of implementing my automation is “Best Practice”.

  • Im reading my Energy Smartmeter via Modbus (in NodeRed) every 10sec and write all data to sensor.
  • From the “Import/Export Grid” Sensor i created a “5 Min Mean” Sensor (negative values are export, positiv values are import)

Now my question for automation:
I have an AC in my kitchen which i’d like to turn on if the “5 min mean” sensor is below -1000 (-> im exporting more than 1000W to the grid) and turn off if the “5 min mean” sensor is above 0 (importing energy from the grid)

So i created an automation which is triggered every time the sensor entity “5 min mean” is changed. Everything is working fine, but this means that this triggered is actived every 10sec.
99% of all runs i does nothing because later conditions prevent any action taken.

Is this type of implementation (trigger an automation 8.640x a day) fine or is there a smarter way to check the condition early and only trigger an automation when there is really something to do?

Kind Regards!

Hi,
have a look at the available triggers section of the automation docs:

In your use case, a numeric state trigger might be useful.
You could trigger an automation when the mean-sensor exceeds a defined upper or lower bound.

If you want to take your automation skills to the next level, you could use the same automation to turn your AC on and off by using a template in the action:-section to decide if you need to call the turn_on or turn_off service for your device.

Sebastian

1 Like

Hi Sebastian,

yes this would reduce the automation calls, but if the value is below -1000 and the AC is already turned on the automation is still fired for no action (or the other way round).

In the first place i though that the automation is only triggered if the conditions are also meet but obviously this isn’t the case.

So still need some more experience with this…

Numeric state trigger is a threshold. So the automation will fire when the numeric state reaches the threshold (eg below 1000), but WILL NOT fire again until the state has gone above the threshold and then below it again. It does not fire on every update.

eg:

5 min mean is -999, nothing happens.
5 min mean is -1000, nothing happens.
5 min mean is -1005, automation fires.
5 min mean is -1500, nothing happens.
5 min mean is -500, nothing happens.
5 min mean is -900, nothing happens.
5 min mean is -1020, automation fires.
5 min mean is -400, nothing happens.
5 min mean is 350, automation fires.
5 min mean is -250, nothing happens.
5 min mean is -1200, automation fires.

Hope this gives you a bit better of an idea how the numeric state sensor works.

1 Like

Oh, good to know. Thank you for that. If you comeing from a different systems (IOBroker with Blockly) you have to rethink all the stuff.

If the trigger of an automation “matches”, the automation fires - i.e. if you simply use a generic state change as trigger, the automation fires. As I understood it, that’s what you’re doing right now, reacting to changes of your 5-min-mean sensor.
You can use the conditions: section to further determine if “it ends there” - but the automation technically still fired if you reach that point.
So the best way, in my opinion, is to have a trigger thats as specific as you can make it to avoid unneccesary invokations of your automation.
Of course, there still will be a few cases where an automation fires unneccessarily - like in your case, the AC had already been turned on (manually?) although the sensor value was above -1000 - when the threshold is crossed, the automation will try to turn on the AC again. You can catch those events in the conditions-section of the automation.

Sebastian

For that, a threshold helper sensor is usefull. That will create a binary sensor when thresholds are reached. Then you build an automation to react to changes in the threshold sensor. In this case the threshold should be -500 and the hysteresis 500 I think:

But you can get the same result with two numerical state conditions as named above too, one for below -1000 and one for above 0.

1 Like

I had a missunderstanding with the number trigger.
I wasn’t aware that it is just triggered if it reached the treshold.
This should really reduce the automation runs to a minimum.

My automation currently looks like this (there are more condition which i didn’t talk about yet)

alias: Automation-AC-Küche
description: ""
trigger:
  - platform: numeric_state
    entity_id:
      - sensor.energy_w_after_ac
    below: -1000
  - platform: numeric_state
    entity_id:
      - sensor.energy_w_after_ac
    above: -100
condition:
  - condition: numeric_state
    entity_id: sensor.boiler_outdoortemp
    below: 15
    alias: Außentemperatur < 15°C
  - condition: state
    entity_id: input_boolean.ac_excessheating_kitchen
    state: "on"
action:
  - alias: On / Off
    choose:
      - conditions:
          - condition: and
            conditions:
              - condition: numeric_state
                entity_id: sensor.energy_mean_over_last_5_min
                below: -1000
              - condition: numeric_state
                entity_id: sensor.boiler_outdoortemp
                below: 10
              - condition: numeric_state
                entity_id: sensor.environment_flur_oben_temperature
                below: "21"
              - condition: state
                entity_id: climate.kueche
                state: "off"
        sequence:
          - service: climate.turn_on
            target:
              entity_id:
                - climate.kueche
            data: {}
          - service: climate.set_temperature
            target:
              entity_id:
                - climate.kueche
            data:
              hvac_mode: heat
              temperature: 28
        alias: Einschalten
      - conditions:
          - condition: or
            conditions:
              - condition: numeric_state
                entity_id: sensor.energy_w_after_ac
                above: -100
              - condition: numeric_state
                entity_id: sensor.boiler_outdoortemp
                above: 15
              - condition: numeric_state
                entity_id: sensor.environment_flur_oben_temperature
                above: 21
          - condition: state
            entity_id: climate.kueche
            state: heat
        sequence:
          - service: climate.turn_off
            target:
              entity_id:
                - climate.kueche
            data: {}
        alias: Ausschalten
mode: single

In the same spirit you might want to add extra triggers for temperature changes. What if the temperature rises while you already produce more than enough power?

The general pattern for automations where multiple conditions must be met simultaneously is:

trigger:
  requirement 1 becomes true
  requirement 2 becomes true
 ...
condition:
  requirement 1 is met
  requirement 2 is met
  ...
action:
  do something

The simple case, with one condition only, does not need conditions, only a trigger. That is because the trigger immediately implies the condition is met. And if only one requirement is enough, you can loose all conditions too.

Personally I like to create two automations, one with reasons to turn the AC on and the other with reasons to turn it off. That is because it is much easier to understand, it avoids needing an if to choose on or off, and the conditions are usually different so having them in one automation is not that usefull.

Having them in 1, makes automation tracing a lot easier though, so you don’t have to jump between automations following why something didn’t work as you expected it to.

I do not agree, because on and off happen at different times. Imagine how much more complex my pattern above is when you put on and off in one automation.

You are right, as the automation is not longer triggered every time the energy changes i have to rework this, too.
Two or multiple seperate automation may be an option, but as HA does not support any grouping of automation (Folder, Tags) the overview in HA gets really messy quick.

I can, I have countless automations like that. And trying to figure out why something didn’t happen as you expected it to, is definitely a lot easier when everything is in the same automation. Once you have different automations controlling the same devices, and various scripts getting called, it starts getting complicated following the rabbit hole of what exactly just happened.

I agree on the organization troubles. I try to match the names so sorting helps. The other thing I do is that is is often very easy to integrate all the reasons why that action is required. So the automation would be called Airco bedroom on or airo bedroom off. And inside may be all kinds of reasons to turn the airco off. Too cold, nobody in the room for some time, go to sleep, push a button, enter holiday mode for the home, …

I really think that helps me have less, and simpler, automations. It also gives me easier debugging: why is the airo turning off is found all in one place.

And if it becomes to complex, I split it in: turn airco of when blah blah. and lickily search works well in the automations editor.

Packages are a good way to organize the code.