Entity naming conventions

Configuration
1

Is there a recommended guideline? I appreciate flexibility, but a starting point would be great. Having a concise structure helps a lot when programming. Below are some thoughts I would like to get more input on.

Even though I prefer English as “computer/programming language”, front-ends (e.g. HADashboard on tablets) in my home feels more natural in my local language. Hence, at some point (entity name or display), the name will be in localized. I think using local language for entity names would be good, as there will be a one-to-one mapping between entity name and display name, but there seems to be trouble using international characters. Is this intended, and is there any way to fix this?

Also, I think location should be a part of the metadata for an entity. Otherwise, it is hard to distinguish e.g. different motion sensors. However, maybe this should be in a property separate from entity name, so that it is possible to use it in different scenarios. So far, I have been using <room name abbreviation>_<type>_[extra for distinguishing if several types], e.g. ktc_light_dinnertable.

All of this seemed to be of no point, however, when I did not find out how to rename the Sonos entities. Isn’t it possible to configure all entity names, just for specific platforms?

To summarize, I would like a guideline specifying

  1. Entity name structure recommendation
  2. Language restrictions
  3. Metadata encoded in name
  4. Which entity names can be configured
2

I’m mostly using room_function, now at least. Some of the earliest entities are less coherently named.

I don’t think you’ll find any formal guideline, since it’s very personal, and any discovered entities can’t be renamed. I’d recommend:

  1. room or room_extra - eg for a kitchen where there’s only going to be one light, it just becomes light.kitchen. For a kitchen with multiple lights it might be light.kitchen_main and light.kitchen_counter`. Remember the entity type is already there, so generally I’d suggest you don’t duplicate that.
  2. Lower case, and assume ASCII (7 bit clean) only. I don’t know if there’s unicode support.
  3. Apply the KISS principle - keep it simple. Only use enough to distinguish it.
  4. Only entities that aren’t auto discovered - eg Chromecasts
1 Like
3

Good point about the component being a part of the name!

Another thing I just found is entity_namespace, which might at least improve the differencing between location and name.

4

One issue might be that at least Z-wave devices have entities in different components. E.g. a lock named entrance will get lock.entrance which is good, but also zwave.entrance which does not explain enough. Furthermore, a light in the same room will get light.entrance, but collide with zwave.entrance.

5

The zwave entities are for the Z-Wave node, for management of the node itself. There’s never going to be any collision, because there will (normally) also be a light, switch, sensor, and/or binary_sensor node that you’ll use to interact with. The only time you’d use the zwave entity directly would be for devices that send Scene or Central Scene messages.

Don’t over think this. There’s no rigid structure to use here. Find something that works for you, and accept that you can’t force it.

6

If I rename my zwave device as you suggested, there will be a crash as soon as I have more than one device in a room - because the zwave part of the lock, light, and sensor will all be named zwave.<room>. Thus, I think it should be <room>_<type>_[extra], even though that would mean redundant types as in light.kitchen_light.