I let ozw decide the names. then in home assistant I override the name…
In node red it uses the OZW name, that is pretty annoying but I always have 2 tabs open when working on it…
NEVER keep the default, it’s almost as bad as device id’s, you can never tell which device you are dealing with.
Be sure to change all the device attributes to a common root too
I’ll post an an example naming convention I use as an example
1 Like
For easily find an entity in the states overview, and to easily have essential information about the entity and where it is located, I rename the entities like:
sensor.“manufactor_type_palcement”.
1 Like
I do not agree… There are other places on this forum where very knowledgeable people defend changing devices names in OZW!
Remember, this is the zwave section the question is asked!
zwave.aeon_labs_dsc06106_smart_energy_switch_2
zwave.switch_aeon_a01
Switch Aeon 01
switch.aeon_labs_dsc06106_smart_energy_switch_switch
switch.switch_aeon_a01
Switch Aeon 01
sensor.aeon_labs_dsc06106_smart_energy_switch_energy
sensor.switch_aeon_a01_energy
Switch Aeon 01 Energy
sensor.aeon_labs_dsc06106_smart_energy_switch_exporting
sensor.switch_aeon_a01_exporting
Null Switch Aeon 01 Exporting
sensor.aeon_labs_dsc06106_smart_energy_switch_power
sensor.switch_aeon_a01_power
Switch Aeon 01 Power
sensor.aeon_labs_dsc06106_smart_energy_switch_power_2
sensor.switch_aeon_a01_power2
Null Switch Aeon 01 Power2
sensor.aeon_labs_dsc06106_smart_energy_switch_interval
sensor.switch_aeon_a01_interval
Null Switch Aeon 01 Interval
sensor.aeon_labs_dsc06106_smart_energy_switch_interval_2
sensor.switch_aeon_a01_interval2
Null Switch Aeon 01 Interval2
sensor.aeon_labs_dsc06106_smart_energy_switch_previous_reading
sensor.switch_aeon_a01_prevenergy
Null Switch Aeon 01 PrevEnergy
sensor.aeon_labs_dsc06106_smart_energy_switch_previous_reading_2
sensor.switch_aeon_a01_prevpower
Null Switch Aeon 01 PrevPower
Adapt to suit yourself
Errr Post 3 examples ?
I have never seen ‘Knowledgeable’ people (on z-wave) see manipulation of the OZW as anything other that the LAST recource (and yes, I have done it myself)
knowledgeable = freshcoast and fishwaldo for starters
Edit: The above is not a brilliant example, instead see post 12 below
- That is only 1, not 3
- It only talks about entity_id’s which I agree with and the list I gave is about changing those as freshcoast contends
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,
- The friendly name is just a title.
- I have to change in HASS every entity of each device. An alternative is to change it in ozw
- I need to decide about a name convention and go for it
Correct?
1 Like
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 : -
- switch.aeon_labs_dsc06106_smart_energy_switch_switch
- switch.aeon_labs_dsc06106_smart_energy_switch_switch_2
- switch.aeon_labs_dsc06106_smart_energy_switch_switch_3
- switch.aeon_labs_dsc06106_smart_energy_switch_switch_4
etc.
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
1 Like
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(', ') }}
23 Likes
Why have I NEVER thought of this?!?
This is brilliant!
1 Like
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.
3 Likes
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?
1 Like
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