Not at all, it could even be a series of numbers if you want like the system generates (as long as it’s in quotes). Again though, you don’t need an ID for manual automations.
1 Like
Thanks, I just wanted to make sure they wouldn’t clash somewhere in the system because they had the same name. TBH I’ve never even played with the automation editor so I have no idea what that ID is really doing even after you described it 
. I just want to make sure I can find and call my automations as needed.
In order for Automations to be editable at Configuration > Automations they need an ID. If you don’t plan on using that UI editor you don’t need to define an ID. Any automations that don’t have an ID will have an icon next to them at Configuration > Automations that looks like a pencil with a slash through it (meaning not editable).
2 Likes
Well, I always like to keep my options open, so I will just copy paste the alias name to the id in case the editor ever comes in handy. Thanks for filling me in.
If you have seen the “future of yaml” thread you will see this is a hotly contested issue.
There have been arguments back and forth but many devs have said that automations and scripts will always be available as yaml.
I think that is probably true because no matter how good the gui editor gets they will never be able to replicate the flexibility of a nicely written template.
So the gui editor is there to assist newbies write simple automations : -
- How to switch on lights at sunset
- How to switch on the coffee maker at 07:20
- How to turn the lights down when the TV switches on, etc.
As they develop and need more control they will move away from the gui editor to experiment with templates (as you are doing) so I think it already very unlikely that you will ever need the id:
Not sure about Paddy and Tediore ‘s case about having a’ name’ for an automation in another language (I do think a name is a good idea regardless) but why should you ever need to see this. If you have to interact with your automations then you haven’t yet perfected it. Call it something hierarchical and unique then forget about it.
I think it’s unlikely I will ever need it too, but it’s so little work to copy paste something once that it’s worth doing just for the peace of mind that it’s there if I ever need it. I do try to where possible keep the option open of using the GUI in the future even though I don’t really plan to (I’m the first comment in “the future of YAML” thread ;-)). You never know what changes will happen that force you to move over in the future, and I’d rather not do all that work all at once.
You can change the friendly name to not use the alias name by using the various customize options.
Depending on how you write your automations (UI editor or yaml) you can change it thru the ui or you can manually edit your homeassistant:->customize: section of configuration.yaml.
1 Like
Yeah that’s true, but it’s a lot of extra work to do that for all the automations, so I don’t know that I’ll go to the hassle.
Tomaato Tomarto.
I don’t see this as different to what you are doing
You are using a decent multi tab editor aren’t you ?
Well, it’s going into another file and inserting the entity name and then the customize option for each item, rather than just going down one line and typing two letters and pasting in the same thing from the line above… Or even worse with the UI, but I’d never consider that. And yes, I use a decent multitab editor… But I don’t want to jump over to another file every time I create an automation, I just want to copy paste a template and set the name and do the automation. I know, I’m lazy… The friendly name is nice to have, but not worth the extra work… For some things it is, but not for automations.
Okay, then you could use packages and then keep it all in the one file, admittedly under two different headings but still the same file.
It’s a personal preference choice. I don’t use either but …
Yeah, someday I might go to packages… As you can see, I’m adverse to having a lot of files to manage, so for now I’m okay with just splitting out things from the main config into a new file when they get too big.
I find packages convienient.
I write a package for one room, copy it for ALL the other rooms, do a search and replace on specific strings and voila all the rooms are done.
Subsequent edits are a tad more tricky but I still copy the new working code and just update that bit.
Also when I’m having problems with “this” automation I just go to “this” package (a much smaller file)
so for example I know that my input_boolean.ib_light_bed4_timer_enable is in the lightbed4 package as is my script.sc_light_bed4_timer and input_number.in_light_bed4_timer
As the lighting levels are common to multiple rooms then the input_number.in_aalight_bed4_lvl is in aalight package
The naming ensure traceability and they are easy to find in lists as they turn up alphabetically
1 Like
Yeah they have a lot of advantages, especially as configurations get larger. I have a feeling I will someday end up on them, but for now I am quite efficient on my current structure as I can still remember more or less exactly where everything is in each file just based on the chronology of when i built it.
I think some time ago the entities were called by id, and at some point it was changed and they were called by their aliases.
Took me at least half a year to debug this, but hopefully my configuration will work now 
If you’ve split your config out from automations.yaml then you also can’t edit from the UI even if you have id: defined. I find it bizarre that automation entity_id’s are generated from alias and scripts generated from id! 
Surely this need’s to be standardised?
I’ve only just noticed this as most of my automations have same alias as id, however, for the exceptions I thought something was broken this morning! 
2 Likes
was this ever raised as a feature request or something?
I find it really confusing - especially as if you first create the automation and then change the alias,
the entity_id does no longer change, but stays the same as initial one …
Can be really confusing if you have old automation and cannot guess any longer where their entity_id is coming from
I find confusing too the fact that friendly name (possibly localized) for automations come from alias and also a programming identifier as entity_id come from alias. If I want use longer, localized display name for automation I need to add a customize section in source file, elsewhere, far from where the automation is defined. Very error-prone and difficult to maintain. Hope something changes.
2 Likes
Should this answer perhaps be updated to say that the ID isn’t only to allow editing, but it also enable traces for debugging?
This is not 100% correct, i set an ID but it is still not editable in the UI because i do not use the automations.yaml but seperate files for my automations and include them.