What happens if I restart without switching back?
If I want to start using this beta on a more permanent basis, what additional steps are needed?
Thanks!
Remove the old zwave configuration settings.
Stopping the network releases the USB stick so the ozwd container can use it, so if you restart without turning one of them off, they’ll fight over the USB stick and you’ll have a bad day.
Sorry if this was answered here before, but is there a way to migrate all existing entity/device names over to the new beta?
I followed the guide at the top of the page, everything started up without a hitch … and then I saw 55 devices and 280 entities I would have to rename. That’s a naww for me dawwwgg 
…Thankfully the switchback went without a hitch as well.
They are working on creating some script or similar for an easier migration.
2 Likes
So, I bit the bullet and made the switch to the new OZW Beta yesterday.
All in all, it was pretty painless, although it of course took some time. I have about 60 devices and 500 entites (but the majority of entities are not actually in use), and it took about two hours before I had the home 80-90% up and running again. Then it took a while longer to go through and verify and fix all the little stuff that did not have consistant naming etc. One device needed to be removed and re added to OZW, but that also was pretty easy.
I basically followed the guide in the first post, but with a few more details outlined here.
First, I used this template in the template editor in developer tools to get a list of all my active zwave-devices in the old integration:
{% for state in states.zwave %}
{%- if state.attributes.node_id %}
{{ state.attributes.node_id }} - {{ state.entity_id }} - {{ state.name }}
{%- endif %}
{%- endfor %}
I took this list offline just to be sure.
Then I made sure I set wake up interval to a few minutes on all the battery powered devices (I actually missed two, but that was entirely my own fault)
I then added the OZW Beta as described in the first post.
After the devices were added to the Integration, I did a rename of the device to the old name, according to the list of Node IDs I already had.
- Just be aware that you should wait for all the entities to show up for each device before doing the rename. That allows the renaming to trickle down to the entites. If you do it to early, the renaminig wont work for new entites as they come in.
Here I also had to push the “wake up” button for the two missing devices. They were easy to find because I had the list of what should be there from the first step.
To test it further, I renamed a few of the entity_ids from the old ZW intergration to “switch.xxxxxx_old” and “light.xxxxxxx_old” and “binary_sensor.xxxxx_old” etc. And I then renamed the new OZW Beta entities to the old names.
I then verified that the automations worked as expected and that I could see the correct info in lovelace for the ones I tested.
I then made the leap. Removed the old ZW Integration. That effectively removed all the old entities, so it was just a matter of doing a change of the entity_id for the new ones. I guess about 150-200 entity_ids all in all that are actually used. Not the most funny part, but doable.
I did not change any options in qt-openzwave, all names and entity_ids are local to Home Assistant only.
One node did not work correctly (the switch would turn on, but not off again, for some weird reason) so I removed it and re added it using ozw-admin.
So now I can restart HA with a bit more confidence when I add new sensors and integrations etc.
8 Likes
So, I’ve tried to test the OZW a few times, but each time with little success.
Listening to OpenZWave/1/Status/ I get a single message reporting "Status": "driverReady". That’s it.
The OZW add-on log is flooded with these messages:
[20200819 10:03:37.738 CEST] [ozw.logging] [debug]: popping Log Mesages
[20200819 10:03:37.741 CEST] [ozw.library] [info]: Info - Node: 3 Received SwitchMultiLevel report: level=0
[20200819 10:03:37.741 CEST] [ozw.logging] [debug]: popping Log Mesages
[20200819 10:03:37.744 CEST] [ozw.library] [debug]: Detail - Node: 3 Value Updated: old value=0, new value=0, type=byte
[20200819 10:03:37.745 CEST] [ozw.logging] [debug]: popping Log Mesages
[20200819 10:03:37.747 CEST] [ozw.library] [debug]: Detail - Node: 3 Changes to this value are not verified
[20200819 10:03:37.747 CEST] [ozw.logging] [debug]: popping Log Mesages
[20200819 10:03:37.749 CEST] [ozw.library] [debug]: Detail - Node: 3 Notification: ValueRefreshed CC: COMMAND_CLASS_SWITCH_MULTILEVEL Instance: 1 Index: 0
[20200819 10:03:37.750 CEST] [ozw.logging] [debug]: popping Log Mesages
[20200819 10:03:37.752 CEST] [ozw.notifications] [debug]: Notification pvt_valueRefreshed: 55148561 Thread: 0x7f8c9262cd48
[20200819 10:03:37.754 CEST] [ozw.mqtt.publisher] [debug]: Publishing Event valueRefreshed: 55148561
[20200819 10:03:37.802 CEST] [ozw.library] [debug]: Detail - Node: 0 Unsolicited message received while waiting for ACK.
[20200819 10:03:37.802 CEST] [ozw.logging] [debug]: popping Log Mesages
[20200819 10:03:37.805 CEST] [ozw.library] [debug]: Detail - Node: 3 Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x03, 0x03, 0x26, 0x03, 0x00, 0xd7
[20200819 10:03:37.806 CEST] [ozw.logging] [debug]: popping Log Mesages
[20200819 10:03:37.809 CEST] [ozw.library] [info]: Info - Node: 3 Received SwitchMultiLevel report: level=0
[20200819 10:03:37.809 CEST] [ozw.logging] [debug]: popping Log Mesages
[20200819 10:03:37.812 CEST] [ozw.library] [debug]: Detail - Node: 3 Value Updated: old value=0, new value=0, type=byte
[20200819 10:03:37.812 CEST] [ozw.logging] [debug]: popping Log Mesages
[20200819 10:03:37.816 CEST] [ozw.library] [debug]: Detail - Node: 3 Changes to this value are not verified
[20200819 10:03:37.816 CEST] [ozw.logging] [debug]: popping Log Mesages
[20200819 10:03:37.819 CEST] [ozw.library] [debug]: Detail - Node: 3 Notification: ValueRefreshed CC: COMMAND_CLASS_SWITCH_MULTILEVEL Instance: 1 Index: 0
[20200819 10:03:37.819 CEST] [ozw.logging] [debug]: popping Log Mesages
[20200819 10:03:37.822 CEST] [ozw.notifications] [debug]: Notification pvt_valueRefreshed: 55148561 Thread: 0x7f8c9262cd48
[20200819 10:03:37.824 CEST] [ozw.mqtt.publisher] [debug]: Publishing Event valueRefreshed: 55148561
Not sure where to go from here…
EDIT: OK, so I was probably just being impatient. I waited it out - took about an hour for only 4 nodes - but now I have "Status": "driverAllNodesQueried". Yay!
You are insane renaming 60 devices! 
I am gonna wait till they figure out some migration script. Proprs for going through it all.
That part did not take long. How much time for each device? Start at the top of the OpenZwave integration-page, click the device, find the node_id on the device page, look it up in the list of old device names and copy that. Edit, change the name, click “ok” a couple of times, and move on to the next device… maybe 5 seconds for each?
So with 60 devices, that is 5 minutes all in all.
Changing the name of the entities was a bit more work, as I did not have a full list of all the entity_ids that are actually in use in all the automations, scripts, template-sensors, lovelace ui etc. But all the major ones, like the lights and switches, motion, illumination, humidity and temperature sensors were pretty quick since they had been renamed already when renaming the device, and they all follow a common pattern when it comes to entity_ids.
That is why I said I guessed around 90% was up again after an hour or two. It’s not something I would do every day, but as a one time job, to get away from the extreme annoyance of restarting the zwave-network each time HA restarts, I think it was worth it.
1 Like
I setup the new OZW Beta and think it would like to use it full time now. I have a question about the network_key part. I only have 1 secured device on my network. It’s one of the First Alert smoke detectors. I looked at my old config (/.storage/core.config_entries):
"data": {
"network_key": null,
"usb_path": "/dev/ttyUSB0"
}
Does that mean if I generate a key, as suggested in the ozw add-on documentation, that my secured device won’t transfer over? It hasn’t yet, but those are battery devices and I haven’t bothered to pull it down and do the wake up procedure. Thanks!
Do you have a key set in your configuration.yaml or options.xml file?
If no you have no secure nodes and setting a key will not break anything.
I have this in options.xml (key redacted), but the line is commented out, so I assume it isn’t applicable :
<!-- <Option name="NetworkKey" value="blahblah" /> -->
<!--
I do have 1 secure node. So If I have to re-associate, it’s not horrible…
If it is in fact secure somehow, yes you’d need to exclude and re-include the node into your network.
Those smoke detectors I hear are finicky you may need to do the battery trick a few times to get it to complete the inclusion. I recall someone having to pull the battery while holding the button then insert the battery until it beeps then release.
1 Like
Hello guys,
I just followed the guide (first part, I’m on HASSIO on Docker (Ubuntu Server as host)) but I stopped on the last part.
When I open the “OZW admin console” and try to connect to my serial, the console suddenly disconnects.
Below you can find the addon logs
I just checked on my host about the port 1006 but it’s actually in use
Thanks for your help
If you use ozw-admin from the “all in one” installation, you need to “network connect” not “serial connect”.
Just click in the bottom “Start”-button on the connection screen.
1 Like
Thanks Olen, it worked.
Passing from Z-Wave (legacy) to the new OZW, should I re-pairing all my nodes or the will be added once awaked? Sorry for the noobed question…
Moreover, why the interface doesn’t show Z-Wave Plus as a capability of my stick?
Thanks again
Moreover, why the interface doesn’t show Z-Wave Plus as a capability of my stick?
+1
All sleeping nodes will show up when they wake up.
When I switched over, I started a few days before, and set the wake up time to 300 or 600 seconds for all of them, and waited until they all had gotten the new config (except two that I missed). Ten I changed them back to whatever I wanted after the switchover…
Thanks again Olen, once at home I’ll check.
Any info on the zwave plus capability side?
Thanks
Ignore the missing ZW+ on the stick, it’s a display bug that’s getting worked on.
Ok, thanks fistof9