Why change the behavior when you can just do that with the front end or with a template sensor
Perhaps we need a “blueprints” for Helpers.
An automation that’s off/disabled cannot detect when its state changes to on/enabled. Its triggers are functional only when its on/enabled.
Programmatically enabling/disabling automations, as part of normal operational logic, is not a recommended design practice. Its preferable to design an automation that contains all required logic to determine exactly when it should/shouldn’t execute its actions. For example, one automation can set a flag that’s monitored by one or more other automations to influence their decision-making.
Reserve enabling/disabling an automation as a manual task meant for debugging and/or testing.
True. I didn’t think about that.
I still think that the states should be changed from ‘on’/‘off’ to ‘enabled’/‘disabled’ to minimize confusion and be more precise.
I agree to a certain extent, in the UI it should say Enable/Disable (handled through translations) but the state should still be on/off, like any other binary entity.
For what it’s worth, I would love to have access to the parallel automations that are running, maybe an additional entity. That could have all these states discussed here.
Using a flag would be OK, but then you need some kind of mutex locking, else you introduce a race condition between the automations. I.e [lock the mutex, set flag, run automation, unlock mutex[ and [lock mutex, test flag, run automation, unlock mutex]
I was actually thinking of making a feature request “add a mutex lock helper”
If you are able to implement your proposal (“mutex lock helper”), you should first submit it for Discussion in the Architecture repository to get approval from the core development team (because it introduces a change to the architecture of automations).
If you are not able to implement your proposal then, yes, you should submit it as a Feature Request (a volunteer developer might implement if they agree it’s worthwhile).
BTW, the “flag” I mentioned was a reference to the common practice of using an Input Boolean to influence another automation’s conditional logic.
Yes, unfortunately I dont have the time to mess with HA internals, so I will add a Feature Request.
The information above, explains another problem I was having with “current”. I was assuming that 1 and 0 represented distinct states (1 = running, 0 = not running), so I added it as a state in the automation condition. The effect of this was that the visual editor inserted “1” in the YAML code, and the check was failing because “1” != 1. Now that I understand it represents a numerical value “current instances”, I edited the automations, and changed this to a numerical state, and made the condition “below 1”, now having done it this way, the YAML code has the correct value, a 1 without quotes. I think much of this confusion could be avoided simply by changing the name of the attribute from “current” to “current_instances”, “running_instances”, “active_instances”, or something similar. Then would be clearer that this is a numerical value, and the meaning of it would be more obvious.
(In fact this is what motivated me to create the feature request, the fact that I erroneously entered 1 as a state, and the YAML value was “1”, was causing the check to not work properly, hence my desire to have the running state to make checking easier).
Having reviewed all of the replies here, I think this can be resolved in a better way, any or all of the following:
-
change the name of the automation attribute “current” to something less ambiguous - I would suggest something like “active_instances”
-
to achieve the result I was attempting, introduce a “mutex helper” as requested here:
Add a "mutex" automation helper
(basically a binary input (flag) which is read and updated “atomically”) -
to clarify the automation state, on and off could become ‘enabled’ and ‘disabled’ (simlar to how covers have open and closed states). These are just user friendly aliases for the states, I believe.
Please also vote for Add a "mutex" automation helper
which resolves the concurrency issue in a much neater way.
I am reading all of this and it seems “Current”, while a poor name, can be used to do what we all want here.
I have been transitioning from NodeRED to core Home Assistant automations so the list is becoming quite long (insert request for grouping here).
Is there a way to write a script or template sensor (I’m not skilled enough) that checks all automations and returns those running (along with a count)?
Would it be possible to do something similar for scripts?
{{ states.automation | selectattr('attributes.current', 'defined') | selectattr('attributes.current', '>', 0) | map(attribute='entity_id') | list }}
for a count
{{ states.automation | selectattr('attributes.current', 'defined') | selectattr('attributes.current', '>', 0) | map(attribute='entity_id') | list | count }}
2 Likes
Thanks. Very helpful indeed.
How would you go about making a FrontEnd card to display this info continuously, in a good looking way?
Using template sensors or the markdown card.
I did, and the result is very informative.
But of course, I want more 
Even when nothing is running, I can see that the card briefly flashes the number ‘1’ now and then along with the name of the triggered automation. But this happens too fast to read and I’d like to add another line with the name of the most recently run routine + the time and date stamp, and that this line stays there until another routine is triggered and takes over it’s place.
Can I bother you to put together a template line for that?
Many thanks in advance 
I think the following code can archive your goal, I hope. You need AutoEntities. I’ve also used Mushroom, but this isn’t necessary.
Big advantage with AutoEntities: it shows only running automations. When automation is completed or not running, it will hide.
type: custom:auto-entities
show_empty: false
card:
square: false
type: grid
title: Running Automations
columns: 1
card_param: cards
filter:
include:
- domain: automation
attributes:
current: 1
options:
type: custom:mushroom-template-card
primary: |-
{% set entityname = (entity) %}
{{state_attr(entityname, 'friendly_name')}}
secondary: Running
icon: null
icon_color: green
multiline_secondary: true
exclude: []
sort:
method: state
reverse: false
I hope this is something your looking for. IMO, the state entity can have more options in the future.
1 Like
How does it do that?
I see no config in the filter for selecting running vs not running.
It’s the current attribute that tells you how many instances of that automation is running.
Oh, yes it does. I missed that.
Thanks.
1 Like
OK, reviewing this again after some months have passed. I resolved my original problem I had with 3 conflicting automations trying to run simultaneously, by each checking to ensure that “current” of the other two was 0. However, this was not ideal. Firstly, one of the 3 automations is lower priority than the other two.
I resolved this by adding a normal condition in the low priority automation, ensuring that neither of the other two are running. Then in the higher priority ones I do a check, and if this fails, wait 5 seconds and then check again. During these five seconds, the low priority automation will finish and the higher priority script can continue. Each of the higher priority scripts has a 10 second delay after finishing, to remove any possibility of hardware problems if another of the automations should trigger. Since the automations also have a time pattern trigger, these are set to minute + 0, minute + 20 and minute + 40.
Obviously, this would be a lot easier if there was a mutex_lock helper* that each script could try to lock as a condition, but since it seems like that won’t happen, I am stuck using checks for current.
I notice the attribute is still the very user unfriendly “current”, rather than something clearer
as I suggested, ‘active_instances’, for example.
The automation state is still on / off, my suggestion to change this to enabled / disabled hasn’t been done.
Here is the important bit:
Imagine a new user, they play around a bit with automations, maybe after a while they have two scripts which update some piece of hardware. Triggered by a time pattern. But hey they mustn’t both run at the same time or the hardware sequence is going to get mixed up ! Easy, they think, I’ll just check in automation A to make sure automation B is not running, and vice versa. Hmm… I don’t see anything like “active” or “running”…there is “current”, I guess that means that the automation is up-to-date. Ah I know, A can check if B is “off” and B can check if A is “off”, that must be it. Ooops ! Why is my hardware bricked ?
Has this happened ? Who knows. Could this happen ? Absolutely.