The documentation should clearly state what is currently missing, when I read the release notes and the OpenZWave page, it doesn’t state anywhere that locks, covers and other items are not currently working.
The OpenZWave page should be updated so at least it would save some people time who try to install it and realize that not all of their stuff is supported.
I think they covered it pretty well in the release blog
It is still early days for this integration, though; not all platforms and devices are supported yet and the setup process has prerequisites that raise the accessibility bar. See our documentation for the current requirements and instructions.
If you want to give it a shot, you should be comfortable with setting up custom add-ons and MQTT. There is no migration from the current Z-Wave integration yet, this is still to come.
The plan is to add more platforms in the future, making it super simple to set up the integration. Stay tuned.
There is currently no plan to deprecate the existing Z-Wave integration. But the hope is that the new integration, in the future, will offer a simpler, more stable and more feature-rich experience than the current Z-Wave integration.
I agree completely. It would be helpful if the statements from the release blog were also included to the top of the OpenZWave (beta) integration page
That said, while there are still things missing from Home Assistant, anyone one willing to raise the accessibility bar can still configure any of their devices using mqtt directly. There are two examples in this thread HERE and HERE.
In playing around with the new qt-ozw in my second HA instance (supervised) I came up with a question…
Now that qt-ozw is separated from the HA environment can we run the zwave over mqtt integration on more than one instance and control/get status from the zwave stick/devices from both instances?
I would assume since it’s over mqtt you could setup a production and test environment and just tap into MQTT for the devices. Shouldn’t really conflict.
I think it worked.
I never got around (yet…) to actually pairing any zwave devices to my second Zwave stick. I really need to get that done so I can start testing this…
Hey - I connected ozw-admin to the OpenZwave Add on and changed all the node names. I then restarted OZW Addon (and therefore the daemon) and when it comes back the names are gone. Is there some kind of save I need to do to make the node names permenant?
Thanks.
Hello all,
there are a way to migrate to the new Zwave (beta) from the old one without lost all configuration ?
Thx
From the release blog
f you want to give it a shot, you should be comfortable with setting up custom add-ons and MQTT. There is no migration from the current Z-Wave integration yet, this is still to come.
I don’t have much experience with Docker – Have you setup a volume to store store the persistent data?
I assume the Zwave network config is stored on the controller, so the only thing you would need to migrate to get basic functionality is the secure key from HA to ozwdaemon. Today in HA you would need to manually rename the entities back the original names to get your UI/automations working. I assume if we ever have a GUI migration it will use the node numbers as the “key” to migrate the nodes.
Does ozwdaemon need to keep any information/state between restarts? I figure the daemon can just query the controller on a restart to get its initial configuration, so it not a big problem if we lose the data mapped to /opt/ozw/config in the docker volume.
DISCLAIMER: I haven’t tried this though, since I am not sure if my thermostat is supported yet on the beta.
OZW keeps a cache file (named ozwcache*.xml, formerly zwcfg*.xml). It will be rebuilt it it’s missing, so it’s not critical, but losing it every restart would be pretty annoying and something you’ll want to avoid. Mains-powered devices will be queried right away, but it will lose information about battery devices until they wake up again. The node names would usually be stored in the cache file and only the cache file, as most devices do not implement the node naming functionality. I don’t think the official OZW Addon currently keeps any persistent data, so that could explain why node names are lost, but I could be wrong as I’m not an addon user.
There are also a number of users that are having major issues related to cache corruption. Even deleting the cache file does not help because errors during startup (i.e. dropped commands) will cause the cache entries to be empty.
Climate devices are supported in the dev builds. You could actually run two separate instances of HA at the same time, one stable and one dev if you wanted (I’m doing that).
Correct
I would suggest this might be important to keep persistent, here’s why
I used ozw-admin to give “Node Names” to all my nodes – this will also rename all the entity_ids of the device to match the new Node Name in Home Assistant
My experience is that losing /opt/ozw/config volume will also lose any “Node Name” you have assigned – Thus resetting all the entity_ids in Home Assistant.
I just downloaded the latest ow-admin release file for OSX and when I try to connect to Cassio I am getting an error:
Followed by a segmentation fault.
I had the same message - I had to pull the latest ozwdaemon image.
I’ll say though - I’m reverting back to the previous version of ozwdaemon ( likely the version you are currently running )-- The newest release of ozw-admin, while it includes some UI and other improvements, there are some regressions in other areas. IMO the (temporarily) lost functionality is worth more than the improvements – Please keep in mind, this ozw-admin is very much alpha so these kinds of bugs or breaking changes are likely
EDIT to say, the screen shot included the previous post is the older version of ozw-admin that I am reverting back to ( the reason I’m reverting to older ozwdaemon )
In the newest version of ozw-admin – There are no value being populated the the configure node tab
I agree. using these “Node Names” is much more convenient then renaming in HA, and these should be remembered after restart of ozwdaemon to prevent misconfiguring all sorts of stuff in HA. I don’t see the point of not remembering the cache file…
Hey guys, I installed it like this:
But cannot connect to it via port 1983… my home assistant ip is 100% correct 
To be sure: you click on the lower Start button right? This shouldn’t be a problem to connect…
EDIT: my interface looks completely different:
I don’t have the add node / heal network etc menubar. Is this on windows?
Really sorry for the noobish questions, but from https://www.home-assistant.io/integrations/ozw/ I understand nothing about what to do after installation.
What I did (on a fresh HA install dedicated to testing this out) was:
In the OpenZWave (beta) integration I see 1 device - “ZW090 Z-Stick Gen5 EU”
So my question is: now what? The docs say to call SERVICE OZW.ADD_NODE, but with what payload? None? If I just press the Call Service button for this service, nothing seems to happen…I tried also to take the stick to a plug I want to add, it kinda seemed to have added it according to the lights, but I can’t see it in HA.
Do I need to “listen” with something like MQTT Explorer? I did connect with MQTT Explorer and saw 2 nodes:
I assume this is the Aeotec stick:
{
“NodeID”: 1,
“NodeQueryStage”: “Complete”,
“isListening”: true,
“isFlirs”: false,
“isBeaming”: true,
“isRouting”: false,
“isSecurityv1”: false,
“isZWavePlus”: false,
“isNIFRecieved”: false,
“isAwake”: true,
“isFailed”: false,
“MetaData”: {
“OZWInfoURL”: “”,
“ZWAProductURL”: “”,
“ProductPic”: “”,
“Description”: “”,
“ProductManualURL”: “”,
“ProductPageURL”: “”,
“InclusionHelp”: “”,
“ExclusionHelp”: “”,
“ResetHelp”: “”,
“WakeupHelp”: “”,
“ProductSupportURL”: “”,
“Frequency”: “”,
“Name”: “”,
“ProductPicBase64”: “”
},
“Event”: “nodeQueriesComplete”,
“TimeStamp”: 1590670650,
“NodeManufacturerName”: “AEON Labs”,
“NodeProductName”: “ZW090 Z-Stick Gen5 EU”,
“NodeBasicString”: “Static Controller”,
“NodeBasic”: 2,
“NodeGenericString”: “Static Controller”,
“NodeGeneric”: 2,
“NodeSpecificString”: “Static PC Controller”,
“NodeSpecific”: 1,
“NodeManufacturerID”: “0x0086”,
“NodeProductType”: “0x0001”,
“NodeProductID”: “0x005a”,
“NodeBaudRate”: 100000,
“NodeVersion”: 4,
“NodeGroups”: 0,
“NodeDeviceTypeString”: “Unknown Type (0x0000)”,
“NodeDeviceType”: 0,
“NodeRole”: 0,
“NodeRoleString”: “Central Controller”,
“NodePlusType”: 0,
“NodePlusTypeString”: “Z-Wave+ node”
}
What is this one, though? The Fibaro plug that I tried to add? Doesn’t really look like it…
{
“NodeID”: 4,
“NodeQueryStage”: “ProtocolInfo”,
“isListening”: true,
“isFlirs”: false,
“isBeaming”: false,
“isRouting”: false,
“isSecurityv1”: false,
“isZWavePlus”: false,
“isNIFRecieved”: true,
“isAwake”: true,
“isFailed”: false,
“MetaData”: {
“OZWInfoURL”: “”,
“ZWAProductURL”: “”,
“ProductPic”: “”,
“Description”: “”,
“ProductManualURL”: “”,
“ProductPageURL”: “”,
“InclusionHelp”: “”,
“ExclusionHelp”: “”,
“ResetHelp”: “”,
“WakeupHelp”: “”,
“ProductSupportURL”: “”,
“Frequency”: “”,
“Name”: “”,
“ProductPicBase64”: “”
},
“Event”: “nodeProtocolInfo”,
“TimeStamp”: 1590673125,
“NodeManufacturerName”: “”,
“NodeProductName”: “”,
“NodeBasicString”: “Routing Slave”,
“NodeBasic”: 4,
“NodeGenericString”: “Binary Switch”,
“NodeGeneric”: 16,
“NodeSpecificString”: “Binary Switch”,
“NodeSpecific”: 0,
“NodeManufacturerID”: “0x0000”,
“NodeProductType”: “0x0000”,
“NodeProductID”: “0x0000”,
“NodeBaudRate”: 0,
“NodeVersion”: 0
}
Seems there was an update to fix a connection issue when connecting to the ozwdaemon “addon”
This likely explains
@foxy82 might have the answer – from discord
I think you probably need this ozw-admin: http://bamboo.my-ho.st/bamboo/browse/OZW-OZW-96/artifact
However one other thing to note - the OpenZwave (Beta) Add on - will lose your network config each restart for that reason i’d probably recommend running ozwdaemon in your docker rather than the addon
I already had that version downloaded and installed:
http://bamboo.my-ho.st/bamboo/browse/OZW-OZW-WB-96/artifact
OpenZwave Admin-0.1.0-installer.exe
now opening again gives me:
Need to pull the latest ozwdaemon container
