Maybe but getting your mind blown isn’t always by definition a positive experience.
But what happens to those who don’t organize their HA like that?
I know it’s not a part of this release but it was mentioned so I’m starting this discussion. Feel free to move it if needed.
There are many questions related to the planned naming standardization.
will the system automatically change the existing names/entity_ids for existing devices/entities?
will we still be able to customize those changed assigned names entity_id’s?
Depending on the answer to the first question then the answer to the second question could result in A LOT of tedious reworking of our system configs.
What if someone doesn’t use areas at all (like me)? How will the auto assigned devices/entities be made if there is no area assigned to the device.
I’m assuming that the renaming (if it happens) will only be done to devices configured thru the UI and so they are contained in the device registry?
So then the user will be in a position where their system will be partially structured for them by the system and part will be structured by them? That sems to negate the benefit of the forced re-structuring of the naming standardization.
I REALLY don’t like the idea that HA may change the naming/entity_id convention I’ve created for MY HA instance through the last five years of use.
It seems that either way this goes there is going to be a lot of potential pain in either needing to update ALL of the existing config (automations/scripts/dashboards/etc) to use the new updated names or for the existing users to need to go thru all existing names and change them back to what they were before.
Maybe this will all be taken into account before anything is actually put into place but reading the dev documentation pointed to above doesn’t really mention backward compatibility except in the short term…
During the migration period, we use the
has_entity_name
property to create “backward compatible” friendly names. In the future, we can show deprecation warnings for entities that don’t set this property, and later, remove it entirely.
…and the dev history where there is a tendency to make decisions without any feedback from the community I figured I’d get started early pointing out potential pain points or to allow the dev team to alleviate concerns by us knowing what to expect when the time comes.