search

openhab / openhab-addons

Add-ons for openHAB
https://www.openhab.org/
Eclipse Public License 2.0
1.85k stars 3.56k forks source link

Z-Wave JS official integration #16374

Open robertsLando opened 5 months ago

robertsLando commented 5 months ago

Hi everyone,

Firstly sorry if this is not the right place to ask this, if not just redirect me to the correct place.

I'm the developer of zwave-js-ui, I started receiving many issues from your users that are currently using MQTT discovery in order to use their Z-Wave devices with OpenHAB.

As I explained in docs:

MQTT Discovery is limited compared to a native integration and Home Assistant updates frequently break it. Based on this I would NOT RECOMMEND using MQTT Discovery, I don't plan to keep it maintained in the future.

So I'm here to ask you if you could consider developing a plugin that uses the websocket apis like Home Assistant Z-Wave JS integration does: https://zwave-js.github.io/zwave-js-ui/#/homeassistant/homeassistant-official?id=how-it-works

This is the most reliable way to work with z-wave js, informations about websocket apis can be found here: https://github.com/zwave-js/zwave-js-server

andrewfg commented 5 months ago

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

robertsLando commented 5 months ago

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 šŸ™ŒšŸ¼

andrewfg commented 5 months ago

@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

lsiepel commented 5 months ago

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 ;-)

andrewfg commented 5 months ago

@lsiepel see the forum link in my post above yours

lsiepel commented 5 months ago

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.

robertsLando commented 5 months ago

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

ccutrer commented 5 months ago

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.

lsiepel commented 5 months ago

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: https://github.com/openhab/org.openhab.binding.zwave/pull/1900

ccutrer commented 5 months ago

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:

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.

robertsLando commented 5 months ago

There is even more but all the most important features are there, thanks @ccutrer šŸ™šŸ¼

lsiepel commented 5 months ago

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 ?

robertsLando commented 5 months ago

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)

andrewfg commented 5 months ago

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..

robertsLando commented 5 months ago

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

andrewfg commented 5 months ago

agnostic

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

robertsLando commented 5 months ago

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

openhab-bot commented 4 months ago

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

apella12 commented 4 months ago

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).

robertsLando commented 4 months ago

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)

openhab-bot commented 3 months ago

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

switzer60 commented 3 months ago

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

robertsLando commented 3 months ago

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 :)

apella12 commented 3 months ago

@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.

robertsLando commented 3 months ago

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

apella12 commented 3 months ago

@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.

robertsLando commented 3 months ago

@apella12 No worries, I know things can be easily misinterpreted when reported from other users on forums :) Hope everything is clear now šŸ™šŸ¼