About binding Zwave device adaptation issues

But with PC controller can be completed directly match. OH also throws an exception when set.

at org.openhab.binding.zwave.internal.protocol.ZWaveDeviceClass$Specific.access$3(ZWaveDeviceClass.java:470)[201:org.openhab.binding.zwave:]
at org.openhab.binding.zwave.internal.protocol.ZWaveDeviceClass.setSpecificDeviceClass(ZWaveDeviceClass.java:106)[201:org.openhab.binding.zwave:]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.notifyEventListeners(ZWaveController.java:598)[201:org.openhab.binding.zwave:]
at org.openhab.binding.zwave.internal.protocol.serialmessage.AddNodeMessageClass.handleRequest(AddNodeMessageClass.java:133)[201:org.openhab.binding.zwave:]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingRequestMessage(ZWaveController.java:248)[201:org.openhab.binding.zwave:]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage(ZWaveController.java:214)[201:org.openhab.binding.zwave:]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$7(ZWaveController.java:208)[201:org.openhab.binding.zwave:]
at org.openhab.binding.zwave.internal.protocol.ZWaveController$ZWaveInputThread.run(ZWaveController.java:1324)[201:org.openhab.binding.zwave:]

Sorry - what do you mean?

All I can say is that if the device type etc are showing as 7FFFFFFFF then this means the information has not been downloaded from the device. Without more information, I’m afraid I can’t say why this is.

I’m not really sure what this is that you have provided - it looks like part of the exception log, but it doesn’t say what the exception is. Please provide the exception log, plus the debug information that is presumably logged prior to the event happening and I’ll take a look.

This is the newly added battery device log. Node2 is the problem device - the door lock, Node3 is the successful device - the window sensor. Occasionally there is a device that does not recognize the situation, but re-added to succeed. Only the door lock device will run out of the empty pointer exception, other battery equipment never appeared this situation.

This is through the sigma-Design official website PC Controller directly to the test chart.It does not seem to need to wake up.

Please provide a debug log, and also please provide it as a log - not as an image.

This will only be required if it is a battery device.

Currently you’ve not really provided a lot of information so I’m sorry, but I’m just guessing what the problem could be based on a single line of information. Please try and provide information about what you are doing - what the device is, what version of the binding you are running, etc. Please provide debug logs showing the error you have and the exception you are getting. Without this information I can only guess what’s happening and this won’t really provide a satisfactory answer for anyone.

openhab.xml (3.6 KB)
events.xml (1005 Bytes)
isurpass_dl9101v_0_0.xml (5.0 KB)
Openhab and event file suffix need to be changed to log.
This equipment is used by Shenzhen iSurpass Technology Co., Ltd DL9101V Door Lock with Handle.
org.openhab.binding.zwave-2.2.0-SNAPSHOT.jar(https://github.com/openhab/org.openhab.binding.zwave/archive/master.zip)events-debug.xml (1.2 KB)

Thanks, but I need a DEBUG log so that I can see what is happening. The current log is only logging WARN, ERROR and INFO entries - this really doesn’t provide a lot of information which is why I request a debug log. At the current level, it tells me that there is a problem, but there’s just not enough information to allow debugging - this requires the log level to be set to DEBUG .


You should also note that as this is a lock, then it will likely not work with the current master branch which does not have security enabled, and you should use the development branch.

I know,I know.
I`m sorry,Debug file is too large to upload, I will upload connection.

If you can just provide the part around (ie before) the exception this will help. Maybe it’s not the only problem, but it’s a good place to start. This should be very short (maybe 10 or 20 lines).

openhab-Debug-log.xml (967.9 KB)

Great news!
I tried a reply to the jar package: it did not throw an exception, and successfully read out the device vendor ID and device ID!

12:20:13.016 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 3: Device discovery could not resolve to a thingType! 021C:5000:1000::0.0

Thank you very much for Chris!!!
Thank you for your support!!!
I would like to get the top jar package source code, can you?So I can try the adaptation of the new device myself,and upload it to the Zwave device database.


The source code is kept on Github so you can get this from there.

Note that you need to enter the data directly into the database - there is no file to edit in the binding before this. You upload the XML that is automatically generated by OH and you now hopefully have already.

Ok!I am familiar with this process. I have adapted some of the devices.

Thank you very much!

Ok, perfect. Any problems, just let me know…


I need to ask you a question. I am in the lock when the lock, how can I operate in the OH-paper UI set the lock`s USER_CODE? Is channel? Is configuration?

Thanks ,my friend!

User code is provided as an option in paper UI / HABmin if the device supports this command class. There is no configuration in the database - it’s handled directly in the binding.

Sorry, I did not understand too much.Through this way, is it right?

If user code command class is supported, then the binding should detect this, and it will add a new section into HABmin to edit the list of user codes.

OK,I know!
Thank you very much!
Look forward to my good news!

I found that the lock power will not be reported! Lock the state will not report!
I do not know what to do!I have read the project source code, but no new discovery.I would like to use COMMAND_CLASS_DOOR_LOCK_LOGGING check the lock to open the record, but also failed to achieve.
I need your help, my old man,Chris!