vschwaberow
(Volker Schwaberow)
September 1, 2016, 9:57pm
1
I am using a GEN5 sensor of this brand. But I am not getting any data from the sensor.
However it is associated correct and I can even send refresh commands:
23:40:07.464 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Command received zwave:device:156dc31235f:node3:alarm_genera
l → REFRESH
23:40:07.465 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Command received zwave:device:156dc31235f:node3:battery-leve
l → REFRESH
Any idea to solve this?
chris
(Chris Jackson)
September 1, 2016, 10:02pm
2
You aren’t sending anything to the device here. I would suggest that the device needs to wake up - it’s a battery device, so it will be asleep. Battery devices need to be woken up manually so they can be configured - possibly woken a few times.
If that doesn’t work, then it might not be included correctly so I’d try re-including it.
1 Like
vschwaberow
(Volker Schwaberow)
September 1, 2016, 10:50pm
3
Thanks. I now reassociated it and it says
00:43:36.150 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling zwave:device:156dc31235f:node3:sensor_binary
00:43:36.150 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling zwave:device:156dc31235f:node3:sensor_temperature
00:43:36.150 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling zwave:device:156dc31235f:node3:sensor_seismicintensity
00:43:36.150 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling zwave:device:156dc31235f:node3:sensor_luminance
00:43:36.150 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling zwave:device:156dc31235f:node3:alarm_burglar
00:43:36.150 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling zwave:device:156dc31235f:node3:battery-level
00:43:36.150 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling zwave:device:156dc31235f:node3:alarm_general
00:43:54.948 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 3: Newly included node already initialising at DONE
00:44:36.042 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 255: Transaction not completed: node address inconsistent. lastSent=255, incoming=255
00:44:36.103 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Updating channel state zwave:device:156dc31235f:node3:sensor_binary to ON [OnOffType]
00:44:36.195 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Updating channel state zwave:device:156dc31235f:node3:sensor_temperature to 30 [DecimalType]
00:44:36.210 [INFO ] [marthome.event.ItemStateChangedEvent] - zwave_device_156dc31235f_node3_sensor_temperature changed from 31.8 to 30
00:44:36.264 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Updating channel state zwave:device:156dc31235f:node3:sensor_seismicintensity to 0 [DecimalType]
00:44:36.339 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Updating channel state zwave:device:156dc31235f:node3:sensor_luminance to 0 [DecimalType]
00:44:36.412 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Updating channel state zwave:device:156dc31235f:node3:alarm_burglar to OFF [OnOffType]
00:44:36.482 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Updating channel state zwave:device:156dc31235f:node3:battery-level to 100 [DecimalType]
00:44:36.592 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Updating channel state zwave:device:156dc31235f:node3:alarm_general to ON [OnOffType]
However it is not firing up any events. New button presses to wake it up are not helping here.
chris
(Chris Jackson)
September 2, 2016, 11:36am
4
Have you ‘trimmed’ the log or is this everything? The log appears to be missing most of the information - there are no signs of anything being sent, no received data even though there is mention of a transaction… Something doesn’t look right - if you can post a more complete log it would be appreciated?
Also, when posting logs, please can you format using the </>
button in the toolbar - it makes it much easier to read and process.
Thanks
Chris
vschwaberow
(Volker Schwaberow)
September 3, 2016, 9:39am
5
Will do this. Thanks for replying and trying to help me, Chris
Right now it looks the sensor reports something, but minutes after it happens. Temperature values are reported after nearly four hours, although I am quite sure that temp has changed in the sector of the building. Will post a log later.
vschwaberow
(Volker Schwaberow)
September 3, 2016, 2:01pm
6
Here we go. (Happening after pressing the button one time)
15:59:13.751 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Initialising state channel zwave:device:156dc31235f:node3:battery-level
15:59:13.751 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Initialising channel zwave:device:156dc31235f:node3:alarm_general
15:59:13.753 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Initialising cmd channel zwave:device:156dc31235f:node3:alarm_general
15:59:13.753 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Initialising poll channel zwave:device:156dc31235f:node3:alarm_general
15:59:13.753 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Initialising state channel zwave:device:156dc31235f:node3:alarm_general
15:59:13.753 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Polling intialised at 1800 seconds - start in 1800000 milliseconds.
15:59:13.753 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 255: Response processed after 1766ms/4177ms.
15:59:13.753 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
15:59:13.754 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 03 02 84 08 25 18 55
15:59:13.754 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 3: Sending REQUEST Message = 01 09 00 13 03 02 84 08 25 18 55
15:59:13.779 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
15:59:13.783 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
15:59:13.783 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8
15:59:13.783 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8
15:59:13.783 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, callback=0, payload=01
15:59:13.783 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 3: Sent Data successfully placed on stack.
15:59:13.971 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 18 00 00 08 FB
15:59:13.975 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
15:59:13.975 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 18 00 00 08 00 00 F5
15:59:13.976 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 18 00 00 08 00 00 F5
15:59:13.976 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=18 00 00 08
15:59:13.976 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 3: SendData Request. CallBack ID = 24, Status = Transmission complete and ACK received(0)
15:59:13.976 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 3: Starting initialisation from DONE
15:59:13.976 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=3, callback=24, payload=03 02 84 08
15:59:13.976 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=18 00 00 08
15:59:13.976 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=SendData, callback id=24, expected=SendData, cancelled=false transaction complete!
15:59:13.976 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
15:59:13.976 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
15:59:13.976 [DEBUG] [curityCommandClassWithInitialization] - NODE 3: updating lastSentMessageTimestamp
15:59:13.976 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 3: Went to sleep
15:59:13.976 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 3: Is sleeping
15:59:13.976 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 3: Response processed after 218ms/4177ms.
chris
(Chris Jackson)
September 3, 2016, 2:35pm
7
There’s nothing wrong there. The device has presumably woken up shortly before the log starts, and so the log just shows it going to sleep which is normal.
My guess if you’re not getting alarms is that there’s something misconfigured with the device. I would first check associations, since if they are not set correctly the device will not send anything to the controller. Then check the configuration of parameters with the manual to see if there’s anything that needs to be enabled.
1 Like
vschwaberow
(Volker Schwaberow)
September 3, 2016, 3:11pm
8
Thanks Chris. I think reading for the manual and going through all configuration parameters is the best thing here.
chris
(Chris Jackson)
September 3, 2016, 3:12pm
9
Make sure to check the association settings first - this is the most likely cause, but if that’s set to point to the controller, then check the rest of the config. Normally there’s an association group that is specifically designed for controller communication - often called Lifeline
.
Good luck ;).
1 Like
vschwaberow
(Volker Schwaberow)
September 3, 2016, 3:33pm
10
Thanks Chris. You solved the case. After setting the association groups the sensor works and reports regular updates.
vschwaberow
(Volker Schwaberow)
September 4, 2016, 5:54am
11
Now it is having a wake up time of 1 second, while I said it should be 300 seconds. After that effect I made a hard reset of the device. Now it is showing up as Node4 and Node5 device. Node4 unknown, Node5 with the correct type. I will exchange the device for the Aeon Multisensor 6.
chris
(Chris Jackson)
September 4, 2016, 7:27am
12
I’m not sure how the wake up time can be set to 1 second - most devices limit the value much higher that this, but maybe this doesn’t.
However if you exclude a device and add it back, it will be given a new nose number, so this is correct. If you excluded the device using Habmin exclude function then it should have removed the old thing when you excluded the device. Otherwise you need to manually remove it or you will have a device that doesn’t exist. This isn’t a faulty device.
Cheers
Chris