Edit: you added a second but that again only says that if lose the HA cache you have lost the names (and your point being ? ) if you’ve lost this what was the point of snapshots or backups ?
I go through the z-wave management front end and pick the node I wish to rename the entities of, 1 device, multiple entities, all in one location
So what is your point? Why do you need need 3? Else it is not accurate enough?
My point is: Using the original entity name created by the OZW addon is safe, unique and stable.
You can easily change the name in every entity by clicking on it.
And yes I already admitted it is not very handy but that another thing.
Thanks.
So,
Correct?
My point is to establish a pattern of consensus, AND as I said @freshcoast was not advocating editing the zwcfg_0xe169924f.xml (or whatever yours happens to be called) and doing so is ALWAYS the last resort.
None of the links you provided supported your contention.
Just using the standard entity_id’s provided by discovery makes coding a nightmare even if you subscribe to the point and click methodology
If you can’t read and understand (intuitively) the elements you are manipulating then you have to ‘refer’ to things (written notes or have a second/third window open to check) this is poor as written notes can become out of date and if you are flipping windows then you are not maintaining a train of thought, so your code becomes either disjointed or you write errors in.
Add to that ‘debugging’ and general maintenance (eg v0.115 entity_id deprecation in sensors though not too hard on it’s own) becomes a similar excercise in futility
The gui editor allows you to use friendly names (I assume ?) but as your coding becomes more intricate then the need to use templates comes into play at which pint it’s too late to rename stuff as you might as well just wipe the slate clean and start again.
eg a Template full of : -
If you can keep track of this in your head you are a better man than I
Appologies, the list I posted was ‘less than clear’
I shall elucidate …
I have a set of text files for each type of device I possess, for example : -
zwave.fibaro_system_fgd212_dimmer_2
zwave.fibdim2_XXm
Light ZZm
sensor.fibaro_system_fgd212_dimmer_2_level_4
light.fibdim2_XXm_level
Light ZZm
sensor.fibaro_system_fgd212_dimmer_2_level_5
light.fibdim2_XXm_sw2_level
Null Light ZZm Sw2
sensor.fibaro_system_fgd212_dimmer_2_alarm_level_2
sensor.fibdim2_XXm_alarmlevel
Null Light ZZm Alarm Level
sensor.fibaro_system_fgd212_dimmer_2_alarm_type_2
sensor.fibdim2_XXm_alarmtype
Null Light ZZm Alarm Type
sensor.fibaro_system_fgd212_dimmer_2_energy
sensor.fibdim2_XXm_energy
Light ZZm Energy
sensor.fibaro_system_fgd212_dimmer_2_exporting_2
sensor.fibdim2_XXm_exporting
Null Light ZZm Exporting
sensor.fibaro_system_fgd212_dimmer_2_heat_2
sensor.fibdim2_XXm_heat
Null Light ZZm Heat
sensor.fibaro_system_fgd212_dimmer_2_power_5
sensor.fibdim2_XXm_power2
Null Light ZZm Power2
sensor.fibaro_system_fgd212_dimmer_2_power_2
sensor.fibdim2_XXm_power
Light ZZm Power
sensor.fibaro_system_fgd212_dimmer_2_power_management_2
sensor.fibdim2_XXm_voltage
Light ZZm Voltage
sensor.fibaro_system_fgd212_dimmer_2_sourcenodeid_2
sensor.fibdim2_XXm_snid
Null Light ZZm SrcNdID
sensor.fibaro_system_fgd212_dimmer_2_system_2
sensor.fibdim2_XXm_system
Null Light ZZm System
This lists known entities for that device and my typical naming format for it
I open the list in notepad (specifically not my usual editor)
I then do a search and replace on XXm (XXm because it has capitals and HA won’t let you save an entity id with capitals) I replace it with a 4 letter mnemonic, say in this case ‘kitf’
I then do a search and replace on ZZm (just because it’s similar to XXm but not)
I replace it with ‘say’ ‘Kitchen Front’
So I get : -
zwave.fibaro_system_fgd212_dimmer_2
zwave.fibdim2_kitf
Light Kitchen Front
sensor.fibaro_system_fgd212_dimmer_2_level_4
light.fibdim2_kitf_level
Light Kitchen Front
sensor.fibaro_system_fgd212_dimmer_2_level_5
light.fibdim2_kitf_sw2_level
Null Light Kitchen Front Sw2
sensor.fibaro_system_fgd212_dimmer_2_alarm_level_2
sensor.fibdim2_kitf_alarmlevel
Null Light Kitchen Front Alarm Level
sensor.fibaro_system_fgd212_dimmer_2_alarm_type_2
sensor.fibdim2_kitf_alarmtype
Null Light Kitchen Front Alarm Type
sensor.fibaro_system_fgd212_dimmer_2_energy
sensor.fibdim2_kitf_energy
Light Kitchen Front Energy
sensor.fibaro_system_fgd212_dimmer_2_exporting_2
sensor.fibdim2_kitf_exporting
Null Light Kitchen Front Exporting
sensor.fibaro_system_fgd212_dimmer_2_heat_2
sensor.fibdim2_kitf_heat
Null Light Kitchen Front Heat
sensor.fibaro_system_fgd212_dimmer_2_power_5
sensor.fibdim2_kitf_power2
Null Light Kitchen Front Power2
sensor.fibaro_system_fgd212_dimmer_2_power_2
sensor.fibdim2_kitf_power
Light Kitchen Front Power
sensor.fibaro_system_fgd212_dimmer_2_power_management_2
sensor.fibdim2_kitf_voltage
Light Kitchen Front Voltage
sensor.fibaro_system_fgd212_dimmer_2_sourcenodeid_2
sensor.fibdim2_kitf_snid
Null Light Kitchen Front SrcNdID
sensor.fibaro_system_fgd212_dimmer_2_system_2
sensor.fibdim2_kitf_system
Null Light Kitchen Front System
So I get a file containing what the format I’ll be replacing ‘should’ look like and what it will be. it’s then a simple cutting and pasting excercise. (edit: and very importantly, discard the file (don’t save) as you need the original to do the next device)
Further I know what the device is and it has a common format so I can copy whole parts of code and then just do a simple search and replace on kitf for kitr and my kitr package is ready to go.
I can generate whole rooms in literally a few minutes.
It also lends itself to template sensors as pattern match allows grouping/actions/sensor counts/minimums/averaging/maximums with ease
I’m not an advocate of using an entity’s name to store metadata. In other words, I don’t recommend creating an entity name packed with its characteristics.
sensor.manufacturer_model_identifier_color_size_location_bla_bla_etc
When the time comes to select entities based on their characteristics, the resulting template can become quite messy.
What I suggest is to add metadata as custom attributes to an entity. Simple add them to customize.yaml or via Configuration > Customizations.
For example:
sensor.kitchen_remote_battery:
integration: hue
type: 'CR2450'
sensor.bedroom_remote_battery:
integration: hue
type: 'CR2450'
For my purposes, I want to know a battery sensor’s integration and the type of battery it uses so I created two custom attributes: integration and type. They will appear as additional attributes when viewing the entity’s attributes.
Here’s a template to select all sensors with a specific battery type (much simpler than trying to parse it out of the entity’s name):
{{ states.sensor | selectattr('attributes.type', 'eq', 'CR2450')
| list | join(', ') }}
If I have many battery sensors and only want the Hue sensors that use CR2450 batteries:
{{ states.sensor | selectattr('attributes.integration', 'eq', 'hue')
| selectattr('attributes.type', 'eq', 'CR2450')
| list | join(', ') }}
Why have I NEVER thought of this?!?
This is brilliant!
I think it’s because the documentation for Customizations presents it primarily as a way to tweak an entity’s “look and feel”, namely its standard attributes like icon and device_class which determine its appearance in the UI. It overlooks to mention that you can add whatever attributes you want to serve as metadata.
While creating a template, I needed to know an entity’s integration and wondered why it wasn’t included as an attribute by default. Rather than submit the idea as a Feature Request (and wait for it to be implemented, if ever) it was easier to just add it as a custom attribute.
In general I would concur but the major reason I do this is to Simplify coding.
And different light ‘devices’ sometimes support different features requiring slightly different coding techniques. For example I believe you mentioned a light that can have its level adjusted whilst off.
The fibaro dimmers support a nominated switch on brightness, others don’t only supporting switching on at the last switch off value etc.
The dim2 bit tells me it’s z-wave plus
And as you’ve seen if it’s largely irrelevant I just include the ‘aeon_labs_dsc06106’ bit so I know what it looks like.
These are also what I have from starting 3 years ago, were I to start again I may do it differently.
However the point I was trying to make was about changing entity_id 's from the default
EDIT: And the method I showed was not to expound a particular naming convention (that is upto the individual) but to show how easily it can be undertaken and the benefits consistency provides
That used to be available but was removed. I don’t recall why it was removed. That whole battery notification mess you saw in the other thread relied on it at one point.
I change the enity_name and friendly_name to be same.
light.living_room
Living Room
lock.front _door_lock
Front Door Lock
I do not change device name
By doing this if I ever change device the new device replaces old in UI
I’m using custom attributes in 0.117.4 so what exactly “was removed”? Do you mean it was documented at one time but that was removed?
Huh, I recall them being removed. TIL, they aren’t removed.
But I have replaced a device, delete the old entities, add the device, rename to the new, restart and you are good to go. 10 minutes if that.
All automations intact and working
I like the concept for specific entities that could benefit from it but I think having to write a customization for single every entity would be mind numbing. And maintenance would be horrible if you did it for every entity that you add in the future (or even worse the ones you might remove later) especially since the integration is easily accessible to you in the entities list.
But the battery type example is a perfect use case for that.
But to each their own and knowing that it’s even possible is good to know. Another tool in the toolbox.
So thanks for the info.
I understand your point. However it’s not always a case of extra effort. If someone invests the time to change an entity’s name so that it contains metadata, I believe that time is better served putting the metadata in a custom attribute. In other words it’s not necessarily more mind-numbing work just the same amount of it but with better results.
To your point, I agree that battery type is one of the better applications of this technique. Most people don’t have a need to use an entity’s integration in a template (so they don’t need it as an attribute). If they simply need to know an entity’s integration it’s available in the Entities view. Nevertheless it was used as an example of the kind of metadata one can include should one need it to, for example, create an inventory of installed gadgetry. 
Does it require anything special to add a new attribute, e.g. do I have to edit a list of attributes or anything? Can I simply call a new attribute anything I want?
You can edit a list as described in the documentation or you can use Configuration > Customizations (one entity at a time).
You can name the new attributes whatever you want just avoid using existing names.
As of version 2021.12.0, Configuration > Customizations no longer exists. You can continue to create custom attributes via the customize.yaml file.
Thanks, I wasn’t sure if there was other required actions other than simply adding new. Super helpful!
Hi, I like this idea since the device has so many entities but where are you pasting to? and what is the syntax, if yaml seems to be missing headers and whatnot.