Well I do most of my work in YAML these days as the UI is too limiting. It is very useful when creating something new to quickly sling together the framework you wish to use, but then fine tuning and templating etc means YAML.
I would therefore be interested to know how, as you say, the ‘service_id’ can be edited in YAML. Alias, description, entity_id, all these are available in and limited to YAML, but this secret ‘service_id’ that gets out of sync with the entity_id has never appeared in any YAML I have seen and which is basically the cause of the problem. Create a script and that ‘service_id’ is created behind the scenes and is the same as the entity_id. Later change the entity_id and wonder why you cannot call that script by the entity_id you so carefully just set. Because some methods use the service_id which you have never seen, so cannot know what it is and it cannot be edited.
If the service_id is required for backwards compatibility, I understand the need to keep it, but would just ask that it is made visible and available to be edited in some way so that deleting and recreating the script is not the only way around the conundrum of not being able to access a script by its obvious and visible entity_id.
You are using a particular meaning of YAML ‘mode’ which I understand, but is not a term I used.
Another term you mentioned is a ‘slug’. I understand that as a general term for something that has been ‘slugified’ (a function/filter I have used myself in YAML), but to what specifically are you referring? I thought you meant the entity_id, but are you in fact referring to the secret ‘service_id’ that I guess is also slugified?
Semantics aside, I still maintain this is a mess for most users. A secret id that is unavailable to view and/or edit but which can prevent normal operation. Simply renaming a script can create a situation where you are calling a script by its correct entity_id, yet it fails to run because “it cannot be found”, while being clearly visible - with that correct entity_id. This being because it is actually being called by the secret id of which the average user has no knowledge, nor ability to control. A situation created merely by the use of standard HA operations that should be expected to not produce faulty results.
Sorry, but this is indefensible.
HA is trying to move towards being more accessible for more people. This sort of mess is not helping that goal.
The service name does not update. This means, if you update your entity_id, your service will continue to work without needing to alter the service calls. E.g.
action: script.your_service_name
will continue to work.
The topic of this thread is just wrong, it mentions entity_id but it really means the service name. In all of home assistant, service names are immutable. This means they cannot change and there is no mechanism built into HA to address this. This is one of the main reasons this hasn’t changed. Secondly, it’s unlikely to change because the only integration that would make use of this “changing service name” is the script integration because it’s the only integration that creates dynamic services.
The only way to edit the service name is to edit the slug, in the example above it’s script_1. It takes 5 seconds, literally 5 seconds to open your scripts.yaml file and change that name followed by a restart. Your service name (NOT ENTITY_ID) will properly update. This is all doable from within home assistant through the file editor app or the vscode app.
Last but not least, changing this functionality to allow the user to adjust the slug from the UI would be a breaking change. We would need to make the script section a list, not a dictionary. And the slug would need to be an additional property like it is for automation. It’s unfortunate that this is something that is holding scripts back, but you need to understand that the integration is literally the oldest integration in HA and any changes will cause massive problems for all users. Meaning, changes should be avoided unless it’s absolutely necessary. And sorry, but this is not an “absolutely necessary” situation.
With all that being said, you have the power to rename things. You and many others just aren’t understanding the difference between an entity_id (which references entities), and the service name (which references services). Scripts is the only integration that dynamically creates both so there’s no “inconsistency” that exists with other integrations.
Well thank you for your kind words, but you are wrong. Since this secret ID is not mentioned anywhere in any docs I came across prior to discovering its existence in this thread, the idea that I did not “understand the difference” is a logical fallacy.
Secondly, now I am aware of its existence (for which I thank you), I understand the difference. We’re not all dumbasses Petro.
Anyway, my point is that it is indefensible that normal operations within the HA UI, like Copy and Duplicate, to produce new versions of something, a Script in this case and to which one then applies the desired entity_id can then be INACCESSIBLE by that entity_id. Any attempt to execute that Script (from another script or automation) results in a “cannot be found” error, because as I have now discovered there is this secret ID that is involved and if HA manages to create its own inability to operate as it should, that is commonly known as a bug.
Clearly it seems that you can justify in your mind that this is all perfectly acceptable. However the fact is that standard built-in HA operations can result in something that simply does not work, for no visible reason and that my friend is indeed indefensible.
Fortunately, I am now aware of the existence of this secret id and certainly do understand the difference between that and the entity_id. All of which means I can deal with any future reoccurrence of the problem and nothing is to be gained by any further discussion so as far as I’m concerned, the matter is now closed.
There’s even mention in the documentation lower that covers calling the script directly using script.NAME or using script.turn_on.
That is not true. Again use the script.turn_on service targeting the entity_id.
There are 2 ways to call a script. Using script.turn_on and using the service name which you still keep calling the entity_id.
Then please, refer to the service name as the service name and not the entity_id.
action: script.your_script #<--- this is the service name.
action: script.turn_on
target:
entity_id: script.your_script #<--- this is the entity_id.
if you change the entity_id, your service name does not update, but your entity_id will. For example, if you changed the entity_id to service.my_script, the example above would be:
action: script.your_script #<--- this is the service name.
action: script.turn_on
target:
entity_id: script.my_script #<--- this is the entity_id.
Notice how you can run the script using the entity_id with the new name?
