The biggest favour you can do yourself is to rename entities to a functional name when you add new devices.
Let’s say if you’ve added a new device, such as a smart switch to control a light and monitor its power. Let’s also say that the integration that allows you to add it to Home Assistant provides you with a technical entity ID such as switch.shelly_1pm_2f4dee. You should rename this to (for example) switch.living_room_lamp, which describes its purpose.
Doing this will ensure that should you one day need to replace the device, you simply need to rename the new device’s entity to the old name. This will allow any script, automations and dashboards that references it to keep working seemlessly. Importantly, in the case of long-term stats (LTS), it will also allow you to retain the previous device’s stats. You will also retain the recent entity history.
Steps when replacing a device:
Delete the old device and entities (don’t worry; the data is safe and won’t be deleted with it).
Restart HA.
Add the new device.
Rename the device or individual entities as needed.
This is good advice. Which, unfortunately, I didn’t have when first setting up HA.
I think the biggest problem with this idea is that, by the time you understand the implications of device and entity names, where they are defined and where they are used, it’s too late.
I’ve got it in my mind that some day I’ll go back and re-name everything. But it’s easy to just put meaningful names on the entities in the UI, and leave the “ugly” names in the background, so that project never seems to make it to the top of the list.
At least, to keep your metrics and minimise the impact, one could rename the new entities to the old (ugly) entities, but that’s not a great option in many cases, since you may be introducing some ambiguity.
That’s probably where lower-barrier requests (in terms of implementation) such as these come from:
As a software engineer, I don’t like renaming of entities. I prefer entities like “light.key9334811” and then I say “virtual_light.kitchen_ceiling is represented by light.key9334811”.
To understand better, how is it useful keeping the original entity ID?
The one reason I can think of is that it potentially encodes information about the physical device: In my example, one would know it’s a Shelly 1PM (to physically identify it) with a MAC address that ends in 2f:4d:ee (to virtually identify it on your network). But, entities like these always belong to a device, where you can have metadata and even navigate to it.
The cookbook belongs to the community (I have no strong feelings about owning this particular page), as to say I’ll entertain this one comment under the category of a feature request, but otherwise the discussion here should ideally about how to improve the cookbook page itself.
I have around 2000 entities. If I get a new device, for example a motion sensor, I put it in the living room and test if it does what I want. If not, it is moved maybe to the bathroom. Or after putting a shelly in the kitchen, after 2 weeks I find that the wifi signal is very weak and I replace it with a zigbee device. So devices move around. And I have an excel sheet with all the devices where I note for example the last battery change date. So keeping the original device name has some advantages, but also renaming it to the location can be useful.
“virtual_light.kitchen_ceiling is represented by light.key9334811”.
How do I create a virtual_light in
the part about representation, but if it is via excel, then I’m out
I had a bit of thoughts on entity IDs, to keep it simple it should be a user assigned unique ID + type and an optional local context and this unique ID is physically visible on the device itself
Let’s say it’s the kitchen:
Day 1: 1_switch, no automation
Day 7: 2_switch, no automation
Day 30: 1_switch_at_door, now with automation
Day 30: 2_switch_at_window, now with automation
If I had automation on day 7, then I will have to update my automation on day 30 because of the rename
Is it known what happens if the new device was already added before the old one was removed and both have some kind of overlapping history?
Example:
Temperature “Sensor A” is running in the living room for 4 years
Since a few weeks I tested a new Sensor B" with higher update rate for heating automation
“Sensor B” showed to be a better match for my use case and should replace “Sensor A”
Both have some history, one only a few weeks and the other a few years, but it’s overlapping for a short time now.
I want to delete “Sensor A” and rename the entities like temp and humidity from “Sensor B” to the old names of “Sensor A”.
Not sure now it this works and the history from the new sensor will not overwrite the old one.
Why I’m afraid of that?
In the past I renamed sensor entites with a long-going history and I’m pretty sure they kept their history. So the history was moved from the old entity id name to the new one I guess.
So how does HA decide internally, if I just want to give an entity a new name and move it’s existing history with it to the new name,
or if I want to replace an entity id with a new device and the history of the old device should be used instead of the values of the new device?
This seems to be a conflict to me, as it can’t use both histories but I also never seen a dialog to ask the user which one should be kept when renaming an entity.
