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

I recently switched over to using dockers for Home Assistant and just got this going. Works like a champ. Even converted my MQTT to a docker as well. Nice work folks.

I don’t have a super complicated setup like some of you (just a few PIRS + door sensors on a Gen5 Aeotec USB stick) but it seems much more stable/faster then the native integration. Had to fix up some automations and sensors/etc but wasn’t that hard. Can’t wait to see how this ends up being prime-time.

Again, nice work!

1 Like

Im struggling with this too. Can you point me to anything that helped you set up the docker?

Currently, I have the integration installed but no idea if the add-on is working.

I installed the docker image:

Here is my dockerfile:

  qt-openzwave:
    image: openzwave/ozwdaemon:latest
    container_name: "qt-openzwave"
    security_opt:
      - seccomp:unconfined
    devices:
      - "/dev/serial/by-id/usb-0658_0200-if00:/dev/ttyACM0"
    volumes:
      - ${DOCKERCONFDIR}/qt-openzwave:/opt/ozw/config
    environment:
      MQTT_SERVER: "ip-address-of-mqtt-server"
      MQTT_USERNAME: "username"
      MQTT_PASSWORD: "password"
      USB_PATH: "/dev/ttyACM0"
      OZW_NETWORK_KEY: "network-key-for-zwave-if-you-need-it"
      QT_LOGGING_RULES: "*.debug=false;ozw.library.debug=true"
    restart: unless-stopped

Then I configured it to communicate with my MQTT docker image (plenty of documentation here on getting that set up. I do it via configuration.yaml vs addon/plugin) with authentication. I’ve used bogus values above in my dockerfile example, you’ll need to use real values here.

In this case, I use the eclipse-mosquitto docker image (which was the same MQTT I ran before I got everything converted to docker images) as seen below:

Once that was all working (check the zwave container logs to verify) all I had to do was remove the native zwave integration in my configuration.yaml and then add the Z-Wave over MQTT plugin via HACS:

image

From there, Home Assistant picked up all my Z-Wave devices. I simply had to change some automations/sensors to use the new names provided (which are not the same as the native integration uses.)

It all just worked. It took me longer to figure out how to spin up docker containers (because I’m new to it) than it did getting it all working. The following config/integrations are mandatory:

HACS
MQTT
Z-Wave over MQTT

As seen here:

Clicking on the Z-Wave MQTT integration shows all your device information:

Hope this helps.

1 Like

These don’t look like directions for home assistant supervised. I believe that’s what @BullieBoy is using.

I guess I run whats called home assistant core – I use it in a container (previously venv) versus hassio + friends. Sorry about that.

1 Like

Anyone know when they’ll get lock support going?

Any bugs or downsides to making the switch to zwave2mqtt? I see in your screenshot it says pre-release has 1.6. I would have to assume you came across some bugs? Great help with the guide but like you said, you spent more time getting docker working than the zwave stuff. That is my problem also. I am running a virtualbox for hassio which is built with a bunch of docker containers. Each addon I installed creates a new docker. Is there a way to have the hassio store install the 1.6 zwave2mqtt? If not, how exactly do I go about adding it in?

how do you manage your zwave devices in qt-openzwave (pair / unpair)? is there a UI of some kind?

It looks like there is a UI. I haven’t installed it yet but just from glancing over the github.

I also found this github but it doesn’t look like the official one that I should be installing for HASSIO?

the qt one is just a stand along application?

Answered my question. Found this community addon.

That’s not qt-openzwave. That’s a competing package Zwave2MQTT.

If you want the home-assistant supervised add-on of the qt-openzwave discussed in this thread, follow directions here. It’s linked in step 5

What is the difference between the addon and qt?

Oh that is what I was wondering. So the community addon isn’t running 1.6? Just that version you linked?

That addon is a 3rd party using openzwave. qt-openzwave is 1st party.

Got everything installed and running. Re-doing my whole network since the old Z-stick died. I can add nodes by putting the stick in inclusion mode etc. and they show up as entities in HA. But there are issues when removing and inserting the stick, OZW can only get hold of the stick 1/5 times or so, which is irritating.

So, I’ve been trying to put the stick into inclusion mode by publishing (via dev tools MQTT console) to “OpenZWave/1/command/addNode/”, which is the relevant topic from my reading of the docs. I listen to “OpenZWave/1/event/#” and check the container logs but alas nothing (only acknowledge that the topic was published).

Anyone in the thread who can enlighten me on commands in general and possibly the addNode command in particular?

thanks

And now I figured out that there are services for this particular thing that actually work (thank you GitHub issue tracker). Still interested in knowing how I can call any particular command using the MQTT console though.

It will be easier if you use an application like MQTT Explorer. Check the docs for the commands and their parameters (OK you said you checked those. :slight_smile: ) Which commands are you trying to use?

Thanks for the reply. I popped of a “OpenZWave/1/command/addNode/” and expected the corresponding event back, but that didn’t happen. I could see it being received in the logs though. Calling the (custom component) built-in service did do the trick, but I wasn’t able to catch the OZW logs from that call before it was below the add-on log fold. I will check the actual file today. Again, mission accomplished (nodes added) but I’m still curious as to what went wrong with my “manual” attempt.

Ah right… :flushed: Despite what the documentation says, the topics must to be in all lowercase, e.g. /command/addnode/.

2 Likes

Awesome, thanks! I should’ve checked GitHub issues better. Always a good idea for projects in this phase. Otherwise, things seem to be working well!

I’m very late to the party, so i don’t expect any change here, but I’m very confused about the rationale for the switchover? For the past year I was under the impression it was just a matter of time that python-openzwave would move to 1.6.

Is it fair to say that this is mostly due to the python-openzwave project being abandoned and it being a lot of work to maintain with api changes? But surely this mqtt solution requires maintenance as well and has the added issue of having mqtt as overhead?

Or is it just because the author’s experience with python is limited? To be clear, I definitely understand that. I would gladly take over the python-openzwave if only I had teh required skills…

The point I guess I’m making is, are we sure this is the most efficient solution? Or shouldn’t more effort go into trying to get the python-ozw project back on track and maybe in an easier to maintain state?

With the current crisis I have half a mind of picking up the project myself, but besides the obvious effort and investment it would require, the chances that it wouldn’t even be used are also holding me back.