Hi there,
I was trying to be smart and make generic scripts that will do the same actions with different entities for me, following “Don’t repeat yourself!”.
For example in my snapcast configuration, when the stream that clients are currently playing goes silent, I want to mute them.
For this, I have an automation that is triggered by the stream switching to “idle” which checks all clients if they currently have this stream selected and mutes them if they do, by calling this script with the entity_id as a passed in variable snapclient_id :
In general this works with any client, but whenever more than one client was using the stream, and the script should be run for several clients, it only mutes the first client and fails on the others:
Yeah, I know it’s already running, I inteded it to be. But why is that a problem?
Is this a general limitation of homeassistant?
Can I not spare myself typing effort and redundancy like I planned?
Do I need to make specific scripts for each client?
What would be the best practice in a scenario like mine where I have a lot of scripts that I want to use for multiple entities and sometimes also at the same time.
I already tried to add in delays but this is not really feasible.
Be aware that that doesn’t always work.
This has always been a bit of a weakness with HA (IMO). It is virtually impossible to be programmatically aware of what HA is actually doing and when it is doing it and hence it is impossible to reliably code in that way.
I believe there are moves afoot to improve this, some of the foundation was laid down in (I think v108).
If pnbruckner reads this he might expand on this, but I’m not going to tag him…
Wait template doesn’t work for scripts very well, HA does not often change a script from off to on when its actually running, so you will still get that error using a wait template.
I’ve moved to using an input boolean, I name it the name of the script, and at the start of the script I turn on the boolean, and at the end I turn it off. Then in scripts calling it, I wait_template the input_boolean to be off. That seems to work reliably.
Yes, the current implementation of scripts (and the action part of automations, which uses the same implementation) is very limited. Work has been, and still is, in progress to make it more flexible. Hopefully before too long you’ll be able to invoke a script multiple times without having to worry about this current limitation.
E.g., you’ll be able to specify what should happen when a script that is running is called again. The options will be: error, ignore, legacy, parallel, queue, restart. You’ll also be able to specify when a script is run whether it should be run in the background or not – i.e., whether the script calling the other script as a service should wait for the “called” script to complete, or just start it off running and then continue on to its own next step. The main part of the new implementation (which is in homeassistant/helpers/script.py) is almost done (a couple of PR’s were committed and have been in production releases for a while, with one more minor update currently in the works), and the corresponding changes to the script component (homeassistant/components/script) have been mostly completed and will be submitted once the “helper” is done.
Regarding using a wait_template to check if a script has finished, yes, unfortunately that’s not necessarily fulproof. E.g., scripts without delays or waits do not change state. (The script in the OP has a delay of zero at the beginning, so that helps to solve that problem.) Also in previous releases there was a potentially not insignificant delay between when a script is called to the time its state was updated in the state machine (which is what the wait_template, of course, looks at.) I think, however, this issue has been mostly addressed recently. Lastly, even if a script is indeed not running and seen as such in a wait_template step, I don’t think there are any guarantess that by the time the next step in a script happens that would invoke the script, the script may not have been started some other way.
Hopefully all of these issues will also be solved with the new implementation. Certainly I had them all in mind while working on it.
doesnt feel right does it? Im never much of a hip-shooter, but not even being allowed an enthousiastic spontaneous tag makes this forum much less vivid, and friendly.
Tbh, I am not much of a hierarchy follower, and glad I live where I live… Always felt good the internet was a bit more self regulatory. Could dispense with the rules.
O well. still a great forum Found many solutions today. Raised a few more questions too …duh
Using @ in front of a person’s forum username will alert them. @paddy0174 EDIT: oh, I see what you did there. Woosh!
People tagging you and personal messaging you for help with integrations or installations you have little idea about or interest in isn’t a lot of fun. Think twice. Most of the people you would tag read most of the new messages anyway. If they want to help they will. Being tagged or personal messaged for help can be a bit demanding.
@paddy0174 (sorry I can only reply to one individual, so is this a spamming tag ?)
Regardless, I think it’s more about “this person is far too busy and important to be bothered with minions tagging them so stop doing it”
It’s generally bogus and unnecessary to remind people of simple manners, and if you continually abuse the privilege then I can always’ block you’
‘Most’ people worthy of tagging are very gracious and helpful anyway but I do try to avoid where possible. Klogg is referring to the time when Marius tagged someone and petro reprimanded him. Marius pointed out it was justified and continued the discussion he’d been having with said tagged person (petro had been recently promoted).
