The Future of Z-Wave in HA - QT-OpenZWave

Just did the transition from the built in zwave to qt-openwave. Was straight forward with only the hassle of renaming in the entity manage for HA.

Installed via docker-compose. Already had MQTT setup with HA and installed the Z-Wave over MQTT integration via HACS.

Make sure you have an MQTT client to view the messages to make sure your network is online and functioning. It also doesn’t have any GUI based MQTT to do node management at this time.

Looking forward to the full release and the update to include covers.

I’m running hassio on a RPi3, the OpenZwave add-on says not available for my system. Is that intentional? Looking at community add-ons there is that ZwaveToMQTT option so I have to think the architecture can support the OpenZwave binaries.

You need to be running 0.110.0, which is not even in beta yet.

How does this change impact using Z-Wave in HA core in a python virtual environment?

You will need to run ozwdaemon (qt-openzwave) and an MQTT server somewhere. The easiest is with Docker, but you could certainly build it yourself, if capable.

1 Like

Is there a direct migration path from the old OZW1.4 integration to QT-OpenZWave?
Renaming entities isn’t a big deal, but I used the UI automation editor and some of my automations are setup using the newer “device” option rather than entities and I have found (from past experience) these get completely messed up if the device disappears and reappears again, even if it reappears with the same name.

All the more reason to not use the “device” option on something that could potentially get removed and re-added then.

@firstof9
Yes I know that now. Live and learn as they say. I was trying to use the latest features in HA to avoid changing things if they deprecate anything in the future. I realise it was a mistake now :slight_smile:

I’d say using the “device” automations would be ok for something like the pollen sensors or any sensor you setup and just leave it be (usually cloud polling sensors).

1 Like

Is there a migration path from the built in version coming in 110 and the beta version via HACS?

2 Likes

Based on the blog post there is no migration path yet no.

I have to chuckle at the concern some people have about latency - The bottleneck is always going to be at the Z-Wave Level (100kbits/sec in a pure ZW+ network). Any overhead that MQTT etc introduce is going to be negligible

4 Likes

Happy Cake day Justin!
image

1 Like

The cake is a lie.

Are we going to discuss the new integration in this thread or should we start a separate category in the configuration section for new-z-wave or some such?

This whole thread is about the new integration.
That’s what it was started for

I am running the new Beta of HA on my test Pi along with the latest Z-Wave-MQTT. I was previously running on the add-on version and have decided to move to ‘official’ version. In order to get a clear experience I have deleted the existing integration and re-added it. I did not change the configuration on the usb stick.

My test smart plug is showing up in HA but the entity naming does not seem ‘as descriptive’ as the current integration

ie: In the new integration I get:

An equivalent entry in the existing Z-Wave integration represents this as:

sensor.aeotec_zw075_smart_switch_gen5_current

Not sure where the respective integrations are getting their naming from but the old seems more useful.

We still want to add a migration path from the old component to the new component, but there’s a few other higher priority projects we want to knock out first, like finishing platform support (color lights, lock, etc)

4 Likes

color lights… curious, will that support RGBW values for RGB lights as opposed to just RGB values? I’m not 100% sure where that limitation is baked in, i think it might be the mqtt-light code as opposed to the zwave/mqtt. but if we could figure that out, it would be great. (most RGB controllers i have looked at so far set color as RGBW values)

1 Like

@cannfoddr
This is how the official OZW 1.4 integration imports ZWave entities as well. I think zwave to mqtt has it’s own management that can name entities before sending them to Home Assistant, where as the native integration just imports the devices directly.
I am not sure with the QT-Zwave, but I know with the OZW1.4 integration you can just grab your device on the Integrations page and rename the device and it will offer to rename all entities to match. I know, a little annoying but it is a one off thing when you first add a device.
For the record, Homeseer, OpenHab, Smartthings and a few other hubs also import them with default names that you would need to rename within the hub. The hubs have no idea what you would want to call them, so they use the device name as specified in the config for the device.