Every thing works fine with my devices in openhab 4.1.1. all my devices where detected .
After updateing to openhab 5.1 2 only some devices will be discovered.
NODE 23 all OK
NODE 24 not dicovered
in openhab 4.1.1 the where the similar devices with same capabilities
Both devices are from outside the same doorcontact from devolo
This i found in logfile
========================= begin LOG =================================
2026-02-23 12:02:43.058 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 24: Controller is ONLINE. Starting device initialisation.
2026-02-23 12:02:43.063 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 21: Updating node properties.
2026-02-23 12:02:43.067 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 21: Updating node properties. MAN=2147483647 <<<<<<<<<######### not discovered
Log looks like an initial startup. Could try to wake the device (door contacts are battery). What are the contents of the userdata/zwave folder? What nodes are missing?
pi@raspberrypi:~/openhab/userdata/zwave $ ls -al
insgesamt 44
drwxr-xr-x 2 root root 4096 23. Feb 14:48 .
drwxr-xr-x 12 root root 4096 23. Feb 14:16 ..
-rw-r–r-- 1 root root 9677 23. Feb 14:48 network_ed00e56a__node_13.xml
-rw-r–r-- 1 root root 1815 23. Feb 14:16 network_ed00e56a__node_1.xml
-rw-r–r-- 1 root root 18491 23. Feb 15:24 network_ed00e56a__node_23.xml
where 13 is a keypad and 23 is a door contact:
13 and 23 are the ones , that always will be discovered.
I installed also a 4.3.10 version and i have the same behavior.
The Zwave Stick is a aontec zwavestick gen 5 (approx. 5 years old) and a raspi 3
all the other door contacts are missing. But the will be shown as online. And i see some communication, if i open / close the window.
fun fact: I removed from one door contact the battery and it was shown as online.
and i got sometimes
NODE 20: Error decapsulating security message
java.security.InvalidKeyException: No installed provider supports this key: (null)
at javax.crypto.Cipher.chooseProvider(Cipher.java:963) ~[?:?]
at javax.crypto.Cipher.init(Cipher.java:1313) ~[?:?]
at javax.crypto.Cipher.init(Cipher.java:1246) ~[?:?]
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.generateMAC(ZWaveSecurityCommandClass.java:528) ~[bundleFile:?]
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.getSecurityMessageDecapsulation(ZWaveSecurityCommandClass.java:319) [bund
leFile:?]
at org.openhab.binding.zwave.internal.protocol.ZWaveNode.processCommand(ZWaveNode.java:1253) [bundleFile:?]
at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager$ZWaveReceiveThread.run(ZWaveTransactionManager.java:548) [bundleFile:?]
2026-02-23 17:42:08.956 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 61
The security message could indicate the issue. If those devices were installed with security, you need to transfer the old key to the new installation. How did you backup the old?
Edit also debug is fine and use the code fences <\>
Another general questions. What os is the rpi3 running. For 5.1 it needs to be 64bit and Java 21. OH 5 is going to be a tight fit IMO, unless it is a pretty small install. Although not related to your current issue.
Thx Bob for the Replay.
Security was in OH 4.3.10 disabled for all Devolo Doorcontacts, so it should not be a problem on the device .
OS on Raspi is Debian
uname -a
Linux raspberrypi 6.1.21-v7+ #1642 SMP Mon Apr 3 17:20:52 BST 2023 armv7l GNU/Linux
Java is 21 , otherwise openhab won’t start. Startup script checks java version.
All Missing things have aa property zwave_secure with value false
To be honest, I can’t infer what the problem could be with the information so far. How many zwave nodes do you have and what other bindings? Three options
Detail the steps you did to transition from OH4.1.1 to OH5.1.2. Did you use apt update, did you make a backup and then restore? Did you manually create a new Zwave bridge or was that restored?, etc. All that will only help to understand what went wrong but probably won’t fix it. The zwave folder should still contain all your nodes after any upgrade path, although the date stamps of the problem devices will be old. Since that is not the case, I’m not sure what happened without more details.
On OH5.1.2 set the Zwave binding in debug (not trace) and restart OH. The log will be long and as new to the community (welcome by the way) you won’t be able to upload it. However, there is a debug viewer here that can provide a picture. Maybe a screen shot or two around the problem devices
The simplest might be (depending on the number of nodes) to use the exclude devices in OH5.1.2 (won’t work in OH4.3.10) and exclude the problem nodes, then use the scan to rediscover. Check the node manual for what to press on the device to exclude and include. They should be a new nodeID and you will have to relink channels to your old items and delete the orphan links. Keep the old items so your rules will work. A debug log of the inclusion (if unsuccessful) would help diagnose what is going on, if there are still issues.
Thx to all.
I got with some magic ( i dont understand ) all my devices working. The last node shows all the sensor values, but the device wasnt correct discovered. After removing the Battery, discovery works and now the last device is discovered and works.
Sorry this was not the End, one device ist still waiting for device init
… NODE 21: Polling…
… NODE 21: Polling deferred until initialisation complete
But i guess the device had still worked. The device shows several channel (temperatur, OpenClose Type) and so on, but still the manufacturer is not set
her some logs from before
2-25 17:27:46.067 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 21: Initialising state channel zwave:device:f65420ee61:node21:alarm_tamper for OnOffType
2026-02-25 17:27:46.075 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 21: Initialising cmd channel zwave:device:f65420ee61:node21:sensor_door for OpenClosedType
2026-02-25 17:27:46.077 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 21: Initialising state channel zwave:device:f65420ee61:node21:sensor_door for OpenClosedType
It seems most (all) of the devices with the problem are battery powered. My initial suggestion was to wake the device by pressing the button per the manual (usually 1-3 times quickly). I’d still suggest that sequence maybe a minute apart until the xml shows up in the zwave folder.
With some devices pulling the battery out, waiting a bit and putting back in will do the same thing. There is sometimes a 30 -60 period when the device is awake and will get configured. Using the log viewer, the end will like this
so i made a hard reset of the zwave controller ( all Nodes gone ) and i included evrey node again into a zwave network and then it works.
The class ZWaveManufacturerSpecificCommandClass get the manufacturer
here is the log
=============================== LOG ====================================
026-02-26 16:06:44.754 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 5: Received COMMAND_CLASS_MANUFACTURER_SPECIFIC V0 MANUFACTURER_SPECIFIC_REPORT
2026-02-26 16:06:44.755 [DEBUG] [WaveManufacturerSpecificCommandClass] - NODE 5: Manufacturer ID = 0x175
2026-02-26 16:06:44.757 [DEBUG] [WaveManufacturerSpecificCommandClass] - NODE 5: Device Type = 0x2
2026-02-26 16:06:44.758 [DEBUG] [WaveManufacturerSpecificCommandClass] - NODE 5: Device ID = 0xe
=========== END LOG ================
I do not know, is this one triggered from the zwave binding or comes it from the network, maybe or may be not.
Thx Bob for the response,
My question was not about the log. This one is clear.
My Question was, who triggers the response in the LOG. The Device itself (sometimes or not) or the zwave binding,
I dont understand, why some of the door Contacts in my old Z-Wave Network where discovered and other not.
I read the Z-Wave specification, but there it was not clear IMO. But Anyway it works now.
All logging is done by the ZW binding. The device communicates with the controller and OH communicates with the controller. The trigger could be a message from the controller to OH (relaying a device message or the controller informing OH of something it is doing) or a command from OH to the controller. The binding translates those bytes into human readable form.
In the pictures above the red TX means OH to Controller and the green RX means OH received from controller. The light gray RES is just between OH and the controller. The yellow REQ is from the device via the controller (note the blue from device in)
