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

Configuration Z-Wave
61

Thanks. I’ll have to manually migrate the security key by looks of things at the moment.

62

I have been using Z-Wave integration for several years and only once had to rebuild the network, and that was because I screwed up an experiment.
I have found sometimes a full reboot will require another restart of HA to get the Z-Wave Network to run, but never as often as you are having. Maybe you have a rogue device on your network? That may not be helped by the new integration.

1 Like
63

The ozwdaemon can be installed outside of the docker container. I’m doing this on a RPi running Archlinux ARM.

The Arch PGKBUILD is available here and will hopefully be added to the AUR in time. For other OSes, the process captured in the qt-openzwave Dockerfile and my PKGBUILD suggest how it can be installed. The tricky part is getting the dependencies in order since the packages needed will likely be different in name and number under different distros or might require source-builds.

A couple of things I’ve noticed about the daemon in it’s current state (and none of the negatives should be taken critically of the devs; I know it’s a work-in-progress and I’m really excited about this project and the efforts being put into this. I’m hoping I can use my experience to help contribute):

  • shutdowns don’t seem to be graceful. In particular it doesn’t seem to update the ozwcfg or ozwcache before just exiting. And could be wrong, but I don’t get the impression that message queue topics get a last-will-and-testament or if the behavior/content of such a message can be configured. I see this as topics sometimes (but not always) being unavailable in HASS after a daemon reboot until the node wakes up to check in (which can be hours if left alone).
  • My own ignorance of low-level zwave leaves me confounded about where/how to best set runtime config values like the zwave network key. Envvars passed through a systemd service file are what I’m using, but I wish I knew a more appropriate way (the ozwdaemon.ini file?).
  • I’m at a loss for managing the zwave network without the HASS zwave integration UI. The zwave-mqtt component allows some management service calls, but getting the right parameters often requires a copy of the device’s technical manual in-hand.
  • The docs are obviously a work-in-progress so it takes a little digging through code to find the authoritative way to do things.
  • https://github.com/OpenZWave/qt-openzwave/issues/15 requires one to allow anonymous connections on their MQTT broker… for now.
  • HASS reboots are so much faster.

I’m really excited about this. I think this is a great approach to implementing zwave.

1 Like
64

I have noticed though, that the cache file is saved more often when compared to OZW 1.4 at least. I refreshed some nodes from an already added network and after doing so the cache file was saved, whereas in 1.4 it would never have been, so some kind of events are triggering a save. At least that way the node values are all retained. You might consider submitting an issue for this one though.

At least for the network key, see the first paragraph in the MQTT docs. You can use the OZW_NETWORK_KEY environment variable. I believe options.xml is still viable, but I haven’t confirmed myself.

Until the control panel is updated to use the new component, you’ll be stuck with manual service calls. However, the OZW Admin tool is also available and improving daily (very alpha at this point). It is reminiscent of the older web-based OZW Control Panel. It can connect to the same ozwdaemon service that HA is using. Downloads are available here.

65

Thanks for the info. I’ll check out the OZW Admin GUI; it sounds like what I’m looking for.

I switched to qt-openzwave very recently and somewhat reluctantly. My zwave network has about 30 nodes and my most important HA automations wouldn’t function without it. Without being 100% sure I could recover the old network setup (turns out I could), I was deeply concerned about migrating and losing some critical functionality (I lost some, but nothing critical). I don’t have a separate network to test/develop on so it’s difficult to experiment when I generally want or need automations to work correctly.

I didn’t lose anything unexpected on the HA side through the transfer thanks to HA’s consistent code structure. All I lost were lock entities for door locks; climate entities for thermostat; and still no sound switch for aeotec siren6. And it feels as though there’s more traffic on the zwave network, though I still need to verify that and re-check all the nodes’ config parameters/associations.

But, now that I’m running with qt-openzwave and the new HA integration, my plan is to orient myself to the changes, get some mqtt topic dumps, and see if I can help add some of the missing functionality to the HA integration.

66

Please open issues on the Qt-OpenZWave page if you have questions or comments.

The core functionality is there, but I’m sure there are a few bugs in places.

I’ll post a reply on the ozwcache on a issue just opened up there.

67

I’ve since had a bit more time to play with it and I’m really pleased. Great work, @Fishwaldo, @cgarwood, et al.

The MQTT topics exposed for all the nodes allowed me to set values for my aeotec siren endpoint’s tones and volumes, and enable the entities which python-openzwave-mqtt/homeassistant-zwave_mqtt doesn’t yet create by default at (door locks, thermostat, covers) via the stock HA MQTT component. I’ll open upstream issues for anything I come across once I’m convinced that the issues are not my own misconfiguration. Cheers.

68

It would be really nice if the installation instructions could be also aimed at those not running hassio too.

I’d like to install this and do a bit of playing but the chain of references to other github repo’s required for installation is a bit confusing and off-putting.

69

So are we in beta on this? I’d be willing to migrate over and set it up if we are.

@finity where are these instructions?

EDIT: I found the hassio instructions… and it looks like a prerelease.

@finity here are the non-hassio instructions.

1 Like
70

I think the way the “hassio instructions” are written is a bit confusing…

The docs from your first link references a repo for a “hassio add-on” to get the daemon and then tells you to install the qt-openzwave “add-on” thru HACS.

The use of “hassio add-on” and “add-on” in the docs implies it’s only for hassio since only hassio allows the use of “add-ons”. But being available thru HACS implies that it can be used in any installed version of HA and isn’t just limited to hassio thru a true “add-on”.

So the instructions from the first link are used to install in any version of HA as a custom component and not as a hassio-only add-on?

is that right?

and it looks like the second link is just the same custom component above but offered as a stand-alone Docker image? Which would presumably be the same docker image that a “hassio add-on” would use (if it existed)?

I think that’s where my confusion was (is… ? :man_shrugging:).

71

No the first docs are 100% hassio. It even references the hassio-addons.

The second link is for running on docker. It just doesn’t mention any of the home-assistant side setup.

You may be able to create venv’s for all this crap too but it looks like you need to piece meal all the requirements:

72

So basicly a docker install if you’re not using HassIO (Home Assistant?) would be best for those who are using venv install (Home Assistant Core?) eh?

73

For the ozwdaemon you really want to use docker. You can attempt to install all the dependencies and build it yourself, but you’re setting yourself up for a challenge. Look at the Dockerfile for example, it currently uses QT libraries from Debian Testing.

I use HA Core via Docker, but a venv would be the same.

  1. Install/run a docker container for ozwdaemon. Recommend using docker-compose.
  2. Install/run MQTT however you like
  3. Install the custom component, either using HACS or manually. I clone the repo myself and symlink it into the custom components directory. You do not need to install python-openzwave-mqtt, the component does it for you.
  4. Configure the MQTT integration in HA
  5. Add the ZWave-Over-MQTT integration
5 Likes
74

I don’t know. I’m only speculating based on the brief look I did on the github repos. I’d believe @freshcoast over what I said. I haven’t set this up yet and I’m almost done building an additional room. When that’s done, i’ll be switching over myself to the hassio add-on.

75

I’ll be giving it a shot once locks and covers are supported. Those are my “must haves” before switching over currently.

76

Yeah, I could see how you might think that based on…

And it does in fact…

but that’s the issue I had with the docs.

It talks about “hassio add-ons” in the same paragraph as it says to install it as a custom component thru HACS (which is definitely not for hassio add-ons).

From the first link:

It is currently available as a custom component through HACS
…

that’s why I said it was confusing. :wink:

Thanks @freshcoast for those more understandable instructions.

77

Sorry but this must be a lack of understanding on the hassio side. Most add-ons that interface with home assistant are like this. You add the add-on which builds the container, then you configure it in your configuration. It just so happens that this requires a custom integration (for now) so you add a step.

Think mqtt, you add the addon, then add the configuration.

78

Fair enough.

I guess it could be a misunderstanding on my part but I don’t think I’ve seen any other custom components listed in HACS that said that you need to install an add-on in hassio before using the custom component. But I haven’t looked thru all of them so I guess it could be moving in that direction.

79

Its really only that way when you are interfacing with other devices and you’re running the container that handles the devices. Off the top of my head: MQTT, ZWtoMQTT, APC, ESPHome all are like this. But they use standard integrations. I would assume (big assumption) that once this stuff goes live, this integration will replace current zwave (after the deprecation period).

80

Using the docker run command from here:

https://github.com/OpenZWave/qt-openzwave

Is there any way to change the port of the MQTT broker in that run command?

I run two brokers on my system and the second one is on port 1884. Do I just add the port to the end of the broker IP? I’d rather use my second broker for testing this if possible.

And did I see somewhere that the app can’t be configured to use an MQTT password yet?