I don’t think so - you’re using the new version right? The PING stage isn’t in the standard development version that most people are using.
Good point. Yes, I’m using the version from post #2952. I think that’s the newest version.
I thought that version just had changes for dead/failed node handling. :scratchinghead:
Yes, but this includes the PING stage. The PING stage is used to work out if a device is alive in place of the old FAILED check.
Ok, then that makes sense. 
I’m using the dead node version and just reinitialized a Minimote. It visually appears to be initialized in Habmin, but there is not reinit option and on Wakeup, I get this…
2018-06-26 19:20:03.483 [DEBUG] [e.internal.protocol.commandclass.ZWaveCommandClass] - NODE 212: Unsupported command class COMMAND_CLASS_ASSOCIATION_COMMAND_CONFIGURATION
2018-06-26 19:20:03.483 [DEBUG] [otocol.serialmessage.ApplicationUpdateMessageClass] - NODE 212: Application update - no transaction.
2018-06-26 19:20:03.505 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 212: listening == false, frequentlyListening == false, awake == false
2018-06-26 19:20:03.505 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 212: Node not awake!
2018-06-26 19:20:03.517 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 212: Application Command Request (ALIVE:PING)
2018-06-26 19:20:03.518 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 212: Incoming command class COMMAND_CLASS_WAKE_UP, endpoint 0
2018-06-26 19:20:03.518 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 212: Command class COMMAND_CLASS_WAKE_UP not found.
2018-06-26 19:20:03.519 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 212: Commands processed 1.
2018-06-26 19:20:03.520 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 212: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@3c7a4606.
2018-06-26 19:20:03.520 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 212: Checking transaction 1191 ApplicationUpdate.
2018-06-26 19:20:03.521 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 212: Checking transaction : state >> WAIT_RESPONSE
2018-06-26 19:20:03.521 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 212: Checking transaction : node >> 46
2018-06-26 19:20:03.522 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 212: Checking transaction : class >> 132 == null.
2018-06-26 19:20:03.522 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 212: Checking transaction : commd >> 7 == null.
2018-06-26 19:20:03.523 [DEBUG] [ng.zwave.internal.protocol.ZWaveTransactionManager] - NODE 212: Ignoring transaction since not waiting for data.
2018-06-26 19:20:03.734 [DEBUG] [.openhab.binding.zwave.internal.protocol.ZWaveNode] - NODE 212: Node doesn't support WAKEUP - ignore wakeup
Also, no XML file showed up. Copying one from another Minimote brought Scene_Activation back, but get the same message on Wakeup.
Ok, then you’re seeing the same thing as me.
Actually, after restarting OH, it’s completely back to normal. It’s just a workaround, but if you want to get it working again, you might try copying in an XML from another Minimote (PM me if you want one).
I’m having the same issue with the Minimote and Wallmote. I just recently switched over to the zwave binding from the first post and they haven’t worked since.
Im getting this from my danalock 3.
Before i openhab2.2, with the dev version of the binding. That worked fine.
After i upgraded to 2.3, everything broke. The logs bellow are from a fresh reinstall.
2018-06-27 18:20:17.436 [WARN ] [tocol.commandclass.ZWaveCommandClass] - NODE 30: Unsupported command class COMMAND_CLASS_SECURITY_2
2018-06-27 18:20:17.440 [WARN ] [tocol.commandclass.ZWaveCommandClass] - NODE 30: Unsupported command class COMMAND_CLASS_TRANSPORT_SERVICE
2018-06-27 18:20:17.455 [INFO ] [mmandclass.ZWaveSecurityCommandClass] - NODE 30: setupNetworkKey useSchemeZero=false
2018-06-27 18:43:40.843 [ERROR] [col.security.ZWaveSecureNonceTracker] - NODE 30: SECURITY_ERROR Device message contained nonce that is unknown to us, id=-34.
2018-06-27 18:43:40.847 [WARN ] [col.security.ZWaveSecureNonceTracker] - NODE 30: Expiring nonce with id=-73
2018-06-27 18:43:41.011 [ERROR] [col.security.ZWaveSecureNonceTracker] - NODE 30: SECURITY_ERROR Device message contained nonce that is unknown to us, id=-8.
2018-06-27 18:43:41.084 [INFO ] [mmandclass.ZWaveDoorLockCommandClass] - NODE 30: Door-Lock state report - lockState=Secured, handlesMode=0x11, doorCondition=0x05, timeoutMinutes=0xfe, timeoutSeconds=0xfe
2018-06-27 18:43:48.132 [ERROR] [col.security.ZWaveSecureNonceTracker] - NODE 30: SECURITY_ERROR Device message contained nonce that is unknown to us, id=3.
2018-06-27 18:43:48.295 [ERROR] [col.security.ZWaveSecureNonceTracker] - NODE 30: SECURITY_ERROR Device message contained nonce that is unknown to us, id=50.
2018-06-27 18:43:48.381 [INFO ] [mmandclass.ZWaveDoorLockCommandClass] - NODE 30: Door-Lock state report - lockState=Unsecured, handlesMode=0x11, doorCondition=0x02, timeoutMinutes=0xfe, timeoutSeconds=0xfe
Security support is not available in the 2.3 stable version of the binding, you need to switch to the dev version.
The problem I was having appears to be with the version containing the new dead code logic (i.e. the one from post #2952. If you’re using the version from post 1, there may be another reason why those devices are not working.
little short question - I want to test/use the development binding - what version of OH must I use for that ? stable 2.3 ? or another newer snapshot … ?! thx, Thomas
Yes, either the stable 2.3 or snapshot 2.4
1 Like
thank you - I´ll try
I’m running (what I think is) stable 2.3.0 (where and how can I check/confirm it?)
and after dropping the .jar file into addons folder, the bundle:list reports:
267 │ Installed │ 80 │ 2.3.0.201806262322 │ ZWave Binding
When trying to start it manually (with bundle:start 267) I get the following errors:
Error executing command: Error executing command on bundles:
Error starting bundle 267: Could not resolve module: org.openhab.binding.zwave [267]
Unresolved requirement: Import-Package: org.eclipse.jdt.annotation; resolution:="optional"
Unresolved requirement: Import-Package: org.eclipse.smarthome.config.discovery.usbserial'
“feature:install openhab-transport-serial” is not accessible, it seems that it is already installed.
What am I doing wrong?
Thanks for the dev binding Chris! I was able to get my Yale YRD446 working finally! I have one stupid question that I tried looking for, but this thread is so long I could have missed it.
On my raspberry pi, I made a udev rule so that I could refer to Zswtick as /dev/zstick. When I installed the dev/beta binding, the old Z-Wave controller was still discovered and working as “Z-Wave Serial Controller” using serial port /dev/zstick. I actually used it to include my lock. However in the PaperUI Inbox, I see a new controller named “ZWave Plus USB Dongle”, but the serial port is the actual device /dev/ttyACMO.
Normally I’de mess around with it, but I’m afraid to touch anything now that my lock is working.
Should I just delete the new discovered controller from the Inbox, or delete old, but working, controller and then add the one from the Inbox?
Thanks!
@chris: Sounds like a weird question but is the 2.3.0-snapshot.jar newer than the 2.4.0.201806152142 that comes along with openhab 2.4.0? I moved to OH 2.4 and since then I am experiencing problems that I did not have before…
So is 2.3.0-snapshot from the github-development branch whereas the zwave-2.4.0…jar was taken as a version for OH 2.4 from the master which seems to be still quite behind?
If that is the case, I would say I can user the 2.3-snapshot even for OH 2.4, correct?
cheers
Stefan
On the bottom of your openHAB startpage:
That is the recent dev version of the zwave binding.
You can also check that via karaf, bundle:list should give:
196 │ Active │ 80 │ 3.12.0.OH │ nrjavaserial
I have not seen that error before, but make sure you uninstalled the stable version of the zwave binding via HABmin or PaperUI before dropping the jar. There should be no need to start it manually.
There is a post “somewhere” above 
where Chris does not recommend to use it. I did and it works fine.
I would just set it to “ignore” and work with your previous stick configuration.
We have four different versions of the zwave binding at the moment:
the stable version
the snapshot version
the development version (from this thread)
a test version of the development version, which just handles dead nodes a little bit different.
So the answer to your question: yes.
Yes, because you are switching from snapshot to development or vicaversa, that means you have to delete all things and readd them to make everything work again.
1 Like