I’m thinking of switching from “native” HA Z-Wave to zwave2mqtt, and wanted to see if I got the pros and cons of zwave2mqtt correctly. The way I see it: Pros:
No need to restart Z-Wave when restarting HA. Z-Wave is available immediately (takes about 10 minutes in my case).
Device definitions are taken from master and are more up to date (if I got this right, this means, for example, no need to edit XML files to get central scene support).
More actively maintained and likely to support OZW 1.6 before HA.
Ability to set multichannel vs single channel associations from UI. In HA you can only set them together from the UI (or call on a service). This is required to get Qubino flush shutters to work correctly in venetian blinds mode.
Cons:
Added MQTT (and potentially network, if on a different host) latency.
Tooling might be a bit behind (e.g. no Z-Wave graph).
I use Zigbee2MQTT, with that running on one host, my broker on a second, and Home Assistant on a third. The latency introduced is insignificant in my experience.
Just within the last couple of days, I have gotten Zwave2Mqtt version 2.0.4 running with OpenZwave master (ver 1.6+) on a sandbox version of HA (plain old Hass on Ubuntu virt env). I’m using an Aeotec USB stick operating as a secondary controller as a way to test a few things out on my working production network (which uses SmartThings as the primary controller). It supports an HA mqtt auto-discovery but I’m not using it.
Yes you won’t need to restart Zwave2mqtt when you only restart HA. Of interest however is the large number and size of MQTT messges, and whether to retain (retain is all or nothing). The messages can be in JSON format which produces very large messages with lots of info, or can be in very simple format which provides only a single value (which for now seems to be all I need). The number of messages from a device is proportional to the number of class commands a device supports, but under normal operations only a few command classes are used by sensors to report so the number of messages aren’t so bad. There is also a “manual” mode to configure MQTT topics which I haven’t tried yet, and this may be yet another way to reduce the number of messages.
Device Definition: I haven’t confirmed, but I believe zwave2mqtt gets its device info from openzwave and ozw 1.6 has a large list of manufacturers files it uses for devices, and in the case of Aeotec Wallmote Quad which I recall was one of those devices you had to manually edit zwcfg file, this appears to be taken care of in 1.6 as the wallmote quad shows up with what looks like all its definitions in the GUI. Zwave2Mqtt does use its own cache file once it discovers these devices, and I’m still playing with it to see how well it works.
Does it fully support OZW 1.6? I don’t know to what extent, but seems far along.
Also Zwave2Mqtt relies on node-openzwave-shared as the wrapper to talk to ozw. There is active work going on updating it, so if its not fully matching 1.6, its probably not far from it.
FYI, If you use Docker for Zwave2Mqtt (which I haven’t tried), looking at the dockerfile, it is pulling in ozw ver 1.4 so you wouldn’t get any benefits of 1.6.
Associations - The GUI supports this as well as multi-instance. I haven’t tried it though to see if it works.