I transitioned from openhab1 to openhab2 and noticed that the controller configuration for the zstick was lacking. This is an issue when pairing devices that require security. When working w/ openhab1 I could set a security key and also LED status with the openhab.cfg file. This parent config file is not present in openhab2 and I can’t seem to find the equivalent.
I’ve also looked in habmin’s interface and have not been able to find a configuration setting. I noticed in cd-jackson’s db the config’ for almost all the zwave pc-controllers have channel errors. This seems weird given the prevalence of these controllers. Any help would be appreciated.
To use security with Z-Wave in openHAB2, you need to use the 2.1.Refactoring/Security Snapshot development Binding from @chris
There is no equivalent flat configuration file for the Z-Wave binding (either the 2.0 stable, 2.1 snapshot or 2.1.Security Snapshot).
With the 2.1.Security Snapshot, use HABmin to perform a secure inclusion of a device.
Thanks for your help Dim,
I tried the Security enabled jar linked from the post above and also tried using the latest snapshot from the zwave git repo (2.1.0). I have removed every node from my controller and used a completely vanilla openhab 2.0 and 2.1.0 base install. For some reason I can’t get my lock (a kwikset 914trl) to securely pair. There are others on this forum who have been successful (Kwikset 914 Inclusion) but nothing I try seems to allow for secure inclusion. The Lock’s attribute tab in habmin has a question mark next to security.
My debug log on re-including the device is below:
2017-05-31 23:19:01.194 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:15c47b89ff1:node9' to inbox.
2017-05-31 23:19:01.194 [DEBUG] [ve.internal.protocol.ZWaveController] - ZWave controller start inclusion - mode 2
2017-05-31 23:19:01.195 [DEBUG] [ol.serialmessage.AddNodeMessageClass] - Setting controller into INCLUSION mode, highPower:true networkWide:true.
2017-05-31 23:19:01.196 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
2017-05-31 23:19:01.196 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 05 00 4A C1 01 70
2017-05-31 23:19:01.196 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 255: Sending REQUEST Message = 01 05 00 4A C1 01 70
2017-05-31 23:19:01.196 [DEBUG] [ve.internal.protocol.ZWaveController] - Message queued. Queue length = 0. Queue={}
2017-05-31 23:19:01.198 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 4A 01 01 00 00 B2
2017-05-31 23:19:01.198 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-05-31 23:19:01.198 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 07 00 4A 01 01 00 00 B2
2017-05-31 23:19:01.198 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 07 00 4A 01 01 00 00 B2
2017-05-31 23:19:01.198 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=AddNodeToNetwork[0x4A], type=Request[0x00], priority=High, dest=255, callback=0, payload=01 01 00 00
2017-05-31 23:19:01.198 [DEBUG] [ol.serialmessage.AddNodeMessageClass] - Add Node: Learn ready.
2017-05-31 23:19:01.199 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveInclusionEvent
2017-05-31 23:19:01.200 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=AddNodeToNetwork[0x4A], type=Request[0x00], priority=High, dest=255, callback=0, payload=C1 01
2017-05-31 23:19:01.200 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=AddNodeToNetwork[0x4A], type=Request[0x00], priority=High, dest=255, callback=0, payload=01 01 00 00
2017-05-31 23:19:01.200 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=AddNodeToNetwork, callback id=0, expected=AddNodeToNetwork, cancelled=false transaction complete!
2017-05-31 23:19:01.200 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
2017-05-31 23:19:01.200 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 255: Response processed after 4ms/2456ms.
2017-05-31 23:19:07.100 [DEBUG] [org.openhab.binding.zwave ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.core.status.ConfigStatusProvider}={service.id=350, service.bundleid=38, service.scope=singleton} - org.openhab.binding.zwave
2017-05-31 23:19:07.101 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler.
2017-05-31 23:19:07.104 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Handler disposed. Unregistering listener.
2017-05-31 23:19:07.106 [DEBUG] [org.openhab.binding.zwave ] - ServiceEvent UNREGISTERING - {org.eclipse.smarthome.config.core.status.ConfigStatusProvider}={service.id=350, service.bundleid=38, service.scope=singleton} - org.openhab.binding.zwave
2017-05-31 23:19:07.109 [WARN ] [home.core.thing.binding.ThingFactory] - Could not create channel 'alarm_number' for thing type 'zwave:device:15c47b89ff1:node9', because channel type 'zwave:alarm_number' could not be found.
2017-05-31 23:19:07.114 [DEBUG] [org.openhab.binding.zwave ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.core.status.ConfigStatusProvider}={service.id=351, service.bundleid=38, service.scope=singleton} - org.openhab.binding.zwave
2017-05-31 23:19:07.123 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler.
2017-05-31 23:19:07.123 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Controller status changed to ONLINE.
2017-05-31 23:19:07.123 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Controller is ONLINE. Starting device initialisation.
2017-05-31 23:19:07.123 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Updating node properties.
2017-05-31 23:19:07.123 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Updating node properties. MAN=144
2017-05-31 23:19:07.124 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Updating node properties. MAN=144. SET. Was 144
2017-05-31 23:19:07.124 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Property to update: config_31_1_10000000, 1, 1
2017-05-31 23:19:07.124 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Property to update: config_40_1_wo, 0, 0
2017-05-31 23:19:07.124 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Property to update: config_31_1_01000000, 0, 0
2017-05-31 23:19:07.124 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Property to update: config_31_1_00100000, 1, 1
2017-05-31 23:19:07.124 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Initialising Thing Node...
2017-05-31 23:19:07.124 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Initialising channel zwave:device:15c47b89ff1:node9:lock_door
2017-05-31 23:19:07.124 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Initialising cmd channel zwave:device:15c47b89ff1:node9:lock_door
2017-05-31 23:19:07.124 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Initialising poll channel zwave:device:15c47b89ff1:node9:lock_door
2017-05-31 23:19:07.124 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Initialising state channel zwave:device:15c47b89ff1:node9:lock_door
2017-05-31 23:19:07.125 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Initialising channel zwave:device:15c47b89ff1:node9:battery-level
2017-05-31 23:19:07.126 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Initialising cmd channel zwave:device:15c47b89ff1:node9:battery-level
2017-05-31 23:19:07.126 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Initialising poll channel zwave:device:15c47b89ff1:node9:battery-level
2017-05-31 23:19:07.126 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Initialising state channel zwave:device:15c47b89ff1:node9:battery-level
2017-05-31 23:19:07.128 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Polling intialised at 1800 seconds - start in 1800000 milliseconds.
I must be missing something. Any ideas?
You need the Sec version (not snapshot) of the Z-Wave Binding.
Make sure that the snapshot is uninstalled first and then install the Sec version.
See this post: OH2 Z-Wave refactoring and testing... and SECURITY
What is displayed when you issue in the console the following:
openhab> list -s |grep Z
201 | Active | 80 | 2.1.0.201705282306 | ZWave Binding | org.openhab.binding.zwave
(this is the snapshot, not the sec version)
As @Dim says, you must use the version he said - the snapshot doesn’t have security. You also will need to set the security key to the same one that you used in OH1 (unless you exclude the device and add it again with OH2). This is set in the controller (enable advanced settings to see it).
I’m retrying using the zwave binding from the security forum link:
list -s | grep Z
38 | Active | 80 | 2.1.0.201705262331 | ZWave Binding | org.openhab.binding.zwave
I re-included the lock but security is still listed as “question mark” in the lock’s attributes tab (as before).
My log following inclusion is as follows:
2017-06-01 08:38:53.792 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler.
2017-06-01 08:38:53.793 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Controller status changed to ONLINE.
2017-06-01 08:38:53.794 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Controller is ONLINE. Starting device initialisation.
2017-06-01 08:38:53.795 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Updating node properties.
2017-06-01 08:38:53.795 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Updating node properties. MAN=144
2017-06-01 08:38:53.795 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Updating node properties. MAN=144. SET. Was 144
2017-06-01 08:38:53.795 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Property to update: config_31_1_10000000, 1, 1
2017-06-01 08:38:53.796 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Property to update: config_40_1_wo, 0, 0
2017-06-01 08:38:53.797 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Property to update: config_31_1_01000000, 0, 0
2017-06-01 08:38:53.797 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Property to update: config_31_1_00100000, 1, 1
2017-06-01 08:38:53.797 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Initialising Thing Node...
2017-06-01 08:38:53.797 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Initialising channel zwave:device:15c63a382fd:node10:lock_door
2017-06-01 08:38:53.807 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Initialising cmd channel zwave:device:15c63a382fd:node10:lock_door
2017-06-01 08:38:53.807 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Initialising poll channel zwave:device:15c63a382fd:node10:lock_door
2017-06-01 08:38:53.807 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Initialising state channel zwave:device:15c63a382fd:node10:lock_door
2017-06-01 08:38:53.807 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Initialising channel zwave:device:15c63a382fd:node10:battery-level
2017-06-01 08:38:53.808 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Initialising cmd channel zwave:device:15c63a382fd:node10:battery-level
2017-06-01 08:38:53.808 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Initialising poll channel zwave:device:15c63a382fd:node10:battery-level
2017-06-01 08:38:53.808 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Initialising state channel zwave:device:15c63a382fd:node10:battery-level
2017-06-01 08:38:53.808 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Polling intialised at 1800 seconds - start in 1800000 milliseconds.
2017-06-01 08:39:18.503 [DEBUG] [ve.internal.protocol.ZWaveController] - Stopping inclusion timer.
2017-06-01 08:39:18.503 [DEBUG] [ol.serialmessage.AddNodeMessageClass] - Ending INCLUSION mode.
2017-06-01 08:39:18.504 [DEBUG] [ve.internal.protocol.ZWaveController] - Message queued. Queue length = 1. Queue={}
2017-06-01 08:39:18.504 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
2017-06-01 08:39:18.504 [DEBUG] [ve.internal.protocol.ZWaveController] - ZWave controller end inclusion
2017-06-01 08:39:18.504 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 05 00 4A 05 01 B4
2017-06-01 08:39:18.504 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 255: Sending REQUEST Message = 01 05 00 4A 05 01 B4
2017-06-01 08:39:18.555 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 4A 01 06 0A 00 BF
2017-06-01 08:39:18.555 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2017-06-01 08:39:18.555 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 07 00 4A 01 06 0A 00 BF
2017-06-01 08:39:18.555 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 07 00 4A 01 06 0A 00 BF
2017-06-01 08:39:18.556 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=AddNodeToNetwork[0x4A], type=Request[0x00], priority=High, dest=255, callback=0, payload=01 06 0A 00
2017-06-01 08:39:18.556 [DEBUG] [ol.serialmessage.AddNodeMessageClass] - Add Node: Done.
2017-06-01 08:39:18.556 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveInclusionEvent
2017-06-01 08:39:18.556 [DEBUG] [wave.discovery.ZWaveDiscoveryService] - NODE 10: Device discovered
2017-06-01 08:39:18.556 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Got an event from Z-Wave network: ZWaveInclusionEvent
2017-06-01 08:39:18.556 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 10: Newly included node already initialising at SECURITY_REPORT
2017-06-01 08:39:18.556 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=AddNodeToNetwork[0x4A], type=Request[0x00], priority=High, dest=255, callback=0, payload=05 01
2017-06-01 08:39:18.557 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=AddNodeToNetwork[0x4A], type=Request[0x00], priority=High, dest=255, callback=0, payload=01 06 0A 00
2017-06-01 08:39:18.557 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=AddNodeToNetwork, callback id=0, expected=AddNodeToNetwork, cancelled=false transaction complete!
2017-06-01 08:39:18.557 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
2017-06-01 08:39:18.557 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 255: Response processed after 53ms/1288ms.
Perhaps the secure inclusion just takes a few hours? Is my binding version correct?
Also, my zsticks attributes have security listed as a “question mark.” Related?
Thanks again for the quick responses.
No - secure inclusion needs to be complete within around 25 second from memory.
This is normal. The stick doesn’t really have any attributes.
@chris it looks like the development jar I downloaded from the link above was built 5/26/17 but the description of the jar states it was built 5/21/17[quote=“Dim, post:2, topic:28941”]
he latest version of the test binding dated 21 May 2017 is here.
[/quote]
Could this be what is causing my secure inclusion issue?
Also, here is my log after removing the lock from the controller and then adding it back
Time Node Entry
23:08:01.080
TX REQ AddNodeToNetwork ADD_NODE_STOP
23:08:01.131 11
RX REQ AddNodeToNetwork ADD_NODE_STATUS_DONE NODE 11
23:08:01.139 11
Stage advanced to IDENTIFY_NODE
23:08:01.140 11
TX REQ IdentifyNode
23:08:01.141 11
Stage advanced to MANUFACTURER
23:08:01.144 11
TX REQ SendData 2 MANUFACTURER_SPECIFIC_GET ACK AUTO_ROUTE EXPLORE
23:08:01.144 11
RX RES IdentifyNode ROUTING_SLAVE SECURE_KEYPAD_DOOR_LOCK LISTENING FLIRS250 FLIRS1000 ROUTING BEAMING
23:08:06.145 11
Sending data abort
23:08:06.146
TX REQ SendDataAbort
23:08:06.146 11
Message retry (2 attempts remaining)
23:08:06.148 11
TX REQ SendData 3 MANUFACTURER_SPECIFIC_GET ACK AUTO_ROUTE EXPLORE
23:08:06.155 11
RX RES SendData 3 ACCEPTED BY CONTROLLER
23:08:06.173 11
RX REQ SendData 3 ACK RECEIVED from device in 25ms
23:08:06.184 11
RX REQ ApplicationCommandHandler MANUFACTURER_SPECIFIC_REPORT 0090:0001:0001
23:08:11.149 11
Sending data abort
23:08:11.151
TX REQ SendDataAbort
23:08:11.152 11
Message retry (1 attempts remaining)
23:08:11.155 11
TX REQ SendData 5 MANUFACTURER_SPECIFIC_GET ACK AUTO_ROUTE EXPLORE
23:08:11.163 11
RX RES SendData 5 ACCEPTED BY CONTROLLER
23:08:11.179 11
RX REQ SendData 5 ACK RECEIVED from device in 24ms
23:08:11.191 11
RX REQ ApplicationCommandHandler MANUFACTURER_SPECIFIC_REPORT 0090:0001:0001
23:08:11.194 11
Stage advanced to SECURITY_REPORT
23:08:11.198 11
TX REQ SendData 6 SECURITY_SCHEME_GET ACK AUTO_ROUTE EXPLORE
23:08:11.205 11
RX RES SendData 6 ACCEPTED BY CONTROLLER
23:08:11.222 11
RX REQ SendData 6 ACK RECEIVED from device in 24ms
23:08:11.233 11
RX REQ ApplicationCommandHandler SECURITY_SCHEME_REPORT SCHEME_0
23:08:11.238 11
TX REQ SendData 7 SECURITY_NONCE_GET ACK AUTO_ROUTE
23:08:11.245 11
RX RES SendData 7 ACCEPTED BY CONTROLLER
23:08:11.262 11
RX REQ SendData 7 ACK RECEIVED from device in 24ms
23:08:11.275 11
RX REQ ApplicationCommandHandler SECURITY_NONCE_REPORT NONCE ID 68
23:08:11.288 11
TX REQ SendData 8 SECURITY_ENCAP NONCE ID 68 ACK AUTO_ROUTE EXPLORE
23:08:11.298 11
RX RES SendData 8 ACCEPTED BY CONTROLLER
23:08:11.323 11
RX REQ SendData 8 ACK RECEIVED from device in 35ms
23:08:11.373 11
RX REQ ApplicationCommandHandler SECURITY_NONCE_GET
23:08:11.374 11
SECURE ERROR OR Device message contained nonce that is unknown to us, id=-96.
23:08:11.375 11
TX REQ SendData 9 SECURITY_NONCE_REPORT NONCE ID 160 ACK AUTO_ROUTE
23:08:11.383 11
RX RES SendData 9 ACCEPTED BY CONTROLLER
23:08:11.403 11
RX REQ SendData 9 ACK RECEIVED from device in 28ms
23:08:11.427 11
RX REQ ApplicationCommandHandler SECURITY_ENCAP NONCE ID 160
23:08:16.375 11
Message retry (2 attempts remaining)
23:08:16.377 11
TX REQ SendData 10 SECURITY_NONCE_REPORT NONCE ID 160 ACK AUTO_ROUTE
23:08:16.385 11
RX RES SendData 10 ACCEPTED BY CONTROLLER
23:08:17.686 11
RX REQ SendData 10 ACK RECEIVED from device in 1309ms
23:08:21.378 11
Message retry (1 attempts remaining)
23:08:21.381 11
TX REQ SendData 11 SECURITY_NONCE_REPORT NONCE ID 160 ACK AUTO_ROUTE
23:08:21.388 11
RX RES SendData 11 ACCEPTED BY CONTROLLER
23:08:22.707 11
RX REQ SendData 11 ACK RECEIVED from device in 1326ms
23:08:26.381 11
Message retry (0 attempts remaining)
23:08:26.384 11
TX REQ SendData 12 SECURITY_NONCE_REPORT NONCE ID 160 ACK AUTO_ROUTE
23:08:26.391 11
RX RES SendData 12 ACCEPTED BY CONTROLLER
23:08:27.657 11
RX REQ SendData 12 ACK RECEIVED from device in 1273ms
23:08:31.387
TX REQ AddNodeToNetwork ADD_NODE_STOP
23:08:31.438 11
RX REQ AddNodeToNetwork ADD_NODE_STATUS_DONE NODE 11
23:08:31.440 11
TX REQ SendData 5 MANUFACTURER_SPECIFIC_GET ACK AUTO_ROUTE EXPLORE
23:08:31.448 11
RX RES SendData 5 ACCEPTED BY CONTROLLER
23:08:32.725 11
RX REQ SendData 5 ACK RECEIVED from device in 1285ms
23:08:32.737 11
RX REQ ApplicationCommandHandler MANUFACTURER_SPECIFIC_REPORT 0090:0001:0001
23:08:50.830
TX REQ AddNodeToNetwork ADD_NODE_ANY HIGH POWER NWI
23:08:50.833
RX REQ AddNodeToNetwork ADD_NODE_STATUS_LEARN_READY
I’m not sure what “description” you mean?
No - any version in the past few months should be fine.
The log is very strange looking (and very short for that matter) - I guess you have deleted a LOT of information. I don’t see anything at all in here about security so unless you have removed this, something is fundamentally wrong I think.
Sorry, by description I mean the output of “list -s | grep Z” which shows the 2.1.0.201705262331 (I’m assuming a timestamp is represented by the rightmost characters). Regardless, the newer version should be working.
Sorry about the strange log. I pasted the raw log into the forum editor but it had too many characters. I then processed the log using your sites’ log viewer before pasting. I guess too much info was lost. Perhaps there’s a better way?
When I finally get this lock added a few beers needs to find their way to England
The JAR filename doesn’t have a date on it I think - just the word SNAPSHOT so if the jar is showing the 26th, then this sounds right. In any case, the only recent changes have been to the database files so I don’t think it will matter…
For security related logs, the best thing to do is to open a ticket on my website and I can take a look. You can attach large files there and that keeps any security related stuff out of public forums.
Cheers
Chris
Finally got things working. I built the latest development branch jar of the zwave binding and made sure the lock was not already paired w/ the z-stick controller (using zensys tool). I put the controller in inclusion mode using habmin and things just worked.
So it seems the Jar linked on chris’ security thread did not work for my setup. Of note, even the alarm channel shows up but produces a stack trace (could be a config issue).
My build info is as follows (using 1.7 as the testCompile target & source):
commit 8312317e3f847151c03499be9d4be2bab2cd7b8a
Author: Chris Jackson <chris@cd-jackson.com>
Date: Thu Jun 8 16:58:27 2017 +0100
Database update (#591)
I’m using a KwikSet 914rl
I have added the zwave binding jar to the addons folder
The base openhab install is 2.1.0-SNAPSHOT
Hope this helps someone else
Ellis
The version that you were previously using was not one downloaded from my site - it was a standard snapshot. Security doesn’t work with these snapshots, so this explains your problem.
The date on the file is not one that I have produced and your log file has entries like this -:
2017-06-03 06:28:08.581 [DEBUG] [curityCommandClassWithInitialization] - NODE 12: Security.initialize, just included, handing back message=[Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=12, callback=0, payload=0C 03 98 04 00 ]
These logs are from the current snapshot, and in fact this class doesn’t even exist in the development version…
So, I’m not sure what went wrong, but you were definately previously running the wrong version and it looks like you’ve now rectified things .
Chris
Thanks for your help. I have everything working. For some reason whenever I downloaded the jar from the security thread I ended up with the non-development branch’s snapshot build. I finally just downloaded your development branch from git and built the jar. I had to do some pom edits and disable testing but the development jar, once built, worked as you specified. Thanks for your help.
Ellis
See build error thread for more info on how I resolved things.