Simultaneously running multiple instances of the same script

Whoops…I’ll correct my original post.

Additionally, my understanding was that like scripts, an automation will fire, go through conditions (and either flunk out or get to the action)
If there’s a delay it will sit in the delay BUT if it fires again (and passes the conditions) it will bypass the delay again. Have you tested for that here ?

In the automations I was concerned with, I didn’t have any delays. So that could be the case, but I don’t encounter it.

Ah I see, the state machine sees the state change in the automation (from its trigger) and you use that as a trigger elsewhere AND you can pass data too
That would be useful in templates to determine specific actions

But I thought the point was the lack of simultaneity in scripts because of delays ?

For me it was because of an automation that got triggered by multiple triggers at the same time, or close to the same time. That automation then called a script that would only get executed once because the second (and subsequent) calls would just not happen because it was already running.

I’m confused.
I think I’ll leave this a Re read it tomorrow.
Simultaneous scripts should only happen in simultaneous triggers (highly unlikely in the real world) OR because they were time related (and co-incidence struck) OR (most likely) because of delays
I shall sleep, think and return (hopefully in that order :crazy_face:)
Thanks again

@SteveDinn A clever idea…

@Mutt I’m not sure if this going to make it clearer or make it more confused but the case I can think of is where you have a centralised process (e.g. and I think quite commonly, a notification ‘engine’) and several unconnected events all fire seperate and different notifications at (about) the same time.

The ‘engine’ will not work properly if it is using scripts. At best, it will just not notify second and subsequent times because the scripts are already running, at worst it will get itself in a right mess if the engine is more complex than just one script and it branches off into several other ‘reusable’ scripts.

I’ve just got up so my thinking may still be a bit cloudy :slight_smile:

I think I got up 10 mins after you :stuck_out_tongue_winking_eye:

That makes more sense to me.
(Steve, sorry but I couldn’t see where this was applicable, but now a light begins to dawn)
I’ve seen people that need to micromanage things and have notifications going off for the dog yawning.
In such situations half a dozen messages could get fired whenever the tracker platform decides to update, and now 4 people are now ‘away’
I don’t think I’ll use it. but it’s a good arrow to have in my quiver for emergencies (so tommorow then :crazy_face:)

Ha! Ha! Yes.
I encountered this problem very early on in my life with HA. I had a greeting whenever anyone came home but if two people came home at the same time it all broke. That set me on a quest to make a notification system that was robust and flexible. It ended up becoming more of an intellectual exercise and a way to learn more about HA than a useful setup.

And in any case that particular announcement drove my wife mad so it soon went. To be fair it was annoying, we know when we are home, we don’t need to be told; and we don’t live in a castle, we can hear when someone else comes through the front door!

Now we only have a morning greeting at breakfast time and a few other important* announcements.

*I use the term loosely. We managed quite well without them before HA!

Well at least it informs you it’s morning :crazy_face:

I have an infra-red-controlled mini-split heat pump that I have made into a “thermostat” in HA. Coming from a programming background, I like to separate my logic from my data. The data is separate for the two indoor heat pumps: They each have their own temperature sensors, modes, and set points. But the logic is exactly the same. They turn on or off when the temperature moves in and out of the ‘comfort range’. I don’t want to have two (or more) of the same set of automations (and scripts) for two heat pumps when they’re effectively identical.

What I typically end up doing is naming the sensor, binary_sensor and input_[number, text, select] fields similarly so I can identify which heat pump has triggered the change based on the entity name. Here’s an example:


  - alias: heatpump_status_changed
    description: Updates the status and starts the timer when the command changes

      - platform: state
        entity_id: input_text.livingroom_heatpump_command
      - platform: state
        entity_id: input_text.recroom_heatpump_command

      - event: climate_status
          area: >
            {# this gets either 'livingroom' or 'recroom' #}
            {%- set area = trigger.entity_id.split('.')[1].split('_')[0] -%}
            {{ area }}

      - service: timer.start
          entity_id: >
            {%- set area = trigger.entity_id.split('.')[1].split('_')[0] -%}
            timer.{{ area }}_heatpump_command

I have a bunch of automations like that. Depending on sensor values, or when I reduce the temperature on both heat pumps for the night, they can get triggered pretty much simultaneously. When I was using scripts (imagine the event action above was instead a script call), I had problems with one heatpump not responding sometimes because the script couldn’t run twice simultaneously.

Using the event-triggered automations instead of scripts, I have no more such problems.

Yep that works for me too.
I guess I didn’t every have models like that needing solutions and previous programming languages have been a touch more flexible.
Thanks again

Thanks for this thread, I had not realized that a script can only run a single instance at a time and was trying to do a very similar thing to you, I have 5 heat pumps I’m trying to automate independently without a bunch of duplicative automation code. Honestly, I’m not clear on the value of scripts if they can’t work in a scenario where they can be leveraged this way.

I tend to agree!

@SteveDinn thanks for the workaround using custom events to handle multiple execution. It’s amazingly lame that scripts are limited to one call at a time until finished executing.

I got tired of my “chime + tts” script reporting errors that it was already running if someone closed a door right after opening it. The script plays a chime sound, then does a delay to allow the sound to finish, then does the tts. If the door closes before the initial chime delay elapses then I never hear the “door closed” TTS. I changed it to a custom event automation based on your example and it works great…always aborts the playing announcement and plays the last one in full. I wish I could avoid the delay by detecting when the chime sound finishes playing, or at least dynamically set the delay based on the chime length (it varies depending on selected chime file).I’d also like to find a way to queue up multiple “chime + tts” when the trigger is not the same, but go ahead and play immediately if the trigger is the same was what is currently playing.

This will be changing in the near future. There’s a PR currently in the works to change the behavior of scripts so that you can run the same script in parallel.

@ptero, that’s great! I’m glad that is finally getting addressed.

That would be a big change. That limitation is what originally led me to explore AppDaemon, which solved the problem for me, but it’s not an end-user solution for most. Building a generic script with parameters that can have multiple instances running simultaneously would be great.

There is definitely a cause for both allowing and disallowing multiple instances simultaneously. I hope they have a script config option for this. Personally, I was fine with my workaround for multiple simultaneous instances using events.