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:
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.
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!
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:
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.
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:
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
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
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.
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
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.
@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.
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?