I have 2 zwave thermostats that create multiple entities (such as a cooling, a heating, a temperature, etc) a total of 8 entities each thermostat, as you can image this is a pain to keep track which entity is for what thermostat. I want to batch add a friendly name to all those entities. So what I found out is under config > integrations > z wave I clicked on the gear for the thermostat and renamed it and added it to a room, but then under Developer Tools > states page i see no remmant of this change, also this change doesn’t change the customize.yaml which I image is because I didn’t add this edit for each entity under the customize tab under config.
My question is what is the purpose of this change here, and how can I batch add a friendly name to these 16 entities to keep track of which one belongs to which one?
From there you can rename each child device. There’s no batch name change in the UI at this time to facilitate a rename of all the child entities. Hopefully it’s something that’s added in the future.
Ok that is what I thought. Just seemed pointless to name the box around it but it doesn’t go anywhere. Found this post below that tells me what I already know that we should be able to rename the node and have it automatically change all the children.
Another way would be to simply have the entity custom name be saved somewhere. I had this experience where I renamed the entity during my first run of using HA about a year or less ago and when I recently moved to Hassio and chose to copy over the config but deleted unnecessary integration I was left with a lot of entities unavailable therefore I had to delete the core.entity registry file and the return state file and that reset my custom entity names for my zwave product back to default which is not descriptive where as if you only use friendly name those changes get saved in your customization file and so long as you don’t delete that file then if even if you delete your entity registry when the devices are reimported the customization file ties the default entity with the friendly name.
I feel there should be a friendly name and a custom entity name apart from the factory one saved somewhere. In Nodered I don’t have access to friendly names so I have to change the entity and even though I risk my entity being reset if I delete my entity registry.
That functionality was part of the zwave control panel and it worked great but was removed from that section a long time back around the time the entity registry concept was introduced.
Supposedly the service to do that still remains in the services tab of the developers tools page. It’s called “zwave.rename_node”. I’ve never had a chance to test it to see if it works the same way it did in the zwave control panel, tho.
Since the OP has a bunch of devices you need to bulk rename then maybe they can try it and see if it works.
It seems like the problem is that the entity names are created and added to the entity registry when the device is added, being derived from whatever the default name for the Z-wave device was.Once that happens there’s not a direct concept of “derived entity names” like there is for entity descriptions (where if you change the entity name and don’t have a customized friendly name already in place it will automatically update). So changing the name of the Z-Wave Device entity after it’s created doesn’t actually affect the child entities. This is why changing the z-wave device name (in the zwave cfg) and then deleting the corresponding entity registry entries works: it forces those entities to be re-registered, but this time their names are derived from the new device name.
Of course, since they helpfully show all the child entities in the Z-Wave integration it’s obvious they still have information about that dependency. It doesn’t seem like it would be too hard to add an “Update Device Name & Entities” option there exactly like you describe.
Honestly, what I would like to see is something mimicing the “adoption/provisioning” paradigm of managed network equipment. If you want to add a node you do the normal “Add Node / Trigger Inclusion on Device”, but then rather than automatically generating a bunch of garbage you almost certainly don’t want, the newly recognized device would go into an “Unadopted Devices” list that shows the Hardware and Node information, but doesn’t actually do any of the work of integrating it into HA. Once you’ve added whatever device(s) you want, you can go through them one at a time and “Adopt” them into your Home Assistant system. The adoption process would give you an opportunity to specify whatever initial properties SHOULD be defined without having to jump through hoops to do it – things like device name, area, what values from it you actually want to expose, an initial configuration, etc. Making the adoption automatic is great if it works, but since it almost universally requires modification after the fact it seems like it would be a much better experience to just bite the bullet and make it a slightly more explicit process.
I agree with you and would add (maybe you are saying this and I didn’t follow completely what you are describing) that to me the first time around doing HA about less than a year ago I would edit entities and was trying to just get things integrated as fast as I could. This second time around I have taken my time to tackle each integration fully, tackle each error in my log etc, and tackle naming and organization of my entities.
With the latter being a long confusing road but one that I have chosen to adopt something sustainable. To me I choose now NOT to edit the entity ID since I noticed that if you were to re create your HA environment from scratch maybe due to loss of a proper backup or you just want to start from scratch (I always prefer this method when building a PC) the entity ID is not kept. If you look at what is actually kept is what is inside the customization.yaml file. This file ties the entity ID with the friendly name, device class etc. Therefore for longevity purposes I feel that friendly names are better to use or whatever is kept static.
To me what would be nice or at the very least would be to adopt something where you have a custom entity ID apart from a friendly name.
Might seem redundant but for a node red user like myself i see that node red doesn’t pull friendly names when you are creating flows. It only pulls entity IDs which makes it hard to decypher. Its a bit of quandary since it is not a guarantee that changing an entity ID will be kept if you start from scratch. Entitiy ID are always used more often than friendly names.
This sounds like a shortcoming of NodeRed to me. If we go to the trouble of giving things friendly names then surely NodeRed should let us use these when developing flows. It can’t be that much of a stretch to fix the NodeRed integration to make this possible can it? Is there anyone out there willing to give it a go?
The way it used to work (when the ability to rename the node existed in the OZWCP section) was that you added the device to your zwave stick and the entities were added based on the default zwave device name.
Then you could rename the node (and maybe still can with the rename_node service), restart HA and then miraculously all of the child entities had a base entity_id based on the new node name. I believe that information was derived from the ozwcfg file. Or it might have even saved that information on the zwave stick itself (which would have been even better). Either way you could make one edit and all of the child entities were renamed to match the name of the node with the functional description appended.
Include the Devices: “Z-Wave > Add Node” for all new devices. Jot down their Node IDs.
Stop Home Assistant: SSH into the hass.io instance and stop HA (hassio ha stop)
Rename the Z-Wave Devices: Open zwcfg_0x*.cfg. Find the entries for whatever nodes I added and edit the name attribute on the root entry for the device. This also lets me do whatever configuration tweaking I might need to do (like adding central scene support, etc).
Delete the old Entities from the Registry: Open config/.storage/core.entity_registry and delete the entries for entities related to the new devices. You can find the z-wave device by looking for "unique_id": "node-<N>" where <N> is the node number. Child entities should be immediately following the Z-Wave device entity, and will have a unique_id attribute that starts with the node number (so "unique_id": "19-72057594361511937" would be a child of the device on node 19).
Restart Home Assistant: Using hassio ha start from the SSH terminal.
When the server starts it will load the z-wave devices with the new names as specified in the zwcfg_0x*.cfg file, and then re-create the entities for it using the new base name. The reason you have to delete the entity IDs from the registry is because the registry essentially is a customizations.yaml file for every entity. Even if you rename the node, the old entities with the old names are still around.
This is also why using the zwave “Rename Node” service doesn’t work now like it once did. Since all entity names are explicitly stored in the entity registry upon creation, renaming the node (which is equivalent to editing the names in the zwcfg_0x*.cfg) will change what Z-Wave calls the device, but it will still point to the same entities with the same names.
The equivalent of what I suggest above with the new interface would be:
Rename the Z-Wave Device: use the (now hidden) zwave.rename_node service to give the device an explicit name.
Rename the Z-Wave Device’s Entity: Use the Entity Registry panel to change the entity_id for the entity corresponding to the z-wave device
Rename Each Child Entity: Use either the Entity Registry or Integrations > Z-Wave panel to rename child entities for the node
You could maybe argue that the above steps are easier than what I suggested before. Personally, I prefer the lack of potential typo errors and UI digging that just renaming the devices and relying on re-generating the entities provides. Also when you start adding lots of devices in one go (redoing a bunch of lights) or dealing with devices that produce lots of entities (hello, flood / multi-sensors) I think it ends up being much more streamlined.
However, regardless of which you prefer it seems like the system has everything it needs to just provide a “Rename Node and Entities” function that does it all. If I can figure out the best way to set up a dev environment without turning my actual house into a sandbox maybe I will poke around at it…
I don’t see why the devs have been so stubborn on implementing something to solve this issue. there have been lots of people that have complained about it for a long time but the lack of concern (or even a reply saying “we can’t & here’s why”) by the devs has been incomprehensible.
I think you are being a bit unfair. No one is being stubborn, there is just no one to do the work. Z-wave has only 1 regular contributor and other occasional contributors, but none full time. Someone who really wants this kind of functionality is going to have to step up and contribute, because it’s not going to happen otherwise.
If you do a search on my name and zwave entity registry I’ve been trying to get someone to look at this or at least give some kind answer why we can’t have a similar functionality to what we used to have that worked pretty good before it was abruptly removed.
the only answer that was ever given one time was that the functionality was removed for compatibility with the newly planned (at the time) entity registry. It then took several months for the entity registry to be implemented so people were kind of stuck in the middle.
And then when the entity registry was finally implemented it was a very poor replacement for the functionality we had because as the procedure posted above by @nathanhoobler shows in that it requires us to go in and edit “system” files that aren’t meant to be user edited. Or that it requires the user to manually individually edit a large number of entities that are created by the devices. To illustrate how cumbersome this can be, I saw someone in one thread a while back mention that each device that they paired created 13 different related entities and they had to end up manually editing over 300 different entities to get everything organized to their satisfaction. To me that’s just silly since it is could possibly be unnecessary. But we don’t really know if it’s necessary since no one of any authority comes on here and answers any questions.
And to be fair I’m not the only one who has complained about this. there are many and long threads related to this that have popped up over the last year and a half and there has been literally almost no feedback given by the devs to any of those numerous threads. I don’t make the claim about there being almost total (apparently stubborn) silence on this for no reason.
And my point was that it could have easily been addressed a year and a half ago when whoever it was decided to remove the functionality we already had and it was still fresh on their mind.
Someone took the time to remove it. If time/availability was the issue then it would have been better to have not taken that action in the first place.
the rest was responding to you saying that I wasn’t being “fair” to the devs.
Either way we are kind of just stuck with what we have until someone takes the time to address it. Until then we will continue to jump thru hoops coming up with workarounds on a system (zwave) that is at the base of almost any widely used home automation system.
Yea i wish that was the case. As I wrote my response I felt that it is more of a Node Red integration in the search where it should pull this up.
I don’t know what the best practices are, but if it is a bit work or a work around to name you node when you may potentially move your switch to another room or maybe you move houses. I prefer to apply a a serial number type of naming convention that I can tie the product number, room, specific light switch all via a panel for organizing.
I recently have starting thinking to moving to MQTT switches since the topics you make them and you can have a good organized way of naming them, and they can be changed by a UI depending on what firmware you use like Tasmota or ESPHome. If I coded my own MQTT sensors well unless I create a webserver I am going to have to live with the topic I chose, but at least you can organize it a bit. I digress anyways.
I do think Node Red should be updated to filter by friendly names.
I agree with your point and with @freshcoast point. In general I don’t see it as a blame its just an idea that should be implemented and still could.
This is the first time I have been involved in being a user of such a large community driven development, and as such it comes with its flaws as well as its benefits. I think that someone does need to step up. I wish I could develop it myself, but while I can code and figure things out I would need to really develop my skills to contribute, I am ok with adopting whatever workarounds there are until it is addressed, but I do agree that issues or ideas shouldn’t be hushed and need to be kept being brought while understanding that not all ideas can be addressed in a time that suits everyone. We should all live with the fact that its a blessing to have such a great community open source development and definitely try to do our part to make it better.
This Z wave organization idea is defnitly something I think should be added to the roadmap and hopefully someone, anyone, maybe me (most likely not me), can get to it. lol
(most likely not me), can get to it. lol