A way to set “permanent” entity names that are independent of the device name or interface (z-wave, zigbee, mqtt, etc). I expect these entities to be permanent, essentially acting as helpers for the “temporary” entities tied to a specific device.
For example: Door Binary Sensor > binary.sensor.entity01
Why do I need this?
I’m working in an environment where the source data can change, but the environment is relatively rigid, and I need to keep historical data for it. I want to de-couple these things from each other to make replacements easy and also very flexible so I can select the best device for the job.
I also want to make sure that all of the automation I build are not disturbed, or very minimally disturbed.
Options I’ve considered.
Use the MQTT broker to set topics in YAML and from what I understand you can tie this topic to a specific entity. I would prefer to not have to touch YAML too much and would like to be as close to what the future of Home Assistant will most likely support (which I am not very familiar with).
I change devices and keep the same entity IDs, but I have to name the devices the same as before as the integration builds the entity IDs based on the device name.
But, even when not the case I’ve renamed entities and then adjusted the DB to use the same “meta” ids so I retain the history. (I just did this with an outdoor temp sensor that failed but I wanted to use a new name.)
I thought there was a way in the UI to do that, but not seeing it right now. I’m fine modifying the DB directly.
(By the way, you might read the comments (now delayed) in the beta about naming. Not really that related, but I just mention this because you noted wanting entity names that are independent of devies names.)
No, that is about displaying the names of entities, not about the entity_ids. The DB uses entity_ids to map to the ids that reference the related history stats. (Why there’s two different IDs for short and long term stats is curious to me.)
Sorry, didn’t mean to conflate your question with that change. Places that use friendly_name (and I assume that means both in templates and internally in the code) will prefix that name with the device’s name. So, the device name may show up in places that users didn’t expect it to (or explicitly changed it to not show the device name).
In addition to the documentation, if you are comfortable with SQL I’d suggest just exploring the database. It’s not that complex, TBH, and understanding it helps mitigate concerns that you might lose history if you have to replace a device. Also, removing a device and adding it back in and watching what happens in the DB and how the entity names are re-created is helpful.
I have a separate HA running on my laptop in Docker that I use to play with. That’s helpful if you want to test not on your “production” HA server.
Thats the reason most guidance on automations is use ‘entities not devices’
Device id’s are 32 char Hex nobody can read the and they get recreated on every integration reinstall. But the ent_id is plain language and the data sticks with the name
So.
Build a system. Let it run under ent_id == domain.foo.
Collect data
Delete provider of foo.
(next happens sometime within 10 days - because history clean up will stale this out once data is reduced to stats, 10 days by default, with no underlying ent. It drops that data.)
Now say you Install provider 2 who delivers more foo in same format - give it the ent_id == Domain.foo BEFORE the data stales out.
Domain.foo now refers to provider 2 and retains the history. Your old automation continues to work
If foo2 delivers data in a different format you may introduce dB consistency issues but the system should flag a repair (which may include instructing the user to wipe the previous data if incompatible with new unit, range etc.)
None of this requires setting up alternate second shadow entities…