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

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

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

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

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

Sounds like I have to re-associate the lock with the controller then. Are the referenced steps from https://github.com/openhab/openhab1-addons/wiki/ZWave-Security-Testing 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

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


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.

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

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.

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.

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.

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)

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.

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…


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:

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


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

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?

I wanted to establish if the failure-to-communicate problem was part of my config or not.

I’ve also since confirmed that the BRG controller is not supported under openzwave with the same kind of problems.

Well it certainly didn’t happen under the old z-wave binding, but if you like I can switch back to it and try for awhile to ensure it certainly is something in this one. I’ve just had a kid and my time to work on this stuff is a little lacking right now. :slight_smile:

But probably (??) the zwave binding isn’t the only thing that’s changed in your system?

Looking at the log, the errors are coming from another binding, so I just think that this would be the first place to look?

Even if the problem is with zwave binding, it’s not reported by others, and there’s absolutely nothing in the logs that points to anything in ZWave - pretty much all logging just stops from all bindings except the homekit one which reports errors. Unless you can find a bit more to go on, I’m afraid I can’t help much - sorry.

Just following up on my earlier reports of a fresh device not secure including properly. I finally was able to manage to get it to work, but it required a full reset on the ZStick. So if you’re running into issues with the Secure inclusion not succeeding, it may be that you need to check the possibility of resetting the ZWave controller in use. At least that solved it for me. Now successfully transmitting.

@chris One issue I have found though, and perhaps this hasn’t been fully fixed/implemented - User Codes are not making it to the device. I tried to add in 3 user codes, but none of them appear to have successfully been transmitted to the device. Should I open a ticket and try to get some logs of the transmission? And/or is there a way to “force” the transmission and watch it? I tried to watch DEBUG logs as I put the codes in, but didn’t see any specific transmissions.

Yes - feel free to raise a ticket with some logs and I’ll have a look.


Just wondering if anyone has successfully used the latest test version with the Yale keyless connected lock?



Yes - I use this device and it’s working fine. I might not be using the 100% latest version on my production system, so I can’t say “yes” if your question is really about the “latest” but otherwise it’s ok.

cool - thanks, Chris. Out of interest, does the binding let openHAB change the PIN code? Or is it just unlock and notifications?