[SOLVED] Openhab2 Configuration of Aeon Zstick Gen5 USB Controller (ZW090)

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.

1 Like

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

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

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.