Done.
2 Likes
Thank you all for your assistance! Next time I’ll happen to create a new entry for the Z-Wave DB, I’ll take into account all your advice. Cheers!
1 Like
Hi, an update;
this morning I re-installed the Z-Wave binding, and as expected all problematic Channels were removed. Unfortunately, the binding still seems incapable of notifying measurements to OpenHAB Items 
Also, I double-checked and the CO2 Channel for this device was set (I don’t recall if I set it myself or it auto-detected ChannelType) to alarm_co2, but the sensor actually gives CO2 measurements and therefore the ChannelType is wrong; could it be the same problem diagnosed last week? Unfortunately there’s no sensor_co2 Channel Type listed in the Z-Wave Database, so I guess this Channel should be dropped too.
Here’s a bit of logging (NODE 15 is the MCO Home device):
2020-02-10 10:59:10.421 [DEBUG] [sactionManager$ZWaveTransactionTimer] - NODE 15: TID 191: Timeout at state WAIT_DATA. 3 retries remaining.
2020-02-10 10:59:10.422 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 191: Transaction CANCELLED
2020-02-10 10:59:10.427 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2020-02-10 10:59:10.428 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: notifyTransactionResponse TID:191 CANCELLED
2020-02-10 10:59:10.430 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2020-02-10 10:59:10.431 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 191: Transaction event listener: DONE: CANCELLED →
2020-02-10 10:59:10.434 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 15: Node Init response (0) org.openhab.binding.zwave.internal.protocol.ZWaveTransactionResponse@1d8f213
2020-02-10 10:59:10.436 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 15: No data from device, but it was ACK’d. Possibly not supported? (Try 0)
2020-02-10 10:59:11.008 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 15: ZWaveCommandClassTransactionPayload - send to node
2020-02-10 10:59:11.010 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: SECURITY not supported
2020-02-10 10:59:11.012 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: Command Class COMMAND_CLASS_CONFIGURATION is NOT required to be secured
2020-02-10 10:59:11.013 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: sendTransaction org.openhab.binding.zwave.internal.protocol.transaction.ZWaveCommandClassTransactionPayload@7193b8
2020-02-10 10:59:11.015 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Adding to device queue
2020-02-10 10:59:11.017 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Added 192 to queue - size 6
2020-02-10 10:59:11.018 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2020-02-10 10:59:11.020 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0A 00 13 0F 03 70 05 01 25 A8 13
2020-02-10 10:59:11.022 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 15: Sending REQUEST Message = 01 0A 00 13 0F 03 70 05 01 25 A8 13
2020-02-10 10:59:11.024 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2020-02-10 10:59:11.026 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2020-02-10 10:59:11.026 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 192: [WAIT_RESPONSE] priority=Config, requiresResponse=true, callback: 168
2020-02-10 10:59:11.027 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2020-02-10 10:59:11.029 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2020-02-10 10:59:11.031 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2020-02-10 10:59:11.033 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg: ACK
2020-02-10 10:59:11.034 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2020-02-10 10:59:11.036 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2020-02-10 10:59:11.039 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
2020-02-10 10:59:11.041 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2020-02-10 10:59:11.043 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2020-02-10 10:59:11.045 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 192: [WAIT_RESPONSE] priority=Config, requiresResponse=true, callback: 168
2020-02-10 10:59:11.046 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2020-02-10 10:59:11.048 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 192: [WAIT_RESPONSE] priority=Config, requiresResponse=true, callback: 168
2020-02-10 10:59:11.049 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2020-02-10 10:59:11.053 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 18 00 13 A8 00 00 02 00 DD 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00 82
2020-02-10 10:59:11.056 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 15: sentData successfully placed on stack.
2020-02-10 10:59:11.056 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Request[0], dest=0, callback=168, payload=A8 00 00 02 00 DD 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00
2020-02-10 10:59:11.058 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 192: Advanced to WAIT_REQUEST
2020-02-10 10:59:11.060 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: TID 192: Transaction not completed
2020-02-10 10:59:11.065 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Request[0], dest=0, callback=168, payload=A8 00 00 02 00 DD 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00
2020-02-10 10:59:11.066 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 192: [WAIT_REQUEST] priority=Config, requiresResponse=true, callback: 168
2020-02-10 10:59:11.071 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2020-02-10 10:59:11.074 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 192: [WAIT_REQUEST] priority=Config, requiresResponse=true, callback: 168
2020-02-10 10:59:11.078 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking TID 192: (Callback 168)
2020-02-10 10:59:11.080 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Callback match!
2020-02-10 10:59:11.082 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Correlated to TID 192: callback 168
2020-02-10 10:59:11.083 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Request[0], dest=0, callback=168, payload=A8 00 00 02 00 DD 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00
2020-02-10 10:59:11.085 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 15: SendData Request. CallBack ID = 168, Status = Transmission complete and ACK received(0)
2020-02-10 10:59:11.087 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 192: Advanced to WAIT_DATA
2020-02-10 10:59:11.088 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: TID 192: Transaction not completed
2020-02-10 10:59:11.090 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2020-02-10 10:59:11.091 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2020-02-10 10:59:16.088 [DEBUG] [sactionManager$ZWaveTransactionTimer] - NODE 15: TID 192: Timeout at state WAIT_DATA. 3 retries remaining.
2020-02-10 10:59:16.090 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 192: Transaction CANCELLED
2020-02-10 10:59:16.091 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2020-02-10 10:59:16.093 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: notifyTransactionResponse TID:192 CANCELLED
2020-02-10 10:59:16.095 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2020-02-10 10:59:16.096 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 192: Transaction event listener: DONE: CANCELLED →
2020-02-10 10:59:16.099 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 15: Node Init response (1) org.openhab.binding.zwave.internal.protocol.ZWaveTransactionResponse@870fd5
2020-02-10 10:59:16.102 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 15: No data from device, but it was ACK’d. Possibly not supported? (Try 1)
2020-02-10 10:59:17.936 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 15: ZWaveCommandClassTransactionPayload - send to node
2020-02-10 10:59:17.937 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: SECURITY not supported
2020-02-10 10:59:17.939 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: Command Class COMMAND_CLASS_CONFIGURATION is NOT required to be secured
2020-02-10 10:59:17.941 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: sendTransaction org.openhab.binding.zwave.internal.protocol.transaction.ZWaveCommandClassTransactionPayload@7193b8
2020-02-10 10:59:17.943 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Adding to device queue
2020-02-10 10:59:17.944 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Added 193 to queue - size 6
2020-02-10 10:59:17.946 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
That’s too short?? Wow 
I read the full logs and it seemed to me there was no other information in them, the Binding simply retries and prints the same messages a couple of times. If you need it I can provide the full logs, but is there a way to collapse them in a kind of “spoilers” dropdown? I don’t want to pollute the thread with km-long messages 
In karaf you can stop the zwave bundle and then restart it. That should give more logging information as the binding looks for all your nodes.
You are looking for code fences. Or attach a zip file.
1 Like
Yep. Post a file on a file-sharing service, and just post the link here.
1 Like
Here it is, hope I got everything that could help.
mco_logs.txt (178.2 KB) mco_logs_2.txt (192.8 KB)
That log is a fragment of a couple of seconds and does not show any data received.
Please post your item definition.
I don’t think data is ever received, though; at least, is what these logs make me believe, since there are literally lines that say “No data from device”.
I tried to glue together as much logs as possible over the course of two minutes, more or less; after that, “NODE 15” no longer appears in them. The sensor itself is measuring stuff, however I don’t see any of those values among the logs. Here they are.
mco_logs_3.txt (361.7 KB)
Do not filter logs. They are useless for troubleshooting. Debug logs after stopping and restarting the bundle in Karaf can be useful though.
I don’t think this log is filtered - or if it is, it is probably still ok. What this indicates is that the device is not responding. The binding is sending out a PING message, and the device doesn’t respond (ie NO ACK). I would reset the device and re-include it. Alternatively, if you think it’s out of range, then move it closer to the controller.
1 Like
Sorry @Bruce_Osborne, I just meant that I copy-pasted logs as they were overwritten by new logs; I did include all information that was provided to me in those 2 minutes, so no filtering was done on my part.
@chris ok, I’ll try resetting it; as for range, if this sensor could not communicate with a controller two inches to its left I would be very disappointed in MCO Home products
Sorry,
I interpreted “glue together” to mean there were parts of the log not included.
1 Like
Probably it is not an issue, but I would suggest to separate them a little. It’s possible for transmitting devices to overload a receiver. I’d keep them say 0.5m apart.
Probably this isn’t the issue though…
In the meantime, just to be over-zealous, could anyone (@chris, @sihui) delete the alarm_co2 Channel from the MCO Home A8-9 listed Channels? I believe it would be malfunctioning even if the device responded, since it is tagged as a Channel-Type alarm_co2 but it is not a switch, it is a measure of air pollution (I checked and there’s no sensor_co2 Channel-Type, I’m afraid). Thank you!
If it’s of any use, here’s a log of when the MCO Home sensor is found by discovery and put in the Inbox. I don’t know if I got it from the beginning though. (Now the device is called “NODE 16”)
mco_logs_inbox.txt (279.1 KB)
Nothing on the re-initialization part, I’m afraid. Still no ACK from the device.
That data likely came from an openHAB xml file based on a device query. Deleting it could very well break other users.