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

apella12 · January 9, 2025, 2:02pm

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

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;

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

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.

JKotan · April 3, 2025, 4:31am

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!

apella12 · April 3, 2025, 12:30pm

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.

JKotan · April 3, 2025, 1:14pm

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.

apella12 · April 3, 2025, 2:32pm

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

JKotan · April 3, 2025, 4:22pm

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.

JKotan · April 3, 2025, 11:20pm

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.

apella12 · April 4, 2025, 1:15am

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

JKotan · April 4, 2025, 3:53am

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!

apella12 · April 4, 2025, 2:28pm

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)