[SOLVED] New entry in Z-Wave Database does not work properly with Z-Wave Binding

Hi everyone, I recently purchased a MCO Home A8-9 Multisensor and wanted to use it with OpenHAB, but the Z-Wave Binding did not support this device at the time of purchase, so I requested access to the Z-Wave Database to add an entry myself; I successfully created and updated the entry, reinstalled the Z-Wave Binding via the zzManualInstaller.sh script and now the Binding acknowledges the device and all its Channels and properties.
HOWEVER, no matter what Channel I decide to link, no state updates are sent to OpenHAB Items. I checked for DEBUG logs of the Z-Wave Binding and there’s this line that caught my attention (Node 14 is the MCO Home sensor):

2020-02-03 12:07:36.200 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 14: No data from device, but it was ACK’d. Possibly not supported? (Try 2)

I’m not sure if I can do anything else about this. Could there be something wrong in how I added the entry into the Z-Wave Database? (I had to force recognition of two Channels, one being a sensor_loudness and the other sensor_voc, by masquerading them as other types or Channels, since their correspectives were not listed in the Channel Types section of the Z-Wave Database Device List; beyond that, I should have inserted all other data correctly) Or could it be an issue internal to the Z-Wave Binding?
Any help is appreciated.

The device entry in quesiton:
https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/1198

An extended version of Binding logs:

2020-02-03 12:07:31.166 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Request[0], dest=0, callback=125, payload=7D 00 00 03 00 CF 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00

2020-02-03 12:07:31.169 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Request[0], dest=0, callback=125, payload=7D 00 00 03 00 CF 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00

2020-02-03 12:07:31.171 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 147: [WAIT_REQUEST] priority=Config, requiresResponse=true, callback: 125

2020-02-03 12:07:31.172 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1

2020-02-03 12:07:31.174 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 147: [WAIT_REQUEST] priority=Config, requiresResponse=true, callback: 125

2020-02-03 12:07:31.176 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking TID 147: (Callback 125)

2020-02-03 12:07:31.177 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Callback match!

2020-02-03 12:07:31.179 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Correlated to TID 147: callback 125

2020-02-03 12:07:31.181 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Request[0], dest=0, callback=125, payload=7D 00 00 03 00 CF 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00

2020-02-03 12:07:31.183 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 14: SendData Request. CallBack ID = 125, Status = Transmission complete and ACK received(0)

2020-02-03 12:07:31.185 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 147: Advanced to WAIT_DATA

2020-02-03 12:07:31.187 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: TID 147: Transaction not completed

2020-02-03 12:07:31.189 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty

2020-02-03 12:07:31.190 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.

2020-02-03 12:07:36.187 [DEBUG] [sactionManager$ZWaveTransactionTimer] - NODE 14: TID 147: Timeout at state WAIT_DATA. 3 retries remaining.

2020-02-03 12:07:36.189 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 147: Transaction CANCELLED

2020-02-03 12:07:36.191 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 14: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent

2020-02-03 12:07:36.193 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: notifyTransactionResponse TID:147 CANCELLED

2020-02-03 12:07:36.196 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

2020-02-03 12:07:36.196 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 147: Transaction event listener: DONE: CANCELLED ->

2020-02-03 12:07:36.198 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 14: Node Init response (2) org.openhab.binding.zwave.internal.protocol.ZWaveTransactionResponse@3029db

2020-02-03 12:07:36.200 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 14: No data from device, but it was ACK’d. Possibly not supported? (Try 2)

2020-02-03 12:07:41.104 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 14: ZWaveCommandClassTransactionPayload - send to node

2020-02-03 12:07:41.107 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: SECURITY not supported

2020-02-03 12:07:41.109 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: Command Class COMMAND_CLASS_VERSION is NOT required to be secured

2020-02-03 12:07:41.110 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: sendTransaction org.openhab.binding.zwave.internal.protocol.transaction.ZWaveCommandClassTransactionPayload@1d47dc5

2020-02-03 12:07:41.112 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Adding to device queue

2020-02-03 12:07:41.114 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: Added 148 to queue - size 6

2020-02-03 12:07:41.115 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

2020-02-03 12:07:41.118 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0A 00 13 0E 03 86 13 59 25 7E 7C

2020-02-03 12:07:41.120 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 14: Sending REQUEST Message = 01 0A 00 13 0E 03 86 13 59 25 7E 7C

2020-02-03 12:07:41.122 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT

2020-02-03 12:07:41.124 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 148: [WAIT_RESPONSE] priority=Config, requiresResponse=true, callback: 126

2020-02-03 12:07:41.124 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06

2020-02-03 12:07:41.126 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=

2020-02-03 12:07:41.128 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=

2020-02-03 12:07:41.131 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 148: [WAIT_RESPONSE] priority=Config, requiresResponse=true, callback: 126

2020-02-03 12:07:41.131 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8

2020-02-03 12:07:41.133 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg: ACK

2020-02-03 12:07:41.135 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty

2020-02-03 12:07:41.135 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01

2020-02-03 12:07:41.137 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.

2020-02-03 12:07:41.141 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01

2020-02-03 12:07:41.143 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 148: [WAIT_RESPONSE] priority=Config, requiresResponse=true, callback: 126

2020-02-03 12:07:41.145 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1

2020-02-03 12:07:41.149 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 148: [WAIT_RESPONSE] priority=Config, requiresResponse=true, callback: 126

2020-02-03 12:07:41.151 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01

2020-02-03 12:07:41.153 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 14: sentData successfully placed on stack.

2020-02-03 12:07:41.155 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 18 00 13 7E 00 00 02 00 D0 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00 59

2020-02-03 12:07:41.156 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 148: Advanced to WAIT_REQUEST

2020-02-03 12:07:41.158 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: TID 148: Transaction not completed

2020-02-03 12:07:41.160 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty

2020-02-03 12:07:41.161 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.

2020-02-03 12:07:41.166 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Request[0], dest=0, callback=126, payload=7E 00 00 02 00 D0 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00

2020-02-03 12:07:41.167 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Request[0], dest=0, callback=126, payload=7E 00 00 02 00 D0 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00

2020-02-03 12:07:41.168 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 148: [WAIT_REQUEST] priority=Config, requiresResponse=true, callback: 126

2020-02-03 12:07:41.169 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1

2020-02-03 12:07:41.170 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 148: [WAIT_REQUEST] priority=Config, requiresResponse=true, callback: 126

2020-02-03 12:07:41.170 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking TID 148: (Callback 126)

2020-02-03 12:07:41.171 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Callback match!

2020-02-03 12:07:41.172 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Correlated to TID 148: callback 126

2020-02-03 12:07:41.173 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Request[0], dest=0, callback=126, payload=7E 00 00 02 00 D0 7F 7F 7F 7F 00 00 03 00 00 00 00 03 01 00 00

2020-02-03 12:07:41.174 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 14: SendData Request. CallBack ID = 126, Status = Transmission complete and ACK received(0)

2020-02-03 12:07:41.175 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 148: Advanced to WAIT_DATA

2020-02-03 12:07:41.176 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 14: TID 148: Transaction not completed

2020-02-03 12:07:41.177 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty

2020-02-03 12:07:41.177 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.

If this is the entry, it was only approved on February 1. Database changes do not magically appear in your installation. The database is part of the zwave binding,

The database was exported to GitHub after your entry was reviewed.
A new snapshot binding was last built 212 hours ago and can be accessed here.

I believe the install script now works for updating the binding to a snapshot version.
Zigbee and Z-Wave manual install script - Tutorials & Examples - openHAB Community

After updating your binding, you would then need to delete the Thing (do NOT exclude from the network) and re-discover to use the updated information.

I have not tested the script with 2.5.x but @5iver indicated he updated it for 2.5.

Hi @Bruce_Osborne, the entry was actually approved two weeks ago, February 1st is the date of last update (also performed by me).
I do know entries don’t magically appear in the Binding, hence I first checked if the GitHub repo for the Z-Wave Binding was updated, then re-installed it as a snapshot and deleted the old Things; I was able to see the edits I pushed last (the ones approved on February 1st), so I assume the entry was successfully added to the Binding, still it doesn’t respond to state updates.
Whether or not the entry was approved and merged is not the issue; the Binding went from not recognizing the sensor to recognize it and list all its properties, so I assume all went well on the maintenance side.

Those channels are wrong, please check:

https://www.cd-jackson.com/index.php/zwave/zwave-device-database/openhab-2-channel-types

@sihui Yes, I am well aware they are wrong, but no Channel Types exist for a “loudness” sensor or a “VOC” sensor, or at least they are not listed in the link you passed; I tried to exclude those Channels from the configuration, but the Editor wouldn’t let me delete them, so I faked them with other Channel Types. Is that what’s causing the issue or is it unrelated?

Open a GitHub issue to get the binding modified then.

Good idea, I was not aware I could open one for Channel Types also! I’ll get onto that immediately.

1 Like

Not all channel types are defined in the binding because not all are in regular use and, I believe, hew ones are added periodically.
As our developer mentioned in another thread, the current binding was mainly developed by reverse engineering the closed Z-Wave protocol.
There appear to be some changes in the future that may open up at least part of that.

That’s ok, those channels in particular are not meaningful to me for the time being, as long as they don’t affect the rest of the available Channels. The issue I am experiencing is affecting regular Channels such as Temperature or CarbonDioxide.

Perhaps the wrong channels are messing up the parsing of others.

Man, that’s definetly not an answer I wanted to hear :rofl:
I’ll keep the thread open if someone else wants to add to this, in the meantime thank you so much for the assistance.

You could possibly delete those problem channels and wait for the, usually weekly, update.

Please consider that you can’t simply enter a channel in the database, and expect it to work. This requires additional coding in the binding - not just the database update.

1 Like

@Bruce_Osborne how do you do that? My first instinct was indeed to delete the problem Channels, but the editor of the Z-Wave Database only let me edit those with no option to delete them.

@chris I expected the problem Channels not to work, I didn’t take into account the possibility it would mess up the whole device configuration; as I mentioned, I did not find a way to exclude those Channels from the Database entry, and I needed the device to “function” -more or less- in a short time (by the way, thank you @chris for your work so far and for being so active in the community). Guess I learned something new today :slight_smile:

1 Like

The problem is that if there are channels defined in things, but the channel type is not defined, then openhab-core will get upset and won’t allow the device to work.

The database doesn’t have a way to delete stuff by normal users (I wanted to avoid “accidents” :wink: ) - but there are people here who can do it if needed so you just need to ask here.

1 Like

or sabotage?? :scream:
I have been on forums where irate users deleted all their posts as they left. It made a mess of everything.

Yes - that too, although I hope/expect that most people who have requested access are not going to wilfully damage the system. Either way, it’s restricted :slight_smile:

1 Like

Bad idea.
Unfortunately your initial contribution for that device from Jan 24th already contained an altered xml file.
This is usually a very bad idea.
I had to compare the channel definitions with the product xml from the zwave alliance website (which is also not a very good idea) to hopefully fix this for you.

1 Like

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