ZWAVE - Monoprice/Vision ZP3102us-5

[imacdonald312 (Ian Macdonald)]

Have some of kfr-ZP3102us-5 from monopice

ZP-3102-5-PIR-R3-500-Series-20150724.pdf

Looks like the definition is off. https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/437

FIRMWARE_UPDATE_MD should be V2
MANUFACTURER_SPECIFIC should be V2
ZWAVE_PLUS_INFO should be V2

properties

dbReference	437
defaultAssociations	1
manufacturerId	0109
manufacturerRef	2002:0205
modelId	ZP3102
vendor	Vision Security
versionMin	8.0
zwave_beaming	true
zwave_class_basic	BASIC_TYPE_ROUTING_SLAVE
zwave_class_generic	GENERIC_TYPE_SENSOR_NOTIFICATION
zwave_class_specific	SPECIFIC_TYPE_NOTIFICATION_SENSOR
zwave_deviceid	517
zwave_devicetype	8194
zwave_frequent	false
zwave_lastheal	2019-01-01T08:31:00Z
zwave_lastwakeup	2019-01-02T03:13:30Z
zwave_listening	false
zwave_manufacturer	265
zwave_neighbours	3,4,5,6,7,8,10,16,17,18,19,20
zwave_nodeid	13
zwave_plus_devicetype	NODE_TYPE_ZWAVEPLUS_NODE
zwave_plus_roletype	ROLE_TYPE_SLAVE_SLEEPING_REPORTING
zwave_routing	true
zwave_secure	false
zwave_version	8.2

Tamper, looks like ALARM, TAMPER, BURGLAR

2019-01-01 22:26:47.757 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 11 00 04 00 0D 0B 71 05 07 FF 00 FF 07 03 01 03 00 99
2019-01-01 22:26:47.758 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=0, payload=00 0D 0B 71 05 07 FF 00 FF 07 03 01 03 00
2019-01-01 22:26:47.758 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=0, payload=00 0D 0B 71 05 07 FF 00 FF 07 03 01 03 00
2019-01-01 22:26:47.758 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2019-01-01 22:26:47.758 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Application Command Request (ALIVE:REQUEST_NIF)
2019-01-01 22:26:47.758 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2019-01-01 22:26:47.758 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: SECURITY not supported
2019-01-01 22:26:47.758 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Received COMMAND_CLASS_ALARM V0 NOTIFICATION_REPORT
2019-01-01 22:26:47.758 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 13: NOTIFICATION report - 7 = 255, event=3, status=255, plen=1
2019-01-01 22:26:47.758 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 13: Alarm Type = BURGLAR (7)
2019-01-01 22:26:47.758 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2019-01-01 22:26:47.758 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2019-01-01 22:26:47.759 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 13: Alarm converter processing NOTIFICATION
2019-01-01 22:26:47.759 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 13: Alarm converter NOTIFICATION event is 3, type OnOffType
2019-01-01 22:26:47.759 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Commands processed 1.
2019-01-01 22:26:47.759 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@67cdf56.
2019-01-01 22:26:47.759 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-01-01 22:26:47.759 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-01-01 22:26:47.759 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-01-01 22:26:47.759 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2019-01-01 22:26:51.873 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 15 00 04 00 10 0F 32 02 21 44 00 00 02 BB 00 3C 00 00 02 BB 00 98
2019-01-01 22:26:51.874 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], 
2019-01-01 22:26:52.029 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 15 00 04 00 10 0F 32 02 21 4C 00 00 02 C2 00 3C 00 00 02 C2 00 90
2019-01-01 22:26:57.455 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 11 00 04 00 0D 0B 71 05 07 00 00 FF 07 00 01 03 00 65
2019-01-01 22:26:57.456 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=0, payload=00 0D 0B 71 05 07 00 00 FF 07 00 01 03 00
2019-01-01 22:26:57.456 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=0, payload=00 0D 0B 71 05 07 00 00 FF 07 00 01 03 00
2019-01-01 22:26:57.456 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2019-01-01 22:26:57.456 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Application Command Request (ALIVE:REQUEST_NIF)
2019-01-01 22:26:57.456 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2019-01-01 22:26:57.456 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: SECURITY not supported
2019-01-01 22:26:57.456 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Received COMMAND_CLASS_ALARM V0 NOTIFICATION_REPORT
2019-01-01 22:26:57.456 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 13: NOTIFICATION report - 7 = 0, event=0, status=255, plen=1
2019-01-01 22:26:57.456 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 13: Alarm Type = BURGLAR (7)
2019-01-01 22:26:57.457 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2019-01-01 22:26:57.457 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2019-01-01 22:26:57.457 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 13: Alarm converter processing NOTIFICATION
2019-01-01 22:26:57.457 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 13: Alarm converter NOTIFICATION event is 0, type OnOffType
2019-01-01 22:26:57.457 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Updating channel state zwave:device:9d6ae427:node13:alarm_burglar to OFF [OnOffType]
2019-01-01 22:26:57.457 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Commands processed 1.
2019-01-01 22:26:57.457 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@66391fbc.
2019-01-01 22:26:57.457 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-01-01 22:26:57.457 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-01-01 22:26:57.457 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-01-01 22:26:57.458 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2019-01-01 22:27:01.942 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 08 00 04 00 02 02 84 07 70
2019-01-01 22:27:01.942 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=2, callback=0, payload=00 02 02 84 07
2019-01-01 22:27:01.943 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=2, callback=0, payload=00 02 02 84 07
2019-01-01 22:27:01.943 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2019-01-01 22:27:01.943 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 2: Application Command Request (ALIVE:DONE)
2019-01-01 22:27:01.943 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: resetResendCount initComplete=true isDead=false
2019-01-01 22:27:01.943 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Is awake with 0 messages in the queue
2019-01-01 22:27:01.943 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Start sleep timer at 1000ms
2019-01-01 22:27:01.943 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveNodeStatusEvent
2019-01-01 22:27:01.944 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 2: Node Status event - Node is AWAKE
2019-01-01 22:27:01.944 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 2: Commands processed 1.
2019-01-01 22:27:01.944 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 2: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@6dfea42.
2019-01-01 22:27:01.944 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-01-01 22:27:01.944 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-01-01 22:27:01.944 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-01-01 22:27:01.944 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2019-01-01 22:27:02.443 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: WakeupTimerTask 0 Messages waiting, state DONE
2019-01-01 22:27:02.451 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 11 00 04 00 0D 0B 71 05 07 FF 00 FF 07 03 01 03 00 99
2019-01-01 22:27:02.452 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=0, payload=00 0D 0B 71 05 07 FF 00 FF 07 03 01 03 00
2019-01-01 22:27:02.452 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=0, payload=00 0D 0B 71 05 07 FF 00 FF 07 03 01 03 00
2019-01-01 22:27:02.452 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2019-01-01 22:27:02.452 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Application Command Request (ALIVE:REQUEST_NIF)
2019-01-01 22:27:02.452 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2019-01-01 22:27:02.452 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: SECURITY not supported
2019-01-01 22:27:02.452 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Received COMMAND_CLASS_ALARM V0 NOTIFICATION_REPORT
2019-01-01 22:27:02.452 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 13: NOTIFICATION report - 7 = 255, event=3, status=255, plen=1
2019-01-01 22:27:02.452 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 13: Alarm Type = BURGLAR (7)
2019-01-01 22:27:02.452 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2019-01-01 22:27:02.453 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2019-01-01 22:27:02.453 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 13: Alarm converter processing NOTIFICATION
2019-01-01 22:27:02.453 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 13: Alarm converter NOTIFICATION event is 3, type OnOffType
2019-01-01 22:27:02.453 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Commands processed 1.
2019-01-01 22:27:02.453 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1328b785.
2019-01-01 22:27:02.453 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-01-01 22:27:02.453 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-01-01 22:27:02.453 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-01-01 22:27:02.453 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2019-01-01 22:27:02.943 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: WakeupTimerTask 0 Messages waiting, state DONE
2019-01-01 22:27:02.943 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: No more messages, go back to sleep
2019-01-01 22:27:02.943 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 2: Creating new message for application command WAKE_UP_NO_MORE_INFORMATION
2019-01-01 22:27:02.943 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: SECURITY not supported
2019-01-01 22:27:02.943 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Command Class COMMAND_CLASS_WAKE_UP is NOT required to be secured
2019-01-01 22:27:02.943 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 2: sendTransaction org.openhab.binding.zwave.internal.protocol.transaction.ZWaveCommandClassTransactionPayload@7d24231f
2019-01-01 22:27:02.943 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 2: Bump transaction 348 priority from Immediate to Immediate
2019-01-01 22:27:02.944 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 2: Adding to device queue
2019-01-01 22:27:02.944 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 2: Added 348 to queue - size 6
2019-01-01 22:27:02.944 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2019-01-01 22:27:02.944 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 02 02 84 08 25 AE E2
2019-01-01 22:27:02.944 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 2: Sending REQUEST Message = 01 09 00 13 02 02 84 08 25 AE E2
2019-01-01 22:27:02.944 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2019-01-01 22:27:02.944 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 348: [WAIT_RESPONSE] priority=Immediate, requiresResponse=true, callback: 174
2019-01-01 22:27:02.946 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2019-01-01 22:27:02.946 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2019-01-01 22:27:02.946 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2019-01-01 22:27:02.946 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 348: [WAIT_RESPONSE] priority=Immediate, requiresResponse=true, callback: 174
2019-01-01 22:27:02.947 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg: ACK
2019-01-01 22:27:02.947 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-01-01 22:27:02.947 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2019-01-01 22:27:02.949 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
2019-01-01 22:27:02.949 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2019-01-01 22:27:02.949 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2019-01-01 22:27:02.949 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 348: [WAIT_RESPONSE] priority=Immediate, requiresResponse=true, callback: 174
2019-01-01 22:27:02.950 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2019-01-01 22:27:02.950 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 348: [WAIT_RESPONSE] priority=Immediate, requiresResponse=true, callback: 174
2019-01-01 22:27:02.950 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2019-01-01 22:27:02.950 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 2: sentData successfully placed on stack.
2019-01-01 22:27:02.950 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 348: Advanced to WAIT_REQUEST
2019-01-01 22:27:02.950 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 2: TID 348: Transaction not completed
2019-01-01 22:27:02.950 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-01-01 22:27:02.950 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2019-01-01 22:27:02.961 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 05 00 13 AE 00 47
2019-01-01 22:27:02.961 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Request[0], dest=0, callback=174, payload=AE 00
2019-01-01 22:27:02.961 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Request[0], dest=0, callback=174, payload=AE 00
2019-01-01 22:27:02.961 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 348: [WAIT_REQUEST] priority=Immediate, requiresResponse=true, callback: 174
2019-01-01 22:27:02.962 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2019-01-01 22:27:02.962 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 348: [WAIT_REQUEST] priority=Immediate, requiresResponse=true, callback: 174
2019-01-01 22:27:02.962 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking TID 348: (Callback 174)
2019-01-01 22:27:02.962 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Callback match!
2019-01-01 22:27:02.962 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Correlated to TID 348: callback 174
2019-01-01 22:27:02.962 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Request[0], dest=0, callback=174, payload=AE 00
2019-01-01 22:27:02.962 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 2: SendData Request. CallBack ID = 174, Status = Transmission complete and ACK received(0)
2019-01-01 22:27:02.962 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: resetResendCount initComplete=true isDead=false
2019-01-01 22:27:02.962 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 348: Transaction COMPLETED
2019-01-01 22:27:02.962 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 2: Response processed after 18ms
2019-01-01 22:27:02.962 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 2: TID 348: Transaction completed
2019-01-01 22:27:02.962 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 2: notifyTransactionResponse TID:348 DONE
2019-01-01 22:27:02.963 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2019-01-01 22:27:02.963 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 348: Transaction event listener: DONE: DONE ->
2019-01-01 22:27:02.963 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-01-01 22:27:02.963 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2019-01-01 22:27:02.963 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 2: Went to sleep COMPLETE
2019-01-01 22:27:06.376 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 11 00 04 00 0D 0B 71 05 07 00 00 FF 07 00 01 03 00 65
2019-01-01 22:27:06.377 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=0, payload=00 0D 0B 71 05 07 00 00 FF 07 00 01 03 00
2019-01-01 22:27:06.377 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=0, payload=00 0D 0B 71 05 07 00 00 FF 07 00 01 03 00
2019-01-01 22:27:06.377 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2019-01-01 22:27:06.377 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Application Command Request (ALIVE:REQUEST_NIF)
2019-01-01 22:27:06.377 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2019-01-01 22:27:06.377 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: SECURITY not supported
2019-01-01 22:27:06.377 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Received COMMAND_CLASS_ALARM V0 NOTIFICATION_REPORT
2019-01-01 22:27:06.377 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 13: NOTIFICATION report - 7 = 0, event=0, status=255, plen=1
2019-01-01 22:27:06.377 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 13: Alarm Type = BURGLAR (7)
2019-01-01 22:27:06.378 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2019-01-01 22:27:06.378 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2019-01-01 22:27:06.378 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 13: Alarm converter processing NOTIFICATION
2019-01-01 22:27:06.378 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 13: Alarm converter NOTIFICATION event is 0, type OnOffType
2019-01-01 22:27:06.378 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Updating channel state zwave:device:9d6ae427:node13:alarm_burglar to OFF [OnOffType]
2019-01-01 22:27:06.378 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Commands processed 1.
2019-01-01 22:27:06.378 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@4e3755d.
2019-01-01 22:27:06.378 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-01-01 22:27:06.378 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-01-01 22:27:06.378 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-01-01 22:27:06.379 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

Motion Node 18 ALARM, MOTION_UNKNOWN, BURGLAR

2019-01-01 22:27:20.524 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 0D 03 20 01 FF 22
2019-01-01 22:27:20.525 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=0, payload=00 0D 03 20 01 FF
2019-01-01 22:27:20.525 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=0, payload=00 0D 03 20 01 FF
2019-01-01 22:27:20.525 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2019-01-01 22:27:20.525 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Application Command Request (ALIVE:REQUEST_NIF)
2019-01-01 22:27:20.525 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Incoming command class COMMAND_CLASS_BASIC, endpoint 0
2019-01-01 22:27:20.525 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: SECURITY not supported
2019-01-01 22:27:20.525 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Received COMMAND_CLASS_BASIC V0 BASIC_SET
2019-01-01 22:27:20.525 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 13: Basic report, value = 255
2019-01-01 22:27:20.525 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2019-01-01 22:27:20.525 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_BASIC, value = 255
2019-01-01 22:27:20.526 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Updating channel state zwave:device:9d6ae427:node13:sensor_binary to ON [OnOffType]
2019-01-01 22:27:20.526 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Commands processed 1.
2019-01-01 22:27:20.526 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@2a094e82.
2019-01-01 22:27:20.526 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-01-01 22:27:20.526 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-01-01 22:27:20.526 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-01-01 22:27:20.526 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2019-01-01 22:27:20.526 [INFO ] [.eclipse.smarthome.model.script.TEST] - Setting Basement on
2019-01-01 22:27:20.527 [INFO ] [.eclipse.smarthome.model.script.TEST] - timer: 0
2019-01-01 22:27:20.527 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Command received zwave:device:9d6ae427:node8:switch_binary --> ON [OnOffType]
2019-01-01 22:27:20.527 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 8: Creating new message for application command SWITCH_BINARY_SET
2019-01-01 22:27:20.527 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 8: SECURITY not supported
2019-01-01 22:27:20.527 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 8: Command Class COMMAND_CLASS_SWITCH_BINARY is NOT required to be secured
2019-01-01 22:27:20.527 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 8: Adding to device queue
2019-01-01 22:27:20.527 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 8: Added 349 to queue - size 6
2019-01-01 22:27:20.527 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2019-01-01 22:27:20.527 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0A 00 13 08 03 25 01 FF 25 AF BC
2019-01-01 22:27:20.528 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 8: Sending REQUEST Message = 01 0A 00 13 08 03 25 01 FF 25 AF BC
2019-01-01 22:27:20.528 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2019-01-01 22:27:20.528 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 349: [WAIT_RESPONSE] priority=Set, requiresResponse=true, callback: 175
2019-01-01 22:27:20.528 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Polling intialised at 86400 seconds - start in 1500 milliseconds.
2019-01-01 22:27:20.530 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2019-01-01 22:27:20.530 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2019-01-01 22:27:20.530 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2019-01-01 22:27:20.530 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 349: [WAIT_RESPONSE] priority=Set, requiresResponse=true, callback: 175
2019-01-01 22:27:20.531 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg: ACK
2019-01-01 22:27:20.531 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-01-01 22:27:20.531 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2019-01-01 22:27:20.532 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
2019-01-01 22:27:20.532 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2019-01-01 22:27:20.532 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2019-01-01 22:27:20.533 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 349: [WAIT_RESPONSE] priority=Set, requiresResponse=true, callback: 175
2019-01-01 22:27:20.533 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2019-01-01 22:27:20.533 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 349: [WAIT_RESPONSE] priority=Set, requiresResponse=true, callback: 175
2019-01-01 22:27:20.533 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2019-01-01 22:27:20.533 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 8: sentData successfully placed on stack.
2019-01-01 22:27:20.533 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 349: Advanced to WAIT_REQUEST
2019-01-01 22:27:20.533 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 8: TID 349: Transaction not completed
2019-01-01 22:27:20.533 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-01-01 22:27:20.533 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2019-01-01 22:27:20.749 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 11 00 04 00 0D 0B 71 05 07 FF 00 FF 07 08 01 08 00 99
2019-01-01 22:27:20.750 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=0, payload=00 0D 0B 71 05 07 FF 00 FF 07 08 01 08 00
2019-01-01 22:27:20.750 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=0, payload=00 0D 0B 71 05 07 FF 00 FF 07 08 01 08 00
2019-01-01 22:27:20.750 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 349: [WAIT_REQUEST] priority=Set, requiresResponse=true, callback: 175
2019-01-01 22:27:20.750 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Application Command Request (ALIVE:REQUEST_NIF)
2019-01-01 22:27:20.750 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2019-01-01 22:27:20.750 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: SECURITY not supported
2019-01-01 22:27:20.750 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Received COMMAND_CLASS_ALARM V0 NOTIFICATION_REPORT
2019-01-01 22:27:20.750 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 13: NOTIFICATION report - 7 = 255, event=8, status=255, plen=1
2019-01-01 22:27:20.750 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 13: Alarm Type = BURGLAR (7)
2019-01-01 22:27:20.750 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2019-01-01 22:27:20.750 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2019-01-01 22:27:20.751 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 13: Alarm converter processing NOTIFICATION
2019-01-01 22:27:20.751 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 13: Alarm converter NOTIFICATION event is 8, type OnOffType
2019-01-01 22:27:20.751 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Commands processed 1.
2019-01-01 22:27:20.751 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@53fd3c7b.
2019-01-01 22:27:20.751 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 1
2019-01-01 22:27:20.751 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 1
2019-01-01 22:27:20.751 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-01-01 22:27:20.751 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2019-01-01 22:27:20.852 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 11 00 04 00 0D 0B 71 05 07 FF 00 FF 07 08 01 08 00 99
2019-01-01 22:27:20.852 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=0, payload=00 0D 0B 71 05 07 FF 00 FF 07 08 01 08 00
2019-01-01 22:27:20.853 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=0, payload=00 0D 0B 71 05 07 FF 00 FF 07 08 01 08 00
2019-01-01 22:27:20.853 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 349: [WAIT_REQUEST] priority=Set, requiresResponse=true, callback: 175
2019-01-01 22:27:20.853 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Application Command Request (ALIVE:REQUEST_NIF)
2019-01-01 22:27:20.853 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2019-01-01 22:27:20.853 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: SECURITY not supported
2019-01-01 22:27:20.853 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Received COMMAND_CLASS_ALARM V0 NOTIFICATION_REPORT
2019-01-01 22:27:20.853 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 13: NOTIFICATION report - 7 = 255, event=8, status=255, plen=1
2019-01-01 22:27:20.853 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 13: Alarm Type = BURGLAR (7)
2019-01-01 22:27:20.853 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2019-01-01 22:27:20.853 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2019-01-01 22:27:20.853 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 13: Alarm converter processing NOTIFICATION
2019-01-01 22:27:20.853 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 13: Alarm converter NOTIFICATION event is 8, type OnOffType
2019-01-01 22:27:20.854 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Commands processed 1.
2019-01-01 22:27:20.854 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@5bf3d1e.
2019-01-01 22:27:20.854 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 1
2019-01-01 22:27:21.191 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=0, payload=00 0D 0B 71 05 07 FF 00 FF 07 08 01 08 00
2019-01-01 22:27:21.192 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=0, payload=00 0D 0B 71 05 07 FF 00 FF 07 08 01 08 00
2019-01-01 22:27:21.192 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2019-01-01 22:27:21.192 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Application Command Request (ALIVE:REQUEST_NIF)
2019-01-01 22:27:21.192 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2019-01-01 22:27:21.192 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: SECURITY not supported
2019-01-01 22:27:21.192 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Received COMMAND_CLASS_ALARM V0 NOTIFICATION_REPORT
2019-01-01 22:27:21.192 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 13: NOTIFICATION report - 7 = 255, event=8, status=255, plen=1
2019-01-01 22:27:21.192 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 13: Alarm Type = BURGLAR (7)
2019-01-01 22:27:21.192 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2019-01-01 22:27:21.192 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2019-01-01 22:27:21.192 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 13: Alarm converter processing NOTIFICATION
2019-01-01 22:27:21.192 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 13: Alarm converter NOTIFICATION event is 8, type OnOffType
2019-01-01 22:27:21.193 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Commands processed 1.
2019-01-01 22:27:21.193 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1ae9f969.

Motion OFF

2019-01-01 22:31:21.118 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 0D 03 20 01 00 DD
2019-01-01 22:31:21.119 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=
0, payload=00 0D 03 20 01 00
2019-01-01 22:31:21.119 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=0, payload=00 0D 03
 20 01 00
2019-01-01 22:31:21.119 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2019-01-01 22:31:21.119 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Application Command Request (ALIVE:REQUEST_NIF)
2019-01-01 22:31:21.119 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Incoming command class COMMAND_CLASS_BASIC, endpoint 0
2019-01-01 22:31:21.119 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: SECURITY not supported
2019-01-01 22:31:21.119 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Received COMMAND_CLASS_BASIC V0 BASIC_SET
2019-01-01 22:31:21.119 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 13: Basic report, value = 0
2019-01-01 22:31:21.119 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2019-01-01 22:31:21.119 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_BASIC, value = 0
2019-01-01 22:31:21.119 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Updating channel state zwave:device:9d6ae427:node13:sensor_binary to OFF [OnOffType]
2019-01-01 22:31:21.120 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Commands processed 1.
2019-01-01 22:31:21.120 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@730e4308.
2019-01-01 22:31:21.120 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-01-01 22:31:21.120 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2019-01-01 22:31:21.120 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2019-01-01 22:31:21.120 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2019-01-01 22:31:21.173 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 11 00 04 00 0D 0B 71 05 07 00 00 FF 07 00 01 08 00 6E
2019-01-01 22:31:21.173 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=
0, payload=00 0D 0B 71 05 07 00 00 FF 07 00 01 08 00
2019-01-01 22:31:21.174 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=13, callback=0, payload=00 0D 0B
 71 05 07 00 00 FF 07 00 01 08 00
2019-01-01 22:31:21.174 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2019-01-01 22:31:21.174 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Application Command Request (ALIVE:REQUEST_NIF)
2019-01-01 22:31:21.174 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2019-01-01 22:31:21.174 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 13: SECURITY not supported
2019-01-01 22:31:21.174 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 13: Received COMMAND_CLASS_ALARM V0 NOTIFICATION_REPORT
2019-01-01 22:31:21.174 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 13: NOTIFICATION report - 7 = 0, event=0, status=255, plen=1
2019-01-01 22:31:21.174 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 13: Alarm Type = BURGLAR (7)
2019-01-01 22:31:21.174 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2019-01-01 22:31:21.174 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2019-01-01 22:31:21.174 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 13: Alarm converter processing NOTIFICATION
2019-01-01 22:31:21.174 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - NODE 13: Alarm converter NOTIFICATION event is 0, type OnOffType
2019-01-01 22:31:21.175 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 13: Updating channel state zwave:device:9d6ae427:node13:alarm_burglar to OFF [OnOffType]
2019-01-01 22:31:21.175 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Commands processed 1.
2019-01-01 22:31:21.175 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 13: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@50b6dc1b.

[rlkoshak (Rich Koshak)]

Follow the guide to request a login and you can edit the database.

https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-database-guide

[Kim_Andersen]

A short question about this…
How to tell from the database, which channels to expect?
I´ve got one of these. When added to openhab it has 4 channels.
Binary
Temperature
Alarm
Battery Level.

Alarm channel doesn´t seem to do much.
Temperature seems to be stuck on 23 degree celsius.
Binary and Battery level works fine.

But what to expect and how to tell?

[chris (Chris Jackson)]

@imacdonald312

Have some of kfr-ZP3102us-5 from monopice

Can you explain what the issue is please? I’m guessing something isn’t working, but you don’t state that? From what I can see, the definition of the motion alarm looks wrong, so I have changed this, but it would be useful if you could provide an explanation of the issue you are reporting.

Also, please advise what version of the binding you are using - if it’s not a recent snapshot, then I would suggest to update to the latest version.

[chris (Chris Jackson)]

@Kim_Andersen

How to tell from the database, which channels to expect?

It is stated clearly in the OH documentation for the device, or in the database (I’d recommend checking the documentation).

[imacdonald312 (Ian Macdonald)]

@chris I submitted a change to the cd-jackson website for this. https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/437

The issue I was seeing was the tamper not working and motion not working other than binary_sensor so I Added 2 specific events for Alarm, burglar event = 8, tamper event=3 and also Updated version for various command classes.

Just curious what you changed compared to what I put in. I am still learning all about the zwave notifications and how that maps in openhab, so wondering if i got right? Also how long does it take for a change in the DB to be reflected in the nightly build. Is there and quick place to look to see if the change has made it into the nightly build?

[chris (Chris Jackson)]

@imacdonald312

I Added 2 specific events for Alarm, burglar event = 8, tamper event=3 and also Updated version for various command classes.

Ok, note that this will not make any difference. What was there before - ie what did you change? Also, what version of the binding are you currently using?

@imacdonald312

Just curious what you changed compared to what I put in.

I changed the name of the motion alarm channel to alarm_motion - this is what matters. The event numbers will not make any difference.

The change will not make it to the nightly build as I’ve not yet done that - I’ll look to do it tomorrow night if I can.

[Kim_Andersen]

@chris

It is stated clearly in the OH documentation for the device, or in the database (I’d recommend checking the documentation).

I may be abit stupid… But I honestly dont see any obvious decription of what channels/functions to expect (I know channels are an openhab term, but I´m not familiar with what else to call them). Not from its manual or the database. It seems implied that one would have to know to tell…

@imacdonald312

The issue I was seeing was the tamper not working and motion not working other than binary_sensor so I Added 2 specific events for Alarm, burglar event = 8, tamper event=3 and also Updated version for various command classes.

This is exactly why I ask. I´m sitting here watching the database, and I really dont get it.
As far as I know, the Alarm Buglar was removed because it´s a duplicate of the Binary. The tamper isn´t working, and Battery should be a switch (Low Battery) and not a Number…

As said, I may be a bit stupid, but I dont get it!

[chris (Chris Jackson)]

@Kim_Andersen

I may be abit stupid… But I honestly dont see any obvious decription of what channels/functions to expect

I’ll show an example then. Picking a random device (the ZW100) -:

I’m not super sure what is not obvious about this, but if I can make it clearer I will try

@Kim_Andersen

I´m sitting here watching the database, and I really dont get it.

As I recomended above - I would suggest to read the openHAB documentation as I try to make this clearer. The database is an editor - it is designed for people who have a little more knowledge, and is a bit verbose. However, if you are editing the database, then the data is also there -:

My recommendation is to use the documentation as the reference. I have spent a lot of time to try and make it useful, so I really hope it is, but if it can be clearer, then let me know and I can look at what can be improved. The documentation is an export from the database, so it can reasonably easily be improved if you think the above is somehow unclear.

[Kim_Andersen]

@chris

I’m not super sure what is not obvious about this, but if I can make it clearer I will try

Okay, first I´m very sorry. I actually wasn´t aware of the full supported list of devices in the openhab doc

Second. When looking at the PZ3102 device (Vision motion detector). From the table of supported channels in openhab it seem correct. But the manual isn´t quite clear regarding the Battery.

(Snip from the manual)
Battery Capacity Detection:
_ * Use “Battery Get” command to have the battery capacity back in %_
* It will detect the battery capacity automatically
* Low Battery Auto Report when power is lower than 2.6V +/- 0.1V

What about the Low Auto Battery Report. Shouldn´t that be a switch channel?
(This is where it gets rather technical, cause I have a feeling to know the answer to this, it requires deeper knowledge of zwave, right?).

EDIT - The same goes for the Tamper Switch. (Or that may be the Alarm Buglar?)

[imacdonald312 (Ian Macdonald)]

I am new to this as well, and just saw his notes about the changes i put to make the database match the documentation may not change how the sensor is used, but I think the information is still useful so i am going to pos anyway

I have been digging into the sensors I own to see if everything maps. If you look at ZP3102 in https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list you will see a couple versions, so it is good to know which one you have, an older version might mean it is an older device that has different capabilities like not supporting secure inclusion, the manufacture sometimes just keeps the same model number but increases the version number. You then need to look at the manufacture datasheet that came with the sensor, Chris has included a link the database page so if you are lucky it is already on included on the device list. here is the one for the ZP-3102 Gen 5 Sensor https://www.cd-jackson.com/zwave_device_uploads/437/ZP-3102-5-PIR-R3-500-Series-20150724.pdf

Now is where is gets a little complicated. The original (older?) Zwave protocol only supported Alarm V1, so if you look at the table you will see it sends Alarm type 0x07 with 0x00 (No movement after 3 mins) or 0xFF (Motion detected). This is Maps to SENSOR_BINARY. The bad thing about this is it also triggers if the tamper sensor is trigged so you have no way of knowing if someone walked in front of the sensor or if the tamp was triggered. So in newer versions of Zwave they created a new version of Alarm called Notification V4. The Sensor should send a Notification V4 message with Notification Type= 0x07 and Notification Parameter=0x08 for movement or a Notification Type= 0x07 and Notification Parameter=0x08 message for tamper so you can tell the 2 apart.

The sensor also does Temperature

The user needs to get the controller for receiving the current temperature except when
the temperature +2°C or -2°C degree then the sensor will automatically report to the
controller. (ZP3102 will send the Multilevel Sensor Report to Controller)

And Battery

Use “Battery Get” command to have the battery capacity back in %
It will detect the battery capacity automatically
Low Battery Auto Report when power is lower than 2.6V +/- 0.1V

The Change I put in the Database a few days back was an attempt at getting tamper and motion notification V4 to work. This change should go into the nightly build shortly where I can test to make sure it works then into the main release when the next one comes out.

You said the temp was stuck on 23’C so either its broken or maybe it doesn’t move more than 2’C. The sensor can either send an update or openhab can request an update, depending on other settings for polling and wakeup this may mean it only sends an update once a day. I have been looking into the temp on these as well since it keeps flipping from 'F to 'C and back, which I think is related to if the sensor sends an update or openhab requests an update, still haven’t quite worked out what is happening, but I noticed it doesn’t send updated very frequently with the default factory settings. Making the sensor send more frequently may have an impact on battery life.

[Kim_Andersen]

I dont know which version I´ve got. But its zwave version 8.2:

|dbReference|437|
|---|---|
|defaultAssociations|1|
|manufacturerId|0109|
|manufacturerRef|2002:0205|
|modelId|ZP3102|
|vendor|Vision Security|
|versionMin|8.0|
|zwave_beaming|true|
|zwave_class_basic|BASIC_TYPE_ROUTING_SLAVE|
|zwave_class_generic|GENERIC_TYPE_SENSOR_NOTIFICATION|
|zwave_class_specific|SPECIFIC_TYPE_NOTIFICATION_SENSOR|
|zwave_deviceid|517|
|zwave_devicetype|8194|
|zwave_frequent|false|
|zwave_lastheal|2019-01-13T23:36:00Z|
|zwave_lastwakeup|2019-01-14T22:34:12Z|
|zwave_listening|false|
|zwave_manufacturer|265|
|zwave_neighbours|1,3,5|
|zwave_nodeid|10|
|zwave_plus_devicetype|NODE_TYPE_ZWAVEPLUS_NODE|
|zwave_plus_roletype|ROLE_TYPE_SLAVE_SLEEPING_REPORTING|
|zwave_routing|true|
|zwave_secure|false|
|zwave_version|8.2|

The temp just changed when I removed the cover… It went 23 to 25 degrees. I have set it to wakeup after 14400 seconds. (4 hours). Since I persists this temperature, I know for sure it havn´t moved in months. So I was rather surprise to see it changed when I removed the cover. I would suspect if it was broken, it wouldnt have moved to 25 degrees?

Regarding the tamper Alarm (buglar) switch…
Hmm, I can get no reaction from it… When I removed the cover, it went from NULL to OFF

2019-01-15 00:38:11.804 [vent.ItemStateChangedEvent] - Node10_AlarmBurglar changed from NULL to OFF

And it seems like it just stays there no matter how many times I remove the cover.

Before I updated the zwave binding (a few weeks ago I think), this motion sensor worked the same on the alarm (buglar) and the binary channels. (Just as you say). And I believe the buglar got removed due to this when I updated…
If I understand you correct, the changes you made a few days ago (which confused me when I looked in the database) will get the Alarm buglar switch to work regardless of the motion detection?

[imacdonald312 (Ian Macdonald)]

@chris

Ok, note that this will not make any difference. What was there before - ie what did you change? Also, what version of the binding are you currently using?

I changed the name of the motion alarm channel to alarm_motion - this is what matters. The event numbers will not make any difference.

Oh…

Originally it was just a single Alarm V4 for Motion Channel=alarm_burglar. I added a new Channel for tamper, then added the event=8 and for Motion and event=3 for tamper to the Config line. which from what you are saying the event= part doesn’t make a difference

So need to work back, looking at org.openhab.binding.zwave/src/main/java/org/openhab/binding/zwave/internal/converter/ZWaveAlarmConverter.java at f9bec676c11671e10cae27ee44dea7ade10af068 · openhab/org.openhab.binding.zwave · GitHub

For the tamper which is type=burglar, event=8, I look for

HOME_SECURITY__MOTION_UNKNOWN(“BURGLAR”, 8),

which maps to

// Motion alarms
events = new HashMap<NotificationEvent, State>();
events.put(NotificationEvent.HOME_SECURITY__NONE, OnOffType.OFF);
events.put(NotificationEvent.HOME_SECURITY__MOTION, OnOffType.ON);
events.put(NotificationEvent.HOME_SECURITY__MOTION_UNKNOWN, OnOffType.ON);
notifications.put(“alarm_motion”, events);

Which tells me the channel to use is alarm_motion, do i have that correct?

I am using the nightly build so 2.5.0.SNAPSHOT (openhab2-2.5.0~S1499-1).

[imacdonald312 (Ian Macdonald)]

opening up the sensor wakes up the sensor and allows messsages like polls to be received, maybe one was sitting waiting to be delivered? There used to be something with zwave where you had to have the sensor close to the zwave stick (not routed through another device like a powered light switch) for it to fully associate, not sure if that is still the case with Gen5 sensors. So opening up the sensor case while close to the zwave stick would also put it in a wake mode that would allow it to fully associate and set commands like setting parameters.

You can put zwave in debug mode by doing

openhab-cli console
log:set DEBUG org.openhab.binding.zwave

and to set it back to normal

log:set INFO org.openhab.binding.zwave

Which will show you more of what is happening.

I have always used binary_sensor so not sure if/when alarm (burglar) stopped working.

The battery-level is a number, it works for me the 2.5 snapshot, i get a % of battery left. It would make sense if there is another channel like alarm_battery which would be an on/off channel for the battery report, but i haven’t played around with that in debug mode, i wonder if i have any Cr123 batteries that have some charge left that I could test with that.

Not sure if you are running the nightly snapshot or not, but i will report back once see the changes and i have the tamper and motion working.

[chris (Chris Jackson)]

@Kim_Andersen

What about the Low Auto Battery Report. Shouldn´t that be a switch channel?

I don’t provide this as a channel in the binding as I don’t see any point. It provides the same information as the battery level since when battery level = 0, then low battery = ON. Do you really think that needs a separate channel?

[Kim_Andersen]

@imacdonald312

opening up the sensor wakes up the sensor and allows messsages like polls to be received, maybe one was sitting waiting to be delivered?

Could be… I have changed the polling time to 30 minutes, cause it was set for 1 day. I dont know if that change anything… I can see from my stats, that there was plenty of activity on the temperature sensor untill August 2018. After that it hardly changed. Right now it´s back on 23 degress, which could be correct though. I´ll keep a close look on it.

@imacdonald312

There used to be something with zwave where you had to have the sensor close to the zwave stick (not routed through another device like a powered light switch) for it to fully associate

I believe this has changed. I think that was common with the 2.3 binding. But Chris might know for sure.

@imacdonald312

Not sure if you are running the nightly snapshot or not, but i will report back once see the changes and i have the tamper and motion working.

Normally I update, if there is some changes which has influence on my devices. I believe I´m using the latest atm. I look forward to see the changes.

[Kim_Andersen]

@chris

I don’t provide this as a channel in the binding as I don’t see any point. It provides the same information as the battery level since when battery level = 0, then low battery = ON. Do you really think that needs a separate channel?

Untill recently, I would have said no. Cause having the battery level, one can make a rule to do the same…
But recently I actually gave it a thought because my IHC battery devices does not provide info about battery level. I asked Pauli (he who make the IHC binding) why, and he says it´s because the device doesnt provide this info. Insted it has a battery warning (low battery) channel… That made me think, that this is actually a very usefull channel. And infact even better than the battery level channel. Because:

1. If the device only provide battery level, the user will have to create a rule to get a warning. Otherweise he will only notice, when the battery is empty and the devices goes offline.
2. Having more battery devices which only provide battery level, and this level isnt the same (ie the amount of voltage isn´t the same). The user has to create a rule for each device.

Now, if there is a low battery swicth channel, the users can create a group for these switches, which:

1. Make the need of a rule needless.
2. Make use of a group, and have a warning if any of the devices turns ON, before it actually goes offline. All independable of the different voltage/battery levels.

So my answer would have to be - Yes I do think it needs a seperate channel, when the device provide this info

[chris (Chris Jackson)]

[quote=“Kim_Andersen, post:17, topic:62157”]
Having more battery devices which only provide battery level[/quote]
In ZWave, the data is exactly the same - the value goes from 100% to 0%, and then to FF to mark that it is low battery. So the data coming from the device is exactly the same and this therefore doesn’t help you when you are looking for multiple methods to get the data in case one doesn’t work.

[Kim_Andersen]

@chris

In ZWave, the data is exactly the same - the value goes from 100% to 0%, and then to FF to mark that it is low battery. So the data coming from the device is exactly the same and this therefore doesn’t help you when you are looking for multiple methods to get the data in case one doesn’t work.

I´m not sure I understand. According to the manual of the ZP3102, the Battery Low switch will trigger at a specific level of voltage. I believe this is hardly the same level for all z-wave devices, or??

[chris (Chris Jackson)]

The ZWave protocol defines the battery low condition. In the ZWave binding this will be reported as 0 battery - and Yes, that is consistent with ALL devices as it is part of the standard.