EDIT: I got ansy, forged ahead bravely, and answered what I think is correct for some of my questions.
Ok - so I’m finally getting around to trying to get this working where I can identify who the user is that is entering the codes. I went back and started reading, but there are a few piece mentioned and I need to better understand what I need to do before I attempt doing anything that might break something.
There was mention of modifying some file _channels.xml - is this needed for the alarm_raw channel to appear? This does not look to be required from my testing - likely handled in the XML’s automatically
The Device DB on Chris site needs to have the right details for the lock in question, I believe mine does YRD-220 I believe this is a requirement, and was satisfied for me as linked here
Removal of the THING - do I need to delete the Thing to have the alarm_raw channel discovered? I already went through deleting the XML file to test if restarting the binding would generate a different XML, no dice. I also updated my XML to use the 20 user codes line since I have 250 (-6 issue). Crossed my fingers, but remember doing this previously and not having major issues, attempted and worked - binding renewed and the new channel was presented - interestingly though my User Code mod stayed put and Item links
If I delete the THING - is this going to mess up my secure inclusion? I can’t stress enough how important it is to NOT lose my secure pairing since I’ve not been successful pairing after I build out my network. That’s an ongoing mystery to be solved (in fact it’s the next task I have planned with my other lock) but I can’t lose it now. Too much work to do to rebuild if I get screwed. This did not in fact disrupt my secure pairing. This makes sense as the secure inclusion happens with the controller, not the THING
After doing all this, what would be an example of the rule language I can use to parse out the user code field? Has anyone built this yet? @rgerrans - you were the originator, any tips?
On a side note, it seems I have a YRD-246 (no keyway version of YRD-220), but it seems my device is discovered as the 220. I don’t know that there is a major difference, but is there something to do to have this corrected?
hmm, I upgraded the z wave module and my lock is no longer connecting… having a look at the device list site and I can see my lock there… however I noticed that it says “Supports Security No”?
The device is showing up when I press scan… however it shows up even when I haven’t set the device to join the network (enter master code, #, press 4, #, press 1) and as a result, the door doesn’t say “connected” to confirm it connected to the network.
If I try setting the door to search BEFORE I set openhab to scan, they don’t communicate…
a couple of times it has come back with “node9” because it wasn’t able to query manufacturer information, but in all instances the door is unresponsive…
Update:
I got this from the logs:
2017-09-27 22:52:15.498 [INFO ] [mmandclass.ZWaveSecurityCommandClass] - NODE 4: setupNetworkKey useSchemeZero=false
2017-09-27 22:52:16.536 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing ‘zwave:device:a7f7ddf9:node4’ to inbox.
2017-09-27 22:52:16.547 [INFO ] [mmandclass.ZWaveSecurityCommandClass] - NODE 4: setupNetworkKey useSchemeZero=false
2017-09-27 22:52:21.588 [INFO ] [mmandclass.ZWaveSecurityCommandClass] - NODE 4: setupNetworkKey useSchemeZero=true
2017-09-27 22:52:21.595 [INFO ] [mmandclass.ZWaveSecurityCommandClass] - NODE 4: Using Scheme0 Network Key for Key Exchange since we are in inclusion mode.
2017-09-27 22:52:32.387 [ERROR] [curityCommandClassWithInitialization] - NODE 4: SECURITY_INCLUSION_FAILED Failed at step SECURITY_SCHEME_GET: 10000ms passed since last request was sent, secure inclusion failed.
2017-09-27 22:52:33.276 [INFO ] [ommandclass.ZWaveVersionCommandClass] - NODE 4: Command Class LOCK has version 0!
I’ve upped the timeout from 30 to 60, however I don’t think this will matter much… too late to test more tonight, will need to do tomorrow evening
@chris - I am going to chime in here along with the oddity that @ae_0017 and @stevenazari have been mentioning with the User Codes.
So I just updated as seen above to using the newer version of the XML where I get the raw channel, and while I was mucking with XML’s, I modified the UserCodes to 20 as I have one of the locks with the 250 codes. So good news is, my codes all showed up - bad news, they had no labels. So I attempted to label them all, then save. To no surprise, I saw a bunch of “pending” bubbles show up. Refresh … refresh … refresh … still showing the Pending bubbles.
I am seeing in the logs (non-debug atm) that it looks like the send is going through and there are some associated logs that look non-eventful. The problem is it looks like it’s going through, but it’s not really.
My assumption is you’ll ask for some debug logs, and if that’s the case I will indeed try to run that at some point over the coming days. At the moment, my bigger concern is getting my rules fixed with the new Alarm Raw channel first. Then I can tackle this as currently the codes still seem to work - just have no labels in the interface. Call it cosmetic for the moment.
I have been using this build successfully on a pc for a long time, but after i moved to a esxi 5.5 vm and installed the binding again and run feature:install… i keep getting:
2017-09-29 15:34:16.980 [WARN ] [org.apache.felix.fileinstall ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.zwave-2.1.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zwave [9]
Unresolved requirement: Import-Package: com.google.common.collect
at org.eclipse.osgi.container.Module.start(Module.java:434)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:392)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1253)[4:org.apache.felix.fileinstall:3.5.6]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1225)[4:org.apache.felix.fileinstall:3.5.6]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:512)[4:org.apache.felix.fileinstall:3.5.6]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:361)[4:org.apache.felix.fileinstall:3.5.6]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:312)[4:org.apache.felix.fileinstall:3.5.6]
when trying to start the binding, if i install the binding from PaperUI it works, and finds the usb passthrough.
I have been reading this thread as it is a similar issue to mine in that I can’t get it to register securely, and so I have had to ensure the lock is disassociated from openHAB with the following process:
Send “Exclude devices” command for openhab to disassociate from software side
Remove Aeotec zwave stick and unpair from door (hold 2 seconds on stick to enter unpairing mode, THEN unpair process on door)
The door then says “completed” and when searching on z-wave binding, I don’t get an insecure result for the door.
I had restarted openhab and found that for some reason version 2.2 had managed to get back on it - I guess it’s from when I did apt update / upgrade… should that really reinstall bindings?? As a result, both new and old bindings were conflicting and 2.2 (old) was presiding over the new. uninstalling and I can now get the door to connect again…
However I am now at the point where I have the on screen “-76” issue again and can’t save in settings, with the log giving:
2017-09-30 19:21:01.455 [ERROR] [st.core.internal.thing.ThingResource] - Exception during HTTP PUT request for update config at ‘things/zwave:device:48f1902c:node2/config’ for thing ‘zwave:device:48f1902c:node2’: null
2017-09-30 19:21:02.978 [INFO ] [mmandclass.ZWaveDoorLockCommandClass] - NODE 2: Door-Lock config report - timeoutEnabled=true timeoutMinutes=254, timeoutSeconds=30
As a result, I can’t manage the door at all.
I have also noticed when trying to use the “Actions” buttons (Remove / Set as failed / Reinitialise / heal device), I am getting the below error in chrome console:
TypeError: scope.configuration[scope.parameter.name].indexOf is not a function
at b.scope.updateInConfig (controllers.min.js:1)
at fn (eval at compile (angular.min.js:213), :4:551)
at e (angular.min.js:254)
at b.$eval (angular.min.js:133)
at b.$apply (angular.min.js:134)
at HTMLLIElement. (angular.min.js:254)
at HTMLLIElement.dispatch (jquery.min.js:3)
at HTMLLIElement.r.handle (jquery.min.js:3)
(anonymous) @ angular.min.js:107
(anonymous) @ angular.min.js:81
$apply @ angular.min.js:134
(anonymous) @ angular.min.js:254
dispatch @ jquery.min.js:3
r.handle @ jquery.min.js:3
This stops me from using the buttons in that section…
I think i found the cause of it not working, i had openhab2-addons & openhab2-addons-legacy installed from the repo.
When i deleted the 2 packages, it worked again
Yes, I noticed that they kept getting installed despite being stopped and uninstalled…
On a side note, I’m wondering if there is a user friendly way for users to ensure they are scanning from openhab first before scanning on the device (as that is the order it needs to go in, while not stating that is the case)… maybe a friendly message for secure devices?
I’ve put a new version of the binding here. This is a 2.2 version as mentioned a few days ago - this version also has a change to initialisation sequence. There’s now a new step that will check the Z-Wave Plus configuration and set the lifeline association group.
Hopefully this doesn’t cause any issues . If you spot any problems, please let me know and provide a log (I’m sure you all know the routine ).
One point to note is that this lifeline setting will remove any other lifeline settings (if you have the ‘master’ setting selected in the controller). It also uses the multi-channel association which will hopefully solve issues with Qubino devices.
Any issues - just shout . At the moment I’ve also kept the link to the 2.1 version at the top of this thread…
Exception in thread "Thread-421" java.lang.NullPointerException
at org.openhab.binding.zwave.handler.ZWaveThingHandler.startPolling(ZWaveThingHandler.java:409)
at org.openhab.binding.zwave.handler.ZWaveThingHandler.startPolling(ZWaveThingHandler.java:435)
at org.openhab.binding.zwave.handler.ZWaveThingHandler.initialiseNode(ZWaveThingHandler.java:277)
at org.openhab.binding.zwave.handler.ZWaveThingHandler.ZWaveIncomingEvent(ZWaveThingHandler.java:1278)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.notifyEventListeners(ZWaveController.java:549)
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.setCurrentStage(ZWaveNodeInitStageAdvancer.java:1124)
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer.access$5(ZWaveNodeInitStageAdvancer.java:1115)
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer$1.run(ZWaveNodeInitStageAdvancer.java:201)
Will give it a whirl now and let you know tomorrow - many thanks for this
With regards to my initial statement, the inclusion mode got me - newbies don’t know that for secure inclusion, openhab needs to be scanning first, THEN the device needs to be activated for search AND in close proximity, personally think a failure for secure devices shouldn’t add the device because it’s a redherring but if it can’t be avoided then that’s just how it is…
I guess a warning for users to say certain z wave devices require a process and aren’t just plug n play as the manufacturer wants you to think.
- thanks 
. Can you explain this please?
. At the moment I’ve also kept the link to the 2.1 version at the top of this thread…