A quick question, are RFID keypads supported already?
I’m getting this error:
My conclusion: “the future of z-wave and home assistant is very vague”. Nothing is working ok, and nothing is clear…
I really hope I will be able to see the light in the near future.
Might I ask if that same Raspberry Pi hosting qt-openzwave also hosting your Home Assistant instance? Thanks!
Try to remember this integration is still BETA and the limitations are very clearly labelled. The old OZW1.4 integration is not being deprecated and is available for use for those who want full ZWave support. The new integration is for the early adopters, willing to take the bumpy ride and report the issues at hand
4 Likes
No, I’m running Home Assistant Core (virtualenv) on FreeNAS, I set up the RPI specifically for qt-openzwave. – I also made an outline of minimal steps to setup RPI for qt-openzwave.
1 Like
Great post troy! Looking at my devces using ozw-admin i can see the options i’m missing within HA so it looks like the OpenZwave integration component is the problem…
EDIT: everything seems to be there in the ozw-daemon, just the HA integration is lacking support for a couple of devices. I worked around it by creating MQTT switches for all missing zwave functions. For instance, to turn on/off my Qubino Heat and Cool thermostat:
- platform: mqtt
name: "Handdoekverwarming"
state_topic: "OpenZWave/1/node/11/instance/1/commandclass/64/value/189792276/"
command_topic: "OpenZWave/1/command/setvalue/"
value_template: '{{value_json.Value["Selected_id"]}}'
state_on: "3"
state_off: "0"
payload_on: '{"ValueIDKey":189792276, "Value":3}'
payload_off: '{"ValueIDKey":189792276, "Value":0}'
So as long as these devices are not part of the new zwave integration i can still use them.
3 Likes
Any idea of the best way to set multiple value ID keys to the same value?
I have 16 switches and collecting value ID keys to put into different flows/automations is quite the onerous task…
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.
1 Like
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…
1 Like
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?
1 Like
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
Click to show screenshot of missing config values
