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.
@chris:
As already stated in the FGS-223 thread, the Qubino ZMNHBD is still NOT working (I tested with Z-Wave binding build 2.1.0.201702181609). I excluded and freshly reincluded 2 of the devices to be sure. The results:
When only the lifeline association is set, no reporting is done to endpoints 1 and 2 (neither for Switch 1/2 nor Power(Watts)1/2).
Even when the association groups for Switch binary or Basic On/Off are set (or both, also tested), NO update comes to the controller for Switch 1/2.
When the assocation groups for power reporting are set, the Power Consumption (Watts) is reported correctly for both endpoints separately(!)
Is there a chance to also get the status reporting of the switches correctly? I have moren than 10 of them installed and can provide any kind of debug log if you tell me what you need. Thanks for your help!
I seem to have the same issue with my newly bought Qubino flush 2 relays.
My system is a clean install of OH2. I can control both switches from the GUI but when I use the physical switches openhab never receives an update on switch 1 or 2 but only on the ‘common switch’. Hence the status on my sitemap is never updated. I have setup associations as per the following image
How did you include the device to the Z-Wave network? Make sure that you use the inclusion function from within OH2 (worked for me with both Paper UI and Habmin) when your Z-Wave stick is connected. I had trouble when I included the devices first decentrally with my Aeon Z-Stick5 and then started OH2, as in these cases the different endpoints were never usable.
So if you included it otherwise you will have to exclude and reinclude the device.
For associations I only set lifeline and this is enough. Endpoints get correct updates and also the energy consumption for each switch.
BUT: The Qubinos react relatively slow, updates take always between 4-8 seconds. While this may be ok to see if a light is still on, it is not usable if you want to react quickly in a rule to this event. For this reason I replaced some of my Qubinos with the Fibaro FGS-223 which is the better choice for quick updates.
The ZMNHBD Flush 2 relay is running fine here with OH2 2.1.0.
The way I included it was with OH2 Habmin and not with the Gen5 Z-Stick Button.
Additionally, I didn’t link the “general Channels” - the ones first in the list for “compatibiltiy”, but only the “:switch_binary1” and “:switch_binary2” as well as their meter_watts. This works fine,
with the exception that when I used OH2 Paper GUI to change properties, I got the the group asscociations wrong in the json config, ie. the Error 404 discussed here.
Does power and state reporting (on/off) work reliably for both endpoints after you included via Habmin? Just wondering why including via Habmin would make a difference. Does that mean I need to move the whole server around the house to include these devices again?
Does changing parameters via Habmin work, or do you also get messed up group associations?
In any case, this sounds like a real PITA and a no-go for buying further Qubino Flush 2 Relays.
It used to be a problem some time ago. Since Release Version 2.0 I can confirm that it worked for me. I did not try all recent snapshot versions but they should work.
The dev branch of the Z-Wave binding has a problem with this at the moment, but snapshot should be fine.
Did you set the association group 1 to the controller?
Yes, but unfortunately setting Association Group 1 to “OpenHAB Controller” makes no difference. It also makes no difference how the device was included (directly via ZStick or via Habmin). Receiving state updates of switches/dimmers may have worked in the past for you, but it is not working in stable 2.1.0 and neither in current 2.2 snapshots (or at least for devices included in those releases). The problem is more generalized, see this thread: Status updates for Qubino Relays/Dimmers generally do not work
