How do you define/rename your devices/entities?
I’m looking for a good template that I can apply to all my devices/entities 
Thanks
2 Likes
I keep entity names as short as possible, containing just enough to understand their purpose. I don’t stuff lots of meta-data into the entity’s name. If I need to add meta-data, I use custom attributes because it’s not only neater but easier to reference when using a Jinja2 template. For more information see this post:
3 Likes
I also try to keep it as simple as possible:
What_where_who
E.g.
binary_sensor.motion_office
sensor.battery_remote_office
device_tracker.presence_phone_dimitri
In the end of the day, you are the one working with them and the system must work for you.
8 Likes
I concur with as simple as possible. I use the auto-entries card for most of my lovelace so I name things in a way that I can easily group them.
I have come up with a naming scheme where the first part of the name is the room and the second part of the name is the device since this makes it easy for my family to work out the name of the thing they want to control from Alexa e.g. “Hall Light”, “Bedroom TV”, “Lounge Fan”, “Kitchen Temperature” (I have ocasionally deviated from this with certain unique items like “Christmas Tree” where the prefix is not needed).
In cases where I have multiple devices in a room then I have used a numerical suffix e.g. “Bedroom Lamp 1” and “Bedroom Lamp 2”, I have also created an assoicated light group “Bedroom Lamps” so either lamp or both lamps can be controlled with a single command.
In some situations where I have devices that can be re-purposed (mostly smart plugs) then I have used a generic Entity Name e.g. “sonoff01”, “sonoff02” etc. but the Friendly Name follows the convention above and can be easily renamed. The theory is that this might reduce the need to edit config as things are inevitably moved around.
7 Likes
I’m about to do my 4th refactoring of Home Assistant and each time I’ve changed naming conventions. What I’ve noticed is that automations are much more in use than manual control.
Import names:
Whenever I have devices integrated, could be Hue, Z2M or whatever… I keep a descriptive name in their current applications. This is so I can configure devices there and know what I’m doing. This name will often be carried over to HA - however can be changed as devices are not linked to their integration by Friendly Name or Entity_ID. (I wish there was an easy way to see the real link-connector, maybe an add-on exist?)
Names in UI
If I use a single entity I try to create a name that is descriptive for their area they are in. So if ZigBee2MQTT gives me Living Room - Floor Lamp, I then rename it in HA as with Friendly Name:
- Floor Lamp
If I combine entities such as Kitchen - Window Lamp Left and Kitchen - Window Lamp Right, I try to create a group or equivalent and give it Friendly Name:
- Kitchen - Window Lamps
I then use areas, to sort them in the entity list. Otherwise I don’t use areas at all…
Entity_ID
In this case I try to have somewhat generic names that include a combination of
- type, area, location, device, no
I do this, since external applications such as InfluxDB or NodeRed doesn’t really carry over anything else than the entity_id. So when I use them there, I don’t want to go back and forth between apps to find them. For example:
- light.kitchen_bench_2
- sensor.kitchen_doorsensor_dining_table
Maybe…
I’m currently contemplating if it is possible to create static aliases for automations and then connect the entity_id to that alias. This would allow me to have more flexibility for external apps with databases and automations.
2 Likes
Thanks everybody for all those nice recommendations.
Now, if HA could be more dynamic when changing names 
I’ve given up on that. So far all the “smart” and “dynamic” stuff has basically screwed up things for me.
I build everything up on entity_id and maintain them as fixed as possible. In some cases I even used virtual devices (like a clone or group) for automations.
Areas and Friendly Names can change as much as they want. No automation or integration use this in my setup.
The larger my device list gets, the more this becomes important.
I’m leaning towards this model though.
But I’m still having a hard time reconciling this vs the actual name and areas. Especially since I put everything from Home Assistant into HomeKit.
[dommain].[brand]_[item]_[item info]_[location]
example:
binary_sensor.ring_lock_tamper_detector_attic_door
binary_sensor.ring_contact_sensor_tamper_detector_attic_door
1 Like
Personally I don’t use brand names in the entity name for a simple reason, if I ever need to change the device and it will be from a different brand, I need to change all automations, sensors, etc. that use this entity. In addition I don’t see any use case for having the brand name in the entity name.
However, as I said already, in the end of the day, you are the one worling with it, so it must fit your way of thinking.
3 Likes
That’s a good point…
How do you solve for multiple devices with the same type of entity in the same location.
For example, having a camera, multi sensor and motion detector all in the same room, all reporting motion as a binary entity?
I don’t have multiple devices with the same entity type for a specific area. I would probably try to describe the location in more detail, e.g. motion_livingroom_front_door.
Shall we create a GitHub documentation on a possible standard to follow for beginners.
I, as a beginner, really would like to have a standard to follow because right now I added a lot of devices and now I have to waste a lot of time renaming it all.
Do you think it is possible?
There is someone that wants to help me create a naming convention wiki repo? As a starting point, then everybody is free to use what they want. But as in writing code tyou can freely decide to use semver standard to have a version for your software or invent yours (I use the semver personaly).
@Burningstone @chansearrington @MDSDM @Ecard @Jonah1970 @GlennHA @123
Thank you all
What did you do when you have a light attached to a switch entity? For example I have a switch in my garage that is attached to my garden light. this should be light.spotlight_garden or switch.spotlight_garden?
Forgot that, but mine isnt a demand, just a kind proposal to the topic partecipants 
I get the point anyway
I, over time, change my standard naming conventions mainly due to my use of Zigbee2MQTT and Zwave2MQTT. So, for my entities they are ‘usually’ started with the location (area) then a more specific location description then what it is.
Example: MBath-Sink_Light (capitalization for readability)
Unfortunately due to the way some integrations assign the entities, you can not always chose between switch and light.
I usually simplify the name: MBath Sink, since I group all my lights on a single page and all my ‘power’ on a different page.
For my Node Red generated entities I add a “nr” to the beginning of them. I do this since most of my integrations add something to the entity denoted the source. Examples being “wf” for WeatherFlow, “octoprint” for OctoPrint, “genmon” for Generator Monitor.
I like to review what others do, and do occasionally see that there is a better convention and I make changes.
I don’t like the term “Standard” for use here, since the HA devs are the only ones that can actually set Standards. The best we can offer is recommendations, or best practices.
Some other reasons I chose my naming conventions is to just make it work with an integration or a card. Not the perfect example, but for the Mushroom Light card, I ‘force’ many more things other than ‘lights’ (I have my reasons).
Hi Glenn, thank you for ur answer. I know its not a standard but Id like to reach something like a Standard that can accomode a lot of integration without changing too much, thats why yesterday I make this repo so I can listen for different feedback and try to adapt it with new stuff.
For example your mushroom nam. convention, Id like to know how you did it, if you wanna share so I can integrate in the document 
1 Like
Do you somehow handle when you move the thing, but want to preserve the history in the original location?
Let’s say I have electric plug with consumption meter. It’s called livingroom_plug_consumption. I buy a new one, the old one died or I will move it to different location for some reason. But all the history, accumulated history will stay with the device, not identificator. So it will look like that my lamp had high consumption a week ago, because it was in kitchen powering a fridge.
A can only think about creating a helper as an alias for the entity, but that will be hard to maintain and will end up with so many values.
Did you try to achieve something similar or don’t care about that?