Hi,@chris
I am through the PC Controller software to obtain the Manufacturer ID, Device Type, Device ID, Firmware version. But my Maven jar package can not recognize the device. The following is the OH2 work logs:
2017-08-24 10:55:06.902 [INFO ] [mmandclass.ZWaveSecurityCommandClass] - NODE 5: setupNetworkKey useSchemeZero=false
2017-08-24 10:55:13.062 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 3: Device discovery could not resolve to a thingType! 7FFFFFFF:7FFFFFFF:7FFFFFFF::0.0
2017-08-24 10:55:13.087 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 5: Device discovery could not resolve to a thingType! 7FFFFFFF:7FFFFFFF:7FFFFFFF::0.0
2017-08-24 10:55:33.220 [ERROR] [ve.internal.protocol.ZWaveController] - Exception during ZWave thread: Input 2. {}
java.lang.NullPointerException
at org.openhab.binding.zwave.internal.protocol.ZWaveDeviceClass$Specific.access$3(ZWaveDeviceClass.java:470)[201:org.openhab.binding.zwave:2.2.0.201708241046]
at org.openhab.binding.zwave.internal.protocol.ZWaveDeviceClass.setSpecificDeviceClass(ZWaveDeviceClass.java:106)[201:org.openhab.binding.zwave:2.2.0.201708241046]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.notifyEventListeners(ZWaveController.java:598)[201:org.openhab.binding.zwave:2.2.0.201708241046]
at org.openhab.binding.zwave.internal.protocol.serialmessage.AddNodeMessageClass.handleRequest(AddNodeMessageClass.java:133)[201:org.openhab.binding.zwave:2.2.0.201708241046]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingRequestMessage(ZWaveController.java:248)[201:org.openhab.binding.zwave:2.2.0.201708241046]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage(ZWaveController.java:214)[201:org.openhab.binding.zwave:2.2.0.201708241046]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$7(ZWaveController.java:208)[201:org.openhab.binding.zwave:2.2.0.201708241046]
at org.openhab.binding.zwave.internal.protocol.ZWaveController$ZWaveInputThread.run(ZWaveController.java:1324)[201:org.openhab.binding.zwave:2.2.0.201708241046]
2017-08-24 10:55:52.392 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘zwave:device:294916e5:node6’ to inbox.
2017-08-24 10:55:58.166 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 3: Device discovery could not resolve to a thingType! 7FFFFFFF:7FFFFFFF:7FFFFFFF::0.0
2017-08-24 10:55:58.194 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 5: Device discovery could not resolve to a thingType! 7FFFFFFF:7FFFFFFF:7FFFFFFF::0.0
2017-08-24 10:55:58.218 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 6: Device discovery could not resolve to a thingType! 7FFFFFFF:7FFFFFFF:7FFFFFFF::0.0
@chris , maybe you can give me a hint? I didn’t find it here in the forums.
Thanks in advance…
If you see this, then it means that the binding has not downloaded the device information from the device. Maybe if it’s a battery device it needs waking up? Mains devices should download this data quickly so should be ok.
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:2.2.0.201708241046]
at org.openhab.binding.zwave.internal.protocol.ZWaveDeviceClass.setSpecificDeviceClass(ZWaveDeviceClass.java:106)[201:org.openhab.binding.zwave:2.2.0.201708241046]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.notifyEventListeners(ZWaveController.java:598)[201:org.openhab.binding.zwave:2.2.0.201708241046]
at org.openhab.binding.zwave.internal.protocol.serialmessage.AddNodeMessageClass.handleRequest(AddNodeMessageClass.java:133)[201:org.openhab.binding.zwave:2.2.0.201708241046]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingRequestMessage(ZWaveController.java:248)[201:org.openhab.binding.zwave:2.2.0.201708241046]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage(ZWaveController.java:214)[201:org.openhab.binding.zwave:2.2.0.201708241046]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$7(ZWaveController.java:208)[201:org.openhab.binding.zwave:2.2.0.201708241046]
at org.openhab.binding.zwave.internal.protocol.ZWaveController$ZWaveInputThread.run(ZWaveController.java:1324)[201:org.openhab.binding.zwave:2.2.0.201708241046]
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.
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.
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.
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).
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.
Hello,@chris
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?
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.
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.
