Ok, this seems to be the first killer feature forcing me to go ahead.
Just one question: Which functions exactly are ot supported in OH1 (it seems to have to do with ZWAVE Plus features?) ?
It’s not so easy to answer that question. In general, newer features over the past year have been made into OH2. Where possible, we’ve also added them to OH1, but in this case, it’s a major change as the way that associations are managed to incorporate the multi_instance_association class is a (relatively) large restructuring of the binding.
Thank you chris, so the feature in question for my qubino devices was the multi_instance_association class that is missing in OH1.
Is it possible that also other newer devices (i.e. Fibaro FGS-223 double Zwave+ relay) have this class implemented for different endpoints. I encounter similar problems with them.
There is no problem with implementation of endpoints, even in OH1. The issue is that Qubino don’t send the unsolicited responses encapsulated within the multi channelencap unless this is configured with the multi-channel-association class. So, this only is a problem when you change the state of the device by pressing the button on the device - not when controlled through the software.
I have not seen this in any Fibaro devices - they have always sent their data using multi channel encapsulation so this should not impact them and I’ve used them fine on OH1 for many years. Maybe they have changed the way this works on very recent devices, but I don’t think so.
One point to note on Fibaro is that some devices don’t encapsulate switch 1 with multi-channel, so you need to use endpoint 0 rather than endpoint 1 for the dual switches. This is something they changed quite a while ago now (maybe 1 year or more) but it is different than the older devices which encapsulated everything with multi-channel.
After having spent half the night with the configuration of OH2 (Build 694) I am close to frustration. The problem with the endpoint reporting of the Qubino ZMNHBD is exactly the same with OH2. Sorry, but I cannot see any difference/improvement.
I have defined threee switch items for the ZMNHBD, for endpoint 0,1 and 2). When I switch the device via UI, the correct light is switched on (1 or 2) or both (when hitting 0). However, endpoints 1 and 2 are NEVER updated in OH when switching is done on the physically switch. The only update in this case is for endpoint 0 (which does not make any sense and is of no use and contradictory).
Here the content of my ItemChanelLink.json:
"zwave_device_15970bead83_node55_switch_binary -\u003e zwave:device:15970bead83:node55:switch_binary": {
"class": "org.eclipse.smarthome.core.thing.link.ItemChannelLink",
"value": {
"channelUID": {
"segments": [
"zwave",
"device",
"15970bead83",
"node55",
"switch_binary"
]
},
"itemName": "zwave_device_15970bead83_node55_switch_binary"
}
},
"zwave_device_15970bead83_node55_switch_binary1 -\u003e zwave:device:15970bead83:node55:switch_binary1": {
"class": "org.eclipse.smarthome.core.thing.link.ItemChannelLink",
"value": {
"channelUID": {
"segments": [
"zwave",
"device",
"15970bead83",
"node55",
"switch_binary1"
]
},
"itemName": "zwave_device_15970bead83_node55_switch_binary1"
}
},
"zwave_device_15970bead83_node55_switch_binary2 -\u003e zwave:device:15970bead83:node55:switch_binary2": {
"class": "org.eclipse.smarthome.core.thing.link.ItemChannelLink",
"value": {
"channelUID": {
"segments": [
"zwave",
"device",
"15970bead83",
"node55",
"switch_binary2"
]
},
"itemName": "zwave_device_15970bead83_node55_switch_binary2"
}
}
Is there any other thing I could (or have to) configure?
Thanks for any help or hints!
Is there any other thing I could (or have to) configure?
Have you configured the devices associations? This is how the reporting is configured.
Yes, but have you configured them in OH2 or is this still configured from OH1?
I do not understand what the point is. The device was first time inluded in the ZWave-Network (paired with my Z-Stick) when I was still using OH1. However, pairing was done just by pressing the button on Z-Stick, not with any OH1-Function. So why should this affect the behaviour of OH2?
My install of OH2 (If that is what you mean) is fresh. I defined items and so on from scratch, but of course the autodiscovery function of “things” discovered the already included ZWave-Devices.
Because OH2 uses different command classes for configuring the associations, and this tells the device to send multi-channel commands. I wouldn’t have suggested to change to OH2 if it was the same as OH1 ;).
Here is the discussion where this issue was resolved for the same switch that you are using - it is ONLY implemented in OH2 due to the multi-channel-association changes that I mentioned earlier.
Sorry - if by ‘pairing’ you mean inclusion, then this is NOT the same as configuring associations. Associations need to be configured through the UI and it MUST be done from OH2.
Ok, i configured the first associations with Habmin in OH1. Is there a way to “upgrade” these associations to a “multichannel-level”?
I guess remove the association, and then add it again would probably do it. You probably only need to configure group 1 which is the lifeline.
Unfortunately it does not change anything. There is still only an update to Endpoint 0.
It is also curious to see, that I cannot set a new association to the Switch_Binary1 or Switch_Binary2 association group. Only the lifeline default reporting group works. Habmin also accepts entries in the other groups, you can apparently save them, but when you call Habmin next time (after having closed the browser) they have disappeared again…
I just excluded now 2 ZMNHBD devices and reincluded them as new nodes in the network to test if that finally helps. Unfortunately they still appear as “unknown device” in Habmin even after 1,5 hours. Is there any way to speed that up?
I am close to give up. Even the resetted and completely new included node shows the same old odd behaviour and only updates the Switch 0. This ZMNHBD device had never any contact with OH1, it even forgot all of the config (like push button etc.) , came freshly in the network and it is exactly the same.
NOTHING improved , it is the same as in OH1. Not a very satisfying result after nearly 24 hours only dedicated to that problem 
@pdegeus: How did you configure your ZMNHBD devices with OH2 at last? And do they really work in a way to update Q1 und Q2 separately when activated by the physically switch?
@chris: Is there any possibility to check what kind of association is set to the device? A kind of reporting or loggin tool or whatever to query this technical detail?
If you can provide a debug log of the commands sent when you set the associations I’ll take a look over the next few days.
Ok, I will preapre that. Just to make sure what you exactly mean with “when you set the associations”:
The association for liefeline (default reporting group 1) is already set automatically after the “new thing” is added to OH2. So it will be difficult to provide a debug log for this very moment. When I open the thing for the first time with habmin the association for group 1 to the Openhab Controller is already there.
AND: It is NOT possible to set any other additional associations groups with Habmin. I can enter the association, save the settings but a few moments later they disappear again. So this is what remains:
So which moment should I try to catch in the debug log?
We should try and find out why the association group is disappearing - this might be related. So I suggest to grab a log of what’s happening when you set the association in one of the other groups.
I’m about to get on a longhaul flight so won’t be able to look at this until tomorrow or Sunday probably.
Ok, thank you for the clarification.
I noticed one curious thing: I can set the associations only when no channels are set for the endpoints of the device. Without defined channels the Save Process for the associations is successful. BUT: When I then try to define the channels(items) for the endpoints afterwards, the system leaves the name empty and the channels cannot be saved. The only way to bring back channels/items is to delete the associations and then I can define items for the 3 switch channels of the devices…Is that a bug in the device or in Habmin?
Thank you very much for your guidance and help so far. Have a good flight!
It seems to be a more fundamental problem than just an issue with one device.
I just unboxed a brand new purchased Fibaro Double Relay Switch FGS223 (Zwave+ also), included it, wired it, set the associations and tried the same thing (switching the physical switches). Result: The same problem, only switch 0 gets updated in OH, Switches 1 and 2 never report that they have been triggered.
So my conclusion for the moment is: OH Zwave Binding presently seems to have a problem to handle Zwave±Double-Relays correctly. The Fibaro FGS223 shows exactly the same behaviour as the Qubino ZMNHBD… 
And this conclusion seems to be confirmed when I have a look at this thread