OH2 Z-Wave refactoring and testing... and SECURITY

Does this development binding work with OH2.3 or should I stick to OH2.2?

Hi, where can I find the log shown in the picture here? Thanks!

It’s working for me: openHAB 2.2.0 Release Build

$ openhab-cli console
openhab> bundle:list | grep -i zwave
226 │ Active │ 80 │ 2.3.0.201802082157 │ ZWave Binding

I think it’s mentioned earlier: uninstall the 2.2 binding via PaperUI, download to /usr/share/openhab2/addons and restart openhab.

This version got my Schlage lock working since it has security. What’s not working is any feedback from devices. For example, when I physically lock to deadbolt it doesn’t update in OH. That’s what I’m struggling with now.

But he asked the other way around :wink: From what I can understand it works in both 2.2 and 2.3.

Yes - the binding name is version 2.3 and it works fine with OH 2.3.

http://www.cd-jackson.com/index.php/openhab/zwave-log-viewer

Some locks, including the Schlage Connect series, do not report lock/unlock through the lock_door channel. You will need to create some rules and utilize the alarm_raw channel if you want to have a single Switch item to display the lock state. Here is an example…

More discussion here…

Hi @chris Could you review the logs and let me know why I can’t add my lock to the network?
http://www.faure.ca/~paul/openhab_feb27.log
It seems to error out even before I start joining the network on the lock.
Thanks,
Paul

In case you want to know about my ZStick due to this:
2018-02-27 17:33:06.080 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - NO callback match! (52 <> 1)

T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=10c4 ProdID=ea60 Rev=01.00
S: Manufacturer=Silicon Labs
S: Product=CP2102 USB to UART Bridge Controller
S: SerialNumber=0001
C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=cp210x

Thanks, Chris

Having a hard time getting my secure node (Kwikset 912) to work with my secondary controller. Can secure nodes be controlled by secondary controllers?

This message is perfectly normal. It’s nothing to do with the stick and is just a debug message from the transaction processor.

I’ll take a look at the log…

Probably not - I don’t know what controller you’re talking about - if you’ve transferred the key to the other controller, then it should be possible, but if the controller is a keyfob or something similar, then no, it won’t work.

In this log, as you said the controller is responding with an error and isn’t going in to inclusion mode. I’m not sure why this would happen.

image

I’ll see if I can find out what might cause this, but from memory the ZWave docs don’t provide any information about possible causes.

I have a Honeywell Tuxedo touch, OH 2.2 on RaspberryPi with your Z-wave binding 2.3 (Feb 25) and Aeon Gen 5 Z Stick. Honeywell works well controlling other non secure nodes. I doubt ill be able to change the Key on the Tuxedo. Honeywell seems to lock the unit down pretty well. Can I try to change the key to in OH2 to match what the tuxedo has? Of course i would have to look to see if i can find the Key in the tuxedo.

Also interesting note when I sync the devices on the tuxedo by making it a secondary and manually hitting the inclusion button on the aeon stick it adds in the “static controller” Node and I can see it on the network and in Things. However, if I do the inclusion process via OH2 the devices sync to the Tuxedo, but I get a “Node not found in Z-Wave network”. Only reason I thought syncing it from OH2 was maybe during the process of sending devices to the secondary controller, maybe it passes the Key as well…If thats not the case then it wont matter much to debug this.

Dear @chris

I also recognize the behaviour mentioned here ZWave device association/physical switches not registering

Regards,
Herbert

I occasionally see the same behavior. Clearing and resetting the association didn’t help. But deleting the Thing and rediscovering resolves it for me. I find it best to delete all Things and rediscover after each binding update. I have a rule for this and will create a post to share it. Saves a lot of time if you have more than a couple devices. But still a huge PITA to have to change 30+ temperature scales from Celsius to Fahrenheit. I know it can be done in the rule, but haven’t quite figured it out yet. Sure wish there was a default setting for that…

No more hints for me @chris, provided the new logs after deleting the xml ?

Regards

Romain

Here are some clean logs from a fresh start of OH:
http://www.faure.ca/~paul/openhab.clean.start.log
Hope it helps.

FYI, I seemed to have an old 2.1 version of the other bindings. I have not updated them to the latest 2.2 and refreshed the log above.

I now see these message in the logs:

2018-02-28 19:02:03.932 [WARN ] [ig.xml.osgi.XmlDocumentBundleTracker] - The XML document '/ESH-INF/binding/binding.xml' in module 'org.openhab.binding.zwave' could not         be parsed: The XmlConfigDescriptionProvider must not be null!
java.lang.IllegalArgumentException: The XmlConfigDescriptionProvider must not be null!
        at org.eclipse.smarthome.core.binding.xml.internal.BindingInfoXmlProvider.<init>(BindingInfoXmlProvider.java:60) [112:org.eclipse.smarthome.core.binding.xml:0.1        0.0.b1]
        at org.eclipse.smarthome.core.binding.xml.internal.XmlBindingInfoProvider.createDocumentProvider(XmlBindingInfoProvider.java:141) [112:org.eclipse.smarthome.cor        e.binding.xml:0.10.0.b1]
        at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.acquireXmlDocumentProvider(XmlDocumentBundleTracker.java:181) [108:org.eclipse.smarthome.confi        g.xml:0.10.0.b1]
        at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.addingObject(XmlDocumentBundleTracker.java:206) [108:org.eclipse.smarthome.config.xml:0.10.0.b        1]
        at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.parseDocuments(XmlDocumentBundleTracker.java:350) [108:org.eclipse.smarthome.config.xml:0.10.0        .b1]
        at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.processBundle(XmlDocumentBundleTracker.java:336) [108:org.eclipse.smarthome.config.xml:0.10.0.        b1]
        at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker.access$3(XmlDocumentBundleTracker.java:331) [108:org.eclipse.smarthome.config.xml:0.10.0.b1]
        at org.eclipse.smarthome.config.xml.osgi.XmlDocumentBundleTracker$2.run(XmlDocumentBundleTracker.java:307) [108:org.eclipse.smarthome.config.xml:0.10.0.b1]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]

2018-02-28 19:02:26.023 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NodeID is not set in zwave:device:cont:node5
2018-02-28 19:02:26.023 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NodeID is not set in zwave:device:cont:node3
2018-02-28 19:02:26.024 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:cont:node8.
2018-02-28 19:02:26.026 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NodeID is not set in zwave:device:cont:node8
2018-02-28 19:02:26.026 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:cont:node6.
2018-02-28 19:02:26.026 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NodeID is not set in zwave:device:cont:node6
2018-02-28 19:02:26.028 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:cont:node4.
2018-02-28 19:02:26.031 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NodeID is not set in zwave:device:cont:node4


2018-02-28 19:02:31.679 [ERROR] [.serialmessage.EnableSucMessageClass] - Unable to disable a running SUC!

FYI, this version worked for inclusion: 2.3.0.201802081624
It didn’t error out and the door lock got included successfully. But controlling the device didn’t work at all.

I am now running: 2.3.0.201802082157

I’m not sure what is causing this - it seems to indicate something wrong with the runtime. Also, are you configuring your things through text files or the UI? Some people seem to have problems configuring through text files recently - I don’t think it’s a binding issue, but it’s what normally causes the NodeID not set error. If you use the UI, this really should not happen.