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

As shown on https://github.com/cgarwood/homeassistant-zwave_mqtt

Notice - Repository Archived

This component has been merged into the Home Assistant Core as the OpenZWave/ozw component. Please submit bug reports to the Home Assistant Core repository.

Thanks for your information the PR’s been merged to resolve these messages.

Yes I understand that. But there were some issues on the old repo (such as https://github.com/cgarwood/homeassistant-zwave_mqtt/issues/15) that served as a roadmap. But those were not transferred over.

So I installed the OpenZWave through the addons / core integration, and I’m having trouble finding my zwcfg or ozwcache file. Where is this supposed to be located? I looked in the /config folder and the /data folder but it just doesn’t seem to exist. Seemingly my network of like 10 ish devices is working fine though…

1 Like

Hi Folks,
This maybe an unpopular opinion, but I wanted to ask a few questions as coming from Zwave2MQTT. (and i’m assuming the point of the beta is to battle test stuff and gather feedback - so please take this as intended as I know people have worked hard on it!)

  1. The qt-OZW docker only allows node numbers to be used (not overly helpful when working out what is what in MQTT) - yes this is solved when you use the integration, but that has its own issue (see #2)

  2. Using the OZW beta integration like the previous Zwave integration adds a LOT of entities that aren’t used - so I could manually add the mqtt devices/entities to reduce the number to just the ones I need to surface (but then need the node name ideally not just the number). A ‘simple’ alternative would be an option to allow OZW docker to send node_names to MQTT, instead of node numbers.

  3. As i’m not able to customize entities on the OZW side, my switches that are lights show up as switches. In Zwave2MQTT i’m able to customize some settings (and use MQTT discovery) OR just manually add my mqtt devices to HA and thus translate switches that are lights to mqtt lights.
    I know this can be done with a light switch platform, but with 20 switches - seems like extra work that isnt needed.

What would be handy is a ‘don’t send to HA’ option in the OZW UI, Then for those devices one could manually add them (and if needed add as a light not a switch).

Also can I ask why another Zwave 2 MQTT implementation was built rather than just work with the Zwave2MQTT dev to shape that to the needs? It has more customization and config that the current qt-OZW docker + integration.

1 Like

That one was answered a while ago. Because zwave2mqtt relies on the node wrapper for openzwave and then adds the complexity of translating zwave items to MQTT items.
While ozw Dämon just puts zwave stuff on MQTT topics without translating them into MQTT lights, MQTT covers, etc.

Ozw daemon is the slimmer, easier to maintain solution. Personally I prefer the zwave2mqtt approach as I do most stuff in node red directly via MQTT. While this works with ozw daemon as well, zwave2mqtt topics are nicer to work with.

I would love if zwave2mqtt would have been the basis but I understand ozw daemon follows a different design idea which is makes a lot of sense as well.

Interesting, thanks for the info (and taking the time to reply!)
I figured it maybe technically more complex.

The only other question then is what made the team choose MQTT? Is qt-openzwave being built for just HA? If so wouldn’t using the HA API make more sense to avoid a step (and add a bunch of noise to MQTT?)

Actually I lied, one other question lol, what does the integration do that enabling MQTT discovery doesn’t?

I went back to Zwave2MQTT as I’m trying to avoid all of the additional entities that aren’t used, plus the other main point was the switch/light conversion.
I’ll raise a FR in case it’s functionality the team want to add

I guess MQTT makes it easier to build integrations with other systems? No idea really.

For my use case Z2M works better for now, but let’s see. Great that there is some work done.

Running the qt-openzwave-allinone Docker image and lost the ability to add nodes to my network through my Aeotec Z-Stick. Anyone experience anything similar? Filed a bug, but I’m still waiting on a response: https://github.com/OpenZWave/qt-openzwave/issues/160.

Hi,

Thanks for the answer.
This is what i have found:

{
    "Label": "Error Code",
    "Value": "",
    "Units": "",
    "ValueSet": false,
    "ValuePolled": false,
    "ChangeVerified": false,
    "Min": 0,
    "Max": 0,
    "Type": "String",
    "Instance": 1,
    "CommandClass": "COMMAND_CLASS_NOTIFICATION",
    "Index": 266,
    "Node": 14,
    "Genre": "User",
    "Help": "The Error Code returned by the device",
    "ValueIDKey": 74872344045961239,
    "ReadOnly": true,
    "WriteOnly": false,
    "Event": "valueAdded",
    "TimeStamp": 1599120664
}

A fix was already merged in, this should be resolved in a future version likely 0.116.

I have the same question. Did you ever get an answer some how?

I am currently setup with OZW installed on an RPi3 along with a few other containers like Portainer and Duplicati for backups. My Hass/MQTT server machine is a NUC in another room. Today I upgraded the firmware on my router which caused about 5 minutes of downtime on my network. Afterwards, OZW never recovered. Everything was just unavailable in Home Assistant. I first tried restarting Home Assistant, but that didnt work. I finally had to restart the OZW Docker container on the RPi and let the network refresh before anything was usable again. Unfortunately I was not in a position to dive into logs to see what happened and had to just get things working again.

Is this normal? Are there plans to make this kind of setup more reliable and resilient to network interruptions?

Other than this, my overall experience has been pretty good other than the initial migration.

ozwdaemon currently shuts down when it gets disconnected from the MQTT broker. Unknown if it will be changed in the future, but I sure hope so (see Github issue).

If you are using the latest container image, it will automatically restart and wait for the MQTT broker for a short timeout. I can’t remember if there’s a limit on the number of retries. Older versions (e.g. the fabled build-150) don’t do this.

If you don’t have a docker restart policy configured, which is sounds like you don’t (?) you probably want to.

I have the restart policy set to unless-stopped. I know the container was running when I finally manually restarted it. Hope this gets addressed somehow.

What version and image are you using?

Allinone-latest

Except that it does not really do that (at least not “-latest”, and not always):
See MQTT client timeout · Issue #140 · OpenZWave/qt-openzwave · GitHub

In these cases ozwdaemon keeps running, and is stuck at 100% cpu when the connection to the MQTT broker is cut off.

1 Like

@Olen I wonder if this is related to https://github.com/OpenZWave/qt-openzwave/issues/150

Seems something gets overloaded and the MQTT connection doesn’t get serviced and then the daemon crashes/shuts down.

1 Like

After installing the latest version of OZW 0.6.0, my Zwave network stopped working.
Be careful installing the update!