For the last 5 years naming of zwave entities the z-wave integration has annoyed me. I loved how MQTT / ZWAVEJS did it as i could specify a format. This is no longer possible as i want to use the integration for future compatibility / simplicity.
My issue stems from having three areas, each area having a z-wave deadbolt. I need / want the friendly name to be deadbolt in each area.
unfortunately this leads to devices where the entities are called lock.deadbolt, lock.deadbolt_2, lock.deadbolt_3 - this is not helpful when using things like pickers in the dashboard as i have no clue which rooms these are in (this is especially true for things like light switches where i have about 20 of them and they all appear as switch.x) - and donât get me started on the sensor entities that donât seem to use the friendly name at all - its impossible to figure out which sensor i need from some types of zwave devices as they are all named the same with just numerics
What i want is my deadbolts entities names to always start as follows:
lock.deadbolt.area.xxxxx
I see that when the z-wave js integration talks to an existing z-wave-js install the integration seems to use the name in zwave-js (but not the area name)
So my thought is:
delete my integration
rename all the names in zwave-js to be friendlyname+area
re-add the integration
remove the area portion by hand from the friendly name on each device and choose to not rename the related entities
then for future devices:
1. turn of home assistant setting in zwave-js-ui
2. initiate inclusion from zwave-js-ui and use the naming convention i mention above and set location
3. turn back on home assistant setting in zwave-js-ui wait for sync
4. remove the area name from the friendly device name in home assistant and choose to not change entity names
I canât think of a better way to achieve what i want and renaming the many devices and entities is not practical as some entities donât get renamed when selecting the option ârename entitiesâ.
Am i missing something? Is there a better way?
Here is another example, imagine i have 10 sink leak detectors - when using pickers in UI for entities how the heck am i supposed to know which of the 10 sensor_node_23_node_staus belongs to which friendly device? i will have 10 of these with v_2, v3_ etc⊠(i.e. i will have 10 of evey entry you see here with no name and all caled sink, sink_v2 etc if i use the integration as-is).
i would say on first observation this approach will do what i want - stupid i have to jump through the hoops to do it when hass could easily have an option to do what i just did âŠ
You realize you can rename these entities as soon as the device is included in Z-wave without impacting Home Assistant or Z-wave-JS UI, right? I always rename my entities once I include a new device, as well as disabling 3/4 of the entities created. Obviously best to do this before including things in automations or YAML but still fixable.
Recently I went through all my entities and disabled anything I havenât touched in the 24 months or so Iâve been using Home Assistant, and there were a lot. If I find I need them later, I can always turn them back on.
It will be harder now, but you can always work through them a device at a time. The device names are tied back to the Z-wave Node numbers, so it shouldnât be that hard.
Keep in mind doing it this far after the fact will break other things that are loosely linked by entity name only, but the newest versions and the Spook or Watchman integration will immediately point out any broken links.
An example of where it fails to do a rename is if the friendly name is not in the concatenated identity string.
Also a rename of the friendly name doesnât wholesale reformulate the whole of the name - for example it leaves the _2 and _3 at the end of the string - those are useful when one has multiple devices in a single room with the same name, but not in other situations. I donât see anyway to reset the name to remove the _2 and _3 - it would be helpful if removing the device from home assistant would then regenerate on next sync with zwave-js.
To be clear you suggestion works as advertised on devices that were not originally creatde with missing friendly name elements in the entityIDs and where i have only one of them. For anything with multiple it seems to be hit an miss depending on how it was originally added (i found a community post that talks about this issue. aka its an edge case but what i describe happens
the great news is, using the approach i outlined i donât loose anything by removing/adding the zwave integration as now my devices have static predictable names based on me using a zwave-js name of name.area_name
and you suggestion educated me i only need to consider this for devices with the _2 _3 etc and with oddities in the original enitiy naming (i suspect the entity naming logic improved since i last did this 2 years ago⊠this was about how to clean up)
The _X numbering occurs when there are collisions in the name. There exists an entity with the same name. It will start by adding _1, _2, and so on. I donât have that scenario myself, but I could see if you have the same type of device in the same area it could occur.
rename friendly name to leak.guest_room to populate that into the identityID.
as you see not all identity IDs were renamed to include the new friendly name as a component becaue it didnât include the previous friendly name
compare this to the ealier leak sensor i did âmy wayâ where i get consistent indenrity naming, this behavior as been present since the very first version of the zwave-js integration first test versions, i logged it then too.
This occurred because in zwave js there is a name column and an area column so i would do âdeadboltâ for name and area âfront doorâ for one device and âdeadboltâ for name and area âback doorâ for another. This worked perfectly in MQTT to home assistant - i would get perfectly formed entity names EVERY time. Home assistant doesnât do that and at the time I moved over to the integration i couldnât figure out how to correct it. I have now.
yeah, i started long before with zwave-js > MQTT > home assistant; along with alex per room where i can go in any room and just say âdevice nameâ i donât need to say the name of the room. so of course putting the area name into the friend name seems utterly stupid to me - beyond one has to do it to make it work, but hey now i know how to fix it and your suggestions helped me realize it depends on device
now i know i can go add the other 15+ leak sensors - i will be doing it via zwave-js as its the only way to ensure consistent entity names
Those entities are created before the product name is known (name is received after the node interview). They do not go through the same discovery process as the others, which occurs after the node interview. Those entities are named with node ID though, so there are never any duplicates.
Perhaps the entity creation could be improved to delay creating those nodes. You could create a feature request or GitHub issue if it concerns you enough. On the other hand, if the node interview fails it doesnât prevent their creation, so you can still ping the node or see its status.
That makes the whole ârename all enittiesâ function hit or miss for z-wave, lol.
As for github issue - Franck argued with me about this behavior when i raised it the last time. ~ when the first version of the integration was still in beta, and told me how stupid i was. I have zero energy in having that discussion again - all those threads i have seen in the last few years on z-wave naming issues could have been largely avoided⊠I have a workaround - which is to do includes through zwave-js in the way i described. I know others hit this - the number of threads on entity renaming says it all.
Really the inclusion process should ask me what i want the device called and what area it is and just do the right thing.
Yes it offends my software design sensibilities that i have to enter the area name in the device friendly name and then reset the device friendly name, but i can live with that, i only do mass includes once every 18mo or so when i feel like doing clean up / move to new stick.
I am referring to the other entities that i already corrected and that were wrong from the get go with integration - the 3 you see were just point examples to prove that not all entities on a device get a name that can be changed by changing the device name, doing the process i outlined in the OP seems to be the only fix for devices where this happens. As such marking myself as having aswered it and eveyone can carry on, and i can let them not worry about my naming OCD.
and your suggestions helped me realize it depends on device