It is possible to check if an automation is running by testing the value of the “Current” attribute, if this is 1 then the automation is running. However this is less than optimal, because it is not at all obvious that this is the correct way to check. In addition, as I just now discovered, when using the visual editor, if you check for state 1, the editor will encose this in quotes, so it becomes “1”, and the check fails, since “1” != 1.
Automations do have a state, however this is also a potential source of confusion, as “on” means enabled, and “off” means disabled.
What I would like to suggest is to add a new state to automations: “running”. This could simply be set when the “current” attribute changes to 1, and then when “current” goes to 0, the automation state reverts to being on or off.
This would be extremely helpful, as it can be the case that automations are mutually exclusive, in the extreme case running mutually exclusive automations could damage or disrupt hardware devices. This can be resolved by adding a small delay and then checking to make sure the conflicting automation is not running. Adding the “running” state makes this simple and obvious. As well as vastly simplifying conditions checks, this adds a nice easy trigger for other automations. And another benefit would be that the state history for the animation would show the times that the automation was running, as well as the duration.
How many automations do you have that spend a lot of execution time within their action section?
What kind of applications do you have that must know if another automation is in-progress?
NOTE
Be advised that any automation that dwells within its action (i.e. is “in-progress” for several minutes and longer) is vulnerable to being terminated by a restart or a Reload Automations (which is performed transparently by the Automation Editor when its Save button is clicked).
There’s a pending effort to change this behavior (Reload Automations only reloads new/modified automations and doesn’t terminate in-progress automations) but, until it’s implemented, all “in-progress” automations are vulnerable.
I have scripts that control an air conditioning unit that send sequences of instructions “display on”, “set temperature”, etc/ that require a pause between each command, In addition the sender unit is not 100% reliable so it sends the command, pauses, then sends again. Apart from switch on and switch off, I have a third script which adjusts the target temperature. I have to ensure that only one of these scripts is running at any time, else the commands get mixed up. As I dont get feedback from the AC unit I try to model its state internally, and having two scripts running simultaneously can cause the intrnal model to become out of synch, which leads to further problems.
Each of the scripts is triggered once per minute, so it is quite possible for two scripts to both try to run at the same time.
I have resolved this quite simply, in Actions, the high priority scripts (on/off) pause for 10 seconds and then check whether the temp adjust script is running. The temp adjust script pauses for 5 seconds then checks if either of the other scripts are running. The 5 second pause is there as the “current” attribute may not update instantly. Then, having th adjustment script check first, means it will exit first, then the 10 second pause in the other scripts ensures that the adjustment scriptis indeed not running. This works fine but having the “running” state would simplify things.
In answer to your observation, the scripts do not run for minutes, but they do run for several (20 or 30) seconds.
Besides which, even if an automation runs instantly, you might want to trigger something else to happen when it is run, it doesn’t have to be used just in conditions.
I think there could be some merit in changing the behaviour of the automation state so that instead of just on/off it has other options which could be more useful for including on dashboards or for troubleshooting e.g.
Off - as the current off state, automation has been turned off.
Disabled - automation has been manually disabled.
Idle - automation is waiting for a trigger to occur.
Active - actions are currently being executed (admittedly this would be a fleeting state unless there were many actions).
Waiting - automation is waiting for a condition to become true or for a delay time to expire.
Failed - automation failed to complete due to an error.
This is similar to what I have seen on industrial automation systems where the state is used to convey information on how the sequence is progressing to the operator. For example the state could be “Waiting” with a message on the screen “Waiting for temperature to reach 60C”.
I think I could get behind something as you described. It would be WAY more informative than what we have now.
But just as a clarification…
there is (should be) no difference between these two:
So it should use “disabled” as the state instead of “off”.
And how would you discern between the two?
“active” and “waiting” could be true at the same time.
Conditions that are part of the “condition:” block are never “waiting” to be true in an automation. they are checked instantaneously at trigger time.
The only conditions that wait to be true are “wait_for_x” conditions that are executed during the “action:” block.
As you mention, each action itself is typically run instantly so that state would happen so fast as to be useless to differentiate between your suggested “active” and “waiting”. All you would ever see in practice would be “waiting”. So I would eliminate “waiting” and just use “active”.
So my suggested updated list of states would be:
Disabled - automation has been manually disabled.
Idle - automation is waiting for a trigger to occur.
Active - actions are currently being executed (admittedly this would be a fleeting state unless there were many actions).
Failed - automation failed to complete due to an error.
I’m not sure, if this is really correct.
Also the provided list is not 100% correct:
an Automation can be in different states.
it could be disabled.
→ all other states are invalid.
it could be enabled - but the automation is off, or running
it could be enabled - and failed → but in this case: is it running? or is it off?
it could be enabled & running → but waiting
it could be enabled & idle
If you really want to get into such a level of detail and failure analysis, you would need to cover each possible situation an automation could be in.
You can try to keep it simple - but then the question would be: “what’s the benefit from this kind of information”?
But yes, the other parts from your statement seem to be correct
There are only two functional states the automation can be in - enabled or disabled.
HA has chosen to call these states ‘on’ or ‘off’.
As far as I know there is no distinction between being disabled “manually” or some other way. I’m not even sure there is any other way to disable an automation other than “manually”. The default when an automation is created is for it to be enabled so even then it would be manually disabled if you chose otherwise.
disabled IS the state. it doesn’t make sense to say that all other states are invalid.
It would be like saying a switch is “on” so all other states are invalid. What does that mean?
Right.
if it’s enabled but not running → idle. If it’s enabled and running → active.
But if it’s off it’s not enabled so the state would be disabled.
If the state is failed it means that the automation is enabled and idle but the last run failed.
But I also might kind of agree with you on this. Maybe make the failed/success status part of the attributes.
How long does the system take to turn on a switch? milliseconds?
If you make waiting a part of the state then you will never see the “active” state.
Just call an automation that is somewhere in the action portion as “active” or “running”. Just like we do with a script since there is no difference between the action part of an automation and the sequence portion of a script.
What you described (several types of commands, each command may take tens of seconds to complete, current command must finish before next command is allowed to execute) is handled by a queue; multiple consecutive commands should be queued for execution.
One can design a single script that can be used to perform any one of multiple commands and its script mode is set to mode: queued so that consecutive command requests are processed in the order they’re received. All of this is currently possible without the need for checking the current attribute (or for the addition of a running state).
All of these suggestions are all good, but none of them work for parallel automations, which is why current was used in the first place.
If you have 2 instances of your parallel automation that are running, what is the state of the automation? Current tells you exactly what you need to know, 2 are running.
My original suggestion was simply to have an extra “running” state. Personally I think other “states” like waiting, failed, are more akin to “statuses” and could be set in an attribute.
I would just like to point out, there is a difference between the states “off” (disabled), “on” (enabled), and “running”. For example, you might want to trigger an automation as soon as it is enabled, whcih would be a state change from “off” to “on”. Or you could have two alternate automations, such that disabling one, triggered the other to be enabled, and vice versa. This is not the same as the “running”
Off is “never run the automation”, on is “potentially run the automation”, and running is “the automation is running now”
Also, just pointing out that “current” is a very vague and ambiguous term. Does it mean “active” it would sense is “current” similar to “active” ? Or does it mean it is up-to-date ? That the state on or off accurately reflects the current state of the automation ?
If that isn’t convincing enough of an argument, would it not be nice to have a single bar in History which showed “On”, “Off” and “running” all together ?
A switch for example, has Unavailable, Off and On. - so Disabled, Enabled, Running, already has kind of a precedent.
But still, “running” could just be equivalent to current > 0. If you wanted to know how many instances were runnin, then you could look at the value of “current”.
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.
