Hi,
I am trying to control a Yale YRD210 lock using openhab2 and Aeotec z-stick Gen 5.
I am using the following jar for the zwave binding
http://www.cd-jackson.com/downloads/openhab2/org.openhab.binding.zwave-2.1.0-SNAPSHOT.jar
The stick and the lock seems to be added fine using PAPER UI. But when I try to get battery status or lock unlock the lock, I do not get any status update from lock.
Not sure if this is the right combination to work with.
Can anyone please advice.
Launching the openHAB runtime…
openhab>
openhab>
openhab> smarthome:things list
zwave:serial_zstick:6af68e25 (Type=Bridge, Status=OFFLINE (BRIDGE_OFFLINE): Controller is offline, Label=Z-Wave Serial Controller, Bridge=null)
openhab> smarthome:things list
zwave:serial_zstick:6af68e25 (Type=Bridge, Status=ONLINE, Label=Z-Wave Serial Controller, Bridge=null)
openhab> smarthome:things list
zwave:serial_zstick:6af68e25 (Type=Bridge, Status=ONLINE, Label=Z-Wave Serial Controller, Bridge=null)
zwave:device:6af68e25:node3 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 3: DZPA1 Plug-in Appliance Module, Bridge=zwave:serial_zstick:6af68e25)
zwave:device:6af68e25:node2 (Type=Thing, Status=ONLINE, Label=Z-Wave Node 2: YRD210 Push Button Deadbolt, Bridge=zwave:serial_zstick:6af68e25)
openhab> smarthome:items list
ZWaveNode3DZPA1PlugInApplianceModule_Switch (Type=SwitchItem, State=OFF, Label=Switch, Category=Switch)
ZWaveNode2YRD210PushButtonDeadbolt_Lock (Type=SwitchItem, State=ON, Label=, Category=Door)
ZWaveNode2YRD210PushButtonDeadbolt_Alarm (Type=SwitchItem, State=NULL, Label=Alarm, Category=Door)
ZWaveNode2YRD210PushButtonDeadbolt_BatteryLevel (Type=NumberItem, State=NULL, Label=Battery Level, Category=Battery)
zwave_serial_zstick_6af68e25_serial_sof (Type=NumberItem, State=164, Label=Start Frames, Category=)
zwave_serial_zstick_6af68e25_serial_ack (Type=NumberItem, State=70, Label=Frames Acknowledged, Category=)
zwave_serial_zstick_6af68e25_serial_nak (Type=NumberItem, State=NULL, Label=Frames Rejected, Category=)
zwave_serial_zstick_6af68e25_serial_can (Type=NumberItem, State=NULL, Label=Frames Cancelled, Category=)
zwave_serial_zstick_6af68e25_serial_oof (Type=NumberItem, State=NULL, Label=OOF Bytes Received, Category=)
zwave_serial_zstick_6af68e25_serial_cse (Type=NumberItem, State=NULL, Label=Received Checksum Errors, Category=)
openhab>
openhab>
openhab> smarthome:send ZWaveNode2YRD210PushButtonDeadbolt_BatteryLevel REFRESH
Command has been sent successfully.
openhab> smarthome:items list
ZWaveNode3DZPA1PlugInApplianceModule_Switch (Type=SwitchItem, State=OFF, Label=Switch, Category=Switch)
ZWaveNode2YRD210PushButtonDeadbolt_Lock (Type=SwitchItem, State=ON, Label=, Category=Door)
ZWaveNode2YRD210PushButtonDeadbolt_Alarm (Type=SwitchItem, State=NULL, Label=Alarm, Category=Door)
ZWaveNode2YRD210PushButtonDeadbolt_BatteryLevel (Type=NumberItem, State=NULL, Label=Battery Level, Category=Battery)
zwave_serial_zstick_6af68e25_serial_sof (Type=NumberItem, State=166, Label=Start Frames, Category=)
zwave_serial_zstick_6af68e25_serial_ack (Type=NumberItem, State=71, Label=Frames Acknowledged, Category=)
zwave_serial_zstick_6af68e25_serial_nak (Type=NumberItem, State=NULL, Label=Frames Rejected, Category=)
zwave_serial_zstick_6af68e25_serial_can (Type=NumberItem, State=NULL, Label=Frames Cancelled, Category=)
zwave_serial_zstick_6af68e25_serial_oof (Type=NumberItem, State=NULL, Label=OOF Bytes Received, Category=)
zwave_serial_zstick_6af68e25_serial_cse (Type=NumberItem, State=NULL, Label=Received Checksum Errors, Category=)
openhab>
Anyone aware of an update on this? I just installed two of these and have similar situation.
They pair, see all the properties, etc., but no control or status updates. Two things I notice are it has been in a state of “Node initialising: STATIC_VALUES” since paired a couple days ago, and the Zwave version is 0.0. Below are all the details from PaperUI Thing detail.
Anything I can do to help get these working? Even do a screen share session to debug, etc…
Thanks
ohab 2.1.0 rel
Status: ONLINE Node initialising: STATIC_VALUES
zwave_class_basic ROUTING_SLAVE
zwave_class_generic ENTRY_CONTROL
zwave_frequent true
zwave_neighbours 1,2,5,6,7,8,9,10,11,12,13,14,15,17,19,20,21,22,23,24,25,27,28,30,31,32,34,36
zwave_version 0.0
zwave_listening false
zwave_deviceid 43520
zwave_nodeid 35
zwave_routing true
zwave_beaming true
zwave_class_specific SECURE_KEYPAD_DOOR_LOCK
zwave_manufacturer 297
zwave_devicetype 4
Channels
Door Lock
zwave:device:gen5a:node35:lock_door
Switch
Alarm
zwave:device:gen5a:node35:alarm_general
Switch
Battery Level
zwave:device:gen5a:node35:battery-level
The release version does not have security enabled. You need to use the version that is on the following post -:
I loaded that snapshot version of the zwave binding on the 1st (since your post), but I haven’t seen anything different in functionality/communications, etc. Anything I need to do differently with that snapshot?
Anything I can do for you to help (logs, ssh, screen-share, etc), let me know.
Thanks!
You will need to delete all your things and add them back. In general though, there’s no obvious difference - it just has security (and some other features).
I have retried several times to follow the necessary procedure with what I have gathered in several threads referenced here and elsewhere within this community that appeared relevant.
The last round of effort is as such.
root@openhab1:/home/openhab/openhab2# find . -name "*.jar" |grep -i zwave ./userdata/tmp/mvn/org/openhab/binding/org.openhab.binding.zwave/2.1.0/org.openhab.binding.zwave-2.1.0-SNAPSHOT.jar
The debug log (yale-debug-node41.txt) and some screenshots included here: https://www.dropbox.com/sh/2d4nzmilbskmvr6/AABpwIHkVdaUpj-CZD7NL-U5a?dl=0
Additional notes:
) that the inclusion of the lock failed. While it appears that some manufacture specific properties are not recognized, the lock/unlock communications appeared to be successful (as far as the logs know, but again no joy recognized by me)
).I hoping there is something very simple I’m missing. I’m am holding off adding the other zwave things back in a long as possible in case there is anything else I can do to help on this.
If there are any relevant details I forgot/didn’t think to include, let me know and I’ll do my best to supplement.
Thanks!!
You are using the wrong version of the binding. You need to use the latest version from this thread -:
If that’s what you are using, then for some reason it’s not running and you are actually still running an old version.
@chris Can you confirm the URL for the download? The one on that thread is the one I currently have in place, has same md5.
(Seeing link for binding dated 29th August 2017 at http://www.cd-jackson.com/downloads/openhab2/org.openhab.binding.zwave-2.1.0-SNAPSHOT.jar)?
Hoping I’m just finding the wrong download link. Thanks!!
Yes, that looks correct. Something must be still picking up the wrong version though. Make sure you uninstall the old binding and make sure it’s not running by checking the Karaf console (using the list command).
Hi @chris I have uninstalled the 2.1.0 distro zwave (bundle:stop id / bundle:uninstall id), confirmed gone, removed jar, re-copied the above jar to the /addons directory and rebooted.
This look like what you expect? Anything else I should do to validate / log / etc? Would like to confirm before I run through the processes again and if any other info would be helpful.
openhab> bundle:list |grep Z 226 | Active | 80 | 2.1.0.201709111810 | ZWave Binding root@openhab1:/home/openhab# find . -name "*.jar" |grep -i zwave ./openhab2/addons/org.openhab.binding.zwave-2.1.0-SNAPSHOT.jar
Thanks!
Mike
It looks fine. I would suggest to just run up the binding and check a few things…
One telling sign is this image you posted -:
The ? next to “Using Security” generally means you are using the old version. The log confirms this as there are no messages from the ZWaveTransactionManager class, and there are messages from the old security classes.
Good luck 
.
@chris
I was confident this was going to work after getting the snapshot jar properly installed. Even before I had un-included the yale lock, habmin showed the lock with a different icon and the binding logs were very showing zwave security related info.
I reiterated through the processes as before to remove/clean/include the lock, but after several attempts, still no progress. The 1st re-inclusion process didn’t appear to go through. I retried and went through, but still didn’t show the “Using Security” flag as green/true.
I went through a couple more iterations, thinking that perhaps since this was a security device, that low power inclusion might have been required, etc. Several additional attempts for inclusion weren’t successful, using both hpi and lpi modes. I also tried another lock thinking the “test unit” may need factory reset, etc… That attempt (lpi mode) wasn’t successful either. Retried the “test unit” and the inclusion went through, but still no security.
Finally, thinking if I set the “Secure Inclusion Mode” from Entry Control Devices to All, it would force including the lock with the security profile. Still no luck.
I’ve included ohab logs / screenshots, etc at https://www.dropbox.com/sh/5fs0lqvxj9fu9bt/AADENf_YGZqXb1kH8EGmvmHSa?dl=0
I’m not quite sure what other process I can test at this point. I’ve ordered another Aeon G5 Stick (matching) that will be here tomorrow to continue testing/etc separately so I can get the main system back to normal.
Primary immediately questions, should I leave the zwave binding on the “production” system with the snapshot or revert to the 2.1.0 distro version while continuing the efforts with a test configuration environment?
Thanks as always!
It’s a bit difficult to follow your logs, but here’s what I see looking at the first one…
Node 28 is included - this node seems to be already included in the network though as there are messages from it before the inclusion. This means it can never be included securely - it must be included for the first time to complete the key exchange.
Later I see node 30 being included - I thought maybe this was a reset of the device, but node 28 is still responding to messages. so I guess this is a different device?
I suggest to completely reset the device, then include it and send the logs if it doesn’t work.
@chris I apologize, I didn’t copy the index of what the logs files and time-line of the what the test cycles were into the share. There were quite a few iterations.
The log of primary interest is renamed to “openhab-1stInclude.log”. The screen-shot “ss42c-incfail.png” corresponds to that log file and highlights where the lock was included, but the secure inclusion failed.
(2017-09-15 16:43:15.655 [ERROR] … NODE 42: SECURITY_INC State=FAILED)This is following the above (in thread) confirmation that the snapshot jar was successfully registered, no other “things” were registered in ohab, etc.
Some of the other nodes were added after several subsequent tests to just confirm that zwave things were still working. It did occur to me that I may need to remove those again to continue legit testing, so why I ordered another matching Aeon gen5 stick. (will be here later today, only spare was the older S2) to continue completely separate without keeping the house in "manual mode 
". I wasn’t sure if the other zwave nodes needed to be removed/re-added due to the updated binding’s refactoring/changes in data structure,etc, but couldn’t find any mention of why, at that point a dedicated DEV environment was in order (VM /ohab/etc just built, waiting on delivery of stick)
However, this raises a key question, I thought I had clear from this/other threads as only needing to be removed from openhab config:
Not sure if worth any more time on these particular logs as I’ll have a proper function test run (or 3) and results posted by EoD.
Thanks!
There’s not much that I can comment on in the log - the device doesn’t respond to the nonce requests, so the key exchange fails.
In theory, neither. However some people have reported that the inclusion doesn’t work properly if there are a lot of devices in the network and I suspect that’s the issue you are seeing. This isn’t something I’ve managed to replicate here unfortunately 
.
After getting the test system (VM and new Aeon Controller) setup, I successfully joined the Yale lock on the 1st try!
Following initial setup of the items, etc. locking/unlocking from ohab was successful 
, battery level appeared to be reporting, but most other tests need some further debugging. (ex. physically locking/unlocking manually wasn’t reflected in the ohab items, unlocking/locking via the keypad wasn’t reflected, etc)
I can see why it may be problematic to join a secure node to the zwave network with other zwave items already included. I was surprised to see the LEDs indicator on the Aeon controller blink so fast. Before this, I didn’t even realize that it had anything to do with the zwave activity. I’ve never seen it (not that I’ve closely monitored it) do anything but the steady slow color cycle blink.
Seeing how much activity the inclusion process appeared to have, I wanted to see just how much more there was (purely out of curiosity as I was very surprised to the activity indicator on the controller led). Using the log entries (zwave binding in debug mode) as the measuring stick with ~106k entries, the following are my findings.
---- DISCLAIMER. I just found this interesting, this doesn’t indicate anything functionally meaningful other than expected debug log activity! ------
With some quick/dirty log analysis (removed java exception/error messages, etc) and summarizing the events per 1sec intervals, the graph (filtered to the time period near the lock inclusion), I could now see why the controller LED was going berserk The time period on the graph of high activity is ~ 6 minutes. That is about avg 1,200 events/sec. For comparison, my “production” environment using the snapshot zwave binding in debug mode, with ~35 zwave “things” generates about ~2 events per second (ball-parking). (That rate of ~2/sec is average run rate of zwave debug mode vs the rate during the inclusion process for the test env.)
Also, just to see if this was zwave related, UI, other, etc, wanted to get an idea on what was happening, so I also wanted to quantify the source of the debug info. The take away that I got is that with zwave security enabled nodes, there is alot more overhead via ZWave Transactions.
In summary, I can see why a zwave controller with more than a handful of other nodes already included might have problems including a security enabled device based on the amount of activity generated
@chris For your perusal of the log file, although I don’t believe I have any real security info contained, to be safe should I email or create a ticket on your site?
Thanks!
Test Environment: VM: Ubuntu 16.04 LTS x64, java 1.8.0_131, ohab 2.1.0 clean install, no bindings from distro; using the snapshot zwave jar in /addons ( size:1,676,468 /md5:7299811f87a98bcbcce2778be26ff526 downloaded 9/15). New Aeon Z-Stick G5. No other nodes already included (lock joined as node 2).
Hi @chris
Is there anything currently I can help with for testing with this (Yale locks)?
Is this link (referenced in several of the threads) the most recent 2.1.x snapshot? http://www.cd-jackson.com/downloads/openhab2/org.openhab.binding.zwave-2.1.0-SNAPSHOT.jar (appears to be as of Sept 18)
or… would it be helpful to be testing with the latest 2.2 build?
https://openhab.ci.cloudbees.com/job/openHAB2-Bundles/lastSuccessfulBuild/artifact/bindings/org.openhab.binding.zwave/target/
Thanks as always!
Just FYI for anyone else searching for this topic, the main thread (I believe, there are several) is here:
