No - the protocol only allows nodes to be securely included within around 15 seconds of its initial inclusion into the network - there’s no way around this.
It needs to be a 16 byte hex number, but formatting is reasonably flexible -:
0123ABCD…
0x12 0x34 0xAB 0xCD
12 34 AB CD
12,34,AB,CD
0x12,0x34,0xab,0xcd
Basically hex values, prepended with 0x if you like, and separated with commas or spaces or nothing - all should work as entry.
Sounds like it’s ok - but in any case I doubt this will stop things working. Probably if the key is invalid, the system would choose its own (I’m not 100% sure about this though).
Managed to add my lock and did two changes that could have had impact.
Didn’t put my own network security key but had the binding do it for me
Didn’t include the lock by removing my usb controller and stand next to the lock but do it when the controller was in the server, in contact with OH2. (Had to try many times since the server and the lock are not super close)
I however still have a lot of exception about the cast error.
Managed to capture one in debug (it started with the latest binding)
2017-02-19 20:52:05.806 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Start transaction timer to Sun Feb 19 20:52:09 CET 2017 - 3672ms
2017-02-19 20:52:07.570 [DEBUG] [org.openhab.binding.zwave ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.core.status.ConfigStatusProvider}={service.id=326, service.bundleid=9, service.scope=singleton} - org.openhab.binding.zwave
2017-02-19 20:52:07.594 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Initializing ZWave thing handler zwave:device:15a52609621:node22.
2017-02-19 20:52:07.598 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occured while initializing handler of thing 'zwave:device:15a52609621:node22': java.lang.ClassCastException: java.lang.String cannot be cast to java.math.BigDecimal
java.util.concurrent.ExecutionException: java.lang.ClassCastException: java.lang.String cannot be cast to java.math.BigDecimal
at java.util.concurrent.FutureTask.report(FutureTask.java:122)[:1.8.0_121]
at java.util.concurrent.FutureTask.get(FutureTask.java:206)[:1.8.0_121]
at org.eclipse.smarthome.core.common.SafeMethodCaller.callAsynchronous(SafeMethodCaller.java:194)[99:org.eclipse.smarthome.core:0.9.0.201702100936]
at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:83)[99:org.eclipse.smarthome.core:0.9.0.201702100936]
at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:67)[99:org.eclipse.smarthome.core:0.9.0.201702100936]
at org.eclipse.smarthome.core.thing.internal.ThingManager$9.run(ThingManager.java:698)[106:org.eclipse.smarthome.core.thing:0.9.0.201702100936]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_121]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_121]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_121]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_121]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]
Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.math.BigDecimal
at org.openhab.binding.zwave.handler.ZWaveThingHandler.initialize(ZWaveThingHandler.java:123)[9:org.openhab.binding.zwave:2.1.0.201702181307]
at org.eclipse.smarthome.core.thing.internal.ThingManager$9$1.call(ThingManager.java:701)[106:org.eclipse.smarthome.core.thing:0.9.0.201702100936]
at org.eclipse.smarthome.core.thing.internal.ThingManager$9$1.call(ThingManager.java:1)[106:org.eclipse.smarthome.core.thing:0.9.0.201702100936]
at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:181)[99:org.eclipse.smarthome.core:0.9.0.201702100936]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_121]
... 3 more
2017-02-19 20:52:08.156 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 61 01 01 71 FB
2017-02-19 20:52:08.158 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
2017-02-19 20:52:08.158 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage inputMessage: class=SendData[0x13], type=Request[0x00], dest=1, callback=97, payload=61 01 01 71
2017-02-19 20:52:08.158 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lockMessage: class=SendData[0x13], type=Request[0x00], dest=1, callback=97, payload=61 01 01 71
2017-02-19 20:52:08.159 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg Message: class=SendData[0x13], type=Request[0x00], dest=1, callback=97, payload=61 01 01 71
2017-02-19 20:52:08.159 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID:190 [WAIT_REQUEST] callback: 97
2017-02-19 20:52:08.159 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2017-02-19 20:52:08.159 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID:190 [WAIT_REQUEST] callback: 97
2017-02-19 20:52:08.159 [DEBUG] [nal.protocol.ZWaveTransactionManager] - checking transaction 97 (Callback 97) ......
2017-02-19 20:52:08.159 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Callback match!
2017-02-19 20:52:08.159 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Correlated to transaction 97......
2017-02-19 20:52:08.159 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[0x13], type=Request[0x00], dest=1, callback=97, payload=61 01 01 71
2017-02-19 20:52:08.159 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 22: SendData Request. CallBack ID = 97, Status = Transmission complete, no ACK received(1)
2017-02-19 20:52:08.159 [DEBUG] [e.internal.protocol.ZWaveTransaction] - Transaction 190 CANCELLED
2017-02-19 20:52:08.159 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TransactionAdvance ST: CANCELLED
2017-02-19 20:52:08.159 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TransactionAdvance TX: null
2017-02-19 20:52:08.159 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TransactionAdvance WT: ApplicationCommandHandler
2017-02-19 20:52:08.159 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TransactionAdvance RX: Message: class=SendData[0x13], type=Request[0x00], dest=1, callback=97, payload=61 01 01 71
2017-02-19 20:52:08.159 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TransactionAdvance TO: CANCELLED
2017-02-19 20:52:08.159 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
2017-02-19 20:52:08.159 [DEBUG] [e.internal.protocol.ZWaveTransaction] - >>>>> transaction payload is the same [[114, 4]] == [[114, 4]]
2017-02-19 20:52:08.159 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 22: **** Transaction completed
2017-02-19 20:52:08.160 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 22: notifyTransactionResponse 190
“Using security” with a green check but no response when I try to control the lock.
Also a huge delay when I try to control my zwave dimmers.
A restart of openhab later the “Using security” has a red cross.
No exception though.
Chris I must thank you for all your hard work on this binding. I finally got my Weiser (Kwickset) lock to work with openHAB2. Habmin was able to exclude and include it to get the security working. It took many tries but it worked eventually.
I had repaired tonight and was able to get it securely paired. Not sure what was going on before. My jar is on the next to latest version. Now to figure out what the Barrier Command class offers me as far as control.
I’m not aware which issue you mean? I don’t think it would only be an issue with this binding (ie it would also highly likely be an issue with the OH2 main branch) since there should be no difference in that respect - reports from devices should always be processed.
Can you describe the issue or provide a reference to a previous discussion?
I saw the issue of updates not occurring with physical switches as well until I removed all of the unknown item links I found in my logs and updated to the most recent version. The error I saw in my openhab log was:
Cannot delegate update ‘0’ for item ‘FireplaceDimmer_Dimmer’ to handler for channel ‘zwave:device:83c23437:node13:switch_dimmer’, because no thing with the UID ‘zwave:device:83c23437:node13’ could be found.
The command I used to remove them from console was:
smarthome:links removeChannelLink ‘item name’ 'channel name’
ex:
smarthome:links removeChannelLink ‘FireplaceDimmer_Dimmer’ ‘zwave:device:83c23437:node13:switch_dimmer’
This may have occurred because I deleted all my things and links from the paperUI prior to updating to the new plugin.
That’s not an error. This simply means that there is no item linked to the channel. So, it means that the binding has updated the channel ok, but there is no item linked to it, so you won’t see any change in your UI.
This isn’t a problem with the binding - it’s just your item configuration.
I agree this was not a problem with the binding. I think deleting the links from the paperUI did not completely delete the channel links. I had to go back and delete them from console. I will add that I was not getting updates from switch presses until I removed them.
I installed the binding from the link near the start of this thread. After multiple tries I was able to get my Schlage lock included and it appears to be secure as indicated by a green check in habmin’s “Using Security” field.
The one problem I have left is that the device does not appear to be fully discovered. Since this is a battery device, do I need to wait for some time for it to wake up and finish whatever exchanges it needs to do to populate these device properties and make the device usable?
I do have a debug-enabled log if that becomes necessary. I am not sure what the preferred method to send it is, though.
Most locks aren’t considered battery devices as they use FLIRS and I’d be a bit surprised if this doesn’t use FLIRS? In this case, it shouldn’t need to be woken up.
Feel free to email me the debug log - chris -at- cd-jackson.com and I’ll take a look in the coming days.
@chris - my BE469 has functional communication, but it seems some of the EXTRA functions are not working properly. Specifically, I tried using this to add security codes to the lock, but it’s not taking them. I’ve also tried to just let it sit for a bit in case it took some time between wakes to send across, but it’s not happening. Is this known? Or should I get some debug logs going again?
I know still low on the never ending list of requests. But wanted to confirm still need the Alarm Type Channel for the locks? And then with that channel we should be able monitor the Alarm Type to sync and update the lock status in a sitemap, etc?
and did two changes that could have had impact.
“Using security” with a green check but no response when I try to control the lock.