I’ll be setting up my zwave network in a few months and it looks like the current best strategy is ZWave2Mqtt running as a separate service. Is that still recommended?
Based on the reliability and speed of esphome devices, has anybody considered a zwave to native api service?
Is this essentially what the built in zwave integration does?
Yes
I think it would be best to wait for openzwave beta to become standard. Especially if you aren’t going to start building a z wave network for a few months. By then I think the ozw would be complete.
You can even try it out now if you wanted. since you aren’t migrating an existing network it would be easier to test
@finity thanks for reply. the new ozw is running in the same process as ha? i feel like it would be better to keep them independent but I guess that is the point of the mqtt route.
the new esp32s2 would be an interesting low power simple gateway for zwave usb sticks. I like the thought of something with fewer moving parts translating zwave to UDP/TCP.
The new ozw integration uses MQTT under the covers, so you can run the ozwdaemon service anywhere you like. It’s “native” in that HA has a python component that handles all the MQTT messaging for you.
The “old” zwave integration uses a python API which wraps the OZW C++ api, so it’s in process.
I think the HA-native esp32 integration uses a protocol buffers API that talks directly to the devices? There’s no equivalent of that for OpenZWave, but the same OZW daemon that uses MQTT also is accessible via the QT Remote Objects API though, so someone could write an alternative implementation that doesn’t use MQTT. The OZW Admin GUI tool is an exampl.e
Z/IP is a protocol that bridges zwave and IP via UDP. You might find some commercial hubs that implement it (?) but OpenZWave does not use it. Silicon Labs provides gateway software that implements it.