Setting up OpenZWave from 0.110

Config flow happens when you add the integration in the UI, ie this Did Click on Configuration > Integrations > + > OpenZWave (beta)

What dialogs you get there depend on the integration, eg whether you need a password or whatever.

This one looks pretty simple: https://github.com/home-assistant/core/blob/a82900ae275560acf1093a5cdd288be6683979e4/homeassistant/components/ozw/config_flow.py

Looks to me (and I am no expert) that it just checks a couple of things and there is no input required.

There an official add-on now ?

I did the migration from my original z-wave integration for Hass to the new docker one… eventually all my connected devices show up in the new integration.

But I still don’t understand how to add new device or remove them with the new integration!
I only see new extra services added:
ozw.add_node
ozw.remove_node

I am not sure, are there any UI to observe the status of the usb/hub with the new integration!?

You’ll need to download and setup an mqtt client to observe the node messages easily when you execute those services. The built in MQTT listener in the Developer Tools is very basic.

1 Like

Thanks, That’s help a bit… I was able to see the status with mqtt listener… a bit hard to understand though.

But overall, I am happy that my sensors won’t lose status with hass restart … I will be excited with the improvements :slight_smile:

We haven’t built a UI for the new component yet. However, OpenZWave has a standalone UI that’s in development that people have had success with: ozw-admin.

1 Like

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?