You donât have to rename anything. You can keep it what the integration names it. But then youâll have to update your automations and UI.
node IDs will stay the same as they are specific to the controller, not to the integration
Everything is handled under the hood. Thereâs a unique_id attached to all the zwave entities. You change the entity_id to anything you like and it will stick forever.
Get that, but since I do not know what the new integration will present me, even if the names are mixed⌠How will I know device A (ozwbeta) is device X in (ozwjs) and device B (ozwbeta) is device Y (ozwjs)âŚ
Based on the node and a little intuition. The template I wrote outputs the node and itâs entities and the friendly names.
SO in the new zwave_js integration, open the list of devices. Click on a device. Iâtll list the node. Look at the node and compare it to what the template output. Then look at the entities under the device. Youâll know whatâs what.
This is excellent, I really appreciate the walk through!
Do you think itâll be easy to switch from the zwavejs2mqtt server to the Supervisor zwavejs addon server? As in, will I have to rename the devices yet again, or will the name stick because weâre using the same integration, just a different server?
Oh that will be super easy. All you have to do is turn on the server access inside the zwavejs2mqtt settings. Then turn off the toggle for the MQTT portion. Install the integration and youâre off running.
Maybe, I havenât gone this route. The names come from the server, so in theory, you donât have to rename. Just turn off MQTT discovery, you might have to delete the topics.
Ah, I was just wondering because I figured I should start with zwavejs2mqtt since it has a full UI for node configuration. Eventually I would prefer to use the âofficialâ server add-on, but since itâs very new and thereâs a lot still being added, it sounds like itâll be more effective to start with zwavejs2mqtt.
Basically, I made the jump to OZW a while ago because I was going to add dozens of new nodes, and didnât want to rename everything down the road (haha, oh well), and I was hoping if I jumped to the ZWaveJS integration now using zwavejs2mqtt as the backend, Iâd be able to avoid a 3rd renaming session later 
But I donât really mind. From what Iâve heard, this will be worth it for the performance gains. Either way, Iâm super appreciative of all the hard work everyone has been doing!
the performance gains are unreal. When I have Alexa turn on the lights now, they turn on before the response sometimes. That never happened in ozw.
1 Like
Is this last bit optional ?
I would like to run the new zwavejs server because itâs âcurrentâ but still have the devices published to mqtt for others and also have any other devices (from another controller) that appear in mqtt to be discovered by HA - is that do-able ?
Use the code from @petro (thanks!!!) before and after the transition. It will then be easier to match the new entity_id with the old.
Small adjustment to that code, made easier to import in excel, text to columns on semicolon:
{%- for node, zstates in states | selectattr('attributes.node_id', 'in', range(1000)) | groupby('attributes.node_id') %}
{%- for s in zstates %}
Node {{ node }};{{ s.name }};{{ s.entity_id }}{% endfor %}
{%- endfor %}
3 Likes
You should be able to take your current network key (if you have secure devices), add that to the config for ZwaveJS and just start it up. Well, stop the old zwave stuff first. Itâll take quite a long time to do all the initial interviews for each node, especially if some are asleep, those could take hours to show up properly, or even a whole day. You shouldnât need to exclude and include everything.
Beyond that, youâll end up with all new entities, which is unavoidable. So youâll need to update all the automations and templates and stuff that used your old entities and point them to the new ones. I donât think thereâll be a migration wizard or anything to automate this, since itâll be very unique to each and every HA instance. Or, once the old z-wave entities are removed entirely, you should be able to rename the new ones to match the old names so templates and automations work properly again. Either way, youâll need to update things manually, and I donât think that aspect of migration will change, tho I could be wrong, and there could be some migration-magic in the pipeline.
Migration is on the roadmap, it may not be a soup-to-nuts, but to me itâs worth waiting to see what that will look like.
3 Likes
Watching the launch party, they are talking about migration right now, could be pretty cool - fully automatic.
Yep, I was referring to the refresh_rate! I had made a note in the comments of my zwave_device_config.yaml to watch out for polling_intensity on me GE dimmer bulbs, but I think I meant to put refresh_rate here.
I fired up a Z-Wave JS Docker container and woke up all my nodes. The GE Enbrighten bulbs work perfect, along with my August Pro Lock 3, Dome motion sensors, and Wink Door/Window sensors.
The only thing giving me issue is I canât adjust the RGB colors or color temp on my HANK Electronics (HKZW-RGB01-V1.0) Z-wave bulbs.
2 Likes
I installed zwavejs2mqtt docker in my Unraid, configured it, added the devices.
Now in HA, Iâm stuck trying to connect the integration moduleâŚ
None of what I tried worksâŚ
Seems to be this settings:
Doesnât workâŚ
Is it the WebUI URL? or something else?
1 Like
You beat me to it. I have Unraid as well and seeing the exact same thing.
I have a number of wireless Zwave devices (locks and sensors). When it talks about âwaking them upâ to get Zwave JS to populate their entities, does that mean pulling them apart and pressing the wake button or merely operating them? Because the former is a huge pain in the ass in some cases, yet I tried operating them and they didnât populate. Will they eventually all populate in the course of 24 hours without any intervention?