I use Home Assistant and their automations (essentially macros) have a concept of 'run modes'
I love semaphores.. but I honestly think that having KM macros simply handle the semaphore logic for us would add a level of power / ease / simplicity that would be fantastic
The modes that HA uses are:
mode
description
single
(Default) Do not start a new run. Issue a warning.
restart
Start a new run after first stopping the previous run. The automation only restarts if the conditions are met.
queued
Start a new run after all previous runs complete. Runs are guaranteed to execute in the order they were queued. Note that subsequent queued automations will only join the queue if any conditions it may have are met at the time it is triggered.
parallel
Start a new, independent run in parallel with previous runs.
Obviously, for KM the defaults / options would be different (for example parallel would probably be the default), but the modes themselves are actually quite nice.
As for your fourth mode, "parallel", that is precisely what KM does for a macro if you don't have a Semaphore Lock action in the macro. And as you state, this is what you believe would be the default for KM. Indeed, it is the default, as that's how KM works right now.
As for your third mode, "queued", that is precisely what KM does if you start your macro with a Semaphore Lock action. I.e., the new instance of the macro will "wait" for the first instance to complete. However, I'm not sure if "runs are guaranteed to execute in the order that they were queued." I'm not sure why this condition matters, since each copy of the macro is identical. Even if the order was not guaranteed, it seems irrelevant since each instance does exactly the same thing. If you can explain why this matters -- I would appreciate knowing. Why would order matter, since each copy is identical?
As for your first mode, "single," this is precisely what KM does if you have a Semaphore Lock action at the start of your macro with the following options. Approximately 25% of my macros do this, I would estimate. I was so happy when KM introduced this action! It has made my life so much easier.
As for your second mode, "restart", that depends what you mean by "after stopping the previous run." If you mean after it stops naturally on its own, then that's what you get if you set the semaphore lock values to "this action will timeout after 99 hours." But if you mean "the Engine immediately cancels the existing macro", then that's another thing. I believe it can be done as described in the following post. I agree, that method is slightly messy. Perhaps KM could add this feature more natively, but if you want direct support for it added, you should probably provide a specific situation that you want to resolve. I have never needed this feature. I think it's a perfectly valid feature to request, and I imagine it could be added by a flag at the top of each macro.
Actually, now that you mention this, I have always lamented that the Semaphore Lock action does not have a way to not have to specify a string/name. I'm usually annoyed when I have to come up with a unique string. (Often I type a random string of digits.) I think it would be great if you could leave this field blank (or remove the field) and it would come up with its own unique string that you don't have to see.
I am concerned about restart as that involves canceling the macro part way through and could easily result in very confused state. But probably for a lot of macros it could work safely enough.
That's an excellent question, I really don't know. I might do some testing with Home Assistant and see how they accomplish it.
One thing they have is the idea of 'scripts' which are basically the same as automations except for a couple key differences:
They don't have 'triggers' (they can only be called)
They have input / output (automations do not).
A scenario that baffles me is this
I have Automation A that calls Script A (let's say it's a script that takes a minute with a mode of 'restart')
Then I have Automation B that calls Script A.. what happens to Automation A?
I'll have to do some testing and see what they do.
But, if people are setting up their macros that way themselves, with their own Semaphores, .. well. they should have the same issues.
Yes, but in that case, they know what will happen because Semaphores have a defined behaviour.
In your example, if there was a Semaphore Lock at the start of Script A, then when Automation B called it, the script would wait until Automation B’s call of the script finished (perhaps timing out depending on the Semaphore Lock’s settings).
In the implicit case, that could also be what happens. It is possible the modes could be implemented with implicit Semaphore Lock’s, perhaps as simple as based off the UUID of the macro, which would handle the single (immediately timeout), queued (wait), parallel (no lock). The restart again is problematic.
But I guess perhaps I add a new mode for Semaphore Lock which cancels the macro with the existing lock. That is probably pretty straight forward.
I still don't particularly like the canceling of the macro, because in general canceling a macro from an external method can leave state (eg variable values) in a confused way, or can break other invariants (such as counting something). But probably that is something that will not really happen all that often.
I agree. In reality cancelling and restarting a macro is not common, but when it is needed, it's awesome to have that capability. In all of my HA Automations, cancellations are harmless, such as timers that get reset, or if I'm in a loop that is no longer necessary or relevant, or automations that are doing one thing, but need to change to do something else.
I think, in (my own personal ) order of 'usefulness' and simplicity, macros have the following 'modes':
Parallel (current and default)
No change here, but it's nice to still have this as a macro mode so it's explicit when people write their macro that "hey.. you call this a lot, it will run a lot'
Single (close second in terms of usefulness)
if one is running, any subsequent calls get ignored as long as the single instance is running, parallels runs of this macro won't be better or helpful and might even be harmful
These are distant 3rd and 4th, but I would find them interesting
Queue (with max # of queued items)
This might not be strictly necessary, and won't often be used, but maybe for things like counters, etc.. it might be nice to have this.
Cancel and Restart (where-ever this macro is at in it's execution, cancel it, and start over from the top (with new trigger / input if that's what's given).
