zwave2mqtt plugin

[heggink]

Similar to zigbee2mqtt and the plugin, I am most interested to investigate what's required to have an alternative zwave implementation. Alternative to the built-in OZW approach.

There already seems to be a working https://github.com/zwave-js/zwavejs2mqtt. The node-zwave-js implementation seems to be the recommended HA implementation for new users already. Implementing zwave support through mqtt provides more independence from domoticz allowing the flexibility to update either side without having to update the other.

Looks like using zwave2mqtt would be the best start requiring building (or adapting) a zigbee2mqtt plugin equivalent.

Thoughts?

[moroen]

I've done some research, and have created a proof-of-concept plugin using zwavejs2mqtt as a backend, so it's quite doable. This is in it self not surprising in light of stas-demydiuk/domoticz-zigbee2mqtt-plugin, which clearly shows that the plugin framework is more than capable of handling MQTT.

I think one possible issue is the plethora of z-wave devices, so while I think that creating a basic zwave-mqtt plugin shouldn't be to much work, maintaining it and implementing support for all possible devices might turn out to be a momentous task. On the other hand, zwavejs2mqtt handles much of the heavy lifting in that regard, so from the plugins standpoint, it might be "just" making sure that the plugin responds to all the relevant MQTT messages, and those appear to be somewhat standardized by zwavejs2mqtt.

IMHO in order to make this manageable, we should prioritize what functionality is required, and what is "nice to have". I would suggest that required functionality is:

1. Switching of devices
2. Setting levels of dimmable devices
3. Reading sensors
4. Responding to events (buttons, scene controllers)

Nice to have:

1. Node management
2. Device configuration

Initially the nice to haves can be managed with the zwavejs2mqtt web interface, which in my opinion is quite good. Setting up zwavejs2mqtt was a breeze, using docker.

We should perhaps also discuss the motivation for such a plugin. If the main motivation is stability, I already have some reservations. When I first started with home automation, I chose zwave because according to what I read at the time, it appeared to be most stable, using mesh and two-way communication. I've since added rfxcom (mostly Nexa) and Ikea Tradfri, and among those three, zwave has by far been the tech I've had the most trouble with, devices dropping out or intermittently not responding etc. This has been debated in other threads on this forum. Now, some of this might be due to openzwave, but in my (albeit limited) time using zwavejs2mqtt, the latency, unresponsiveness etc. have been more or less the same as using openzwave...

That said, with openzwave currently looking a bit "dead in the water", perhaps this is a good time to explore other possibilities...

As to if we should try to adapt the zigbee2mqtt plugin or create something "from scratch" is open to debate. zigbee2mqtt is quite complex, and as far as I can tell, some parts, like the adapters, might not be needed, with zwavejs2mqtt more or less acting as a adapter. If I were to partake in this, I must confess that for me personally, it would be much simpler to create a plugin based on the principles of the tradfri-plugin.

We should also consider if it would be worth waiting for the next version of the plugin framework, IMHO much of what @Dnpwwo has laid out for the next version, would greatly simplify creating a zwave2mqtt plugin for Domoticz.

Regards,
M

[moroen]

There is a prototype of a zwavejs2mqtt plugin available on https://github.com/moroen/ZWave-MQTT-plugin. It's pretty rough, and far from production ready, but works with binary and multilevel switches. I'll add support for (some) sensors and scene controllers next.

I'm thinking that it might be an idea to make this as a more general MQTT plugin, where it's possible to use different backends as adapters for different kinds of hardware. We could use the MQTT message format of zwavejs2mqtt as a specification, and then create different adapters using what ever languages/systems/what nots as interfaces between domoticz and hardware. I plan to explore this idea with IKEA Tradfri to see if it's feasible.

Regards,
M

[heggink]

I've done some research, and have created a proof-of-concept plugin using zwavejs2mqtt as a backend, so it's quite doable. This is in it self not surprising in light of stas-demydiuk/domoticz-zigbee2mqtt-plugin, which clearly shows that the plugin framework is more than capable of handling MQTT.

I think one possible issue is the plethora of z-wave devices, so while I think that creating a basic zwave-mqtt plugin shouldn't be to much work, maintaining it and implementing support for all possible devices might turn out to be a momentous task. On the other hand, zwavejs2mqtt handles much of the heavy lifting in that regard, so from the plugins standpoint, it might be "just" making sure that the plugin responds to all the relevant MQTT messages, and those appear to be somewhat standardized by zwavejs2mqtt.

IMHO in order to make this manageable, we should prioritize what functionality is required, and what is "nice to have". I would suggest that required functionality is:

1. Switching of devices
2. Setting levels of dimmable devices
3. Reading sensors
4. Responding to events (buttons, scene controllers)

Nice to have:

1. Node management
2. Device configuration

Initially the nice to haves can be managed with the zwavejs2mqtt web interface, which in my opinion is quite good. Setting up zwavejs2mqtt was a breeze, using docker.

We should perhaps also discuss the motivation for such a plugin. If the main motivation is stability, I already have some reservations. When I first started with home automation, I chose zwave because according to what I read at the time, it appeared to be most stable, using mesh and two-way communication. I've since added rfxcom (mostly Nexa) and Ikea Tradfri, and among those three, zwave has by far been the tech I've had the most trouble with, devices dropping out or intermittently not responding etc. This has been debated in other threads on this forum. Now, some of this might be due to openzwave, but in my (albeit limited) time using zwavejs2mqtt, the latency, unresponsiveness etc. have been more or less the same as using openzwave...

That said, with openzwave currently looking a bit "dead in the water", perhaps this is a good time to explore other possibilities...

As to if we should try to adapt the zigbee2mqtt plugin or create something "from scratch" is open to debate. zigbee2mqtt is quite complex, and as far as I can tell, some parts, like the adapters, might not be needed, with zwavejs2mqtt more or less acting as a adapter. If I were to partake in this, I must confess that for me personally, it would be much simpler to create a plugin based on the principles of the tradfri-plugin.

We should also consider if it would be worth waiting for the next version of the plugin framework, IMHO much of what @Dnpwwo has laid out for the next version, would greatly simplify creating a zwave2mqtt plugin for Domoticz.

Regards,
M

Agree with most of your observations. I already use the zigbee2mqtt plugin and have no issue with using the native zigbee2mqtt interface for certain things. As long as the base day to day can be done from domoticz (include, exclude, switch, report) then the rest (display the mesh, firmware updates, heals, ..) is fine from the zwave2mqtt interface.

My objective would be independence. I have no illusions about stability initially. Hopefully it can improve over time but I suspect it's also part of zwave. Independence also means that I would strongly recommend to keep it zigbee centric and not include other formats (zigbee).

I'll take a look at your new development as soon as I can. Thanks for the great work!

Sent from my SM-G980F using Tapatalk

[Patricen]

Hello,

This is probably a silly question, but if I understand correctly, OpenZWave that I'm currently using can be replaced with Mosquitto installation on my RPI and ZWave2mqtt plugin, I'm I right?

If it is the case, would enabling Mosquitto and the plugin be the fix for ZWave stability issues related to OZW?

Thanks!

[heggink]

Yes. That's what I did. Please note that the plugin is still relatively new so there may be devices that need work to be supported.

Sent from my SM-G980F using Tapatalk

[Patricen]

Yes. That's what I did. Please note that the plugin is still relatively new so there may be devices that need work to be supported.

Sent from my SM-G980F using Tapatalk

That makes me a bit scary, what you call "work" means coding?

[heggink]

I hope not. The plugin uses an external config file to map devices onto domoticz devices. When we built it, we could only map devices we had so there's definitely missing devices. So far, rgb devices are missing and there seem to be some issues with power devices (although mine appear to work).

You can test drive by disabling OZW, starting zwavejs2mqtt and the plugin. That way, you can switch back again although dzvents sometimes gives you hassle if you use the same name in both (even if ine is disabled).

Sent from my SM-G980F using Tapatalk

[Zith]

This is perfect!
However, I'm not getting any devices added - mostly error messages like:
2021-09-01 17:47:38.636 Error: Z: (Z) ----> Line 234 in '/home/domo/domoticz/plugins/ZWave-MQTT/api/devices.py'

And:
"Command Class None with type None is unknown"

Not sure where to begin digging...

[heggink]

Quick update: gizmocuz is making a lot of progress with integrating the homeassistant mqtt autodiscovery. I did some testing on the mqtt_autodiscovery_branch today to conclude that it's working really well. There is obviously more work to do but it's already 80+% there.

Since he had access to both my zwavejs2mqtt and zigbee2mqtt messages, this approach integrates both without the need for any plugin and with no restrictions in the number of devices.

Clearly, that is excellent news. Reason to hold additional development in this plugin as I suspect it will be superceded 'shortly'.

For those that are already on the plugin, this means that you can continue to use it, run the autodiscovery side by side and gradually replace devices.

All in all, very promising!

Sent from my SM-G980F using Tapatalk

[Patricen]

That sounds like excellent news for ZWave and ZigBee devices users!

Looking forward to discovering this new feature!