Both traces come from the same device… the only difference is that I did renaming between 1 and 5. First, I renamed the names only. Then, yesterday when you mentioned the entity id, I renamed the ID…
Button 3 works as expected. But buttons 1 and 5 keep changing their names and calling the other (original) script… It is like if the entity ID was replaced with an UUID and different parts of the Database have the UUIDs out of sync… now… I do not know what I am talking about but it feels something like that…
Both of those traces show that both runs worked properly. the first 1 ran script.scenecontrol_livingroom_scene001, the second rand script.scenecontrol_livingroom_scene003.
There are no references to script.scenecontrol_livingroom_scene005 in the script.scenecontrol_livingroom_scene001 run.
Yes, but it’s not coming from this automation. I’m not sure how else to tell you that, but you keep focusing on that. It’s coming from another automation.
I learned several things yesterday/today… how to work with the traces, the meaning of the trace log, how to make my automation using the template to call a service…
You helped me a lot… Will dig through the other automatons and see if I can find the one racing for this… will also modify the other Automatons to use templates and I will let you know what I get to!!
Another question… is there any way to know what triggered the scene? that Automation is the only one that I see is being triggered.
If I press the button, it is the only one that says “Last triggered, 1 minute ago”.
Further more, if I disable that Automation, nothing happens… but if I enable it again and press button 5, scene 001 scrip gets executed…
Yes, that was the problem yesterday… and I renamed them… today they are the same…
I am trying two things now:
Full reboot… waiting on that…
Reading about the trace logs… trying to learn what the context id and parent_id mean and if I can recreate what triggered what… although by disabling the automation I proved that there is likely nothing else calling it…
After the reboot I will try again, and re-check the name/entity_ids
I have similar issues. When I change the entity_id of a script, then ‘action: script.new_entity_id’ often lags. Sometimes using ‘action: script: old_entity_id’ works for a while but then stops working and sometimes once that happens netiher ‘action: script.old_entity_id’ nor ‘action: script.new_entity_id’ works and I have to delete the lot and create new versions. This happens when calling scripts from other scripts or automations and also with things like action widgets on my Android devices.
The action for running a script is script.unique_id and not script.entity_id. If you define the script in YAML, the unique_id is set explicitly. If you define the script in the UI, the unique_id is the slugified name of the script when it is first created (and the entity_id is set the same way, and so the entity_id and unique_id will be the same initially).
If you later rename the script or change the entity_id, the unique_iddoes not change.
You can only change the unique_id in YAML; there is no method available to do it in the UI.
Ah okay. So how do I do that? I’ve tried adding ‘unique_id: xxxxx’ via the YAML mode of the script editor UI but it rejects it as "message malformed invalid extra key not allowed’.
Ah - so I go into the automations.yaml file and change the YAML key of the script there and then reload automations, do I?
When he says yaml, he means full yaml mode. Not “swap the UI to yaml”. So if you created this script in the UI at all, you are stuck with the unique_id you originally chose. You can delete and recreate your script if you really don’t like your unique_id, that’s the only way to change it if you use the UI.
Also, to be clear. This only impacts the script.xxx service. The entity_id does update and you can use the script.turn_on service and call the entity_id. Just keep in mind, this will call the script as non-blocking and the actions will essentially run in parallel to your automation. So if the script does things that are needed for the next action, that will stop working properly.
Well, in some cases I use scripts as functions to return the same data to multiple other scripts & automations so ‘script.turn_on’ isn’t much use there.
The ‘hidden’ unique ID is very non-intuitive. I know Home Assistant seems to be trying to shift to doing things via the UI, but you can still drop into YAML for scripts (thank heavens) and seeing ‘action: script.xxxx’ for entity ‘script.yyyy’ is going to confuse a lot of people.
If no way of changing the UID is provided via the UI, this really should be made clear in the documentation although frankly the documentation for a lot of other things in HA is also disjointed and incomplete. (PGA I suppose!)
that will still work if you provide a response_variable.
It’s because scripts back in the day were slug based in yaml and yaml doesn’t allow you to change the slug. So here we are many years later with the UI having to deal with code that keeps everything still working for people like me who’ve been here since day 1.
Yes, there does seem to be some inconsistencies as to how things are done which I had already assumed was the hoary old problem of backward compatibility.
On your other comment, I’m puzzled as how a script running in parallel can return a value to the script that turned it on. Does adding response_variable to a script.turn_on action serialize its invocation?
