What is the purpose of automation ID? Does it work any more or do we only have alias for naming?


I have a bunch of automations that are defined with both ID and alias as per below.

- id: calculate_coronavirus_delta_today
  alias: "Calculate Change in Coronavirus Cases Today"

My assumption was that ID would give it the entity name and alias would give it the friendly name… But it appears it’s turning the alias into the entity name, which makes me wonder what the purpose of the ID is… Does anyone know?

If it serves no purpose, is there a way to define the exact entity ID you want to use for your automation and separately give it a friendly name (for example what’s shown in the logbook)?

1 Like

The ID is only needed if you want to be able to edit the automation in the UI editor. AFAIK there’s no way to define the entity ID as anything other than the alias.

1 Like

I find it “unusual” as well, to say the least. :wink: And I do not understand the intention behind. It is more than annoying, and gives a lot of possibilities for errors. And in my opinion it contradicts the idea to have automations setup and edited by the UI.

Automation like other domains in Home Assistant have entity ids, id on an automation is typically automatically generated. Having the ability to set the id is an override in my mind and rarely used. It does have a use, I do refer to the entity id of automations for the purposes of turning off or on an automation from automations and scripts. And in the past (this probably will not change again) how automatic entities ids were generated was changed and my references to the automation’s id broke and this is where I used id as an override.

Did you read my response above? The id is used for the UI automation editor. If you’re manually creating automations, there’s no need to manually add an ID unless you wanted them to also be editable in the UI for some reason. Otherwise the system simply generates a random id when you use the UI editor.


Yes, I know. What frustrates me is the fact, that an id normally (and for what I know also everywhere in HA) is used to uniquely identify something. With this id implementation it is exactly the opposite.

In my case I don’t like it, because it contradicts every effort to use automations in a non-english language. I want to name and adress my automations in english, as I use english internally, but the UI and everything there is in german… So to call an automation, with this implementation I have to use the german name, despite everywhere else I can use the id and have a friendly (german) name in the UI…

I want to be able to write my automations in yaml, as this is way easier for me. On the other hand it is simply practical, if one (wife, me from the mobile) can edit an automation via the UI.

My second problem with it is the possibility for escaping errors. The name should be explanatory, so you know what to find in a particular automation. The longer the name, and the more spaces it has, the more possibility for errors is given. This could be avoided, if the system with id and friendly_name would be used here as well. I could name my automation like phone_delete_missed_call_notification and the friendly_name Delete missed call message after 24h. See what I mean? :slight_smile:

I simply find it not consistent, compared to the whole other system and it’s use of ids.

1 Like

Is it a problem to define them as the exact same thing like here?

  - id: notification_turn_off_trash_input_boolean
    alias: notification_turn_off_trash_input_boolean

Not sure how it’s the opposite since the ID does uniquely identify it, but I understand your issue with not being able to have the automation entity ID and friendly name in different languages.

1 Like

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 :wink:. 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).


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 : -

  1. How to switch on lights at sunset
  2. How to switch on the coffee maker at 07:20
  3. 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.