A little more insights on zwave?

Hi I would like to understand the zwave messages a little better to better find reasons why stuff is not working.

If I look at the log below there is a switch (node5) which is
turned on and after some seconds turned off again…
am I correct if there is no “Receive Message” between this “on” and “off” … that means that the meter report was not sent by the device? hence if I would expect a meter report should be there there is NO issue with endpoint and command classes but way more likely with Config Params or Association if no “receive message” was watched at all?

Thanks for some infos

2016-09-07 18:23:36.318 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 05 03 25 03 FF 2D 
2016-09-07 18:23:36.328 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2016-09-07 18:23:36.334 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 00 05 03 25 03 FF 2D 
2016-09-07 18:23:36.339 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 00 05 03 25 03 FF 2D 
2016-09-07 18:23:36.344 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 05 03 25 03 FF 
2016-09-07 18:23:36.347 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 5: Application Command Request (ALIVE:DONE)
2016-09-07 18:23:36.349 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 5: Starting initialisation from DONE
2016-09-07 18:23:36.352 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@274956 already registered
2016-09-07 18:23:36.355 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 5: Incoming command class SWITCH_BINARY
2016-09-07 18:23:36.359 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - Received Switch Binary Request for Node ID = 5
2016-09-07 18:23:36.362 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 5: Switch Binary report, value = 255
2016-09-07 18:23:36.365 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2016-09-07 18:23:36.367 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2016-09-07 18:23:36.369 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got a value event from Z-Wave network, endpoint = 0, command class = SWITCH_BINARY, value = 255
2016-09-07 18:23:36.373 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Updating channel state zwave:device:15348538564:node5:switch_binary to ON [OnOffType]
2016-09-07 18:23:36.379 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 2: Transaction not completed: node address inconsistent.  lastSent=2, incoming=255
2016-09-07 18:23:54.357 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 05 03 25 03 00 D2 
2016-09-07 18:23:54.367 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2016-09-07 18:23:54.371 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 00 05 03 25 03 00 D2 
2016-09-07 18:23:54.376 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 00 05 03 25 03 00 D2 
2016-09-07 18:23:54.383 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 05 03 25 03 00 
2016-09-07 18:23:54.388 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 5: Application Command Request (ALIVE:DONE)
2016-09-07 18:23:54.394 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 5: Starting initialisation from DONE
2016-09-07 18:23:54.400 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@274956 already registered
2016-09-07 18:23:54.404 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 5: Incoming command class SWITCH_BINARY
2016-09-07 18:23:54.434 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - Received Switch Binary Request for Node ID = 5
2016-09-07 18:23:54.438 [DEBUG] [dclass.ZWaveBinarySwitchCommandClass] - NODE 5: Switch Binary report, value = 0
2016-09-07 18:23:54.449 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2016-09-07 18:23:54.451 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2016-09-07 18:23:54.454 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Got a value event from Z-Wave network, endpoint = 0, command class = SWITCH_BINARY, value = 0
2016-09-07 18:23:54.457 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 5: Updating channel state zwave:device:15348538564:node5:switch_binary to OFF [OnOffType]

Yes - that would be a fair assumption.

Correct.

I would strongly recommend using the log viewer to view logs - it’s much easier to see what is happening. This will show you exactly what is sent/received in a nice simple way (hopefully anyway :wink: ).

1 Like

I actually used that :slight_smile: … I just was not sure if it would show a RX entry even when there was no command class that could be triggered by it. Now I know that aswell :slight_smile:

once thing with the config parameters for this device is … it is the only device in habmin where the parameters are not sorted 100% ascending… parameter 1 is the last in list… all other stuff I triple checked in the DB

Strange - what is the device. I think in the database they should be sorted (but maybe not!) and in OH2 the theory is they should maintain the order from the XML. My guess is the database doesn’t sort like I think, but I’ll take a look.

of course my favorite device … out of 20 I have it is the only one thats not working as expected. the reason why I look for anything that might be odd there and noticed the sort of parameters in habmin.

http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/177

cheers

Thanks - it looks like the export from the database is not sorted - I’ll take a look at this.

The reason that parameter 1 is out of order here is it is defined as an action (it’s write only), and it’s handled in a separate parameter group. I don’t use PaperUI, but I guess it doesn’t handle groups?

I dont use PaperUI aswell.
My screenshot was from Habmin.

So thats not the reason that nothing from “meter” is send then :frowning:

Ok, well, that’s still the reason why it’s last - it’s marked in the database as write only.

Generally speaking, the position of this parameter in the list shouldn’t impact the device configuration.