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

digitaldan · March 31, 2017, 3:32pm

Hey @chris , is the current working branch for this https://github.com/cdjackson/org.openhab.binding.zwave/tree/dev-switchall-config-type ?

chris · March 31, 2017, 3:40pm

Yes - I should merge it into the development branch - I’ll look at doing that over the weekend.

Masssssy · April 1, 2017, 7:40am

Everything worked perfect until a reboot.

Not really had time to investigate but I am now getting:

[WARN ] [nal.converter.ZWaveDoorLockConverter] - NODE 10: Command class COMMAND_CLASS_DOOR_LOCK not found

Known problem? Suggestions for solving?

chris · April 1, 2017, 8:19am

This likely means the binding doesn’t think the lock is securely included. If the lock didn’t complete initialisation before the restart the it will try to communicate securely and if that fails then it will fall back to non secure which won’t support the lock class.

If you get a debug log then please open a ticket on my website and I’ll have a look.

TordYevl · April 1, 2017, 4:31pm

Anyone with experience of including ID Lock to openhab2?
I have my server with openhab and the usb controller in the basement and the lock is on ground floor.
If I remove the controller from the server and put it in inclusion mode, would that ever manage a secure inclusion?
Any experience in this area would be great.
Thanks in advance

chris · April 1, 2017, 4:39pm

No - this is not possible. The zstick must remain in the server for secure inclusion to work.

jeffsf · April 1, 2017, 5:18pm

Having problems with getting a Schlage BE469 to come up on a fresh system with what I believe to be the latest test version installed.

176 | Active   |  80 | 2.1.0.201703151108    | ZWave Binding
211 | Active   |  80 | 3.12.0.OH             | nrjavaserial

Trying to get debug logging has been “challenging” due to the mess of documentation out here.

https://github.com/openhab/openhab1-addons/wiki/ZWave-Security-Testing indicates that the given stanza should be added to “your /configuration/logback.xml file” as described in https://github.com/openhab/openhab1-addons/wiki/Z-Wave-Binding#logging

There is no logback.xml file in a deb install. org.ops4j.pax.logging.cfg as described one place in the official openHAB2 docs is not XML format. Elsewhere in the official docs, openhab-distro/lauch/home/logback_debug.xml is given as the path to the XML file for log configuration. This doesn’t exist either. sudo find / -name '*logback*' returns nothing.

Since changing the log level in the Karaf console does not persist across restarts, and I don’t think you can specify redirection of the logging output to a different file, what is the current approach for getting enough log information to figure out why this is failing?

Running openhab2 off last night’s nightly, with the hope that it would resolve the communication problem

chris · April 1, 2017, 5:34pm

This documentation is for OH1 - it’s completely irrelevant for OH2 - don’t use it.

Strange - it definately does for me. I never use the logback.xml in a production environment.

jeffsf · April 1, 2017, 5:43pm

Thanks @chris,

I’ll take a look again with the logging. I’m getting to the point where reading the documentation is proving it to be not only useless, but often counterproductive.

Are the Steps to test there at least the right ones?

From what I can tell, openHAB is definitely “talking” with the Sigma Designs UZB3-U-BRG controller, and that controller is reporting back that it has knowledge of the Schlage (after I paired them last night). There are only the two Z-Wave devices present. The 32-hex-digit random security key was set before pairing the lock. The lock was never paired with any other controller. The controller has never been paired with any other devices.

Typical INFO-level logs look like this

2017-04-01 08:59:02.341 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Connecting to serial port '/dev/ttyACM0'
2017-04-01 08:59:02.440 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Serial port is initialized
2017-04-01 08:59:02.516 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller
2017-04-01 08:59:02.517 [INFO ] [ve.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false.
2017-04-01 08:59:05.878 [INFO ] [age.SerialApiGetInitDataMessageClass] - ZWave Controller using Controller API
2017-04-01 08:59:05.879 [INFO ] [age.SerialApiGetInitDataMessageClass] - ZWave Controller is Primary Controller
2017-04-01 08:59:05.880 [INFO ] [age.SerialApiGetInitDataMessageClass] - ------------Number of Nodes Found Registered to ZWave Controller------------
2017-04-01 08:59:06.490 [WARN ] [ve.internal.protocol.ZWaveController] - NODE 2: Restore from config: Error. Data invalid, ignoring config.
2017-04-01 08:59:07.979 [WARN ] [.serialmessage.ZWaveCommandProcessor] - SerialMessage class null is not implemented!
2017-04-01 08:59:07.980 [WARN ] [.serialmessage.ZWaveCommandProcessor] - SerialMessage class null is not implemented!
2017-04-01 08:59:07.981 [WARN ] [ve.internal.protocol.ZWaveController] - TODO: Implement processing of Request Message = -- (0xA8)
2017-04-01 08:59:15.045 [WARN ] [.serialmessage.ZWaveCommandProcessor] - SerialMessage class null is not implemented!
2017-04-01 08:59:15.047 [WARN ] [.serialmessage.ZWaveCommandProcessor] - SerialMessage class null is not implemented!
2017-04-01 08:59:15.048 [WARN ] [ve.internal.protocol.ZWaveController] - TODO: Implement processing of Request Message = -- (0xA8)
2017-04-01 08:59:23.009 [WARN ] [.serialmessage.ZWaveCommandProcessor] - SerialMessage class null is not implemented!
2017-04-01 08:59:23.011 [WARN ] [.serialmessage.ZWaveCommandProcessor] - SerialMessage class null is not implemented!
2017-04-01 08:59:23.012 [WARN ] [ve.internal.protocol.ZWaveController] - TODO: Implement processing of Request Message = -- (0xA8)
2017-04-01 08:59:27.990 [ERROR] [alization.ZWaveNodeInitStageAdvancer] - NODE 2: SECURITY_INC State=FAILED
2017-04-01 08:59:29.283 [WARN ] [.serialmessage.ZWaveCommandProcessor] - SerialMessage class null is not implemented!
2017-04-01 08:59:29.286 [WARN ] [.serialmessage.ZWaveCommandProcessor] - SerialMessage class null is not implemented!
2017-04-01 08:59:29.287 [WARN ] [ve.internal.protocol.ZWaveController] - TODO: Implement processing of Request Message = -- (0xA8)

with that (0xA8) series then repeating “forever”

I’d appreciate any suggestions on where to go from here

chris · April 1, 2017, 5:59pm

Sorry - where is ‘there’? I can’t see any steps to test in any of the logging sections - maybe I’ve missed it?

chris · April 1, 2017, 6:05pm

This means it isn’t securely included.

Secure inclusion must be completed within 20 seconds of the main inclusion, so you must ensure this happens.

I don’t know what controller you’re using - possibly a non-standard controller that’s causing the A8 messages? Either that or there’s an error with COM ports or something. A debug log would be useful (don’t post secure debug logs here - open a ticket on my website).

jeffsf · April 1, 2017, 6:18pm

It’s a Sigma Designs UZB3, their reference design controller. Probably the one all the Chinese ODMs copy, even if they don’t use Sigma Designs chipsets

Sounds like I have to re-associate the lock with the controller then. Are the referenced steps from Home · openhab/openhab1-addons Wiki · GitHub correct for the current OH2 binding as well? I’d prefer not to have to do a factory-reset of the lock, but will if that is required.

Steps to test

Run the code downloaded above. Note that pairing process is different than with other zwave devices. The zwave controller needs to stay connected to the machine running openhab and it needs to be very close to the secure device (a foot or less) during pairing.

[…]

chris · April 1, 2017, 6:23pm

Which version? There are multiple firmware versions of this device.

No - as mentioned previously - this documentation is for OH1. The OH1 code is in no way related to the OH2 code when it comes to security. Of course the basic function of inclusion is the same, but that’s about it.

01av · April 1, 2017, 6:27pm

Tommy,
Look through this thread(the latest posts), and see if it can be of any help:

jeffsf · April 1, 2017, 6:42pm

No clues on the FW version, as HABmin doesn’t show anything (Manufacturer through Specific class are blank), /var/lib/openhab2/zwave/network_d3f6d6e9__node_1.xml doesn’t have anything useful in it, and I don’t see anything in the logs about firmware. Doing a full reboot now to see if anything shows up with a version number.

Since it sounds like I need to start over from scratch, where are the current instructions for including a lock? I’ve been following links in this thread, but apparently they are leading to outdated and/or factually incorrect information.

chris · April 1, 2017, 7:05pm

No - there’s no way to get this information from the serial interface on a controller - is there anything written on it?

I suspect it’s the bridge firmware which isn’t 100% compatible as it’s designed for a different purpose.

Generally, I would suggest to check the manual from your lock. As far as OH goes, to include a device just click on the “discover” button in either habmin or paperui. I’d recommend HABmin as it will give you feedback on how things progress which you won’t get through HABmin.

jeffsf · April 1, 2017, 7:18pm

Nope, nothing written on it to suggest a FW revision. It’s brand new from DigiKey, which is Sigma Design’s eval-kit partner in the US.
https://www.digikey.com/product-detail/en/sigma-designs-inc/ACC-UZB3-U-BRG/703-1131-ND/6111635

I know the steps for both requesting Z-Wave pairing, as well as for a factory reset of the lock. Are you saying that I do not need to factory reset the lock under OH2?

(Yes, I agree with you that PaperUI is perhaps pretty, but pretty useless)

chris · April 1, 2017, 7:44pm

Yep - that’s what I was looking for… So this is the Bridge version - with the BRG in the model number… It’s meant as a development board for a specific Sigma software product - I’m actually a little surprised that you managed to buy it without getting asked to pay for the developer kit…

No - if you’re already included it, then you’ll need to exclude it again unless you know the key that was used when you last included the device into the stick, and then you can type this key into OH2. It depends on what you’ve done previously. To securely include a device, it needs to all be done within around 20 seconds - if it doesn’t work in that time, then you’ll need to exclude it and start again.

jeffsf · April 2, 2017, 1:01am

Looks like the BRG version isn’t terribly happy, even trying to connect with a GE/Jasco 12721 switched outlet. The binding sees that there is a node, but apparently fails to communicate with it properly. Next step is a clean install of everything and I’ll see what happens. I’ll hold onto the debug-level logs, if you’re ever interested. I knew I should have ordered both! Silly me thinking that the bridge version would be for, well, a bridge…

Edit:

From http://forum.z-wavepublic.com/t/uzb-static-versus-bridge/104

Hi, can someone explain the difference between ACC-UZB3–STA and ACC-UZB3–BRG. From the description, I see that the difference is static and bridge. Does that mean that bridge model will act as a repeater for all traffic and the static model will not? Thanks.

Answered with:

The bridge controller allows the creation of virtual nodes. It is identical with the static controller in any other aspect.

Confirmed in http://forum.z-wavepublic.com/t/bridge-controller-uzb/22/2

Regarding your questions:

Both are supported and have the same performance, while there is a slight difference in components.
While it is technically possible to update the static controller UZBs, however the firmware images and tools are not publicly available.
Z/IP Gateway, the core software component relies on the bridge functionality for session handling and IP associations.

and

The onboard SAW filter has been replaced to match our latest recommendation for hardware designers.The Z-wave SoC is unchanged; the SD3503.

Edit 2:

Confirmed still an issue with a fresh install from https://openhab.ci.cloudbees.com/job/openHAB-Distribution/858/ and no config other than dropping the 2.1.0.201703151108 Z-Wave binding into the addons/ directory in the un-tar-ed distribution, installing the Expert UI package, and the still-required openhab> feature:install openhab-transport-serial and a restart of openHAB before trying to add the Z-Wave Serial Controller.

chris · April 2, 2017, 8:27am

From what I’ve seen of the bridge controller I don’t think the above statement is correct.

What “issue” are you talking about specifically that still exists in the latest version?