2023.8: Update breaks automations

Since I updated to 2023.8 last night a lot of my automations have been failing and I cannot figure out why. It seems to be the ones that employ “mode: restart” as well as a delay before triggering that same automation again.

What happens: The automation is started once and seems to never stop again.

- alias: Upstairs Servercorner Motion starts Lamp
  trigger:
  - platform: state
    entity_id: binary_sensor.motion_servercorner
    to: 'on'
  action:
  - choose:
    - conditions:
      - condition: state
        entity_id: binary_sensor.motion_servercorner
        state: 'on'
      sequence:
      - service: switch.turn_on
        target:
          entity_id:
          - switch.plug_desk
      - delay: "00:05:00"
      - service: automation.trigger
        target:
          entity_id:
          - automation.upstairs_servercorner_motion_starts_lamp
    default:
    - service: switch.turn_off
      target:
        entity_id:
        - switch.plug_desk
  mode: restart
  max_exceeded: silent

Attributes:

last_triggered: 2023-08-03T08:48:33.218611+00:00
mode: restart
current: 1
friendly_name: Upstairs Servercorner Motion starts Lamp
Turned on triggered by automation Upstairs Servercorner Motion starts Lamp triggered by state of Motion Sensor Servercorner
10:48:33 - 16 minutes ago

Since binary_sensor.motion_servercorner was off, the automation should have been triggered five minutes later, which it hasn’t.

When I open Settings->Dashboard->Automations, running the automation manually does not work (last triggered stays at 16 minutes ago no matter how often I click “run”).
Also, I cannot seem to disable those automations in question that are running forever. (Other automations can be disabled and re-enabled as expect).
Potentially relevant (?): When I click “traces”, an empty dialogue opens with just an “ok” button in it, which seems to be true for all automations, even the ones working.

Note: Other automations (mode: single and no delay) seem to work as expected.

All of this has worked for months. So, I do not see why it is failing now after the update to 2023.8.

Please help!

I’ve had this problem start for me too - most automations working fine but just a select few will randomly stop. Running manually does not work like you. Disabling them does not work like you. The fix is a reboot then they are good again for a day or two and the problem is back. Except… the problem began with 2023.7.3 not 2023.8

I rebooted several times. The problem comes back right away.

Upon reboot I am able to disable and re-enable the automations that have not been run, yet. It does not make a difference, though.

Total guess here, but do you both not have ID: in your automations? …I’m trying to look for commonality and can see that @thorshammer doesn’t have it in his example. I know that id: isn’t mandatory and only enables traces and editing in the UI, but maybe worth a shot?

- alias: Upstairs Servercorner Motion starts Lamp
  id: something_unique_here
  trigger:
  [...]

[edited for typos]

1 Like

I’ve switched to YAML mode and none of my automations have that id:

They are all working fine except for a couple that have developed this problem since 2023.7.3

When the problem starts the trace shows all subsequent runs are aborted because (as with ALL my automations) they are set to single instance. It thinks the automation is still running even though nothing more than trigger on sensor and turn on a light. Can’t disable, can’t run, nothing. Restart and it’s good again until it becomes stuck.

I tried something funky a minute ago because, ironically, it started again. I duplicated the automation, renamed the original to OLD, and was then going to delete the Old. Except… the new one didn’t show up and the old one was still listed as the original name (yet when clicked said it was called old). Cleared cache, refreshed, no change. Rebooted Home Assistance and the new one now showed up and the old one was now called Old. Have nuked the old just for sake of it, but something definitely gets stuck and screwy.

1 Like

Agh, OK - it’s not necessary if you created the automation using the UI :+1:

Can you remove this as it maybe hiding entries from your log that may help diagnose the issue.

1 Like

Are you the same as @thorshammer in that this only happens to automation with mode: restart?

1 Like

Tried the id: line, no difference.

However, I was successful in disabling and re-enabling a few of those “stuck” automations right following a reboot (I’ve had quite a number of those now). There is only one rather longish automation that still gets stuck. Tried renaming - reboot - new name, same problem.

When I hit “reload automations”, it seems to get stuck (spinner spinning forever). Reloading all YAML does not help, either. I always have to reboot.

P.S. Also had removed the max_exceeded: silent a few tries ago (still removed).

Now you can run Trace. What does it say for the run that stuck?

1 Like

So, I removed that automation from automations.yaml. Rebooted. It was gone. Good.

I added that automation with a completely new name. Rebooted. I could disable and re-anable it upon reboot. However, it still gets stuck. It runs once indefinitely and cannot be run again nor can I disable it.

So, I am getting a feeling all my problems are related to that one automation - perhaps?! What boggles my mind is the fact that this particular automation has not been changed in months. And it has always worked until last night’s update.

What do I look for in the trace?
The first trigger (trace timeline) shows me triggered by… and then cancelled … (runtime: 0.06 seconds). How can I see what cancelled it?
Then, there is a completely blank trace.
Next, there are two more: In trace timeline I see the triggered by… and then “still running” in the next line.
Finally, there is another blank trace.
Nothings follows not even when I trigger that automation.

I removed that automation for now and will observe further.

Honestly not sure, but I imagine it was cancelled by restart and then stopped because it only runs once.

  • Why do you want restart anyway? If it has already started, don’t you want it to complete?
  • Also, why do you have the automation re-run itself - surely that’s an infinite loop?

edit: Can you hash out this section, change to mode: queued and see what happens?

#      - service: automation.trigger
#        target:
#          entity_id:
#          - automation.upstairs_servercorner_motion_starts_lamp

The automation controls one lamp, changing color according to different triggers (bathroom occupied, front door open, something stuck in the letterbox, after sunset but before bedtime). It is not an infinite loop, as the default is to turn off the light and end the automation.

1 Like

As for your suggestion: I am afraid that would serve a different use case. The whole reason for the delay&re-triggering were some wonky motion sensors originally. I needed a reliable five minutes of light after they had been turned on. When I started adding numerous triggers, this solution seemed very comfortable. I could/can (hopefully) throw all kinds of things at these automations and still be sure that five minutes later the state would be re-evaluated until it finally ended with everything turned off.

Anyway, the automation mentioned in my first posting is working again. It’s just a complex one that is still on the fritz (hopefully just that one). As aforementioned, I have removed that culprit now. I’ll replace it step by step with something all new to re-iterate what might have caused the automation to get stuck in the first place. But that’s for another day.

Thanks a million to you for sticking with me! It is such a wonderful feeling to know I wasn’t alone in this. @jchh, your help is very much appreciated!!!

You’re missing an entity_id in your condition. I’d wager that’s your problem.

I just checked the original automations.yaml. The entity_id: binary_sensor.motion_servercorner is actually specified there. So, I am sorry about the strangely abbreviated version I posted. Weird, must have gotten lost by just copying and pasting… Again, sorry @petro . Else, that would have been a good candidate.

P.S. Corrected the first posting.

No mine are all set as single

1 Like

Cheers - sorry that none of my thoughts were actually of any use!

1 Like

Can you post one?

1 Like