Some steps in multiple automations reset themselves

Configuration
1

I have noticed that some steps in some automations that I haven’t touched in years seemingly randomly reset to their default states. This causes the automations to break silently until I notice somehow.

For example, I have one that starts the robovac if nobody is home for 15 minutes. And this 15m “for (optional)” parameter sometimes resets to zero. Happened many times on several different automations, usually it’s time parameters like this.

It is NOT caused by me inadvertently changing it in the UI editor or find/replace by accident in Automations.yaml as I don’t recall changing timers manually in YAML, ever.

What can cause this? Some breaking change that I overlooked? I run HA since 2019 and am fairly well versed in it. Thanks.

2

I assume that the for: value doesn’t survive a restart / disconnection issue of HA. Mybe sth. like this happened.

3

Correct. Or a reload of automations, which happens automatically whenever a new automation is saved.

Pretty sure this cahnged a few versions ago. for: used to survive a restart / reload but no longer does. This is by design. See https://github.com/home-assistant/core/issues/63324#issuecomment-1004251345

4

That seems really weird to me, why is the for (optional) parameter there at all then? How is the user supposed to know this? I understand the reasoning but it seems to me the current implementation favors logical purity before usefulness.

And how do I go about implementing it in another way? I mean my automation that runs the vac if nobody’s home for at least 15 minutes?

Thanks.

5

I agree with you, this behavior is neither convenient nor obvious.

For my part, I solved it by using helpers for all non-survivors:


  trigger:
    - platform: state
      entity_id: input_select.status_me
      to: 'gerade heimgekommen'
      for:
        minutes: "{{ states('input_number.status_halten_minuten') |int(0) }}"



  action:
    - service: …

    - delay:
        minutes: "{{ states('input_number.rollo_werktags_delay') |int(0) }}"

and so on…

1 Like
6

Just to clarify…

are you saying that sometimes the automation doesn’t wait for the 15 minutes specified in the for: option? that the actions are taken immediately?

Or the actions are never taken because the 15 minute for: option was interrupted while it was waiting for the 15 minutes to complete?

or are you saying that if you go into the UI editor and look at the for: option it no longer says 15 minutes (now says 0 minutes) even tho you didn’t change it?

7

The last thing! It just reset to zero which is super weird to me. It was set to 15m (and working) for at least two years. And the same thing happened repeatedly with more time-based (“for (optional)”) automations such as turning off light in the bathroom after motion detector stopped detecting motion for more than three minutes (or such).

I can’t say exactly when this started but it’s probably in the last month or two.

8

That’s what I thought.

If you are sure it’s a repeatable thing then it sounds like a bug report should be submitted. Well, I guess either way but a repeatable thing would be easier to fix.

9

hi, as @finity stated, we’re talking about different things. I am NOT talking about the actual timer not surviving a restart - I don’t expect it would. My issue that the very number in the automation gets reset to zero.

What was originally this:

trigger:
  - entity_id:
      - group.persons
    from: home
    platform: state
    to: not_home
    for:
      hours: 0
      minutes: 15
      seconds: 0

becomes this:

trigger:
  - entity_id:
      - group.persons
    from: home
    platform: state
    to: not_home
    for:
      hours: 0
      minutes: 0
      seconds: 0

That can’t be anything else but a bug IMHO.

10

Yeah, that should not happen.

11

Who, what, how can anyone edit the configuration.yaml ? Sounds like a ui bug.