2 reasons:
- the jinjava transform issues called out earlier in the thread
- I prefer to create the channels I require and not clutter my things with channels I am never going to use
1 Like
I found this description and tried it out.Moving from Z-Stick Gen5 to Z-stick 7 · zwave-js/node-zwave-js · Discussion #2927 · GitHub
The Gen5+ stick was running the latest firmware V1.02, according to the Aeotec homepage:
Updates Z-Wave device library to 6.07 (using Z-Wave SDK 6.81.06).
The Z-Stick 7 has FW: v7.17.2 and SDK: v7.17.2.
Thanks for sharing the link, that is good information and might help others with a simpler process. (I did suspect you were on the latest firmware on the Gen5+.)
Edit: Also glad to see yours is working on 7.17.2. There were some discussions about problems Problems with 700 series sticks (zwave-js.github.io) prior to that version and most of my testing was on 7.18.3
I have updated the Aeotec Z-Stick 7 to version V7.20.2 (FW: v7.20.2, SDK: v7.20.2) and everything has been running for a few days without any problems.
Until today? Sounds a little bit scary. So please let us know when its seems to work “forever” 
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.
3 Likes
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.
2 Likes
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)
- Pretty much all the key features of Simplicity Studio (without removing the zstick from ZUI).
a) NVM Backup
b) Zombie node removal
c) Node health check
d) Set Priority and Return Routes - Smart Start
- S2 security
- Better diagnostics (see the network routing map above (post 5)
- Larger user population (leads to more devices being available in their DB)
a) adding a new device temporarily is easier, permanently is subject to a longer delay that OHZ.
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.
6 Likes
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.
1 Like
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.
1 Like
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"]
}
4 Likes
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:
9 Likes
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 …