I’m defining a long running automation that should do some work, wait for a week (delay), then do something more and finalize. I expect to have 14 instances of this automation running concurrently.
I was testing the automation by triggering it from a button. As part of the code, it increments a counter. I clicked until it reached 10, then it stopped incrementing. I looked in the traces of the automation, and while the traces are there, all nodes in the trace are white - not one step has seemingly been performed on the automation instances beyond the 10.
Is there an upper limit to how many concurrent instances that can run? If yes, can this upper limit be changed?
Haha, yeah, I know it’s not great but I actually hoped that the management of the tasks was optimized enough to let it lay dormant until the delay wakes up.
I guess I’ll have to find a different solution model…
As was already mentioned, long running automations are an anti-pattern that will just cause you problems. If you post more details I’m sure you can get some advice on a different way of modeling the automation and specifically its triggers.
To answer your question for posterity’s sake… the default limit for parallel execution instances is, in fact, 10. It’s configurable, though.
My limit for any automation is usually only 5 minutes. Maybe 10 or 15 for automations that aren’t important. And for critical automations I use a datetime trigger as the delay. A week is absolutely a no-go.
you might get away with it if you NEVER restart HA. But I wouldn’t even come close to using that by factors of 100.
Ok, just to recap so that I am sure I understand the takeaways:
The automation can be triggered in two ways and based on that have two flows: (1) by some arbitrary trigger (sensor etc) and also (2) a time trigger. If the automation is triggered by the former, flow 1 runs and the datetime is set to some date the future on the input_datetime. The automation will then be triggered at that time and flow 2 will run.
The second takeaway is that during the time between flow 1 and 2 there’s no active instance of the automation. Better for resource management and avoids any issues of max limit on delayed automations … plus more durable.