No - only this branch as it relies on the updated transaction management. I’ll do an update of this branch this evening.
As an added update, here is a snippet of logs from a few days ago with the first download of the new security enabled binding. This discovery was able to fully identify the device (I believe) as seen from the log fully outlining the Thing type and matching to the DB entry provided above. But alas it still sat as an unknown device.
2017-02-07 22:43:18.285 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 24: Device discovery could not resolve to a thingType! 014F:4754:3038::5.8
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: ProtocolInfo
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: Listening = true
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: Routing = true
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: Beaming = true
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: Version = 4
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: FLIRS = false
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: Security = false
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: Max Baud = 40000
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: Basic = BASIC_TYPE_ROUTING_SLAVE
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: Generic = GENERIC_TYPE_SWITCH_MULTILEVEL
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: Specific = SPECIFIC_TYPE_POWER_SWITCH_MULTILEVEL
I had the same issue with a Linear GD00Z garage door opener showing up as an Unknown Device. It’s:
http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/11
I downloaded the source and compiled my own to do some testing and found it had to do with the version check on the device. I noticed there was no min or max version in the database and that the device had no version. Not sure if it was correct, but I found if I modified ZWaveProduct to set versionMin and versionMax if they were null in the database, then the version checking code was skipped and it was matched. I can provide a patch if you would like. Now I just need to figure out how to make use of the Barrier command class.
I’m also looking into the Kwikset deadbolt ( http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/283 )and figuring out how to detect lock/unlock using the Alarm command class. I have a hack that seems to work for me, but I’m sure isn’t the correct way of doing it. I can provide more information regarding what happens here if you would like.
Hope that helps,
I don’t quite understand this. I’ve got tests on this now and I just checked that with null for the version from the database, it should work ok as it sets the min/max to 0 and 255.255. Or, do you meant that this device actually doesn’t return a version, and this is what is causing the failure? That would be a bit strange as I think it’s mandatory, but then I’ve found a bunch of things that are meant to be “mandatory”, but devices are still certified 
Sure - I expect it’s similar to what I have here with the Yale where it’s sending alarms when state changes (I really don’t understand why they chose this strategy). I don’t think it is too hard to process this, but it’s not top of my list right now. What I’d suggest is to raise an issue on the issue list with your findings rather than discuss it here as it will likely get lost ;).
I wasn’t sure what was happening either. From looking at it, I agree the code should work. I got the following when I added in a debug line for the checks:
2017-02-10 12:02:33.506 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 26: Device discovery could not resolve to a thingType! 014F:4744:3030::0.0
and
2017-02-10 12:02:30.267 [DEBUG] [.binding.zwave.internal.ZWaveProduct] - Min Version didn’t match: 0.0.0 - 0.0.0
I think there is no version from the device. I don’t see a version an applicationVersion in the XML file for the Version command class for that device.
Thanks for all your work on this. 
I see comments in another thread saying it works ok -:
If there’s no version, then the node class will return 0.0 which should work fine (the test does actually test this case and it passes the test) -:
So, not so sure what’s up really, but it seems it should work ok. I’ll update this security branch later so it would be worth trying again with this.
Sounds good. I’ll take a look and see what happens 
1 Like
Hi @chris. Thanks for all your work with this!
Thought I’d try out this new version, mainly because I’ve got massive problems with “dead” nodes (ie nodes that the controller completely refuses to communicate with even though they’re perfectly functional) and I hope they’ll be happier after some healing. I’ve only got one small question that I haven’t found the answer to in this thread: This renaming of command classes, is it completed or will there be more of it? What I mean is, if I upgrade to the snapshot version now (deleting all my Things), will I be able to upgrade to the stable 2.1 (or 2.2 or whatever) later without needing to delete everything again?
Probably not. The renaming of command classes is complete, but I also want to rename the channel names to be more systematic. This is related to the move toward dynamic channels.
I’m hoping to do all the changes here before merging into the master branch, but if you use this branch now, it will likely need reconfiguration later.
1 Like
Hi @chris
Firstly, thank-you the security command classes work great. I am unable to lock and unlock my Yale lock (secure inclusion was performed on 2.0 stable binding).
However, I observed the following issues and needed to revert to the stable version:
- It’s much slower than previous implementations (including 1.7, 1.8 and 2.0)
- The initial discovery wasn’t able to resolve some things. I have 6 of the same types of dimmers, some worked and some were still unknown requiring multiple restarts of the binding.
- Some things refused to work. In the logs I could see that the command had been received but the thing never changed.
- Some things which were the 2.0 binding could not be resolved (Fibaro Motion Sensor).
Thanks again for all your hard work on this… let me know if you want detailed logs or for me to raise issues in GitHub.
Thanks - these are known issues and discussed above (although I know this is getting to be a long thread now ;). I need to look at the speed issue which is caused by a thread lock I think. The detection of devices should be fixed in the version I loaded last night, although the database for this version might have issues still as it is different than the main OH2 binding…
Hopefully I’ll work through these issues in the coming week or two.
Cheers
Chris
Successfully added my Danalock V2 when I started to use this new binding.
Although because of exploratory testing i needed to do a complete fresh installation
Now I’m not able to include my lock “Using Security”.
Network keys are mentioned in this thread, what are those?
I haven’t used any, is that my mistake?
Now to something completely different, can I scan for new things from HABmin?
Thanks in advance
The network key is like your password - all security systems have a key of some sort… It’s configured under the network settings in the controller thing configuration.
It probably doesn’t matter - if I remember correctly the binding will choose a random number if you don’t set one.
There’s a discovery button. In the Thing configuration menu, there’s two buttons in the top of the menu - one is the discovery button (magnifying glass icon I think).
I removed some of my changes and updated to the dev-switchall-config-type branch (is that the correct dev branch?) and get the same issues. Also get it with the latest jar from the link above. In looking at this though, I now realize that my device was never successfully secure included. Not sure if that explains my above problems, but it explains why I couldn’t get the channel to work. I redid the inclusion with debug logging enabled. Not sure what’s going on with secure inclusion. I’ll try and wrap my head around secure inclusion and see what’s happening. If the log or anything else would be helpful, let me know and I can post it.
Thanks
If by -:
… you mean the device is still not discovered, then we need to understand why, so logs would be needed for this. If you can debug this device to work out exactly the conditions, and what is stopping it working, it would really be great. The best thing is if you can reproduce this in a test case.
It’s unlikely since in my experience the manufacturer information is not secure, so it should be available even if not securely included. If we’re still talking about the garage door opener (??) then this definitely works for others without security so this information is definitely available in the clear.
Secure inclusion is basically the same as normal inclusion, but with some extra stuff on the end - if you want to send a log, then please feel free and I’ll have a look. I would recommend using the log viewer though - it makes things a LOT easier to visualise. This is especially true when security is involved as things otherwise become very complex with all the additional transactions for handling the nonce.
Thanks everybody and specially @chris for your patience with all my questions.
I still have some problems adding my Danalock V2 with security (node18).
The lock is found but Attributes show Using Security=x.
My actions to try and change this is to delete the think and try to add it again, with no luck.
21:58:30.095 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:device:15a32b9cacd:node18' changed from ONLINE to UNINITIALIZED
21:58:30.343 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:device:15a32b9cacd:node18' changed from ONLINE to UNINITIALIZED (HANDLER_MISSING_ERROR)
21:58:30.358 [INFO ] [smarthome.event.ThingRemovedEvent ] - Thing 'zwave:device:15a32b9cacd:node18' has been removed.
21:58:36.887 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:15a32b9cacd:node18' to inbox.
21:58:36.889 [INFO ] [smarthome.event.InboxAddedEvent ] - Discovery Result with UID 'zwave:device:15a32b9cacd:node18' has been added.
21:58:36.900 [INFO ] [smarthome.event.BindingEvent ] - org.openhab.binding.zwave.event.BindingEvent@24e53b3d
21:58:43.709 [INFO ] [smarthome.event.InboxRemovedEvent ] - Discovery Result with UID 'zwave:device:15a32b9cacd:node18' has been removed.
21:58:43.710 [INFO ] [smarthome.event.ThingAddedEvent ] - Thing 'zwave:device:15a32b9cacd:node18' has been added.
21:58:43.713 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:device:15a32b9cacd:node18' changed from UNINITIALIZED to INITIALIZING
21:58:43.714 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:device:15a32b9cacd:node18' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
21:58:43.715 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:device:15a32b9cacd:node18' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to UNINITIALIZED
21:58:43.723 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:device:15a32b9cacd:node18' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
21:58:43.740 [ERROR] [ome.core.thing.link.ThingLinkManager] - Exception occured while informing handler:null
java.lang.UnsupportedOperationException
at java.util.AbstractList.add(AbstractList.java:148)[:1.8.0_121]
at java.util.AbstractList.add(AbstractList.java:108)[:1.8.0_121]
at org.openhab.binding.zwave.handler.ZWaveThingHandler.channelLinked(ZWaveThingHandler.java:432)[190:org.openhab.binding.zwave:2.1.0.201702122241]
at org.eclipse.smarthome.core.thing.link.ThingLinkManager.informHandlerAboutLinkedChannel(ThingLinkManager.java:264)[105:org.eclipse.smarthome.core.thing:0.9.0.201702100936]
at org.eclipse.smarthome.core.thing.link.ThingLinkManager.receiveTypedEvent(ThingLinkManager.java:304)[105:org.eclipse.smarthome.core.thing:0.9.0.201702100936]
at org.eclipse.smarthome.core.thing.link.ThingLinkManager.receiveTypedEvent(ThingLinkManager.java:1)[105:org.eclipse.smarthome.core.thing:0.9.0.201702100936]
at org.eclipse.smarthome.core.events.AbstractTypedEventSubscriber.receive(AbstractTypedEventSubscriber.java:50)[98:org.eclipse.smarthome.core:0.9.0.201702100936]
at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:192)[98:org.eclipse.smarthome.core:0.9.0.201702100936]
at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:1)[98:org.eclipse.smarthome.core:0.9.0.201702100936]
at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:181)[98:org.eclipse.smarthome.core:0.9.0.201702100936]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_121]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]
21:58:43.741 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:device:15a32b9cacd:node18' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING
21:58:43.740 [ERROR] [ome.core.thing.link.ThingLinkManager] - Exception occured while informing handler:null
java.lang.UnsupportedOperationException
at java.util.AbstractList.add(AbstractList.java:148)[:1.8.0_121]
at java.util.AbstractList.add(AbstractList.java:108)[:1.8.0_121]
at org.openhab.binding.zwave.handler.ZWaveThingHandler.channelLinked(ZWaveThingHandler.java:432)[190:org.openhab.binding.zwave:2.1.0.201702122241]
at org.eclipse.smarthome.core.thing.link.ThingLinkManager.informHandlerAboutLinkedChannel(ThingLinkManager.java:264)[105:org.eclipse.smarthome.core.thing:0.9.0.201702100936]
at org.eclipse.smarthome.core.thing.link.ThingLinkManager.receiveTypedEvent(ThingLinkManager.java:304)[105:org.eclipse.smarthome.core.thing:0.9.0.201702100936]
at org.eclipse.smarthome.core.thing.link.ThingLinkManager.receiveTypedEvent(ThingLinkManager.java:1)[105:org.eclipse.smarthome.core.thing:0.9.0.201702100936]
at org.eclipse.smarthome.core.events.AbstractTypedEventSubscriber.receive(AbstractTypedEventSubscriber.java:50)[98:org.eclipse.smarthome.core:0.9.0.201702100936]
at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:192)[98:org.eclipse.smarthome.core:0.9.0.201702100936]
at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:1)[98:org.eclipse.smarthome.core:0.9.0.201702100936]
at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:181)[98:org.eclipse.smarthome.core:0.9.0.201702100936]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_121]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]
21:58:43.741 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing 'zwave:device:15a32b9cacd:node18' has been updated.
21:58:43.741 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:device:15a32b9cacd:node18' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
21:58:43.742 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:device:15a32b9cacd:node18' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE
Any idea?
Thanks in advance
@chris - I know you’re not releasing official versions or anything, but to help the rest of us testing out this pre-release binding - could you change the numbering/naming somehow on the download from the above link? I think by following through the thread I see there is a new version, but I’m not sure I can actually tell when new versions are released. Would be helpful if the file could just be changed in the initial thread to point to a new date/time or version # release to let us know it’s available? And/or to let us subscribe to the possible notification of just that update.
1 Like
Also wanted to report, I’m seeing an odd message in my logs and I think this may possibly be related to why I was unsuccessful in sending the PIN codes to my lock:
16:37:00.365 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 26: Sent Data was not placed on stack.
Node26 obviously being my lock. I saw some odd messages like this when my pairing was failing too. It doesn’t seem “frequent” but it’s appeared a few different times.
Should I drop down to debug level logs and catch some more activity to report?
Ok, I see what happened with my build. There was some code that didn’t update correctly. Not used to how Eclipse works with git. Now the garage door device is identified correctly.
I used the log viewer to see what’s happening. Looks like it gets to the SECURITY_REPORT stage and never gets a response. I believe this was with the last posted jar. Going to wait and try again tomorrow and see what happens with the updated jar I built tonight. Will post the logs if I get the same errors.
I think that the error that’s in your log was fixed so I’d double check that you’re running the latest binding from the download link.