Setting up OpenZWave from 0.110

Can you clarify which addon should be used at this time? There is the official “experimental” addon, and there is the custom addon. The docs are currently recommending the custom one, is that the way to go?

As far as I can tell, the official addon will not persist the daemon files (XML configs and more importantly ozwcache*.xml file) and does not support using OZW Admin, but maybe has better MQTT integration? The custom one has data persistence and supports OZW Admin.

I haven’t actually been involved in the addon development side, so I’m not sure what the status is on the official addon. For now I’d follow the recommendation in the docs.

Thanks for the reply. So on the release notes for the beta:

It talks about several items that need to be done. Are we saying all I need to do is to install this integration? If so why did it say to setup an MQTT Server? Then install the ozwdaemon. Then install the integration?

It appears so. But see post 7 above for a UI Setting up OpenZWave from 0.110

I dont understand from the doc, how to enter the network key in the “configuration” tab under the addon. Are there any examples of the format expected etc? With the old zwave, it was in this format: zwave_network_key: "0x01, 0x02, ... ", however, that does not seem to work.

I am totally agree that it is totally confusing. I can tell you what I did.
I had my z-wave devices connected to the my controller through the original hass z-wave integration. with the following instructions:

To migrate to the new beta integration:

  1. delete old z-wave config/ integrations. (keep a note of the network-key that you used).
  2. Install the new beta openzwave addon.
  3. In the configuration, use the same old network-key and add the correct usb path for the controller, then start the addon.
  4. If you don’t have a MQTT broker/integration, you need to setup one. The easiest one is Mosquitto broker addons
    a. install Mosquitto broker addons.
    b. Configure username and password with your own.
    c. In the integrations section, add new integration for MQTT broker (I remember it will actually show up in the discovery)
  5. Add the new " OpenZWave (beta)" integration from the integration section.
  6. it will take some seconds/minutes, then you will see the controller as a device in the new integration.
  7. Then, The controller will start to build the network again, and you will see old connected sensors showing too in the integration as connected devices.

One thing that I like about the new integration, it won’t affect the z-wave network with hass reboot. At the same time, I was able to use the USB path based on the id of the controller, rather than /dev/xxx[01] , which may change depend on which controller connected to my raspberry pi detected first. The latest pros wasn’t possible with z-wave-to-mqtt addons.

4 Likes

I’ll have to give it a try, hoping OZW fix the problem I have with my two GE dimmers

Great guide. On what format did you enter the network key in the config? And did you enter it from the web-ui? (Some doc pages says it cant be added there, other says it can.)

You can generate a random key using the following commands:

cat /dev/urandom | tr -dc '0-9A-F' | fold -w 32 | head -n 1 | sed -e 's/\(..\)/0x\1, /g' -e 's/, $//'

as per the Z-Wave Documentation:

So if installed Z-Wave over MQTT (Pre-Release) through HACS, should I remove it since it is now in CORE?

I got it running side by side at first. This allowed me to setup some specific things like a scene activation by double tap and dynamic change of certain dimmer parameters; I have bedroom and bathroom dimmer with a low “forced switch on brightness” setting at night and 100% at daytime. I also have a roller shutter which is not supported (yet) so I needed to setup the MQTT Cover component.

Once setup I fired up QT-OpenZwave and now I am ready to disable the “old” zwave component.

Downside is that I had to rename all devices in automations.

If you are having an issue where your dimmers aren’t reporting state changes correctly, add the following to the zwave section of your configuration.yaml (you’ll need to add this for each dimmer):

  device_config:
    light.kitchen_lights:
      ignored: false
      polling_intensity: 1
      refresh_value: 2
      delay: 3
1 Like

Thanks a lot for your help. Unfortunately I already have that config… The problem I’m experiencing isn’t related to the UI not refreshing.

Rather, it’s the dimming that is applied by the hardware, at best, 1 time out of 4. On/Off command is working 100% of the time, but dimming using a light card on then dashboard isn’t.

I end up most of the time having to fiddle with the brightness slider 3-4 times before the dimmer finally react accordingly. I tried varying time between each adjustments (2 seconds to several (like 60+) and it doesn’t change anything.

I checked the log and all commands are sent and response received. There’s no difference in the log between a successful dim and an unsuccessful one.

I have the key, the problem is how to enter it in the webui. :slight_smile:

I’ve tried : zwave_network_key: "0x01, 0x02, ... ", but that does not work, it gets replaced with

zwave_network_key:<
0x01, 0x02, ... 

for some reason?

I removed the Open Z-Wave Daemon Addon and the Z-Wave over MQTT Integration. The new addon and Integration finds all my devices, however i need to rename all devices and entities again. I’m considering rolling back to Z-Wave over MQTT (Pre-Release) and waiting a little longer for a migration tool.

This totally hosed my Zwave network that has been rock solid for years now. Documentation is not well written and has cost many hours of troubleshooting. There should be standards before coming out of beta.

Thats why it is still in beta. What issues did you run into, perhaps submit issues so they can be rectified. The software clearly states it is still in development so you only have yourself and what has been written as guides by others here so far.

I have a small zwave network so didn’t run into any issues but users with larger networks like yourself should definitely detail what specific things you encountered to improve it.

Been in IT and Development for many years and understand beta releases, however this is more like a ALPHA release then a beta. And IMO it should not be published out to the masses, To many issues, documentation is not well written, and just not mapped out very well.

2 Likes

If you really do work in IT, then I’m sure you recognise the risks you take when you CHOOSE to install software that is very clearly marked BETA.

1 Like

That’s not the point @ccollinscj is trying to make. He is saying that the way it was released it does not deserve a BETA status, which I agree with. Very unorganized release. I was unable to find any official documentation describing changes and mentioning removal of the current config gui and all of the features tied to it. I don’t even see anything describing what is wrong with the current Z-Wave functionality and why is it getting replaced. This is a huge breaking change for people. My network is small and I was able to rollback, but i did have to spend some time getting things to run properly after realizing that this “BETA” crippled my current Z-Wave situation and added absolutely nothing of value.

1 Like