Validate my naming strategy please

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:

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:

  1. delete my integration
  2. rename all the names in zwave-js to be friendlyname+area
  3. re-add the integration
  4. 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).

and here is what it looks like if i do it my way rather than the HA way:

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.

It would be a pain, but well worth it.

When you rename the device you are prompted if you want to rename the entities as well. I will occasionally use this as a batch rename function by renaming the device in the entity name schema I want, letting it rename the entities, then change the device name back to its friendly name and saying no to the rename prompt. I’ve never séen it not rename all entities.

Thanks that’s helpful.

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.

Here you go. I have an example (most of my locks, lights were like this, this is a leak sensor)

Add z-wave device as normal in home assistant: - note how the firendly name is missing from some entities

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.

I guess I never noticed. I always name the entities after the location and purpose. I also remove the redundant sensor.something_sensor syntax.

I’m sure someone here can tell you how the slugify routine picks names, but I can’t.

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 :slight_smile: 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

1 Like

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.

These entities didn’t exist when the integration was first created, so I’m not sure what you’re referring to exactly.

I’m referring to the “node_status”, “last_seen” and “ping” entities.

Also, there probably is a bug there because only a couple of my nodes are in this state. Many are named properly.

1 Like

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.

i literally had this issue on almost every one of 24 devices across 250+ entities