[SOLVED] Heiman smoke detector, not all values discovered

Hello,

I have three Heiman smoke detectors. They are detected by my Zwave USB dongle, and so by the zwave binding. But only the first is fully discovered, the other two only basic. Could it be the database needs to be updated or so, or do i need to do something?

I can provide the jsondb if requested.

Regards,
Bastiaan

So basically everything is working, good.

Whatever ā€œbasicā€ means: wake the devices up (manually via button, look in your manual how to do that), battery operated devices need to be woken up several times until the get fully recognized by the binding.

With basic i mean that no channels are detected, and no information other then the node id is discovered.

Have waked the smoke detectors by pressing the test button multiple times. It still doenst get properly discovered by the zwave binding.

Are you sure that wakes up the smoke detector? Normally there is a button (the same button you have to push when you include the device) which needs to be pushed to send a wakeup signal.
I still would guess those two are not yet fully initialized because if the first one is working fine your setup is correct, the database is correct, ā€¦
Also check if they are all from the same device type (check the device type and device id): the only one that is in the database is 8002:1000.

Got them discovered. I needed to push the bind button three times, as if I would be binding again, then the undiscovered smoke detector got discovered and the channels were created.

Thanks for the help!

1 Like

Well, still got problems.

Let me explain the situation. I have four nodes:
node1: usb controller
node2: hall smoke detector
node3: 1st floor smoke detector
node4: 2nd floor smoke detector

They are all about 3 meters apart from each other, and should result in a meshed network.

Node 2 has no problems at all, functions great. This was the first node bound to the controller. Node 3 and 4 I installed later, and had some problems getting them fully discovered, but that has by doing an bind near by the controllerā€¦ What currently happens is that in my habpanel network I see all nodes except node3. Looking at neighbour status, node2 has only 1, node 3 and four has 0.

Node 3 and 4 have status online. I have created items and rules to trigger an telegram message when smoke is detected. This works flwless for node 2, but not for 3 and 4.

One thing thats odd is when I re-add the node3, and add the item configuration, itā€™s shown in habpanel. When I trigger an alarm, the event is not triggered and the channel bindings are gone in habpanel.

Iā€™m pulling my hair and do not se any solution to this.

Items:

Switch	Zwave_Rookmelder_gang			"Rookmelder [%s]"				(gSmokeDetectors) 				{ channel="zwave:device:myzwave:node2:alarm_smoke" }
Switch	Zwave_Rookmelder_gang_binary	"Rookmelder [%s]"				(gSmokeDetectors) 				{ channel="zwave:device:myzwave:node2:sensor_binary" }
Number	Zwave_Rookmelder_gang_battery	"Rookmelder battery [%d %%]"	(gSmokeDetectors,gBatteries) 	{ channel="zwave:device:myzwave:node2:battery-level" }

Switch	Zwave_Rookmelder_1e				"Rookmelder [%s]"				(gSmokeDetectors) 				{ channel="zwave:device:myzwave:node3:alarm_smoke" }
Switch	Zwave_Rookmelder_1e_binary		"Rookmelder [%s]"				(gSmokeDetectors) 				{ channel="zwave:device:myzwave:node3:sensor_binary" }
Number	Zwave_Rookmelder_1e_battery		"Rookmelder battery [%d %%]"	(gSmokeDetectors,gBatteries) 	{ channel="zwave:device:myzwave:node3:battery-level" }

Switch	Zwave_Rookmelder_2e				"Rookmelder [%s]"				(gSmokeDetectors) 				{ channel="zwave:device:myzwave:node4:alarm_smoke" }
Switch	Zwave_Rookmelder_2e_binary		"Rookmelder [%s]"				(gSmokeDetectors) 				{ channel="zwave:device:myzwave:node4:sensor_binary" }
Number	Zwave_Rookmelder_2e_battery		"Rookmelder battery [%d %%]"	(gSmokeDetectors,gBatteries) 	{ channel="zwave:device:myzwave:node4:battery-level" }

This is logged when triggering an alarm on node3:

2018-01-25 21:06:53.508 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'zwave.items'
2018-01-25 21:06:53.589 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Command received zwave:device:myzwave:node4:sensor_binary --> REFRESH
2018-01-25 21:06:53.589 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Command received zwave:device:myzwave:node4:alarm_smoke --> REFRESH
2018-01-25 21:06:53.591 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Polling intialised at 3600 seconds - start in 50 milliseconds.
2018-01-25 21:06:53.595 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Polling intialised at 3600 seconds - start in 50 milliseconds.
2018-01-25 21:06:53.594 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Command received zwave:device:myzwave:node4:battery-level --> REFRESH
2018-01-25 21:06:53.598 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Polling intialised at 3600 seconds - start in 50 milliseconds.
2018-01-25 21:06:53.648 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Polling...
2018-01-25 21:06:53.650 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 4: Polling deferred until initialisation complete
2018-01-25 21:07:45.347 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 08 00 04 00 03 02 84 07 71
2018-01-25 21:07:45.350 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2018-01-25 21:07:45.351 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 08 00 04 00 03 02 84 07 71
2018-01-25 21:07:45.352 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 08 00 04 00 03 02 84 07 71
2018-01-25 21:07:45.353 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 03 02 84 07
2018-01-25 21:07:45.356 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Application Command Request (ALIVE:DONE)
2018-01-25 21:07:45.357 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 3: Starting initialisation from DONE
2018-01-25 21:07:45.358 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@77b8be01 already registered
2018-01-25 21:07:45.360 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Incoming command class WAKE_UP
2018-01-25 21:07:45.361 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 3: Received Wake Up Request
2018-01-25 21:07:45.362 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 3: Received WAKE_UP_NOTIFICATION
2018-01-25 21:07:45.364 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 3: Is awake with 0 messages in the wake-up queue.
2018-01-25 21:07:45.365 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveWakeUpEvent
2018-01-25 21:07:45.366 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got an event from Z-Wave network: ZWaveWakeUpEvent
2018-01-25 21:07:45.375 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=3, callback=152, payload=03 02 84 08
2018-01-25 21:07:45.376 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 03 02 84 07
2018-01-25 21:07:45.377 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, callback id=152, expected=SendData, cancelled=true      MISMATCH
2018-01-25 21:07:46.375 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 3: No more messages, go back to sleep
2018-01-25 21:07:46.375 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 3: Creating new message for application command WAKE_UP_NO_MORE_INFORMATION
2018-01-25 21:07:46.376 [DEBUG] [ve.internal.protocol.ZWaveController] - Message queued. Queue length = 1. Queue={}
2018-01-25 21:07:46.376 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
2018-01-25 21:07:46.378 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 03 02 84 08 25 9B D6
2018-01-25 21:07:46.379 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 3: Sending REQUEST Message = 01 09 00 13 03 02 84 08 25 9B D6
2018-01-25 21:07:46.390 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
2018-01-25 21:07:46.392 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2018-01-25 21:07:46.393 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8
2018-01-25 21:07:46.394 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8
2018-01-25 21:07:46.395 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, callback=0, payload=01
2018-01-25 21:07:46.396 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 3: Sent Data successfully placed on stack.
2018-01-25 21:07:46.406 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 9B 00 00 02 72
2018-01-25 21:07:46.408 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2018-01-25 21:07:46.409 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 9B 00 00 02 00 00 7C
2018-01-25 21:07:46.410 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 9B 00 00 02 00 00 7C
2018-01-25 21:07:46.412 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=9B 00 00 02
2018-01-25 21:07:46.413 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 3: SendData Request. CallBack ID = 155, Status = Transmission complete and ACK received(0)
2018-01-25 21:07:46.414 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 3: Starting initialisation from DONE
2018-01-25 21:07:46.415 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@77b8be01 already registered
2018-01-25 21:07:46.417 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=3, callback=155, payload=03 02 84 08
2018-01-25 21:07:46.418 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=9B 00 00 02
2018-01-25 21:07:46.419 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=SendData, callback id=155, expected=SendData, cancelled=false        transaction complete!
2018-01-25 21:07:46.421 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
2018-01-25 21:07:46.422 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 3: Went to sleep
2018-01-25 21:07:46.423 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 3: Is sleeping
2018-01-25 21:07:46.424 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 3: Went to sleep
2018-01-25 21:07:46.425 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 3: Is sleeping
2018-01-25 21:07:46.426 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2018-01-25 21:07:46.427 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 3: Response processed after 45ms/4137ms.

Battery operated devices donā€™t create meshed networks, only mains powered devices.
Test all your rules when all devices are near to the controller, when that works you know where the problem is ā€¦

I did a complete reset approach and moved all nodes next to the controller: I have excluded all zwave nodeā€™s from the controller, then I hard reset the controller itself. On the nodeā€™s I did an reset also. So everything back to start. Then I bind them node by node thru habmin. All nodes got included and discovered. This went smoot and much better than the first time I did this.

Then I created the Items. This imported to openhab without errors. I see the channel bounds in PaperUi and habmin. So you would think all is fine. Well, all exept the Alarm Swich channel is working, and this behavior is the same for all three nodes. So when I press the test button or trigger the alarm by real smoke, I only see an ā€œThing ā€˜zwave:device:myzwave:nodeXā€™ has been updated.ā€, but not a other bus message.

When I enable zwave tracing, I see messages coming in during alarm trigger. Cant see anything wrong in there.

This is my item file:

rule "Send telegram when smoke is detected in gang"
when
	Item Zwave_Rookmelder_gang changed to ON
then
	sendTelegram("haastrecht_openhab_bot", "Het brandalarm in de gang gaat af.")
end

rule "Send telegram when smoke is detected in 1e etage"
when
	Item Zwave_Rookmelder_1e changed to ON
then
	sendTelegram("haastrecht_openhab_bot", "Het brandalarm van de 1e etage gaat af.")
end

rule "Send telegram when smoke is detected in 2e etage"
when
	Item Zwave_Rookmelder_2e changed to ON
then
	sendTelegram("haastrecht_openhab_bot", "Het brandalarm van de 2e etage gaat af")
end

And this is a debug trace when an alarm is triggerd on one of the nodes:

2018-01-28 10:58:44.632 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Received SOF
2018-01-28 10:58:44.636 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 08 00 04 00 03 02 84 07 71
2018-01-28 10:58:44.640 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Creating new SerialMessage from buffer = 01 08 00 04 00 03 02 84 07 71
2018-01-28 10:58:44.644 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 0x71
2018-01-28 10:58:44.648 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Checksum matched
2018-01-28 10:58:44.653 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Message payload = 00 03 02 84 07
2018-01-28 10:58:44.656 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Message is valid, sending ACK
2018-01-28 10:58:44.660 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT
2018-01-28 10:58:44.663 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2018-01-28 10:58:44.664 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 0x71
2018-01-28 10:58:44.668 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 08 00 04 00 03 02 84 07 71
2018-01-28 10:58:44.670 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 08 00 04 00 03 02 84 07 71
2018-01-28 10:58:44.675 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 03 02 84 07
2018-01-28 10:58:44.678 [TRACE] [ve.internal.protocol.ZWaveController] - Incoming Message type = REQUEST
2018-01-28 10:58:44.681 [TRACE] [ssage.ApplicationCommandMessageClass] - Handle Message Application Command Request
2018-01-28 10:58:44.683 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Application Command Request (ALIVE:DONE)
2018-01-28 10:58:44.686 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 3: Starting initialisation from DONE
2018-01-28 10:58:44.689 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@55162923 already registered
2018-01-28 10:58:44.692 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Incoming command class WAKE_UP
2018-01-28 10:58:44.700 [TRACE] [ssage.ApplicationCommandMessageClass] - NODE 3: Found Command Class WAKE_UP, passing to handleApplicationCommandRequest
2018-01-28 10:58:44.705 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 3: Received Wake Up Request
2018-01-28 10:58:44.708 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 3: Received WAKE_UP_NOTIFICATION
2018-01-28 10:58:44.710 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 3: Is awake with 0 messages in the wake-up queue.
2018-01-28 10:58:44.713 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveWakeUpEvent
2018-01-28 10:58:44.716 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got an event from Z-Wave network: ZWaveWakeUpEvent
2018-01-28 10:58:44.735 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=3, callback=82, payload=03 02 84 08
2018-01-28 10:58:44.738 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 03 02 84 07
2018-01-28 10:58:44.741 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, callback id=82, expected=SendData, cancelled=true      MISMATCH
2018-01-28 10:58:45.735 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 3: No more messages, go back to sleep
2018-01-28 10:58:45.736 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 3: Creating new message for application command WAKE_UP_NO_MORE_INFORMATION
2018-01-28 10:58:45.738 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 3: Creating empty message of class = SendData (0x13), type = Request (0x00)
2018-01-28 10:58:45.739 [TRACE] [ve.internal.protocol.ZWaveController] - Callback ID = 83
2018-01-28 10:58:45.741 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
2018-01-28 10:58:45.741 [DEBUG] [ve.internal.protocol.ZWaveController] - Message queued. Queue length = 1. Queue={}
2018-01-28 10:58:45.743 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 0x1E
2018-01-28 10:58:45.744 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 03 02 84 08 25 53 1E
2018-01-28 10:58:45.746 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 3: Sending REQUEST Message = 01 09 00 13 03 02 84 08 25 53 1E
2018-01-28 10:58:45.749 [TRACE] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2018-01-28 10:58:45.749 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Received ACK
2018-01-28 10:58:45.755 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Received SOF
2018-01-28 10:58:45.757 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
2018-01-28 10:58:45.758 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Creating new SerialMessage from buffer = 01 04 01 13 01 E8
2018-01-28 10:58:45.760 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 0xE8
2018-01-28 10:58:45.761 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Checksum matched
2018-01-28 10:58:45.763 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Message payload = 01
2018-01-28 10:58:45.764 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Message is valid, sending ACK
2018-01-28 10:58:45.767 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT
2018-01-28 10:58:45.768 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2018-01-28 10:58:45.769 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 0xE8
2018-01-28 10:58:45.771 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8
2018-01-28 10:58:45.771 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Received SOF
2018-01-28 10:58:45.772 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8
2018-01-28 10:58:45.775 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 53 00 00 02 BA
2018-01-28 10:58:45.774 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, callback=0, payload=01
2018-01-28 10:58:45.777 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Creating new SerialMessage from buffer = 01 07 00 13 53 00 00 02 BA
2018-01-28 10:58:45.779 [TRACE] [ve.internal.protocol.ZWaveController] - Incoming Message type = RESPONSE
2018-01-28 10:58:45.778 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 0xBA
2018-01-28 10:58:45.782 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Checksum matched
2018-01-28 10:58:45.784 [TRACE] [wave.internal.protocol.SerialMessage] - NODE 255: Message payload = 53 00 00 02
2018-01-28 10:58:45.785 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Message is valid, sending ACK
2018-01-28 10:58:45.780 [TRACE] [l.serialmessage.SendDataMessageClass] - Handle Message Send Data Response
2018-01-28 10:58:45.787 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 3: Sent Data successfully placed on stack.
2018-01-28 10:58:45.789 [TRACE] [wave.internal.protocol.SerialMessage] - Ack Pending cleared
2018-01-28 10:58:45.792 [TRACE] [WaveSerialHandler$ZWaveReceiveThread] - Response SENT
2018-01-28 10:58:45.793 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2018-01-28 10:58:45.795 [TRACE] [wave.internal.protocol.SerialMessage] - Calculated checksum = 0xB4
2018-01-28 10:58:45.796 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 53 00 00 02 00 00 B4
2018-01-28 10:58:45.798 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 53 00 00 02 00 00 B4
2018-01-28 10:58:45.801 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=53 00 00 02
2018-01-28 10:58:45.803 [TRACE] [ve.internal.protocol.ZWaveController] - Incoming Message type = REQUEST
2018-01-28 10:58:45.804 [TRACE] [l.serialmessage.SendDataMessageClass] - Handle Message Send Data Request
2018-01-28 10:58:45.806 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 3: SendData Request. CallBack ID = 83, Status = Transmission complete and ACK received(0)
2018-01-28 10:58:45.810 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 3: Starting initialisation from DONE
2018-01-28 10:58:45.813 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@55162923 already registered
2018-01-28 10:58:45.815 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=3, callback=83, payload=03 02 84 08
2018-01-28 10:58:45.818 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=53 00 00 02
2018-01-28 10:58:45.820 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=SendData, callback id=83, expected=SendData, cancelled=false        transaction complete!
2018-01-28 10:58:45.823 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
2018-01-28 10:58:45.825 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 3: Went to sleep
2018-01-28 10:58:45.831 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 3: Is sleeping
2018-01-28 10:58:45.833 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 3: Went to sleep
2018-01-28 10:58:45.834 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 3: Is sleeping
2018-01-28 10:58:45.836 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2018-01-28 10:58:45.837 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 3: Response processed after 85ms/4109ms.
2018-01-28 10:58:45.837 [TRACE] [ve.internal.protocol.ZWaveController] - Released. Transaction completed permit count -> 1
2018-01-28 10:58:45.839 [TRACE] [ocol.ZWaveController$ZWaveSendThread] - Acquired. Transaction completed permit count -> 0

I really have no idea what could be wrong here.

From feeding your log through the log viewer I can only see a a wakeup, but no data ā€¦ sorry, no more ideas.

Ok, thank you, so the node is not sending anything on the channel, as it looks like. What can I do about this, is there something wrong with the xml, or the database entry of openhab, create thing manual?

There is a comment at the end of the database entry from a user who seems to have had the same problem ā€¦ I donā€™t know if he solved the problem.

Yes, indeed, looks like the exact same problem. Unfortunately the device database website has a problem with the captcha image, so I cant post any reply message. Have send @chris an email to investiage the issue.

One thing i noticed is that the nodeā€™s are being handled as new by the zwave binding, they are re-discovered after triggering the alarm, while they were already a thing. The nodex.xlm get updates/recreated. Perhaps this give some indication itā€™s an openhab issue?

Edit: Problem with device database captcha is only when not logged in. I can login now and make posts.

I would like to update my situation, I have managed to solve my issues. For other readers stumbling on the same isues:

From start, my Zwave USB controllers network was not functioning properly, have not determined what, but Iā€™ve done multiple full resets, but none of them will full whipe of all dependencies. I needed to do this:

  • Exclude all nodes from the controller
  • Do a full reset of the USB controller
  • On the nodes, and this depends on the hardware, perform hardware default reset (For Heiman Smoke detector, remove battery, press and hold pin, insert betary while holding pin, wait 10 seonds, release pin. Wait 30 seconds for device to reset.)
  • Remove all nodes/things AND uSB controller from openhab.
  • Remove all XML files from /userdata/zwave
  • Just to be sure, restart OH
  • Add your USB controller and include your nodes
  • After this procedure, the network, the neigbours, the Habmin - zwave maps start functioning properly.

Note that the Heiman smoke detector works on the binary channel from ON to OFF ext.

I have updated the device database to complete all info, this had nothing to do with the operating of the node.

Thanks all for helping me out on this.

2 Likes

I am just going to emphasize this little comment as it help me pair a lot of devices, I have also referenced this thread in an issue I posted on the Z-Wave bindings Github: https://github.com/openhab/org.openhab.binding.zwave/issues/889#issuecomment-393331823

For the Heimann Smoke Sensor, the Heimann Door/Window Sensor, the Heimann Motion Detector, and the Everspring SP103 (and the branded FlexControl Motion in Denmark) the solution is the same:

  1. Start Include in OpenHab2
  2. Set devices in include mode (press the include buttons 3 times rapidly)
  3. Hey, wait a minute
  4. Try to set the devices in include mode again (press the include buttons 3 times rapidly)
  5. If no immediate success repeat 3 and 4

I have a Z-Wave stick with a activity LED, and it is quite clear when it works there is a lot of activity. So there is no need to check the logs or site, just stand by the controller do the steps 3 and 4 until lots of activity.

Hi Bastiaan,

From this thread I learned that the Heiman smoke detectors are working with openhab2. Thatā€™s a good thing!

Before buying me one I wonder what your experience is with batterylife? I see that your first message is already from beginning 2018. That could mean that the sensors are already working for almost two years. Are the sensors still on the same batteries? Is averything still working as it should?

Regards(groetjes :))
Mario

Dear Bastiaan,

I do also have three of the heimann smoke detectors. All three fully discovered, with three values. The discovery was easy from the beginning.

At the moment the following values are included:

Binary sensor
Alarm smoke
Battery level

Unfortunately, the battery level is not displayed any analogue value. It is shown just n/a at the overview. Additional I am not sure, for what I can use the other values. Is it possible to send an alarm to the Heimann device as a binary and then use e.g. as alarm siren if any other alarm occurs?

Also I have not been able to couple the smoke detectors to each other, so when any smoke alarm is triggered, that also the other detectors will communicate and generate this alarm.

Maybe you can advise if you encountered the same problems or you have an idea what could be done in order to have the battery value and the communication among the three smoke detectors.

Did you ever find a solution for the battery level not showing?
Facing the same issue hereā€¦

Dear Andy,
the battery level is being transmitted ā€œat the momentā€ daily once and I get an update notification, so for ~ 3 weeks it is stable.
What I did:

  1. Reset my USB controller fully (Hardware and Software reset via my PC)
  2. Updated Openhab to the 2.5 version (over Christmas I had time)
  3. Included all battery powered devices via Openhab ā€œincludeā€ (not via USB Z-Wave Software) even if the Device looks different in the Z-Wave software when included via openhab! (The device was near to my Z-Wave dongle during inclusion)
  4. After inclusion and configuration of the Heiman Smoke sensors, correctly showing up with the item description and the different channels, I pressed the button of the Z-Wave sensor plenty of times with the hope for the Z-Wave alarm to show up on the command window.

If it was not showing up, I excluded the device and included again. (Exclude via Z-WAve Software and Reset of the smoke sensor, include via Openhab)

Due to the update from 2.4 => 2.5 I started the PC really plenty of times and always the battery signal was gone!

  1. I created an analog meter for my battery Status and persisted this
  2. I created a variable which is showing the ā€œlast updateā€ of the battery status

This is working since 3 weeks and I get an update every day in the morning.

The following observations I can not prove, but it seemed to me like:

  • the reset of the Z-Wave dongle has nothing to do with the working sensor now. More important seems to be the deletion of the files that were created during openhab inclusion and Z-Wave removal via Z-Wave software
  • The Heiman sensor does not always submit the battery signal if you press the ā€œtestā€ button and also not always if you start ā€œinclusion via 3x quickā€ For me it was sufficient, when it was submitting this once. (For one of the sensors, the battery signal did not show up while pressing the button, but after one or two days it was showing up)
  • I monitored the battery level during inclusion and I did not find a significant voltage drop, so the battery power in my case does not have to do anything with the inclusion
  • I have a neo coolcam door sensor, which is working very reliable from the point of ā€œopen/closeā€ information, but for the battery value it is very bad! This is only submitting the battery if I press the small button below the cover 3-4 times.