It’s doing it again now and I really am at a loss on what to try. Same problem, nothing responds, and every entry in the log complains that Security is not supported. No linux level issues with the controller, things all show online… Log will be attached at your site.
I’ll add in this state I can go into controls via the openhab sitemap and change states and nothing occurs, not even a log entry… Almost like openhab itself has crashed, however listing modules from a console ssh session I don’t see any problems, perhaps I don’t know what to look for?
I’m confused as to why you think this is related to zwave?
In both the logs you sent, there’s no errors from zwave, but there are a lot of errors from homekit that occur at the time everything stops working. To me, it looks like something is taking your system down - there’s pretty much nothing in the log other than these homekit errors so I would have looked there.
Maybe from the UI or something, you have a different impression that this is caused by ZWave - I just don’t see the link myself at the moment.
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.
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
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
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
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
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.
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.
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.
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.
