I am trying to get two MCO Home switches to turn each other on and off by association. I have added the devices to OH and created the association.
The issue I am having is when I am turning on and off the lights the controller gets the update but the other switch does nothing.
I will upload logs but I wasn’t sure if the devices need to be linked in some way. I presume it is z-wave and they work the same way.
I will upload some logs of z-wave in debug.
2018-11-21 21:12:37.619 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 8: SECURITY not supported
2018-11-21 21:12:37.620 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 8: Received COMMAND_CLASS_MULTI_CHANNEL_ASSOCIATION V3 MULTI_ASSOCIATIONCMD_REPORT
2018-11-21 21:12:37.621 [DEBUG] [ss.ZWaveMultiAssociationCommandClass] - NODE 8: association group 10 has max associations 5
2018-11-21 21:12:37.621 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got an event from Z-Wave network: ZWaveAssociationEvent
2018-11-21 21:12:37.622 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ASSOCIATION, value = 0
2018-11-21 21:12:37.623 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 8: Commands processed 1.
2018-11-21 21:12:37.624 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 8: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@cf51e7.
2018-11-21 21:12:37.624 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 8: Command verified org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@cf51e7.
2018-11-21 21:12:37.625 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 8: notifyTransactionResponse TID:21209 DONE
2018-11-21 21:12:37.626 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2018-11-21 21:12:37.627 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 1
2018-11-21 21:12:37.628 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-11-21 21:12:37.629 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2018-11-21 21:12:37.629 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2018-11-21 21:12:37.630 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0C 00 13 08 05 70 04 02 01 01 25 C0 7E
2018-11-21 21:12:37.631 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 8: Sending REQUEST Message = 01 0C 00 13 08 05 70 04 02 01 01 25 C0 7E
2018-11-21 21:12:37.632 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - Message SENT
2018-11-21 21:12:37.633 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 21210: [WAIT_RESPONSE] priority=Config, requiresResponse=true, callback: 192
2018-11-21 21:12:37.634 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
2018-11-21 21:12:37.635 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2018-11-21 21:12:37.636 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2018-11-21 21:12:37.637 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=null[0], type=ACK[2], dest=255, callback=0, payload=
2018-11-21 21:12:37.637 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 21210: [WAIT_RESPONSE] priority=Config, requiresResponse=true, callback: 192
2018-11-21 21:12:37.638 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg: ACK
2018-11-21 21:12:37.638 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2018-11-21 21:12:37.639 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2018-11-21 21:12:37.641 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8
2018-11-21 21:12:37.642 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2018-11-21 21:12:37.643 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2018-11-21 21:12:37.644 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2018-11-21 21:12:37.645 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 21210: [WAIT_RESPONSE] priority=Config, requiresResponse=true, callback: 192
2018-11-21 21:12:37.645 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2018-11-21 21:12:37.646 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 21210: [WAIT_RESPONSE] priority=Config, requiresResponse=true, callback: 192
2018-11-21 21:12:37.647 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Response[1], dest=255, callback=0, payload=01
2018-11-21 21:12:37.648 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 8: sentData successfully placed on stack.
2018-11-21 21:12:37.648 [DEBUG] [nal.protocol.ZWaveTransactionManager] - TID 21210: Advanced to WAIT_REQUEST
2018-11-21 21:12:37.649 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 8: TID 21210: Transaction not completed
2018-11-21 21:12:37.649 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2018-11-21 21:12:37.650 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start. Holdoff false.
2018-11-21 21:12:37.657 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 C0 00 00 02 29
2018-11-21 21:12:37.659 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=SendData[19], type=Request[0], dest=0, callback=192, payload=C0 00 00 02
2018-11-21 21:12:37.660 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=SendData[19], type=Request[0], dest=0, callback=192, payload=C0 00 00 02
2018-11-21 21:12:37.661 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=SendData[19], type=Request[0], dest=0, callback=192, payload=C0 00 00 02
2018-11-21 21:12:37.662 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction TID 21210: [WAIT_REQUEST] priority=Config, requiresResponse=true, callback: 192
2018-11-21 21:12:37.662 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
2018-11-21 21:12:37.663 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Last transaction: TID 21210: [WAIT_REQUEST] priority=Config, requiresResponse=true, callback: 192
2018-11-21 21:12:37.664 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Checking TID 21210: (Callback 192)
2018-11-21 21:12:37.664 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Callback match!
2018-11-21 21:12:37.665 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Correlated to TID 21210: callback 192
2018-11-21 21:12:37.666 [DEBUG] [ve.internal.protocol.ZWaveController] - Incoming Message: Message: class=SendData[19], type=Request[0], dest=0, callback=192, payload=C0 00 00 02
2018-11-21 21:12:37.666 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 8: SendData Request. CallBack ID = 192, Status = Transmission complete and ACK received(0)
2018-11-21 21:12:37.667 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 8: resetResendCount initComplete=true isDead=false
2018-11-21 21:12:37.668 [DEBUG] [e.internal.protocol.ZWaveTransaction] - TID 21210: Transaction COMPLETED
2018-11-21 21:12:37.669 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 8: Response processed after 36ms
2018-11-21 21:12:37.669 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 8: TID 21210: Transaction completed
2018-11-21 21:12:37.670 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 8: notifyTransactionResponse TID:21210 DONE
2018-11-21 21:12:37.671 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 8: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
2018-11-21 21:12:37.672 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
I have done some further investigation and I am not sure if it is a device issue or OH config issue. On a single switch I have to associate All Status Reports to a switch on the remote switch however on the remote switch that is dual switch I have to put the Switch button config the opposite way round, although this isn’t reliable all the time either sometimes it just doesn’t work.
I am still learning this stuff how would I find out if this is a OH issue or MCO issue?
While I don’t have any MCO Home devices, I have a couple thoughts:
You should provide the version of the zwave binding you’re using. If you’re on an old version (e.g. 2.3), you should consider upgrading first.
There are many MCO Home devices. You should provide the specific device models you’re using.
Please use code fences when posting log files, etc.
The red arrow for node 9 in the HABmin network viewer means it’s a one-way link. That would seem problematic for this device. It may be an indication that there are communication issues with this device.
It looks like you’re asking about nodes 2 and 9. The log you provided isn’t very helpful as it only shows activity for node 8.
The Z-Wave log viewer, which was used to produce the above image, is your friend.
From a problem determination point of view, I would suggest the following
At the end of the day, without proper test equipment, you won’t be able to see communication between nodes 2 and 9, so that aspect of your problem will be hard to diagnose.
Thank you.
The Z-Wave binding I am using is Snapshot 2.4m6 running on the latest stable release of OH.
The switches are MH-S311,312,314.
Acknowledged on the other parts.
The node 8 and 9 have just been added and I find they always come up in that way till after a few days.
I was more looking for guidance on how to debug hence that lack of those other parts of information but I will provide more if need. I am making contact with MCO to ask as well as it seems very hit and miss.
Looking at the manual:
It is supposed to do it. How do I look at if OH is sending the correct information?
As I suggested above.
OK thank you steep learning curve and trying to get my head around it sorry for making you repeat.
For this test I tried to node 11 associate button 1 with node 10 button 1.
I am a long way out of my depth and maybe miss reading the HEX output but I don’t see this matching the manual. Am I correct in this?
No worries. The log above shows Association Group 1 for node 11 being removed (REMOVE), set to node 10 (SET), queried for it’s value (GET), and reported back as being set to node 10 (REPORT). This worked, but may not be what you want. 
According to the manual you posted above, Association Group 2 is for Key 1.
I would suggest you do the following for node 11:
Refresh my memory, what is the model of node 11?
You are starting to align with my thoughts that the GUI to Z-wave/HEX code is off. When I did an association from group 2 (in the GUI) button 1 worked instead of button 2.
The removal was remove node1_1.
Node 11 is an MH-S312 and the node 10 is MH-S311.
to provide a visual of what I am doing:
Wait a minute. I completely missed that the manual you posted above is not for the MH-S312.
There are only 3 association groups for the MH-S312.
The switch supports 3 association groups. The first two groups are used for switching associated
devices（switch N controlling group N），and each group can support up to 5 nodes or terminals. The 3rd association group is used for reporting devices’state to the controller if any changes happen.This group supports one node, which defaults to controller node.
For the first two groups, the touch panel switch will send basic set command to related
association groups when setting switch state by gateway or key-pressing. Then the switch states
of associated devices and their related key will be synchronic. For the 3rd group, a report will be sent to associated controller by it when any state changes happen in other groups.
Association Group 1 is for Button 1, AG2 is for button 2. AG3 should be the Controller.
It is the key number+1.
So my understanding is group 1 should be controller always. Group 2 is then key 1 and so one…
That’s not what the manual says for the MH-S312.
And, it’s not how the database is defined (the database matches the manual).
Digesting the manual the key thing that sticks out is:
The device supports several (key numbers +1) association groups (AG). The 1st AG is used for reporting devices’ state to the controller if any changes happen.
I read this as group 1 is for reporting and groups:
2 - Key 1 HEX 0x02
3 - Key 2 HEX 0x05
4 - key 3 HEX 0x08
5 - key 4 HEX 0x0B
So my current thought is that OH and the Z-Waves plugin is using the DB which is incorrect.
Ah, I see.
Well, normally Group 1 is the Lifeline/Controller group, so you may have a point.
If you set Group 3 to Node 10, does button 2 send a command to node 10?
Shamefully no which granted does put a dent in the idea however looking at the HEX 0x01 should be the controller. I am trying to look in the string where that should appear and if the “group” matches the HEX.
The thing that might be worth mentioning is the all reporting group if that has the controller in it the OH gets no updates. If I put the controller in the other groups I then get updates.
Wonder if you could confirm my thinking.
The Hex they have listed in the manual does that convert to a group number? As in 0x0B is decimal 11 meaning group_11?
