Selecting that I got an error. I did find where to update that if it helps anyone else. It was in File / Preferences / Network Tab and then I updated it to 2000.
I was able to find where to update the polling interval. Thank you!!
So after dreading moving over to the new integration for weeks it ended up being trivial. Fine, I had to manually rename entities to match the original but it was an opportunity to do an audit and see what I actually had. I also did some cleanup.
Thanks to all involved in this integration. Happy customer here.
1 Like
HI, i followed the instructions and i get a message saying:
You have more than one OpenZWave instance running. Which instance would you like to manage?
and there is nothing else in the window to select. I already stopped the network on the zwave integration.
Ideas?
This usually happens when the MQTT integration isn’t configured.
it is configured and all my MQTT devices working as expected
The only other reason it would happen is the OpenZWave/# topic is missing.
well, looks like i missed an obvious step here…i didnt know i had to setup a fully separate ozwdaemon docker to use this.
the original post didnt say that, maybe obvious to others. So iguess i have to do the following:
- Remove the zwave stick port mapping from my HA docker file
- Restart it (it will be a mess b.c of all the entities not responding
- Get an ozwdaemon docker up ad running through MQTT
- Add the OZW beta integration on UI
is this correct?
Sounds about right.
so i did the test and switched to OZWbeta from the Zwave integration. Found many issues, maybe someone can help, here is what i did:
- I installed the ozwdaemon docker
- Confirmed that it was working via the ozwadmin - i could see “most” devices
- The battery-based devices sometime show up, sometimes they didnt.
- Waited 3 hours or so, i operated them to make sure there was transmission, some of them were present but had all blank info on it. This is all observed from ozwadmin, in HA they mirror the ozwadmin state which was blank. Not sure why. i tried to heal them, etc to no success
- I took one of those and excluded it from the network and re added it. It worked but then after 2 reboots it went also to the dead zone.
- I restored the configuration with the zwave native client in HA and everything was back as normal, so i am glad i didnt lose all those devices and i am able to switch back and forth.
The value of this for me is to avoid the long restarts of HA and restarting the network. But the OZWdaemon/admin combo for some reason is not able to see all the devices. Note that i am running my network unencripted, not zwave plus. I just have too many devices and those battery operated devices are in locations that is hard to go there one by one and re-include them in the network.
Any hints or configuration ideas to make ozwdaemon work and see all the devices? for some reason some of them seems to not be recognized properly. It is the OZW version 1.6.xx, the latest docker tag.
Wake your battery devices up via the wakeup process listed in your device’s manual. Operating the sensor does NOT wake a node.
Please stop doing this, it doesn’t do what you think it does.
the device manual does not list a “wake up” procedure. i waited literally for hours, and the node id was listed in ozwadmin but all fields were blank. When i reloaded the old config, on HA it works as usual. Are there any settings that can be reset on the ozwadmin controller to facilitate the process?
What device do you have? Make and model number is best.
ok, so i did what you said, and yes it works now. Some notes for other to take into consideration when migrating, as it is not obvious:
-
Take note of your node_id and entity/device names in the regular zwave before switching, you are going to have to rename everything and you want it to match or at least know which device is which.
-
Stop HA and start ozwdaemon
-
Wait a long time and watch ozwadmin to check that all devices have names and are not blank. Specially battery devices, you have to wait until they wake up on its own to update the controller, that can be in some devices upto a day or even more.
-
So the workaround to #3 is to “wake” the devices. i didnt know that operating them will not wake them. the “wake” is a procedure that actually sends node update info to the controller. This is needed to populate all the fields and the devices to be recognized accordingly by the controller (now running under ozwdaemon not HA anymore) when you see the “product” column empty (see picture) it means the device has not fully updated the controller. Wait until that happens or “wake” the device
-
Devices that need wake up are the battery devices. Either wait a long time or see the manual on the procedure to wake them. Most manuals say how, but not all. Example i have a few smoke detectors (first alert). Those are tricky and i had to wake them 3 times in order for the configuration to complete.
-
When all devices are recognized properly by ozwdaemon. The “product” column will be populated for all devices. What i did was to make sure all devices where seen properly in ozwadmin by looking at the “product” column and looking at “QueryStage” in the node status tab. They all showed “complete”
-
After making sure all was goos in ozwdaemon and ozwadmin, then i added the ozwbeta integration in HA and it picked up all devices shown by ozwadmin
Then have fun renaming every one of them, i had to rename 39 
The main benefit of this is that the Zwave network will run independently from home assistant, easier to debug, easier to maintain and minimize all the issues listed above everytime you restart home assistant. In my case i have all this running on a NAS 24/7 in docker containers, so i am glad i did this, so the ozwdaemon docker remains on all the time with no disruption at all. This is defiitely the way to go. Also the ozwadmin is a great tool to monitor and debug any zwave issues you may have
Thanks @firstof9 for point out the “wake” procedure
I hope this helps others
1 Like
Caveat: Renaming should be done entirely from inside Home Assistant, this will make your life tons easier in the future as those names (in Home Assistant) are linked to the node id. So the names should persist as long as you have a backup of your .storage directory.
Yes within HA correct
it was all good… until i noticed the zwave network not respoding. ozwdaemon is not responsive, this is on the logs:
020-10-12 16:15:33.456057749 [20201012 9:15:33.455 PDT] [ozw.library] [debug]: Detail - Node: 25 Queuing (Send) SwitchMultilevelCmd_Get (Node=25): 0x01, 0x09, 0x00, 0x13, 0x19, 0x02, 0x26, 0x02, 0x25, 0xe0, 0x1f
2020-10-12 16:15:33.456214517 [20201012 9:15:33.456 PDT] [ozw.logging] [debug]: popping Log Mesages
2020-10-12 16:19:01.752918622 [20201012 9:19:01.752 PDT] [ozw.library] [critical]: Error - Node: 0 ERROR: Not enough space in stream buffer
2020-10-12 16:19:01.753120330 [20201012 9:19:01.753 PDT] [ozw.logging] [debug]: popping Log Mesages
2020-10-12 16:19:01.754803761 [20201012 9:19:01.754 PDT] [ozw.library] [critical]: Error - Node: 0 ERROR: Not enough space in stream buffer
2020-10-12 16:19:01.754856597 [20201012 9:19:01.754 PDT] [ozw.logging] [debug]: popping Log Mesages
2020-10-12 16:19:02.727548386 [20201012 9:19:02.727 PDT] [ozw.library] [critical]: Error - Node: 0 ERROR: Not enough space in stream buffer
2020-10-12 16:19:02.727738826 [20201012 9:19:02.727 PDT] [ozw.logging] [debug]: popping Log Mesages
2020-10-12 16:19:02.729188977 [20201012 9:19:02.729 PDT] [ozw.library] [critical]: Error - Node: 0 ERROR: Not enough space in stream buffer
2020-10-12 16:19:02.729296665 [20201012 9:19:02.729 PDT] [ozw.logging] [debug]: popping Log Mesages
2020-10-12 16:19:03.727688730 [20201012 9:19:03.727 PDT] [ozw.library] [critical]: Error - Node: 0 ERROR: Not enough space in stream buffer
2020-10-12 16:19:03.727819362 [20201012 9:19:03.727 PDT] [ozw.logging] [debug]: popping Log Mesages
2020-10-12 16:19:03.729424625 [20201012 9:19:03.729 PDT] [ozw.library] [critical]: Error - Node: 0 ERROR: Not enough space in stream buffer
any ideas? some people point to a usbstick power issue. But it is directly connected to the PC (NAS) in this case. and never saw this error with the old HA zwave integration that i had running for 3 yrs at least
Are you running the build-150 or “latest”?
i am running
openzwave/ozwdaemon:latest
There’s an issue reported regarding the buffer:
yes, i saw that, the only useful thing i found was here:
But i don’t see any hints to resolution, they seem to be pointing out to a usbstick power issue, which is not the case.