@chris so as per the command classes supported for my lock, I should not expect SENSOR_BINARY to work but use BASIC instead? I just want to see what the response of the lock is in relation to the status of the lock.
Since it looks like the lock doesn’t support SENSOR_BINARY, I guess you shouldn’t expect it to work 
@chris Yes, I believe the status is within the DOOR_LOCK CC but I would rather poke and probe than twiddle my thumbs 
@mganapa I was actually playing with this earlier today. I’ve updated the wiki to show the following which is working a little better in terms of showing status.
Switch Door_Lock “Door Lock” (GF_Office) {zwave=“3:command=door_lock”}
Contact Door_Basic “Front door lock” (GF_Office) {zwave=“3:command=door_lock,refresh_interval=20”}
Number Door_Corridor_Battery “Door lock battery level [%d %%]” (GF_Office) { zwave=“3:command=battery” }
I also made some code fixes to my 1.8 testing branch to get this working.
BUT… for me at least, the icons are backwards. I see the lock with the red X when door is locked, and the lock with the green checkmark when the door is unlocked.
So I’m wondering if this is:
- The way all locks report status OR
- Some anomaly with kwikset locks OR
- Some anomaly with the kwickset 910 lock OR
- A combination of 1, 2, or 3 above with the direction the lock faces (left opening door vs right opening door).
So if anyone could help with testing to gather some more data. Please use the code and configs from the wiki at Home · openhab/openhab1-addons Wiki · GitHub
Then test to see if the status gets updated. Note that it takes about 20 seconds for the status to update on the OH UI and the events.log file. Try sending a lock/unlock request via OH and also just walking up to the door and manually turning the lever.
I don’t need to see log files or anything, just looking for a generic report of “it’s backwards for me too” or “the icons are working for me” and which side of the door your lock is mounted on when looking at it from the inside. My kwikset 910 is mounted on the left.
Thanks!
Dave
@dbadia Here are my results
- The door does not lock or unlock with every request. The attempts to do so are successful sporadically. Thid was not the case with the 1.6 branch where every attempt to lock or unlock was successful.
- Battery level is no longer displayed. I just get a -.
- The lockstatus per icon is reversed. The display string also says open when lock is closed and vice-versa. My lock is mounted on the right (facing door from inside the house).
- The log states that product not found in database. I did not see any error in the log for 1 and 2 above. But then its 2 in the morning so I will have to examine the logs in detail tomorrow. Attached is the screenshot of my sitemap when the door was unlocked. .
I would very much like to help with testing. This is exactly what I’ve been looking for in my (very new) setup. I even bought a Schlage Connect today to start trying to connect to my Z-Stick Gen5 and start trying to tie it into openHab. However, I’m having a hell of a time compiling.
I’ve started another thread over in the IDE section of the forum: Mwe2Launcher Error
Maybe someone here has some idea?
Hello Dave, I just realized something with my second testing process. I was still using OpenHAB version 1.6 with the ‘security-beta-test’ tree of your zwave binding. Should I switch to OpenHAB 1.8.0SNAPSHOT instead?
Looking into the log I see that a lot of my messages failed transmission and the node was eventually marked as dead before being marked alive at a later point in time. I also had error messages like below:
[ERROR] [eController$ZWaveReceiveThread:1494]- Protocol error (CAN), resending
I also see
2015-10-20 01:43:42.319 [ERROR] [b.z.i.protocol.ZWaveController:1163]- Exception during Z-Wave thread: Input.
java.lang.NullPointerException: null
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass$NonceTimer.access$0(ZWaveSecurityCommandClass.java:1384) ~[na:na]
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.queuePayloadForEncapsulationAndTransmission(ZWaveSecurityCommandClass.java:719) ~[na:na]
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.queueMessageForEncapsulation(ZWaveSecurityCommandClass.java:668) ~[na:na]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.enqueue(ZWaveController.java:575) ~[na:na]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.sendData(ZWaveController.java:959) ~[na:na]
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeStageAdvancer.sendMessage(ZWaveNodeStageAdvancer.java:238) ~[na:na]
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeStageAdvancer.advanceNodeStage(ZWaveNodeStageAdvancer.java:890) ~[na:na]
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeStageAdvancer.handleNodeQueue(ZWaveNodeStageAdvancer.java:214) ~[na:na]
at org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeStageAdvancer.ZWaveIncomingEvent(ZWaveNodeStageAdvancer.java:1049) ~[na:na]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.notifyEventListeners(ZWaveController.java:616) ~[na:na]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingRequestMessage(ZWaveController.java:229) ~[na:na]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage(ZWaveController.java:200) ~[na:na]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$6(ZWaveController.java:195) ~[na:na]
at org.openhab.binding.zwave.internal.protocol.ZWaveController$ZWaveInputThread.run(ZWaveController.java:1156) ~[na:na]Hey Mahesh -
Yes, you should switch over to 1.8.0-SNAPSHOT and use that with my security-beta-test branch. I had the same problems here, but I found a couple bugs and just pushed my changes out to github. Also fixed the state showing incorrectly.
Grab the latest and give it another try when you get the chance.
Thanks
Dave
Hello Dave, I will do that tonight. Hopefully, the basics should work 
Yes, I think this build will work much better
Thanks again for the detailed status report, it helped a lot
Dave
Got through the IDE setup and compiled the 1.8.0-SNAPSHOT version of openHab with no issues. Got it running with my basic Nest setup that I had running on the stock 1.8 openHab… so good to start testing with my lock!
Ran through the Steps to Test on https://github.com/openhab/openhab/wiki/ZWave-Security-Testing and here’s where I got stuck:
-
Pretty certain the pairing worked ok. My lock (Schlage Connect 469) flashed the checkmark (which the manual says indicates it has joined the Wave network successfully) and I can see the lock as Node 2 in the Wave Device list in Habmin.
-
Looking at the zwave.log, I’m seeing lots of the following error:
2015-10-21 21:22:53.640 [DEBUG] [.z.i.config.ZWaveConfiguration:274 ]- NODE 2: No database entry: Schlage [ID:5044,Type:6341]
-
Can’t lock or unlock the lock from the web interface… pretty certain that’s just because I haven’t set up the sitemap or items correctly. The following warning is in my zwave.log every time I hit the switch on the web interface:
2015-10-21 21:22:54.985 [WARN ] [.b.z.i.c.ZWaveConverterHandler:394 ]- NODE 2: No command class found for item = Door_Lock. Class = door_lock(DOOR_LOCK), endpoint = 0. Ignoring command.
Here’s my items file:
Switch Door_Lock "Door Lock" <none> (GF_Office) {zwave="2:command=door_lock"}
Contact Door_Basic "Front door lock" <lock> (GF_Office) {zwave="2:command=door_lock,refresh_interval=20"}
Number Door_Corridor_Battery "Door lock battery level [%d %%]" (GF_Office) { zwave="2:command=battery" }
And my sitemap file:
sitemap nest label="Lock"
{
Frame label="Lock" {
Switch item=Door_Lock
}
I’m happy to share my log file but I can’t attach it (too big & unacceptable file extension)… I’m open to suggestions if anyone would like to see it.
Hello Dave,
I managed to do some testing with your latest commit.
- Lock/ unlock no longer works. - openhab.log says command received but does not say item updated like it does for other zwave devices.
- Battery shows the correct value for me (96%)
- Lock status shows the right value when lock is closed/ open. I opened/closed the lock manually.
This seems to be the same as what @Bill reported. However, as soon as openHAB was started my lock, which was open, was closed. Auto-close was turned off and the lock was left open for 30 minutes. I was never able to reproduce this particular scenario.
Openhab is 1.8. SNAPSHOT pulled from cloudbees this evening.
@dave here is a link to my logs. log files
One thing that was interesting is that my Aeotec smart strip failed to function with this version of the binding but the aeotec micro switches and dimmer were functioning perfectly fine.
2015-10-21 22:32:42.097 [WARN ] [.b.z.i.c.ZWaveConverterHandler:394 ]- NODE 21: No command class found for item = MB_SmartStrip_3. Class = switch_binary(SWITCH_BINARY), endpoint = 3. Ignoring command.
Ok… So I know why I’m getting the device not found error… The BE469 isn’t in the zwave database.
I’ll add the 469 to my local database tonight (and use the 468.xml file because my research indicates these two models are nearly the same and should use the same commands) to see if that fixes the first problem. If so, I’ll submit the PR to add this model to the sourcecode.
@mganapa @Bill
Interesting that you guys are seeing different results than I get here. I did a new pull of my code from github, my lock/unlock requests work all the time, and the status updates most of the time (still debugging why status doesn’t always update).
Mahesh - That’s good that battery and status is working when you open/close the lock manually. You said that openhab.log shows command received… where do you see that?
Looking at your log, it appears the command isn’t reaching the zwave stack, as normally you would see:
09:22:40.479 [DEBUG] [.p.c.ZWaveDoorLockCommandClass:143 ] - NODE 3: Creating new message for application command DOORLOCK_SET
...
09:22:40.480 [DEBUG] [.z.internal.protocol.ZWaveNode:902 ] - NODE: 3 Incoming message Message: class = SendData (0x13), type = Request (0x00), payload = 03 03 62 01 FF required security encapsulation=true
Critical parts being DOORLOCK_SET and 62 01 which is the door lock set raw hex command. I see those in your original 1.6 log when it was working, but I don’t see this at all in the last log you posted. So it seems there is a disconnect somehow.
Let’s try testing a different way to ensure we are testing the same thing as there are some recent changes in the OH 1.8 branch that I haven’t pulled into mine. I’m going to have you compile the full OH from my branch and run it that way:
- Go into my security-beta-test branch on your machine (referred to as new from here on), do a git pull
- Follow steps 2 - 8 of Pure Eclipse from https://github.com/openhab/openhab/wiki/IDE-Setup
- You are almost ready to run openhab from the new/distribution/openhabhome directory, but we have to copy over the old configs first
- From your old testing openhab install, copy over /etc/zwave/* to new/distribution/openhabhome/etc/zwave
- From your old testing openhab install, copy over /configuration/items, sitemaps, etc to new/distribution/openhabhome/configurations
- Copy zwave jar from new/bundles/bindings/zwave/…/target to new/distribution/addons. (Added this step from my phone so not 100% on the paths)
- cd to new/distribution/openhabhome and run start_debug
I did those steps here with a fresh git pull and it’s working as expected for me. Be curious to see if you guys have different results doing it this way.
@mganapa curious to see if this fixes your smart strip as well. Interesting about the door locking on startup, again I don’t see any requests in the log file so I’m not clear as to why that happened. Let’s keep an eye on that one and see if it happens again
Thanks
Dave
Hello Dave,
In my events.log you can see a few lines similar to the ones below:
2015-10-21 22:19:17 - Front_Door_Lock received command ON
2015-10-21 22:13:36 - Front_Door_Lock received command OFF
These appear when I activate/deactivate the switch item from my app (HABDroid).
Hello Dave,
I tried to follow the steps outlined by you but I was never able to have the addons loaded when OpenHAB was run from within eclipse. When I try to run the start(_debug).bat file(s), the server directory is not inside openhabhome and this causes the ECLIPSEHOME variable to empty which prevents the runtime from startingup
I instead followed the procedure below:
- Used the compiled distribution-1.8.0-SNAPSHOT-runtime.zip runtime from the new/distribution//target
- Used the Z-Wave binding jar from new/bundles/binding/org.openhab.binding.zwave/target
- Used my other bindings from my old install (ntp, astro etc)
- Copied all my configurations from items/sitemap/transforms
- Copied over /etc/zwave directory
I am still not seeing DOORLOCK_SET in my Z-Wave.log. I can see DOORLOCK_GET and looks like my smartstrip is working as the switch now stays in place. I will confirm this once I get back home.
@dbadia sorry to report that I have the same result as before. Lock status and battery level work fine. Locking and unlocking does not work. Smartstrip doesn’t work.
@mganapa Ok, the steps you followed seem reasonable, but the outcome is really confusing… no idea why the commands aren’t making it through. not that it should matter, but what UI are you using? I’m using Classic UI for all of my testing. Also, when you click the switch, do you see anything in the logs?
@Bill can you upload your logs somewhere so I can look at them? I’m curious to see if you are having the same issue as Mahesh or it it’s something different. You can use google drive or maybe pastebin to upload them.