Specifying configuration manually in configuration.yaml

Configuration
1

The way I would expect configuration to work is that there is some device_id that is the same everytime Home Assistant starts, even after a new install (e.g. based on some hardware identifier) and that one can bind this identifier to a human readable name for example “my_switch”, such that if it is a switch one can then refer to it as “switch.my_switch”, but Home Assistant seems to even have made such an extremely basic definition overly complicated.

For example, one entity_id currently is switch.tz3000_kdi2o9m7_ts011f_704901fe_on_off. At the same time I see that "using entity_ids are “deprecated” in various places on the WWW.

I have a list of times when I want to have a group of switches enabled on as such I just want to have a group of binary switches, AFAIK, but I really would have to be able to define the basics first.

(I don’t want to use the UI for anything, but displaying the state.)

The documentation is not comprehensible. I see lots of examples isomorphic to:

# Example configuration entry
binary_sensor:
  - platform: homeassistant
    id: muted
    entity_id: media_player.mega_speakers
    attribute: is_volume_muted

, but I don’t have such nice names as media_player.mega_speakers. Is that just because the example is wrong, or is there some other place in which the mapping between a device_id and an entity_id is made?

EDIT: Based on Entity_id - how do you find it?, I conclude the documentation is just extremely misleading.

2

Not sure where you’re seeing that, other than maybe written by people who don’t actually know HA at all.

There are no binary switches. There are binary sensors, and switches, but not binary switches.

Which documentation?

That’s from their system. You can change many entity_id entries, or just use what the integration provides.

3

That’s using the UI. I specifically said without the UI.

4

That name appears to be something generated automatically by an integration. Which integration are you using for that switch?

There are certain properties of an entity that can be customized manually in configuration.yaml and they are listed here: Customizing Entities. However, in the list of things that can be modified, the entity_id option is not listed so it can’t be changed that way. Therefore you must use the UI to do it.

5

It completely depends on the integration.

some entity_ids are based on the user defined config of the entity - as in automations, scripts, legacy templates, etc. Those can be modified in yaml (or in many cases also in the UI)

others are created automatically by the integration and can only be modified in the UI. Or possibly in the .storage files manually but those files aren’t meant to be user edited.

6

How do I give a unique id to a defined automation using configuration.yaml? The documentation, again, is terrible.

The reason I want to do that, is because the UI tells me I need to define those, but it doesn’t just spit out the code to do so, which is as anti-user as it can get from a UI experience perspective.

I did define an automation, however. Just not the one I want, yet.

7

Changing the entity ID outside of the UI isn’t supported.

Good news, you can help improve it, rather than simply complaining about it.

You define an id, as covered here.

8

in the automation yaml config just add:

id: kjygfkblkinljo

so something like:

- alias: my automation
  id: my_automation
  trigger:
    etc....

the id can be anything as long as it’s unique.

the thing I see might be that you are now defining a yaml configured automation in two places - one when it is created by using the slugified alias and then later when you change it using the UI.

I just tend to create the alias to what I want to see as the friendly name and I know the entity_id will match it.

otherwise if I need to search for it later I need to remember what I renamed the entity_id in the UI.

9

Even though, you were first (and I used your solution), I marked the other one.

The problem is really in the software not pointing at the right documentation in the case of an automation. IMHO, such documentation should also be part of the application, not external (e.g. on some website, because it creates an unnecessary dependency).

10

The problem might not be the documentation. For example, assigning an id field to an automation is described in the example in the YAML section for automations. Changing an entity’s options is described in the link posted above.

The documentation is created by the community. If you believe it should be improved, feel free to volunteer your time to do it. At the bottom of each page there’s a link to edit the page. Full instructions for modifying documentation can be found here:

1 Like
11

You can lead a horse to water but you can’t make him drink.