Automations no longer trigger when condition already met after rebooting HA (since an update to core)

Configuration
1

For the last month or so, my longstanding automations no longer trigger if the condition was already met when rebooting HA…
I have a number of automations such as this:

- id: '1517162270741'
  alias: Solar heat lounge ON
  trigger:
  - below: '-0.9'
    entity_id: sensor.smartmeter
    platform: numeric_state
  condition:
  - condition: state
    entity_id: switch.mystrom_lounge
    state: 'off'
  action:
  - data: {}
    service: switch.turn_on
    target:
      entity_id: switch.mystrom_lounge
  mode: single

They switch radiators on and off as I generate solar electricity.

Since an HA Core update a few weeks ago, I now find that if I reboot HA and the condition is already met (in this case, if I am already generating over 900W of electricity) then the automation will not fire. It used to be the case that if the condition was met after a reboot, it would fire right away. Now I need to manually turn on the radiator toggle so it consumes 1,000W so the 900W condition is no longer met, then both on and off automations will work normally until the next time I reboot HA.

I update HA regularly and am currently on 2021.4.4.
Does anyone know if something changed in the way YAML is handled in an update a few weeks ago that could cause this change in behaviour?
Could it be the ‘single’ vs ‘restart’ mode?

2

This is no the thing that is causing the issue. This just specifies how the automation should perform if there is a trigger while the automation is already executing.

Also I dont know what exact change has happened with automations.yaml to cause this issue but i can suggest a work arround for the time being.

alias: Solar heat lounge ON
trigger:
  - below: '-0.9'
    entity_id: sensor.smartmeter
    platform: numeric_state
  - platform: homeassistant
    event: start
condition:
  - condition: state
    entity_id: switch.mystrom_lounge
    state: 'off'
  - condition: numeric_state
    entity_id: sensor.smartmeter
    below: '-0.9'
action:
  - data: {}
    service: switch.turn_on
    target:
      entity_id: switch.mystrom_lounge
mode: single
3

Thanks for your help.
So you are advising to just add event: start? Can you advise what that does?

4

Triggers the automation at startup of HA. Then it checks if the conditions are valid and progresses

1 Like
5

@Siggy101 Note that @sheminasalam has actually added two new lines in the trigger:

  - platform: homeassistant
    event: start

…which fires the automation when HA restarts, and a new condition:

  - condition: numeric_state
    entity_id: sensor.smartmeter
    below: '-0.9'

which ensures that the original trigger is also true at startup, otherwise the switch would turn on at HA restart independent of the value of the sensor.

This pattern feels messy, and is very hard to work out with more complicated automation trigger / condition combinations — feels like there should be a better way to deal with this.

1 Like
6

Thanks for the correction. I had missed the platform: homeassistant line.
Now I understand that it adds the condition.
I was wondering why firing it at every reboot would help.

I agree that it feels a bit messy but it might just do the trick. I have about a dozen automations so I will need to add it to all of them and see how it goes.

I still feel that something changed in how the YAML is handled. It’s frustrating because these have been working great for a long time. Now they are a right pain.

7

Thought of a different solution on my lunchtime walk:

trigger:
  - platform: numeric_state
    entity_id: sensor.smartmeter
    below: '-0.9'
  - platform: template
    value_template: "{{ (now()|as_timestamp() - states('sensor.uptime')|as_timestamp() < 60) && (states('sensor.smartmeter')|float < -0.9) }}"

You don’t need the extra condition any more. This now triggers within a minute of HA restarting if the sensor is already under -0.9, and then any time in future when it drops from above to below -0.9.

You need to include the uptime sensor in your configuration. I think if you’re using this for multiple automations, it’d make sense to create a “recently restarted” binary sensor to get rid of all that cruft in the template above:

binary_sensor:
  - platform: template
    sensors:
      recently_restarted:
        friendly_name: HA recently restarted
        value_template: "{{ (now()|as_timestamp() - states('sensor.uptime')|as_timestamp() < 60) }}"

Then the above trigger could be simplified to:

    value_template: "{{ (states('binary_sensor.recently_restarted') == 'on') && (states('sensor.smartmeter')|float < -0.9) }}"
8

Oooh, that’s fancy! I likey!
I will have a little stab at that. I don’t have the uptime sensor in my config as yet but can happily add it. As you say, it keeps this template tidy(er).
I have some similar automations for charging the Tesla on pure sunshine. I might need to ask your advise if I can’t get them to play nicely with the same concept.
I’ll report back if I get stuck.
Thanks to both of you!

9

Something did change. A restart used to reset the Numeric State Trigger but it doesn’t do that anymore.

The new behavior is actually better. Consider this example:

 - platform: numeric_state
   entity_id: sun.sun
   value_template: "{{ state_attr('sun.sun', 'elevation') }}"
   below: -4.0

It triggers at the moment the sun’s elevation decreases below -4 degrees (i.e. just after sunset). Imagine it is used to turn on a light which is later turned off at 23:00.

If Home Assistant is restarted after 23:00, it resets the Numeric State Trigger and so it triggers again. This has the unfortunate side-effect of turning on the light that was already turned off.

It’s important to remember that the Numeric State Trigger is designed to trigger only when the threshold value is crossed and not afterwards. However, a restart would allow it to trigger not at the crossing point but afterwards. That is not how a Numeric State Trigger is supposed to operate and so this non-standard behavior was eliminated.

Your automation relied on the Numeric State Trigger’s anomalous behavior at startup but now it must be modified to explicitly handle the case of what should happen when Home Assistant is restarted.

3 Likes
10

Thank you. I think you are absolutely spot on there.
This looks like the root cause of my change in behaviour. Nice work!

I will try Troon’s new template and see how it goes. Feel free to chip in if you know a better way.

11

No, the numeric state trigger has always worked like this (except for restarts as Taras points out) in fact there are innumerable threads where people misunderstand how this is supposed to work. And workarounds like @sheminasalam are common in the solutions.

Moral of the story: - When something doesn’t work as you expect it - test your assumptions, read the documentation and then search for similar threads

2 Likes
12

@Mutt
Do you have any theory as to what changed, if it wasn’t the numeric state trigger changing behaviour?
I did search beforehand but didn’t find anyone with the same change in behaviour of their automations.

13

FWIW, I had suggested the same approach sheminasalam did to someone else here:

It’s self-documenting because you see this means it’s handling startup:

    - platform: homeassistant
      event: start

Troon’s suggestion ought to work as well.

As for this:

You don’t need the extra condition any more

The “extra” condition is actually still there, just incorporated in the Template Trigger, but it is true that it doesn’t appear as an “extra” line in the condition section. However, this approach relies on an “extra” sensor (uptime). :wink:

2 Likes
14

Eh !
No, my point is that most people expect (say in your case) a radiator to be on if temp below a certain value irrespective of when the automation was started, reloaded, values changed etc. If this behaviour is important to you, you must test all relevant conditions in order to provide the functionality you desire.
I would add that I think that @sheminasalam 's solution is simpler (and much easier to read) than the

By @Troon

The simple rule when having 2, 3 or 4 triggers to ‘start’ a sequence is that you should have similar conditions (testing the same things) as the triggers.

So to have a light come on, only if you are home, at 18:00 and if the sun is below the horizon but before 23:00 (ie to turn it off again) you could (in the simplest (newbie friendly) manner) set 4 triggers with 4 conditions and you are done.(and a restart is an extra)
You could also create a binary sensor and just flip the light on that (super simple but the binary sensor is not for newbies)

15

The restart is covered by pretty much any of the above.
But apart from the binary_sensor option - what happens when you write the automation (with the sensor already past the threshold) and reload automations to add said automation ?

16

Perhpas the odd thing here is that I am not concerned with temperature to control the rads. That would be nice and easy, comparatively.
My setup is aimed at using only 100% solar energy to power the radiators. I can see how that would be a fairly different flavour of automation and it results in a lot more on/off cycles as the trigger condition is met and then breached (clouds passing by etc).

17

It has gone cloudy at the moment but once I see some sunshine, I will try reloading the automations and see if it fires or not.

18

Yes, try to concentrate on your end goal (rather than your first stab at trying to get there)
If you want to save money (for example) then having a sensor advise how much surplus energy is available and have tiered switching based on that.
Be careful here as some kit can not be switched on and off arbitrarily or need minimum on times (compressors etc.) and there’s the duty life of components to consider. Switching something on-off 500 times a day will not help it reach its first birthday.
Binary sensors can sometimes help here utilising their “delay on” and “delay off” options

19

Reloading won’t help in that case as the previous version is still loaded until the reload (so continuous) I’m imagining a completely new automation (don’t use your live kit for this - leave it to someone with a test instance)

20

OK, the sun came out.
I was generating 4kW (well over the 900W threshold). I restarted Automations but nothing fired.
I had to manually toggle all 3 radiators and now the automations can turn them off and back on.

Regarding the hardware etc, all of this hardware has been running for 3 years.
I live in the Swiss Alps and have paid nothing to heat a 7 bedroom house for 3 years. It’s all good.

I am definitely open to improving the setup though.
I have recently tried tuning it a bit so they only turn off or on if the last state change was over 60 seconds ago. That has stopped the high frequency toggling but it’s not a huge issue for me. These are all second hand oil radiators and they seem to be bulletproof.