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:
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.
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?
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:
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
And for completeness I tried yet another device, a Qubino ZWAVE+ Dimmer ZMNHDD. It only switches one dimmable load, but offers also up to 3 endpoints which can be wired to different switches or sensors.
The result is the same: When physically switching Input Switch I1 or Input Switch I2 the reporting to OH controller is always with endpoint 0. Endpoints 1 and 2 are never updated (the same story as with Qubino ZMNHBD and Fibaro FGS223).
I finally believe that here is really an issue with the OH binding as already 3 new devices show the same behaviour.
It would be great if we could get the additional endpoints usable (which was easy with the old ZWAVE-Generation devices with multi instance endpoints). At the moment the new devices are a step back with OH as they cannot be used completely.
Thanks for the log - the system is not using the multi channel association SET for some reason. The GET is using the multi channel so I’m not sure why the SET isn’t… I’ll try and look at this either later tonight or tomorrow.