Zwave Z-stick SDK issue with OH Z-wave binding

Tutorials & Examples Solutions
, ,
1

Tl;dr The newest Z-sticks need an adjustment with Silicon Laboratory “Silabs” Simplicity 5 to work in openHAB (OH), until an automatic fix can be included in a stable OH Z-wave binding. (Update: there is a fix in OH5.0, but not in OH4.3.3). The procedure is outlined below:

Brief Context: Z-sticks are marketed by their chip (500, 700 and 800), but have different firmware (Silabs Development Kits (SDKs)). The latest SDK for a 500 chip is 6.x and has no issues with the OH Z-wave binding. The 700 and 800 chips use 7 series SDKs that support the Z-wave Long Range protocol (LR) but are backward compatible with “classic Z-wave”. The issue is the newest SDKs 7.21 (for 700 chip Z-sticks) and SDK 7.22 (for 800 chip Z-sticks) are shipped with 16-bit node IDs to support LR nodes IDs (256 to 4096). The OH Z-wave binding only supports “classic Z-wave” with 8-bit node IDs (1-232). Even without LR, 700 and 800 Z-sticks have performance benefits from faster chips and better range (just not LR).

Check first if this is your issue: Before going through the procedure have the Z-wave binding in debug. Look for a line like this. It should be in the response to the first message after the binding is loaded and controller found (TID 0?). If not 7.21 or 7.22, this is likely not your issue.
Got MessageGetVersion response. Version=Z-Wave 7.22, Library Type=7
Alternately review the screen shown below in the Silabs PC Controller your SDK version.

Before starting the procedure reset the Zstick and set the controller as SIS. <–Avoids an WARN message in OH

800 controller 2025-01-07 183046
800 controller 2025-01-07 183046740×654 54.3 KB

Procedure: Obtain the Simplicity Studio software. It is free but requires registration. IMO for Zwave networks of any size it is a valuable tool to remove zombie nodes, do firmware upgrades, evaluate network communication, etc.). The reference procedural outline is here for this issue. Plug your new Zstick into a USB port and start the program. Under tools, choose the PC Controller. From there follow the guide. The command to enter;

serial 0 start API 2025-01-07 182713
serial 0 start API 2025-01-07 182713762×692 40.1 KB

You can check for success with the Zniffer on the log file setup shown in the document

zniffer 2025-01-07 184109
zniffer 2025-01-07 1841091130×611 57.9 KB

Stop Studio 5, remove Z-stick and put in your OH server. Delete any prior bridge/controller attempts and create a new bridge. Best to have the Z-wave binding in Debug before creating the controller/bridge, so if there is a problem you will have the data for a forum post. Go back to INFO log level once the controller is online.

3 Likes
2

I have been working on transferring my network from my Zooz ZST10 500 stick to a SmartStick G8 800 using the G8 Migration Guide. My only successful attempt at doing this came after using the Z-Wave JS UI to back up from my 500 and restore to my 800 and then your edit using Simplicity Studio software.

Earlier attempts using various methods allowed me to back up and restore to the 800 and when plugged into Openhab everything would be green. However, if you tried to control something the device would not respond. Which lead me to searching and trying multiple methods of transferring the network from one stick to the other.

In my attempts I did try Openhab 5 and it did not seem to work until after I used your fix. Now this could have been user error or me in a delirium at that point, but it was only after I did your fix that the controller started to work and control my nodes.

So, for now, everything seems stable on the 800 stick I hope it stays that way.

Thanks again
–Jason!

1 Like
3

That is a little concerning, but I did test the PR several times before it was merged into OH5 ZW snapshot. It does the same thing as the Simplicity studio fix, just during the start process.

If anyone else has a problem with a newer Z-stick and OH5 I’ll need a debug level log to review.

4

Maybe it was due to the way I migrated to the gen 800 from 500?

I had a-lot of difficulties getting the gen 800 to have a sis =1 and for it to be considered node 1 when using simplicity Studio and Homeseer methods. In the respective applications it would look like the SIS = 1 and node 1 but when I connected to openhab 4 the web interface would show sis =1 but the error message would say it was was actually sis =0. It was also not node 1. I think in Openhab 5 it showed the SIS and node was actually 175 in my case instead of 1.

In both OH 4 & 5 changing the sis in the web interface did not work. In OH 4 it would look like it changed and even save it to the web interface as sis 1 but the sis =0 would remain in the log. I OH5 it showed 175 and if you tried to change it to 1 it would fail and revert it back to 175.

It was only after I used the standalone node js ui to migrate and did your edit in simplicity studio that things worked.

Prior to doing your fix in OH 4 and using the standalone version of node js ui I got a long message about the SIS not being >=1 the message also indicated that it was a bug. In OH 5 it was a different shorter message about sis not being =1. I will see if I cant find the message in my OH5 log tonight.

5

I’d have to go back and study a bit, but the message should be okay in OH5, but not OH4. I have this note: (That is why I suggested to set controller SIS in simplicity)

Did not avoid this- kept going even though SET SUC wasn't complete
2025-01-08 15:14:52.555 [WARN ] [.core.thing.binding.BaseThingHandler] - Attempt to apply invalid configuration 'Configuration[{key=controller_softreset; type=Boolean; value=false}, {key=security_networkkey; type=String; value=1A 58 CC 95 5D 55 92 63 30 A5 D8 06 E4 C3 02 D6}, {key=security_inclusionmode; type=BigDecimal; value=0}, {key=controller_sisnode; type=BigDecimal; value=0}, {key=controller_maxawakeperiod; type=BigDecimal; value=10}, {key=controller_sync; type=Boolean; value=false}, {key=controller_master; type=Boolean; value=true}, {key=inclusion_mode; type=BigDecimal; value=2}, {key=port; type=String; value=/dev/zwave}, {key=controller_wakeupperiod; type=BigDecimal; value=3600}, {key=controller_exclude; type=Boolean; value=false}, {key=heal_time; type=BigDecimal; value=2}, {key=controller_inclusiontimeout; type=BigDecimal; value=30}, {key=controller_hardreset; type=Boolean; value=false}]' on thing 'zwave:serial_zstick:18c96fd644' blocked. This is most likely a bug: {controller_sisnode=The value must not be less than 1.}

And this picture from the log viewer

suc800 2025-04-03 102921
suc800 2025-04-03 102921759×440 43.6 KB

6

Yea that was the message from Openhab 4.
I should have the logs from my attempts with Openhab 5 as I set it up as a test instance based on your posts which if I do I will post later today.

Unfortunately I cant do much more than that and answer questions about the steps I took as it is working now.

1 Like
7

Now that I am home, I have opened up the log and here is the line.
It is indicating and issue with NODE 1 and SetSucNodeID.

As I mentioned before In total I tried three ways of migrating networks.
1 of which was Simplicity where I tried Shift and also adding in the new controller and using Set SIS. The main issue I encountered doing this was that I could not get the new controller to be considered Node 1.

When using the back and restore of HomeSeer it was weird as it seemed like the new controller was node 1 when connected to both HomeSeer and even Simplicity (Where I tried using the Set SIS) but when I connected it to Openhab it was given a different Node 1 and not considered to be SIS 1. I also can’t remember if this happened in Openhab 5 or not but the note 1 that the stick discovered when added to my things had a thing type of the original controller ZST10.

2025-04-02 21:29:44.838 [ERROR] [serialmessage.SetSucNodeMessageClass] - NODE 1: SetSucNodeID command failed.
8

No worries and I appreciate the posts. What caught my eye was the OH5 reference because the ZW binding has not been updated in the patch releases OH4.3.X. Since OH5 needs java 21 and a 64-bit OS and add in the requirement for a new Z-stick with SDK 7.21 or .22, you might have been the first (besides me) to test it. My tests are pretty standard, but you never know what will happen out in the “wild”.

However, I need to have debug log information (from someone else :wink: ) to see if there is a problem. The error looks like something that would happen with 16-bit nodes ID’s but that is a guess.

tl;dr -As noted the WARN message will still appear, but in OH5 it is not fatal and due to a timing issue. When the controller starts, the binding immediately queues 5 or so messages. When the SUC is not set is returned, a new message is added to set it, but it gets added to the end of the queue and the rigorous checker in the core (note that it is from the BaseThingHandler) is triggered first. You can see that in the picture. Anyway you are up and running.

9

Yep, I just hope my trial and error helps others. The process/documentation on moving from a zwave 500 stick to a zwave 800 is fairly spotty and inconsistent. With brick your stick warnings if you try and migrate to a Zooz 800 and/or use Simplicity studios back up function. Granted most of my googling yielded results from a year or so ago and some of these issues may have been resolved. In my research the best stick to migrate from a 500 or 700 stick was the G8 which had the best documentation around even if it was incomplete in regard to getting it to work with Openhab which is where this post came in.

In the end I did get it to work on both Openhab 4 and 5 although I am not ready to fully migrate to 5 yet. I do look forward to migrating to it though as I like keeping up to date but somehow, I always end up needing to spend hours due to my stubbornness fixing some random issue that forces me to learn new things about hardware/coding/interfaces, etc…

Thank you again for your hard work in identifying this issue and providing a solution that I could find!

10

Too late in this case, but I have put this on the forum before (but don’t recall where).
Transitioning a network from 500 chip.pdf (235.8 KB)

11

I just successfully migrated from a Razberry Zwave 500 Controller to a Zwave 800 Zooz ZST39 Stick using backup/restore. And it worked absolutely fine and fast.

Source: RaZberry2 Zwave 500 Controller on latest firmware ( OH 5.0.2 on Rasperry 4, openhabian, OH-Zwave Binding)
Destination: A brand new Zooz ZST39 Zwave 800 Controller

This ist what I did:

  1. Stopped OH Service
  2. Startet latest Zwave JS UI in Docker
    (I interviewed all devices at an earlier stage, not sure if it’s needed for this process)
  3. Take a NVM backup of the old Razberry2 controller
  4. Shutdown to remove Razberry and connect Zooz Stick
  5. Startup RPi4 and stop OH Service to start Zwave JS UI again (Adjust path of Controller)
  6. Obviously no devices will be displayed anymore at this stage.
  7. Update Zooz Stick to latest firmware (1.6)
  8. Take NVM Backup of Zooz Stick (Just to be save)
  9. Restore NVM backup of old controller (Razberry2) to ZooZ Stick
  10. After less than a minute it was finished an all devices where back. (I was so relieved :slight_smile: )
  11. Rebuild the routes in Zwave JS UI to be sure they are optimized with the new controllers range
  12. stop Zwave JS UI
  13. Start OH Service and navigate to the controllers thing which now may be offline if your device path changed (like in my example)
  14. modify the controller thing to the new device path if needed and give it some time to initialize. (I disabled and re-enabled the thing because it stayed offline for some seconds. But maybe it’s not needed)
  15. After some seconds, it should be back online as should all Zwave nodes.

I’m so happy this worked. Because of the Razberry2 controller I would have had no other choice than exclude/re-include 46 devices.

I hope this helps others who are afraid of possible controller bricks when using backup/restore

1 Like
12

I have tried to migrate from one 500 controller to another in the past, but had to back out. It’s very nice when people post something that actually worked for them, even if there potentially are unnecessary steps there. To me, it’s absolutely crucial to not have to include all the devices again, so I’ll gladly perform some extra steps as long as I get there in the end :wink:

13

Yes there may be potentially unnecessary steps. But it was important to me not to leave anything out, because I think there is a lot of uncertainty out there regarding this. Like this each one can decide for himself which steps he wants to take or not :wink:

As far as I know in the past there where issues with restoring. But i read somewhere (Maybe HA Forum) that it was fixed in Zwave JS UI. Because of this I lukily gave it a try.

1 Like
14

Yes, in the past there were issues with a correct NVM-Backup/Restore in ZWave-JS-UI. In the meantime this is working really quite good.

In the past weeks I jumped a lot between different ZWave-Controllers (Zooz, Aeotec) and Platforms (500/700/800) back and forth to try things out and find the right controller for my system (Home-Automation with ~100 Z-Wave-Things).

It is quite easy using NVM-Backup/Restore in ZWave-JS-UI. The only thing you need is a ZWave-JS-UI instance (either standalone or with Home-Assistant). I used an older RaspberryPi for this.

15

With OH5.0 there is a zw-js binding that uses the ZUI websocket too

1 Like
16

Will all that effort - do tell us - which worked best? I’m very curious.

1 Like
17

Yes, I know, thats the ZWave-integration I use in the meantime.

18

Yes, will write down some lines about my findings of this journey in the next days.

2 Likes
19

If you are using Z-Wave sticks in OH5, the best way to do it right now is to use the ZWave-JS binding with the Z-Wave JS UI websocket. It is now much easier to back up and restore NVM, so switching between sticks (Aeotec, Zooz) or moving between the 500, 700, and 800 series is much less painful than it used to be.

Important things to remember from real life:

For backups, use a separate ZWave-JS-UI instance (Pi works well).

Always back up your NVM before changing sticks.

The binding and websocket combination works well with big setups (about 100 devices).

It doesn’t matter much if you choose standalone or Home Assistant; just choose the one that works best for you.

In short, controller changes and restores are now solid thanks to JS binding and NVM backups.

20

FWIW. A PR has fixed this issue in OH5.0 and beyond, so this procedure is not needed any longer.