Z-Wave JS official integration about openhab-addons HOT 27 OPEN

Ah, okay. There have been a few forum discussions regarding why one would want to use zwave-js instead of the current native ZWave binding. https://community.openhab.org/t/zwave-js-ui-in-place-of-oh-zwave-binding/150007 seems to be the most prominent.

There may be several reasons one might want to use zwave-js-ui instead of the built-in binding:

• Migrating to or from another automation platform, having the ZWave network exist outside of the automation platform both allows for not having to re-add devices, but can also allow multiple platforms to access it at the same time
• 700 and 800 series support
• S2 support
• Smart Start support
• OTA updates of devices
• Reliable removal/replacement of failed devices
• A network map that actually works if you have a substantially sized network
• Viewing/assigning priority routes (which can very much increase the reliability and responsiveness of the network)
• Actual feedback on if the controller is in inclusion/exclusion mode, and for how long
• If openHAB is restarted, the ZWave network doesn't have to be re-interviewed from scratch. This can cause a significant amount of traffic and responsiveness delays on a decently sized network. My rule of thumb for my network was it would take 30 minutes for ZWave to stabilize after an openHAB network.
• In fact, even a restart of zwave-js doesn't require all nodes to be re-interviewed - just a simple ping suffices. You can re-interview on demand if you suspect the device has actually changed (like if you've applied an OTA update)
• By disconnecting the openHAB release from the zwave-js release, you don't have to wait for an openHAB release to get support for a new device; zwave-js releases far more frequently
• In fact, most new devices don't even require zwave-js to have an update in order to be fully supported
• The ability to send lower level ZWave commands, such as a multicast to multiple nodes at once.
• Backup/restore of the NVM on the ZWave controller

Like you pointed out, a few of these can be resolved in the native binding with some effort, but it's been slow going, and some of them are pretty major features.

from openhab-addons.

Ok I saw that @wborn already transferred the issue to the correct repo

you are asking for someone to develop an Add-on to integrate things via your API. Or??

What I want to say is: many users are moving to Z-Wave JS UI as they are not happy with the actual OpenHAB zwave addon. Actually their alternative is to use Z-Wave JS UI with MQTT discovery and, as said above, that's not the best choice neighter. There is an alternative using the weboscket apis that is not maintained directly by me but it's integrated in Z-UI and it's also the way Home Assistant is using in their official zwave integration. Mine is just a suggestion as I think could be a good addition to your platform 🙌🏼

from openhab-addons.

want to post something about th

As that is a 70+ post topics with some clutter, i was looking for a TL:DR /key information to be added to this issue so that a developer that might pick this up would have a clear overview of the request. Thanks for pointing to that link, will look at it when i have the time.

from openhab-addons.

Also will it be possible to enable/disable certain topics via the websocket like they can now be done with the HA Mqtt discovery

That would be up to the dev that would create the binding on OH side using the websocket apis. That will allow full access to all zwave-js driver so they can decide everything, they can also send actions to it in order to retrieve informations needed and based on them create the entities on OH (this is what HA zwave js integration does)

from openhab-addons.

If I understand your issue correctly, you are asking for someone to develop an Add-on to integrate things via your API. Or??

If so, then this issue should not be located here in the OH Core repo but rather in the OH Addons repo.

https://github.com/openhab/openhab-addons/issues

from openhab-addons.

@robertsLando you may also want to post something about this on the OH Community Forum -- for example here...

https://community.openhab.org/t/zwave-js-ui-in-place-of-oh-zwave-binding/150007/1

from openhab-addons.

Ok I saw that @wborn already transferred the issue to the correct repo

you are asking for someone to develop an Add-on to integrate things via your API. Or??

What I want to say is: many users are moving to Z-Wave JS UI as they are not happy with the actual OpenHAB zwave addon. Actually their alternative is to use Z-Wave JS UI with MQTT discovery and, as said above, that's not the best choice neighter. There is an alternative using the weboscket apis that is not maintained directly by me but it's integrated in Z-UI and it's also the way Home Assistant is using in their official zwave integration. Mine is just a suggestion as I think could be a good addition to your platform 🙌🏼

Can you share some insights into what the users are missing with the current integration? I'm using the z-wave addon for years and am quite happy with it, but now you triggered me and i want to know what i'm missing ;-)

from openhab-addons.

@lsiepel see the forum link in my post above yours

from openhab-addons.

I'm not an OpenHab user so I cannot say what it is missing, maybe @ccutrer could tell you more about this

from openhab-addons.

As I understand it, the tl;dr is that right now zwave-js-ui supports MQTT, and auto discovery via MQTT with Home Assistant conventions, which openHAB supports, but it is not well maintained. The recommendation is that openHAB develop a specific binding that doesn't use MQTT or Home Assistant discovery at all, but instead directly connects to the zwave-js websocket port, and speaks the zwave-js javascript/typescript API, as documented at https://github.com/zwave-js/zwave-js-server.

from openhab-addons.

As I understand it, the tl;dr is that right now zwave-js-ui supports MQTT, and auto discovery via MQTT with Home Assistant conventions, which openHAB supports, but it is not well maintained. The recommendation is that openHAB develop a specific binding that doesn't use MQTT or Home Assistant discovery at all, but instead directly connects to the zwave-js websocket port, and speaks the zwave-js javascript/typescript API, as documented at https://github.com/zwave-js/zwave-js-server.

Ah, i guess my question was not clear at all. I can understand the current support for the zwave-js-server wrapper is subpar, but why would you want to use this at all? If there is allready a decent 'plug and play' zwave addon available?

I know that 7-series sticks support is a little better, but there are some PR's to fix that in the zwave-repo, like: openhab/org.openhab.binding.zwave#1900

from openhab-addons.

There is even more but all the most important features are there, thanks @ccutrer 🙏🏼

from openhab-addons.

Ah, that is a lot more then i could think of. Nice list!. Are you aware of some java wrapper to interface with zwave-js ?

from openhab-addons.

There is no java adapter but the zwave-js-server websocket apis expose everything (it's maintained by home assistant as they use it for their integration)

from openhab-addons.

no java adapter but the zwave-js-server websocket apis expose everything

I’m guessing that the API produces JSON (@robertsLando is that correct?) .. in which case it IS a Java adapter..

from openhab-addons.

Giving that I already mentioned websocket in my previous comment I thought he was looking for something Java specific, JSON over websockets is language agnostic

from openhab-addons.

agnostic

Ok (but for the avoidance of doubt JSON = Java-Script Object Notation..)

from openhab-addons.

Yeah but it's JavaScript not Java-script. Mind that Java and Javascript are two totally different languages...

If with that you meant that JSON is a JavaScript-specific thing I wrote "agnostic" because there is websockets and json (native) support for every language out there

from openhab-addons.

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/zwave-js-ui-in-place-of-oh-zwave-binding/150007/83

from openhab-addons.

FTR My recommendation in the community posting above for those who wanted to try Zwave-js was to NOT use the MQTT discovery. The alternative (and what I did) was to use OH generic Mqtt things option to pick the topics directly. This was not because it was being phased out (although that is a good reason too), but because the HA configs have problems in Jinjava transformation. @ccutrer has done a stellar job at addressing one issue in OH, the blank or "" entry and has an open PR in the Hubspot/JinJava to address the use of numbers as keys in the HA JSON configs.

I know from the forum discussions that "discovery" is important for some and currently that is the major advantage of the current OH Zwave binding.

I did look at bit at the websocket concept, but it was beyond my limited skills. My question is what would be discovered, if websocket was implemented? The current HA configs still have the Jinjava issue. Also will it be possible to enable/disable certain topics via the websocket like they can now be done with the HA Mqtt discovery? Some experienced OH users do not like the number of the HA configs that get discovered (some are redundant (IMO) and some do not need to be dynamically changed).

from openhab-addons.

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/zwave-js-ui-in-place-of-oh-zwave-binding/150007/105

from openhab-addons.

FWIW, this is my first foray into openHAB issues.

@robertsLando Are you saying that it's the "MQTT Discovery" code segment that's an issue or the zwave-js-ui integration with MQTT that's an issue? If it's just the MQTT Discovery. it might be best for the openHAB community to think about and take action on that, (i.e. the openHAB community thinking thru the MQTT naming, and figuring out how to best integrate them into the openHAB ecosystem)

However, if you are suggesting that the openHAB community switch the integration method from MQTT to WebSockets, that's a different issue. It's my understanding, and please correct, is that zwave-js-ui offers both a WebSocket and an MQTT integration point. It sounds like WebSockets is the primary and preferred (by zwave-js-ui) integrations mechanisms and MQTT is a secondary, less preferred (by zwave-js-ui) integration mechanism.

@robertsLando Can you explain the why behind (I believe) your preference for the OpenHAB community to built around the WebSockets interface vs. the MQTT interface?

Or, said another way, does it matter which integration point the OpenHAB community builds around? Why?

MQTT is a widely recognized messaging standard, whereas, the zwave-js-ui WebSocket API server/client model is very customized. It seems like from an wider adoption perspective it would be a better course to have MQTT be a "first tier" integration point. I guess I'm thinking about users of NodeRED, and a whole ecosystem of other smart integration platforms.....

As a user, one thing I've really enjoyed is pivoting from the native OpenHAB zigbee and zwave bindings to Zigbee2MQTT and zwave-js-ui. I loved the list compiled by @ccutrer. It's really nice to just have all of the devices updating MQTT. I now have wifi devices updating MQTT as well. Another thing that is fabulous about the MQTT integration is the visibility into the communications. I can see all of the updates and communications from each event using readily available tools like MQTT Explorer. As a weekend hobbyist, this insight has been monumental.

Lastly, my understanding of WebSockets is that it does not offer native pub/sub capabilities (does zwave-js-ui implement pub/sub?), and while I'm not using that capability today, it does open the door for a bunch of other possible integration points.

[Edit: It does look like zwave-js-ui has the concept of a multicast group, but not really as a pub/sub concept?]

Frankly, from my perspective, and -very- limited understanding of the technology, it would seem to me that having the openHAB community develop integrations around MQTT would be easier and much more versatile than to develop integrations around WebSockets AND in terms of broad adoption for zwave-js-ui using a standardized messaging platform like MQTT offers a great deal more users than just HA users.

It sounds like both platforms can agree that the zwave-js-ui MQTT Discovery is not the way forward as an integration mechanism?

[Edit: It does look like the HA/MQTT Discovery with openHAB is working for some!]

I'm hoping this will move the conversation along!

SixO

from openhab-addons.

it's the "MQTT Discovery" code segment that's an issue or the zwave-js-ui integration with MQTT that's an issue?

The problem is that Zwave-JS UI MQTT isn't born with MQTT discovery in mind, at start it should have been a Control Panel and a simple MQTT<--> Z-Wave gateway, then I added MQTT auto discovery support on top of it. The problem I have found with auto discovery are mostly related to complex devices like thermostats, thermostats with fans etc... For such devices I had to create this that's like a DB of all such devices to help me find out how to discover them properly. When I started developing it I also experienced many breaking changes on Home Assistant upgrades and that made it difficult to keep it updated also considering that I'm not using it at all.

Can you explain the why behind (I believe) your preference for the OpenHAB community to built around the WebSockets interface vs. the MQTT interface?

This will give them the ability to have full control of the Z-Wave devices, the experience Home Assistant users have with the Z-Wave JS integration is much better then what they could have with the MQTT Auto Discovery. But I understand that this would require at least one developer working on that plugin and keep it maintained, mine was just a suggestion in order to have the best user experience.

It sounds like both platforms can agree that the zwave-js-ui MQTT Discovery is not the way forward as an integration mechanism?

As said above I'm not against Auto Discovery It's just hard for me to keep it maintained for the reasons explained above, I had many many issues opened regarding discovery and I have no time for them, I prefer to focus on UI functionalities and other bugs.

If there are users like @ccutrer that wants to help me to keep it maintained I'm glad to review their PR, I know now there are many users using it so I have no reason to drop its support.

My goal is just to give users the best user experience :)

from openhab-addons.

@robertsLando Not to put words in anyone's mouth, but the discussion of MQTT discovery support was viewed by some that the simple MQTT <--> Z-Wave gateway support was also in danger of being dropped. Many in the OH community use the MQTT topics directly and have no desire for discovery option. Could you address that?

Ironically, your reference to the custom discovery hass/devices.ts are generally devices (thermostats) that won't work in OH with discovery anyway, at least until some change is merged in the jinjava helper application in use by OH. The use of xxxx_map: with number keys kicks out an error.

from openhab-addons.

but the discussion of MQTT discovery support was viewed by some that the simple MQTT <--> Z-Wave gateway support was also in danger of being dropped. Many in the OH community use the MQTT topics directly and have no desire for discovery option. Could you address that?

I never said that, MQTT gateway feature is the reason why I developed it and it's also the way I use it everyday. I only mentioned the MQTT discovery to be "Deprecated" but that was when Home Assistant released their integration and both Domoticz and OpenHAB were still not using zui with mqtt auto discovery, as said multiple times now I don't have any plan to drop it since I know there are many users using it.

Anyway I don't understand what I should address here, mqtt discovery is a setting that is opt-in so disabled by default, if you have mqtt gateway enabled MQTT disovery can be disabled

from openhab-addons.

@robertsLando No worries. In an international forum things can get misinterpreted. I know you never said that, but just wanted an unambiguous comment on the MQTT gateway aspect without all the MQTT discovery discussions. Thanks for doing that ! and sorry for causing any confusion.

from openhab-addons.

@apella12 No worries, I know things can be easily misinterpreted when reported from other users on forums :) Hope everything is clear now 🙏🏼

from openhab-addons.