"Already running" New automation bug?

[smugleafdev]

I have never seen this before and yet now I’m running into these daily.

“Automation: Already running” “and shows up 27 times”

This is absurd. Look at how simple this automation is:

alias: 💡Kitchen Lights
description: ""
trigger:
  - platform: state
    entity_id:
      - binary_sensor.screek_2_presence
    id: detected
    to: "on"
  - platform: state
    entity_id:
      - binary_sensor.screek_2_presence
    to: "off"
    id: clear
condition: []
action:
  - choose:
      - conditions:
          - condition: trigger
            id:
              - detected
        sequence:
          - service: light.turn_on
            data: {}
            target:
              entity_id: light.kitchen_dimmer
      - conditions:
          - condition: trigger
            id:
              - clear
        sequence:
          - service: light.turn_off
            data: {}
            target:
              entity_id: light.kitchen_dimmer
mode: single

No waits, no timers, no delays. This should run in milliseconds and be done. How can it be already running, and for 9 hours?

Home Assistant 2023.7.3
Supervisor 2023.07.1
Operating System 10.3
Frontend 20230705.1 - latest

I think this started with 2023.7 but can’t be certain.

[Holdestmade]

Think this might be why, been around for a while:

Filter "Already running" in logs

The default mode for all automations is single. In single mode, if an automation is busy executing its action and it’s triggered again, it will ignore it and report the incident with a warning message “Already running …” just so you are aware it happened. Sometimes one is not aware that an automation might be re-triggered while it’s busy so it’s useful to be warned that it has occurred. In that case, one might want to change the automation’s mode to something more suitable. In other situations…

[Dujith (Charles Evers)]

@smugleafdev

binary_sensor.screek_2_presence

Can u look in the history and see what it is doing? something might have changed how this sensor acts.
The warning itself would suggest it gets triggered multiple times at once?

[smugleafdev]

I walked into my kitchen holding my laptop in front of me. The trace on the automation showed the trigger highlighting to the choose icon, but didn’t move beyond. What it should have done was hit the choose circle, and then immediately moved downward along the left path like it’s doing now:

The sensor seems to be working fine. The presence entity is a combination of the moving and still detections. Once I disabled the automation and then re-enabled it, walking in front of the sensor triggered the automation properly and the light turned on. While it wasn’t working I walked in and out of my kitchen holding the laptop with two screens up: the trace and a Lovelace page showing Screek 2’s moving target, still target, and presence. All three sensors were working as intended; only the automation wasn’t.

[Dujith (Charles Evers)]

You are saying the entity is made out of multiple sensors?

he presence entity is a combination of the moving and still detections

What is the yaml code for that presence entity? Could it be that 2 sensors trigger that entity at once and that would be possible to be the culprit. In essence that would activate 2 triggers depending on how the entity is setup.

[smugleafdev]

I do not know how it works exactly in the background, but all three of these entities come straight from the device itself. From what I can tell, it’s a fancy way of tracking occupancy. If moving target is detected, still target is also detected, thus presence is detected. If moving target is not detected, there’s some stored “energy” still tracked by the still target and it decrements as long as a still target is not actually detected, and when it hits a low enough number presence changes to clear.

That’s why I’m not tracking still or moving targets, I’m just trusting the device to figure it out, thus I only use presence for my automation. This means the millisecond I enter the kitchen, it turns on the light, and if I leave the kitchen, it takes a couple seconds before it turns off.

The above is of course for when it’s working and not when it’s “Already running”, which should, um, never happen ever?

[Rofo (Ro)]

Its pretty common for presence sensing devices to now have multiple sensors, like mmwave and PIR in the one device, and for a combination of those sensors to provide a third sensor which is usually called something like ‘occupancy’ or ‘presence’.

Given that you are triggering your automations on the ‘presence’ sensor shouldn’t make any difference, because your screenshot for that sensor doesn’t appear to show it triggering multiple times at once, and thats what your automation trigger is based on.

Scrolling down the logbook for that sensor, you absolutely don’t see any situations where its toggling on and off rapidly ?

[smugleafdev]

Not sure what you mean by rapidly. All of these are the amount of time I would expect for someone walking into the kitchen, grabbing something out of the fridge, and leaving. Or perhaps someone walking into and out of the kitchen repeatedly with a laptop in hand.

And of course a cat jumping onto the counter repeatedly in the middle of the night. Cat, I see what you’re doing.

[Lux4rd0]

I’ve been going bonkers on this over the last week as well. Some of my automations are getting stuck and the only way to get them to start working is to either reboot HA or disable and re-enable the specific automation. It’s not the same automation each time either. Something seems to be getting gunked up in the core system as other timers are piling up as well.

Home Assistant 2023.7.3
Supervisor 2023.07.1
Operating System 10.3
Frontend 20230705.1 - latest

Edit:

Even disabling and re-enabling stops working after a bit…

[Rofo (Ro)]

@smugleafdev

Not sure what you mean by rapidly.

Everything looks pretty normal as you say, so it doesn’t seem to make any sense as to why you’re getting the warnings. I’d be tempted to change the automation mode to queued and see if that lights actually blink on and off or not, but that still doesn’t explain why its happening.

[smugleafdev]

That’s the experience I’ve been having as well.

[petro]

Well, i’m not sure what’s happening on your system. All I can say is that it seems pretty odd that you have so many triggers on your graph in a short period of time which will cause the message. If you check the automation attributes, and you see current: 1 but it doesn’t appear to be running, then that’s a problem. Otherwise it seems like you could just be hitting many motion triggers in a short period of time. And if your light takes a while to say “I’ve reached my on state”, you’ll get that message.

FYI, you can simplify your automation to…

lias: 💡Kitchen Lights
description: ""
trigger:
  - platform: state
    entity_id: binary_sensor.screek_2_presence
    from:
    - "off"
    - "on"
    to:
    - "off"
    - "on"
condition: []
action:
- service: light.turn_{{ trigger.to_state.state }}
  target:
    entity_id: light.kitchen_dimmer
mode: single

[smugleafdev]

Regarding your code, that’s a good point. Though why not go all the way to this?

alias: 💡Kitchen Lights
description: ""
trigger:
  - platform: state
    entity_id:
      - binary_sensor.screek_2_presence
condition: []
action:
  - service: light.turn_{{ states('binary_sensor.screek_2_presence') }}
    target:
      entity_id: light.kitchen_dimmer
mode: single

Tangent: It’s too bad the visual editor can’t handle an array of strings. Could easily pop up an extra text field to fill out, or allow comma separation

[petro]

because light.turn_unavailable or light.turn_unknown are not valid services and will cause the automation to deactivate if your binary sensor decided to disconnect.

Secondly, that’s using the state machine which may not be in sync with your actual trigger, which is why mine is using the trigger object over states(..)

[smugleafdev]

Good point. Does the “from” add anything?

[petro]

yes, they ensure your states will only trigger when you move from valid states like on and off to on and off. i.e. unknown or unavailable will not impact the automation.

[jumon]

I’ve been having the same issue here, many automations stop working and when I try to manually run, the logs show it is already running but it should not be. Its like the automations are hanging. Not all automations are affected, but many are and they work fine the rest of the time. I cant even restart HA, that wont work, I have to reboot the RPI its running on (RPI4 8GB). I just updated from 2023.7.3 to 2023.8.2 and will see if this happens again. Unfortunately, it takes several days before it locks up like this and always seems to start in the middle of the night.

[Wiigian]

I am also seeing this issue in 2023.7.3.
Several automations seem to be hanging, and I am seeing warnings with "Already running"in the logs.
Updating to 2023.8.2 now.

[Alain_Raymond]

I’m also having this problem, there are also a few issues on github about this.
I found that the automations that are problematic on my side (and that were working perfectly fine for months before) are the one using z-wave devices.

I can’t disable and re-enable the automation to reset it, it won’t disable at all.
Instead of rebooting HA, I tried rebooting the Z-wave JS UI addon. When rebooting the addon, the automation will finally fails and leave the ‘‘already running / hanging’’ state.

I’m pretty sure this issue is related to some change introduced in 2023.7 or some change in Z-wave JS UI that were introduced at the same time 2023.7 was released.

Can you confirm if your hanging automations are also using z-wave devices and that you are also using Z-wave JS UI?

Automations marked as "Still Running" After Upgrade to 2023.7 & 2023.8

Automation: keeps running state

And look at the last few posts here: Automation keeps in "still running ..." state - #21 by scottconnor

Its clear that there is something wrong with HA / z-wave since july

[jumon]

Yes! Those are exactly the automations that are all hanging, zwave.