we (the company nexiles) planned to introduce a new binding for the
awesome ZWaveToMQTT.
Why?
The ZWave binding offered by openHAB limited us in devices (by beeing unknown), and digging trough the forum/GitHub showed us that there are a bunch of issues.
We are already using ZWaveToMQTT and as we are planning to also run an openHAB instance it would be pretty awesome to have this well working tool integrated, somehow.
How?
We planned to use the by ZWaveToMQTT offered discovery made for HomeAssistant, and add bridges/things/channels on the fly. Keeping the user interaction as limited as possible.
TL;DR:
We planned to integrate ZWaveToMQTT instead of using the already implemented ZWave-Binding by openHAB due to various issues.
Please give us your toughts about our plans and approach to this topic.
Any idea, suggestion, help,ā¦ is welcome!
We are pretty new to OSGi and ApacheKaraf, but we already started our first tries, we will share here soon.
There is a simple and well known process to add new devices to the Zwave bindingās database. The turn around is usually a matter of a couple of days for the first report of a device to it being added to the database.
My understanding is that ZWaveToMQTT uses the OpenZwave libraries which has support for fewer Zwave devices than the openHAB binding does.
Itās also worth noting that there is a Z-Way that works with Z-Wave.me.
To my knowledge there are no issues in OH 3.1 that are not being actively researched and worked off. Iāve not experienced any problems so I havenāt payed that close attention to those threads though. The majority of Zwave binding users are not reporting any problems at all.
If ZWaveToMQTT already supports the HA MQTT standard than your work is done. The MQTT Binding can already discover and create Things that follow either the HomeAssistant or the Homie MQTT topologies and standards.
If for some reason that doesnāt work for you, Iād personally rather see the MQTT bindingās support for the HA standard improved instead of the creation of a brand new binding that duplicates the same capability but in a more limited scope.
first of all, thanks for your fast answer and the input!
Just to give some more information about our current setup, we have multiple Z-Wave networks that we are controlling using a single piece of software and Z2M.
Its device database keeps growing and uses configurations imported both from OpenHAB, OZW and Zwave Alliance.
Based on this information we assumed that Z2M is capable of supporting more devices.
Is not applicable to our setup and therefore no option for us.
Weāve already tried that one but we werenāt able to get things added correctly. Maybe the problem there is on our side. But I guess we will then have another look into that. We faced the problem of limited documentation there, but we will dive into the code then.
We would be glad if we could bring mqtt.homeassistant to work properly.
Here a screenshot what resulted when the discovery finished:
Then yes, Iād prefer (and I have absolutely no power here so it doesnāt really matter what I prefer) that you focus your efforts on making the HA support in the MQTT binding work properly. Then not only will it benefit integration to ZwaveToMQTT but all services and devices that support the HA MQTT standard.
That is zwavejs2mqtt. It already works with OH if you use MQTT ti onterface.
They also have a websocket implementation that works with Home Assistant. Something similar for OH would be great. MQTT and Z-Wave do not get along well, as discovered by others.
Have you got an example? I thought Iād seen things about serial port problems between the OH binding and a Zigbee stick (so maybe Zigbee2mqtt), but I donāt see why Z-Wave and MQTT technologies canāt play well alongside each other?
That is one reason Home Assistant abandoned their attempt to use Openzwave over MQTT. They now use zwavejs or zwavejs2mqtt in websocket mode. Their zwavejs implementation also uses websockets.
I like the idea the device database is able to be updated separate from the core system.
I am using zwavejs2mqtt with both OH and HA.
Home assistant mqtt thing autodiscovery does not support climate entities in OH.
I have had also issues with dimmers and covers. You can always setup generic mqtt thing for these.
In HA I use the websocket so no experience with mqtt autodiscovery for zwavejs2mqtt.
I would love to see better support for the mqtt binding. Iāve been trying to use mqtt.homeassistant binding with zwavejs2mqtt but its support seems limited. I know there is a PR for climate items currently on github and it looks like that has a good deal of refactoring in it as well. But what I really need is better support for Dimmer items. Currently it is trying to make a Trigger Channel of a color out of one.
Making Generic MQTT items works decently enough, but again there is trouble with dimmer items as you canāt send outgoing ON commands. So it will get set to full brightness.
Being able to place the zwave controller physically away from my server and have Zwave database updates not tied to Openhab version is a big enough value to keep trying to make zwavejs2mqtt work however.
Iām not sure I understand where the shortcomings would be. Both are bidirectional. If anything it seems like MQTT would be a benefit with its retained messages. A reboot of openhab doesnāt require querying the state of all the zwave items, just subscribing back to the broker. Technically websockets will have slightly better latency, but if you need to access the broker from multiple places MQTT is the perfect protocol.
Of course none of that has to do with the Dimmer Item issue. That is all in the binding.
The other huge benefit of zwavejs2mqtt is that it allows you to do firmware updates on zwave items.
That you can do with a number of tools so that is not an argument.
Or rather you cannot do that at all as most vendors donāt provide firmware updates anyway.
A good example why you should always āuse the right tool for the right jobā.
Translating protocols into each other might serve as a workaround to catch some edge cases,
but doing so does not improve overall functionality but introduces new issues you would not have with a genuine implementation.
Not an argument either and no, publish/subscribe is multidirectional. Websockets just donāt match the comms model and software architecture.
Your non-understanding just means you donāt see all the implications yet.
Think e.g. about a zwave device to send an alarm, say a smoke detector sets off.
In ZWave you would use broadcasts. Any listener can decide what to do such as most zwave rollershutters can be configured to open on alarms being āheardā (rather than being ātoldā 1:1 which would require server side processing and distributing).
MQTT inbetween will break this, and thatās a potential life saver it breaks !
Current method: Unplug zstick from server. Go to device. Exclude from network. Plug zstick in laptop. Load up zwave pc controller. Include device. Upload firmware. Exclude device. Shut down openhab. Insert zstick back into server. Start openhab. Delete Thing. Include device (assuming network wide inclusion works). Recreate Thing.
New method: Log into zwavejs2mqtt dashboard. Upload firmware. Done.
That seems like a compelling argument to me. Iām not sure what vendors of zwave products you use. But my preferred vendor, Inovelli, releases new firmware all of the time. I would have agreed with your statement 3+ years ago.
Seems like the tool specifically made to talk to zwave devices without having to shoehorn in the requirements of being an OpenHAB addon and translating everything into MQTT a protocol built specifically for for IoT devices could very well be the right tool for the job. My Dimmer issue is just a bug in the MQTT binding. There is an issue for it on github.
Now Iām starting to wonder if you even use ZWave devices or are completely misunderstanding what is being discussed. No one is putting mqtt between devices. Everything you just described would be handled inside of the Zwave network. That doesnāt change if you are using zwavejs2mqtt or the openhab zwave addon. The only difference from OpenHABās perspective is the event is reported through the MQTT addon instead of the Zwave addon. Trading a serial connection to the zstick with a mqtt ā to serial connection. Which also works with 700 series sticks. Something the OpenHAB addon does not do last I checked.
There is a reason for interest in a zwavejs2mqtt binding and HA making zwavejs their recommended zwave interface. Maybe that interest should be spent trying to create a binding that uses the websocket interface it supports. The mqtt work has a huge headstart though. The writing is on the wall that SILabs wants to remove the Serial API from new versions of zwave. At that point the OpenHAB Addon is going to stop supporting new zwave devices without a major rewrite. Seems like putting support behind a project with more active development might be prudent.
My example was generic as to why you should not tunnel through other protocols when a native function is available. Complicating system architecture like that has a big potential to create lots of problems.
I wouldnāt trust these broadcasts properly arrive at openHAB, and that they continue doing so alongside ongoing SW development of OH, any zwave/mqtt gateway software and whatever else you put inbetween.
But that is the beauty of it. As long as OpenHAB has a working mqtt addon it doesnāt matter what SW development happens on either side. Currently if you buy a new zwave device you have to move off of Stable OpenHAB to get support for it or wait for stable to include an updated version of the zwave binding because it canāt access the zwave database remotely and has to be built in. So lets try your āgenericā example again with a new Alarm. You are using the Stable version of OpenHAB because you value a trusted setup. Your new alarm is in an association group with your blinds. The alarm sounds and the blinds go up, but openhab has no idea that the alarm sounded. You have no way to manually add the unknown item. On the zwavejs2mqtt side. The alarm sounds, the blinds go up and a message is published to the mqtt broker that an alarm sounded. Being a simple boolean value the mqtt binding knows exactly what to do with that and updates a switch item.
Or how about we try your example with the server where openhab is hosted in a closet in the garage (my current setup). The alarm sounds, the blinds go up, the zstick never receives the broadcast because it is too far from the alarm. I understand that I could run my whole OpenHAB setup from the same raspberry pi that runs my zwavejs2mqtt instance in a more central location, but I like having it on more powerful hardware.
Maybe I need to spend some time looking at the code but this statement is kind of like saying āUDP is worse than HTTP because UDP is connectionless.ā But they are at completely different levels of the communications stack. You can run HTTP over UDP. And you can run MQTT over websockets. What isnāt clear to me is whether ZwaveToMQTT is doing that or if itās using some other protocol on the websockets. But saying websockets are better than MQTT just doesnāt make sense. Itās apples to oranges.
That applies to brand new devices only which there are not many.
And in any professional deployment (or alikes) selecting any of these would be a no-go for a (validated) setup.
āStableā or not is a sometimes raised pseudo argument I donāt follow. āStableā is just a label that - misunderstood by most - does not imply itās better tested, more stable really in a literal sense or terms of operations or anything. Thereās nothing wrong with moving to a milestone or snapshot if you really want to have that device supported. You can even put any new device into the database yourself and will get it compiled in in just a couple oā days.
I donāt know for sure off the top of my head on the specs but would expect the broadcast to be forwarded just like any zwave message is routed when the destination is not in range.
So server placement is not relevant.
I would say most issues with zwave that people have is related to placement of the Zwave controller. It is indeed the primary reason I was looking for alternatives. Zwave is great if everything is one hop from the controller. 2 hops and things start to get sluggish. 3 hops and things start to fall apart.
So yes, placement of the controller is extremely important. Do you have any devices 2 or 3 hops away from the controller? There is most certainly a delay between actions if they even happen at all.
Iāve update and made the initial contribution on a few of the zwave database entries. And I will continue to do so because that database is also used for zwavejs2mqtt. It just streamlines how fast the updates are usable and I donāt have to worry about adding a breaking change into my openhab setup for a new device.
You actually donāt need to do the exclude/reinclude parts if youāre using a USB stick already. Just stop OH, move the stick to your computer that has the zwave pc controller software, update firmware, and move it back. Iāve been doing it that way for a while now with the Inovelli stuff, itās just their directions are confusing and you only need to exclude/include if you are using something with zwave built in like smarthings to temporarily get the devices talking to the USB stick for the firmware update.
