Short update:
Moved to Zwave-JS-UI 3 weeks ago - no issue what-so-ever and therefore removed Zwave binding 2 weeks ago.
Not regretting this change.
Should have done that way earlier, since finally all my use-cases are covered.
Additionally this issue Z-Wave Binding: Fibaro FGR-222 Rollershutter UP command not fully raising Blind is finally resolved as well.
Strongly recommending this change to anyone asking.
Hello,
i am not familiar with nodjs sooo…installed zwavejs ui via
npm install zwave-js-ui
How can i start it now?
What bout reading the zwave-js-ui documentation.
Other than the Fibraro RollerShutter not fully supported in OH zwave, what are the other use cases? It’s always good to understand differences of the OH zwave implementation compared to others.
I’ll let @Chri46 answer for himself, but throw in my 2 cents.
I started with OH several years ago because of the open-source ZW binding. I would not be using OH today without the ZW binding being available then. I’m personally grateful to the developer for that (and try to provide ZW support within my ability). Since the move to NZ the developer has been very busy with his real job and so the binding hasn’t changed much beyond incorporating new devices. That’s fine, this is a volunteer effort.
OTOH, Zwave-JS-UI (formerly Zwave2MQTT) has been able to leverage the HA connection to include new features and fund more active development. I wrote this post to highlight that OH users did not have to switch to HA to get the benefit. (similar to Zigbee2MQTT). The major drawback is generic MQTT things need to be used (at least in part - the HA discovery configs do not always work.)
Now, to answer your question; ZUI has (to name a few)
As to the future, the ZUI team seems focused on certification by the ZW Alliance and true ZW Long Range support.
I think the OH ZW binding is great for new and OH users with only a few ZW devices (discovery is a snap), but for users with larger networks, comfortable with generic MQTT, and committed to ZW, ZUI is going to be an attractive alternate.
really nothing to add to @apella12 summarization.
I started with OH back in 2017 because of ZW binding and from my point of view ease of use compared to HA back then.
After deciding for OH and defining my use-cases, I did hit a few issues with OH + ZW binding (Z-Wave Binding: Fibaro FGR-222 Rollershutter UP command not fully raising Blind and Fibaro FGR222 Roller Shutter 2 in Venetian Blind mode - use of manual switch no updates sent to OH2.4), but was too deep into OH and finally accepted those 2 issues as “known limitations” (mainly to due to lack of time to migrated all to HA).
After learning about Zwave-JS-UI and finding some time around Christmas to investigate and test the migration to Zwave-JS-UI I was convienced that Zwave-JS-UI is the way to go.
The number of devices supported by Zwave-JS-UI is another compelling advantage over Zwave binding, refer to Zwave-JS supported devices, and so is the larger user base.
In my view the switch to Zwave-JS-UI makes sense for all network sizes, even if MQTT needs to be introduced at same time.
The migration from binding to Zwave-JS-UI was as simple and as straight-forward as described in the previous post.
And of course, there is nothing stopping someone from either fixing the HA discovery to work better or implementing a discovery add-on to MQTT to support what ever their “normal” MQTT topic structure is. I’m a little surprised that no one has done this for zigbee2mqtt yet.
How can I switch a binary sensor via openhab?
Here is my implementation
Thing mqtt:topic:zwave (mqtt:broker:mosquitto) {
Type switch : nodeID_2_switch_binary "nodeID_2_switch_binary" [ stateTopic="zwave/nodeID_2/switch_binary/endpoint_0/currentValue", commandTopic="zwave/nodeID_2/switch_binary/endpoint_0/targetValue", on="true", off="false", transformationPattern="JSONPATH:$.value", formatBeforePublish="{\"value\": %s}"]
}
I only see the current value but can’t switch it via openhab…
solved with this
Thing mqtt:topic:zwave (mqtt:broker:mosquitto) {
Type switch : nodeID_2_switch_binary "nodeID_2_switch_binary" [ stateTopic="zwave/nodeID_2/switch_binary/endpoint_0/currentValue", commandTopic="zwave/nodeID_2/switch_binary/endpoint_0/targetValue/set", on="true", off="false", transformationPattern="JSONPATH:$.value", formatBeforePublish="{\"value\": %s}"]
}
Glad you found that.
FYI yesterday I updated the first post. Added some links to the zwave-js-ui “Quick start” (an earlier question) and updated the zwave-js-ui channel examples to help with questions like yours. It is based on UI (not textual), but the “state” and “command” topics will be the same.
I’ve also recently switched to ZwaveJSUI for many of the same documented reasons as @apella12. I took a slightly different route using the text-based .things configurations in the things folder. I wanted to provide a few examples of my configurations in hopes that it helps others.
Thing mqtt:topic:zwave01-nodeID_2 "F2_BonusRoom_Overhead_Light" (mqtt:broker:8fd56e1f3c)
{
Channels:
Type dimmer : dimmer
[
transformationPattern="JSONPATH:$.value",
stateTopic="zwave01/nodeID_2/switch_multilevel/endpoint_0/currentValue",
commandTopic="zwave01/nodeID_2/switch_multilevel/endpoint_0/targetValue/set",
min=0,
max=99,
step=5
]
}
Thing mqtt:topic:zwave01-nodeID_7 "F3_Attic_4_in_1" (mqtt:broker:8fd56e1f3c)
{
Channels:
Type number : temperature [stateTopic="zwave01/nodeID_7/sensor_multilevel/endpoint_0/Air_temperature",unit="°F",transformationPattern="JSONPATH:$.value"]
Type number : illuminance [stateTopic="zwave01/nodeID_7/sensor_multilevel/endpoint_0/Illuminance",transformationPattern="JSONPATH:$.value"]
Type number : humidity [stateTopic="zwave01/nodeID_7/sensor_multilevel/endpoint_0/Humidity",unit="%",transformationPattern="JSONPATH:$.value"]
Type number : motion [stateTopic="zwave01/nodeID_7/notification/endpoint_0/Home_Security/Motion_sensor_status",transformationPattern="JSONPATH:$.value", off="0", on="1"]
Type switch : cover [stateTopic="zwave01/nodeID_7/notification/endpoint_0/Home_Security/Cover_status",transformationPattern="JSONPATH:$.value", on="0", off="1"]
Type number : battery [stateTopic="zwave01/nodeID_7/battery/endpoint_0/level",transformationPattern="JSONPATH:$.value"]
Type switch : battery_low [stateTopic="zwave01/nodeID_7/battery/endpoint_0/isLow",transformationPattern="JSONPATH:$.value", off="false", on="true"]
}
Thing mqtt:topic:zwave01-nodeID_11 "CS_Storage_SumpPump_Outlet" (mqtt:broker:8fd56e1f3c)
{
Channels:
Type switch : switch
[
transformationPattern="JSONPATH:$.value",
stateTopic="zwave01/nodeID_11/switch_binary/endpoint_0/currentValue",
commandTopic="zwave01/nodeID_11/switch_binary/endpoint_0/targetValue/set",
on="true",
off="false"
]
Type number : kWh [stateTopic="zwave01/nodeID_11/meter/endpoint_0/value/65537", transformationPattern="JSONPATH:$.value"]
Type number : watts [stateTopic="zwave01/nodeID_11/meter/endpoint_0/value/66049", transformationPattern="JSONPATH:$.value"]
Type number : volts [stateTopic="zwave01/nodeID_11/meter/endpoint_0/value/66561", transformationPattern="JSONPATH:$.value"]
Type number : amps [stateTopic="zwave01/nodeID_11/meter/endpoint_0/value/66817", transformationPattern="JSONPATH:$.value"]
}
I’m actively working on it! I’ve already had a few PRs accepted into zwave-js-ui to make things work better with openHAB’s mqtt.homeassistant binding (and technically Home Assistant if one were to us Home Assistant with zwave-js-ui over MQTT, but that’s pretty highly discouraged), as well as lots of recent work on the openHAB side in the MQTT binding. There are still a few open issues, but I really want to get to the point where people don’t need to recommend using generic MQTT things to hook up a bunch of ZWave (or zigbee! I also use zigbee2mqtt) devices to openHAB.
I switched to zwave-js-ui a couple weeks ago. I have a quite large network (~150 nodes). I also switched from a Aeotec Z-stick Gen 5 to a 700 series (Zooz ZST10-700) in the process, and wanted to re-include my devices with S2, so I ran both networks in parallel for a couple weeks during the transition. It was a little rough for a bit during the transition, especially as the old network lost routes so got quite laggy. But now that it’s done, I’ve been ecstatic with the performance. Besides actually being able to remove failed nodes, the inclusion and exclusion UX is very much clearer in zwave-js-ui, not having to be confined to openHAB’s UI. It’s an actual wizard, and shows the state of the device (if it’s in inclusion mode or not), instead of just hoping and praying that inclusion or exclusion was actually triggered in openHAB, or not knowing if it stopped early due to other ZWave activity. Really, my biggest wins though have been with zwave-js-ui’s network map, and the ability to configure priority routes. ZWave is super resilient to RF interference and routing changes, always routing around. But I’ve found in my complicated network it often gets “stuck” with sub-optimal routes. You can try to HEAL (or Rebuild Routes as zwave-js-ui more intuitively calls it) a device (or the whole network!), but that’s usually a crapshoot if it actually improves things. By specifying priority routes and using the health check tool, I can be assured that devices will always try what I’ve determined is the quickest route (almost always direct; and often direct with a lower transmission speed is faster than taking an extra hop) first, and then if some intermittent RF conditions interrupt that it will try something else, but just for that transmission. The other super nice thing is that the ZWave controller’s “life cycle” is no longer connected to openHAB. So restarting openHAB no longer means my ZWave network goes to crap for 30-45 minutes while it tries to re-interview every device. In fact, zwave-js-ui doesn’t even re-interview devices on restart - it just pings them.
Here’s my network map:
I’m under the impression that HA is stepping away from the HA MQTT standard anyway so that doesn’t surprise me.
Completely off topic. MQTT 5 introduced retained message expiration: MQTT Session Expiry and Message Expiry Intervals – MQTT 5 Essentials Part 4.
You’ve been in the code, would that be challenging to add as an option? It’s a pretty useful option over all in a lot of use cases. IIRC the HiveMQ library is used for MQTT in the binding so it should be supportable.
Interesting - have you read posts about it or how do you come to this conclusion?
Maybe I’m misremembering. But I recall seeing some comments in PRs and issues to that effect when Tasmota dropped HA MQTT support.
I don’t know - I’m just curious. I know that they seem to make extensive use of web sockets for their service-to-service communication. But we’re getting off topic …
For sending commands to devices, it would likely be pretty easy to add. Would it be useful, though? We don’t currently send commands as retained at all.
For receiving messages, I’d have to look into it in more detail. It would depend on the use case (i.e. discovery messages, availability messages, or state messages), and even then it’s probably down in the lower level handling in mqtt (not even mqtt.generic) which I don’t go into much (last time was to fix an issue with handling of retained messages, though). But until someone has an example of a device that uses this feature, I’m not inclined to spend much time investigating it. So many other things that are higher priority!
No, I wouldn’t use it for retained commands but not all messages published by MQTT are commands.
For sensors it’s not unusual to publish messages as retained. That’s how the MQTT Event Bus rule template does it. Without a timeout that last sensor reading stays there forever. With a timeout eventually the reading goes away and there isn’s a false sense of a sensor reading that’s working but is in fact stale. Clients don’t know when a message was published. All they know is when they connected to the broker they got a message.
I was mainly thinking about the publishMQTT Action though, not the Generic MQTT Thing. But it wouldn’t be awful to be able to set a timeout where ever we can set the retained flag itself.
That’s transparent to OH. It’s the publisher that sets the timeout.
It’s a call on the chain in the call to the publishWith method.
Publish - HiveMQ MQTT Client It would be passed along and handled the same as the retained flag.
How set up the "native Tasmota discovery"? - #9 by Johann_Obermeier is the best reference I can find. I would guess he’s a non-native English speaker, so the grammar isn’t completely clear. I read it as “Home Assistant [discover in Tasmota] has deprecated” not that “Home Assistant has deprecated MQTT discovery”. AFAICT MQTT discovery in Home Assistant is alive and well… there have been some recent additions to it. A bit of browsing around looks like the Tasmota was dissatisfied with how their specific features map to Home Assistant’s discovery “schema”, as well as how much code it took for them to implement it, so they made their own that maps more directly to their features, and is more compact. In Tasmota, this is implemented in Sonoff-Tasmota/tasmota/tasmota_xdrv_driver/xdrv_12_discovery.ino at development · stefanbode/Sonoff-Tasmota · GitHub, and it sounds like the Python library Home Assistant uses to parse it is GitHub - emontnemery/hatasmota. It looks like someone started implementing an openHAB binding at openhab-addons/bundles/org.openhab.binding.mqtt.tasmota at main · JoergOstertag/openhab-addons · GitHub, but looks abandoned. I don’t run Tasmota, so don’t have much interest in continuing that work. But if someone else were to finish that binding, I would definitely keep it in mind when doing other MQTT maintenance work.
What I have gathered about HA from using ZUI is that the websocket server is preferred over the MQTT discovery.
edit: Regarding stale data: I have been using the ZUI lastActive (via items) in OH widgets.
I was under the same impression as Rich, but it was from a couple of years ago and I can’t remember where I got the information. I think it’s very likely (in my case) that it started out as “Tasmota has deprecated HA discovery” and turned into “HA discovery is deprecated”.
