Everything on my side works great. I can get both the alarm codes and the alarm level from the json.
Thanks!!! More beer money on it’s way soon.
Great stuff - I’m glad it’s working 
.
Maybe it’s a timing issue if there’s a lot going on - I’m not sure from this though. Nonces are only valid for a few seconds after which they are invalid and can’t be used.
My old Vera went out in the mail yesterday to a new owner 
1 Like
Maybe it was intentional, but it looks like there is an extra underscore in the notification value. I got the lock to report jammed by only partially locking it. And I don’t recall ever getting a Forced Entry alarm to show up (pounded on the door)! But it also then set alarm_number to 2, which I had been using as an unlock. Hmmm… time for a rewrite.
NODE 183: Updating channel state zwave:device:07cb40a2:node183:alarm_raw to {"notification":"ACCESS__MANUAL_LOCK","type":"ACCESS_CONTROL","event":"1","status":"255"} [StringType]
NODE 183: Updating channel state zwave:device:07cb40a2:node183:alarm_raw to {"notification":"ACCESS__MANUAL_UNLOCK","type":"ACCESS_CONTROL","event":"2","status":"255"} [StringType]
NODE 183: Updating channel state zwave:device:07cb40a2:node183:alarm_raw to {"notification":"ACCESS__KEYPAD_LOCK","code":"1","type":"ACCESS_CONTROL","event":"5","status":"255"} [StringType]
NODE 183: Updating channel state zwave:device:07cb40a2:node183:alarm_raw to {"notification":"ACCESS__KEYPAD_UNLOCK","code":"1","type":"ACCESS_CONTROL","event":"6","status":"255"} [StringType]
NODE 183: Updating channel state zwave:device:07cb40a2:node183:alarm_raw to {"notification":"ACCESS__LOCK_JAMMED","type":"ACCESS_CONTROL","event":"11","status":"255"} [StringType]
NODE 183: Updating channel state zwave:device:07cb40a2:node183:alarm_raw to {"notification":"ACCESS__KEYPAD_LOCK","type":"ACCESS_CONTROL","event":"5","status":"255"} [StringType]
NODE 183: Updating channel state zwave:device:07cb40a2:node183:alarm_raw to {"notification":"BURGLAR__TAMPER_UNKNOWN","type":"BURGLAR","event":"2","status":"255"} [StringType]I don’t think it is a problem with your code. I have had this same issue for a while: Schlage BE469 - Zwave binding with security - missing features you even replied
Yes - this was the intention. It breaks up the notification and the event (ie notification type is ACCESS, and the event is MANUAL_LOCK).
It is true that this makes is slightly different than the type in the “type” field which is a bit annoying and I might revisit this. When I defined these event types a few months back I wanted to avoid making them reeeaaaalllyyyy long so truncated things like ACCESS_CONTROL down to ACCESS
Just to be clear - I guess that this is just how the lock works right?
I keep seeing a number of these exceptions running snapshot #1025 and version 2.1.0.201708272249 of your new binding. Causing message is quoted at the top of the log.
network_xxxxxxxx__node_42.xml (2.4 KB)
jsondb-excerpt-node42.xml (5.7 KB, not really XML but the node 42 definition in jsondb)
2017-08-30 17:52:11.266 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0D 00 04 00 2A 07 56 01 30 03 FF D1 CB 5A
2017-08-30 17:52:11.272 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
2017-08-30 17:52:11.278 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=42, callback=0, payload=00 2A 07 56 01 30 03 FF D1 CB
2017-08-30 17:52:11.282 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=42, callback=0, payload=00 2A 07 56 01 30 03 FF D1 CB
2017-08-30 17:52:11.287 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=42, callback=0, payload=00 2A 07 56 01 30 03 FF D1 CB
2017-08-30 17:52:11.289 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2017-08-30 17:52:11.291 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 42: Application Command Request (ALIVE:REQUEST_NIF)
2017-08-30 17:52:11.293 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 42: Decapsulating COMMAND_CLASS_CRC_16_ENCAP
2017-08-30 17:52:11.295 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 42: COMMAND_CLASS_CRC_16_ENCAP not found
2017-08-30 17:52:11.297 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2017-08-30 17:52:11.299 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start
2017-08-30 17:52:11.300 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 49: listening == false, frequentlyListening == false, awake == false
2017-08-30 17:52:11.302 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 49: Node not awake!
2017-08-30 17:52:11.304 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 90: listening == false, frequentlyListening == false, awake == false
2017-08-30 17:52:11.305 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 90: Node not awake!
2017-08-30 17:52:11.307 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 42: listening == false, frequentlyListening == false, awake == false
2017-08-30 17:52:11.309 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 42: Node not awake!
2017-08-30 17:52:11.310 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction from controllerQueue
2017-08-30 17:52:11.312 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage nothing
2017-08-30 17:52:11.352 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 2A 03 60 0D 01 B7
2017-08-30 17:52:11.383 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
2017-08-30 17:52:11.386 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=42, callback=0, payload=00 2A 03 60 0D 01
2017-08-30 17:52:11.389 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=42, callback=0, payload=00 2A 03 60 0D 01
2017-08-30 17:52:11.392 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=42, callback=0, payload=00 2A 03 60 0D 01
2017-08-30 17:52:11.394 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2017-08-30 17:52:11.395 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 42: Application Command Request (ALIVE:REQUEST_NIF)
2017-08-30 17:52:11.397 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 42: Decapsulating COMMAND_CLASS_MULTI_CHANNEL
2017-08-30 17:52:11.400 [ERROR] [nal.protocol.ZWaveTransactionManager] - Exception processing frame: Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], dest=42, callback=0, payload=00 2A 03 60 0D 01
2017-08-30 17:52:11.401 [ERROR] [nal.protocol.ZWaveTransactionManager] - Exception processing frame:
java.lang.ArrayIndexOutOfBoundsException: 3
at org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload.getPayloadByte(ZWaveCommandClassPayload.java:49) [208:org.openhab.binding.zwave:2.1.0.201708272249]
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveMultiInstanceCommandClass.getSourceEndpoint(ZWaveMultiInstanceCommandClass.java:381) [208:org.openhab.binding.zwave:2.1.0.201708272249]
at org.openhab.binding.zwave.internal.protocol.ZWaveNode.processCommand(ZWaveNode.java:1207) [208:org.openhab.binding.zwave:2.1.0.201708272249]
at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager$ZWaveReceiveThread.run(ZWaveTransactionManager.java:421) [208:org.openhab.binding.zwave:2.1.0.201708272249]
This is a corrupt frame coming from node 42. The error is simply saying it’s a corrupt frame with no data received. I ca change the error, but it will still be corrupt unfortunately.
Ok, thanks … now since it’s a pretty standard node (Fibaro FGMS) that has been working well for a long time (IIRC, it’s producing errors with the standard binding, too, but the message is different) , and short of the possibility to obtain a firmware update, is there anything I can do except to ignore it ? Does the message give you a hint w.r.t. an invalid parameter setting or some such ?
Yes - the different bindings can log different errors - they are quite different.
The only thing I can think of is to reset it. First I would try removing the power (battery) and see if that helps. If not, you might need to exclude it.
No - it’s a multichannel encapsulation message with no data inside
The above part of the message is -:
60 = multichannel command class
0D = encapsulation
01 = source endpoint
This should be followed by the destination endpoint, and the actual encapsulated data.
That is my guess based on the fact that myself and @5iver are seeing the same thing. Seems pretty silly to me but I was not intending to infer this is a problem with your binding @chris
Thanks, and no problem - I just wanted to be sure 
.
I had replied to your post, but still had not yet played with the alarms from the lock 
, or I may have spotted this sooner. With my previous rules, when the Forced Entry alarm went off, the door would unlock! I need to check on the other alarms yet, but my rules are now changed to use alarm_raw instead of alarm_number. The core of the issue for my rules was that alarm_number and notification_access_control display the number for any type of alarm, not just ACCESS_CONTROL. So, this is probably something that should be changed in the binding.
Why? The purpose of the alarm_raw was to provide raw alarm information. Are you now suggesting to reduce this to only access_control? Why not just filter this in your rule - you have all the information you need - right?
I must have not been clear in my explanation. I’m quite happy using alarm_raw as is! TY! I suggest a change to alarm_number and notification_access_control for those NOT using alarm_raw, and interpreting alarm_number=2 as a manual lock when it was actually a burglar, as I had been.
Ok, sorry, I thought you meant a change to alarm_raw…
So are you suggesting then to redefine some of the values? ie you want value 2 to be a different value? If so, I don’t really want to do this if it’s device specific unless we can find a generic way to define it and then add it to the database. I really want to avoid device specific kludges in the binding if possible.
I’ll add in that I know different locks will provide different numbers it seems for different functions. So I’d vote on not adjusting because as a number, we can define it ourselves. If we try and make specifics for each device, universal use becomes much more difficult and more work in the DB just to make different locks work. Also, if something was to miraculously change (don’t think it would) - but imagine a firmware update changes the numbers by adding a new number in, bumping the others - you could end up with problems due to the difference in firmwares as well. Another layer of complexity.
This in theory should only be true for V1. For V2 and above, the definitions of the functions are defined in the standard and the locks should follow this if they are compliant to Z-Wave standards.