Z-wave (Schlage) Lock Support on OH1

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 :smiley:

Yes, I think this build will work much better :smile:
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:

  1. 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.

  2. 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]

  3. 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.

  1. Lock/ unlock no longer works. - openhab.log says command received but does not say item updated like it does for other zwave devices.
  2. Battery shows the correct value for me (96%)
  3. 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:

  1. Go into my security-beta-test branch on your machine (referred to as new from here on), do a git pull
  2. Follow steps 2 - 8 of Pure Eclipse from https://github.com/openhab/openhab/wiki/IDE-Setup
  3. You are almost ready to run openhab from the new/distribution/openhabhome directory, but we have to copy over the old configs first
  4. From your old testing openhab install, copy over /etc/zwave/* to new/distribution/openhabhome/etc/zwave
  5. From your old testing openhab install, copy over /configuration/items, sitemaps, etc to new/distribution/openhabhome/configurations
  6. 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)
  7. 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:

  1. Used the compiled distribution-1.8.0-SNAPSHOT-runtime.zip runtime from the new/distribution//target
  2. Used the Z-Wave binding jar from new/bundles/binding/org.openhab.binding.zwave/target
  3. Used my other bindings from my old install (ntp, astro etc)
  4. Copied all my configurations from items/sitemap/transforms
  5. 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.

@mganapa I missed your post where you mentioned using habdroid… can you try from classic UI?

I have used classic UI as well and the same results.

When i click the switch, I get the following line in my openhab.log and events.log
Front_Door_Lock received command ON
Or
Front_Door_Lock received command OFF

Hi Dave,

Had a little bit of time to muck about with this tonight… fixed my device not found error by adding the 469 device ID to the zwave database and recompiling the snapshot… error gone.

Unfortunately, the lock still isn’t responding to the lock command on the UI and still seeing the “No command class found” error in the zwave log. I dumped my log files into a public dropbox folder here: https://www.dropbox.com/sh/15rzjxjvf2kzauf/AAAlAi3cRleaww_99mI81itua?dl=0

Let me know if you can retrieve the logs ok and, if so, if you see anything interesting in there.

@dbadia & @bill Just an FYI which I thought might be useful. I use logview plus to analyze my log files. You can create a parser rule in the application for each of the logfiles using the pattern defined in the logback.xml and logback_debug.xml.
Makes it easier to track the logs. :smile:

I should have mentioned that I’m still using your original snapshot, Dave… haven’t tried the newer code yet - will do tonight or this weekend if you’d like to see the results.

@Bill
Thanks for posting your log file. Looks like the original secure pairing didn’t work:

2015-10-22 21:18:18.772 [ERROR] [.p.c.ZWaveSecurityCommandClass:1013]- NODE 2: Invalid state! secure inclusion has not completed and we are not in inclusion mode, aborting

which explains the command class not found.

When you did the original pairing, did you follow the instructions on the wiki and use habmin to put the controller into inclusion mode?