Zwave-JS-UI in place of OH Zwave binding

All that sounds complicated. Technically both OH and HA could subscribe to the same Mqtt topics (ZUI in MQTT mode), so graphing in either would be possible. The complication would be control/rules. Sending duplicate commands (from HA and OH) back to ZUI is asking for trouble.

EDIT: welcome to the community.

Thank you, I get your point.

Maybe another layer ZUI could be developed to manage this issue, but also remember how often these commands might be happening. In my house, unless the wife’s favorite “all off” is issued, even with all my devices, not much is being commanded (I know polling is likely going on) but using basic queues and queue logic it might be able to return a deny response (which is likely outside of the zwave protocol process) or just queue it as it comes in, or allow priority queuing, ex. OH commands come first (this can be done on host IP alone).

I think it would make it so much easier to switch either direction or use both without having to worry about doubling up on zwave modules and make them become zwave friends. I mean with ZUI, the first big step is complete.

Reason for me, I am planning in home HA, because the wife for whatever reason likes it better and for now I will use Tailscale for remote access. However, among other things I have a DMZ in my house, yeah, overkill, whatever, and plan to put OH there for external user access and guest access. I would love to convert her and make the switch easy and even have inside/outside OH systems. That way I can have different plugins loaded and network access restricted.

Sorry for the security and network nerd stuff.

Merry Christmas!

BTW, wasn’t the issue around websockets (although I see OH could do it does ZUI not or only for HA integration I should say)?

You are far more network technical than I. I had MQTT running so ran my ZUI test with it.

Can ZUI support 2 WS connections? (don’t know). I know WS is the recommended way for HA and I know OH has WS support. I suggested MQTT for your idea because I know both apps can be subscribers.

ZUI can take care of the device inclusion, polling, configuration, etc and Zwave network management all by itself. At a high level, OH and HA are both Home automation apps that get the incoming data (from Zwave, Zigbee, cameras, etc.) and decide what to do based on your rules, scripts. Publishing is what is tricky IMO. In the Zwave case, they would publish back to MQTT and ZUI would make it happen.

Anyway good luck !

Hello everyone,

I have also switched to Z-Wave JS UI because I have all the tools for e.g. backing up the controller, deleting dead nodes etc. in one tool.

Basically it is quite simple if you know how to do it. I switched to Docker (there are plenty of instructions here) and then created another Z-Wave JS UI stack.
The Docker Compose file can be found on the Z-Wave JS UI Github page (https://github.com/zwave-js/zwave-js-ui/blob/master/docker/docker-compose.yml).

At the beginning you have to read out the ID of the Z-Wave stick that goes
with

ls /dev/serial/by-id/
usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_7-port0

and enter it in the Docker Compose file

devices:
   # Do not use /dev/ttyUSBX serial devices, as those mappings can change over time.
   # Instead, use the /dev/serial/by-id/X serial device for your Z-Wave stick.
   # To find the ID use:  ls /dev/serial/by-id/
    - '/dev/serial/by-id/usb-Silicon_Labs_CP2102N_USB_to_UART_Bridge_Controller_7-port0:/dev/zwave'

Now comes the part that is a little more complex. Extracting the correct information from the MQTT data and assigning it to the old items. I used the MQTT Explorer to do this.

I left the openHAB Z-Wave binding on for the time being because otherwise my original Z-Wave things would be empty.

Here is an example of a thermostat (See all my Z-Wave devices here
zwave-js-ui-channel.txt (5.2 KB)
)

First the information as I see it in the MQTT Explorer
grafik

To display the current temperature, I have to search for the Air_temerature entry and enter it in the corresponding channel in the thing.

UID: mqtt:topic:73089d4ec9:Wohnzimmer_Heizkoerperthermostat_Node_3
label: Wohnzimmer Heizkörperthermostat
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:73089d4ec9
channels:
  - id: sensor_temperature
    channelTypeUID: mqtt:number
    label: Current temperature
    description: Indicates the current temperature
    configuration:
      stateTopic: zwave/nodeID_3/sensor_multilevel/endpoint_0/Air_temperature
      transformationPattern: JSONPATH:$.value
      unit: °C

If I don’t know exactly where to find the current temperature value, I can also view this very nicely under Z-Wave JS UI

2 Likes

I became very familar with MQTT the last weeks and all Channels based on Generic MQTT Items work increadible perfect (Tasmota on the other side)

So know I am very interested on an experimental Z-Wave Setup (lets say with 3 Nodes) and the BackUp functionality of Zwave-JS-UI.
Not sure If I will also go the Docker way.

Can anyone explain me what I do need after a factory reset of all devices? How can I start recovery (lets say based on a broken Raspery or it SD-Card)

Thanks a lot and Happy New Year 2024!

Second choice IMO would be the package installation. I found SNAP doesn’t work well with Rpi Debian and using YARN to compile uses a lot of resources (worked on 2G Rpi4, but not on 1G Rpi3). Lastly Zwave-JS-UI does get updated frequently, so keep that in mind. Docker upgrade is easy.

Not quite sure what you are doing here. I just used the same Z-stick, no factory reset, no recovery. Network is on the Zstick, not in OH (or ZUI for that matter). Had both OH (ex-ZW binding) and ZUI running

If Rpi/SD card broken and no other apps running, reimage SD with Debian O/S, and follow one of the non-Docker Zwave-JS-UI instructions

Used Z-Wave Binding all the time with 3x OH Installation and was not able to restore 52/Nodes Z-Wave-Items. Its a nightmare to reconfigure such a Mesh and therefore I search for a masterplan of restoring before doing it the next time.

I had the Aeotec Z-Stick Gen5+ controller in the past. For Z-Wave JS UI, I swapped the Gen5+ for the Z-Stick 7. To do this, I first started Z-Wave JS UI with the Gen5+ stick and made an NVM BACKUP (Control Panel → Advanced Actions)

I then shut down the system, replaced the Gen5+ with the Z-Stick 7 and rebooted. I then used NVM RESTORE to restore the Gen5+ backup to the Z-Stick 7 and everything worked. In the the past I have used a tool to back up the Aeotec Gen 5+ stick, which can be found can be found on the Aeotec site.

Moved away from Zwave binding to Zwave-JS-UI.
The cut-over to Zwave-JS-UI was pretty straight-forward in my setup.
Running Openhab (now 4.1) in docker container on Synology NAS (on lastst DSM version) (since years) and Aeotec Z-Stick Gen5.

  • added Zwave-JS-UI docker container
  • stopped the Zwave binding in karaf (bundle:stop id)
  • started up the Zwave-JS-UI container and changed the configuration to use the same serial port as before. All Zwave nodes were visible immediately, and I was even able to easily remove dead nodes. I did not define the zwave device in docker configuration in Synology´s container manager.
  • Zwave-JS-UI Home Assistant settings are switched off
  • configured Zwave-JS-UI to use existing mqtt broker (running in dedicated docker container)
  • created Generic MQTT things for all my Zwave devices (sensors, rollershutters, switches)
  • created the required channels for each Generic MQTT things
  • linked to the channels to the existing items used before with Zwave Binding
  • all rules worked without any modifications

Running this setup for another week before finally removing Zwave Binding.

The main benefit and improvement for my setup is that the Fibraro RollerShutter in Venetian blinds mode are not fully supported by Zwave Binding (https://community.openhab.org/t/fibaro-fgr222-roller-shutter-2-in-venetian-blind-mode-use-of-manual-switch-no-updates-sent-to-oh2-4

The Zwave-JS-UI has full support and all my use-cases are finally covered, opening/closing/tilting blinds with physical switches is now reported back and both Homekit (via node-red in dedicated container) and all rules are picking up the correct and actual blinds position and tilt angle.
A small modification in node-red was required to get rid of the workarounds required to handle/translate the tilt angle, but this change was expected.

Basically followed the same procedure. Thanks for the summary version :smiley:

Still a little confused. Even if Rpi and SD crashed the 52 Zwave nodes should still be on the stick. You should be able to use that in either OH ZW or Z-Wave UI, if you have not factory reset it.

As to backup, as noted by @HolBaum5 I periodically backed up my zsticks using either the Aeotec tool or the Silabs Simplicity suite (depending on the SDK of the stick). Now I just use a Z-Wave UI’s weekly NVM and Store backup.

This worries me a bit (but I’m glad it worked for you). There are numerous warnings about incompatibility between Zsticks of different SDKs. What SDK was your Gen5+ Zstick?

I started on a guide (draft).
Transitioning a network from 500 chip.pdf (235.8 KB)

Why do it: “Zwave-JS-UI Home Assistant settings are switched off” ?
I was thinking that auto-discovery in OH would make the move easier since then all the channels appear automatically and are easier to link to items from both “.item” files and the UI.

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” :wink:

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