I have two of the ZMNHSD, one is working as it should the otherone shows the mentioned problem.
The inclusion process of these two devices gave a different result (Why?):
Could this be a reason for this issue?
Can you show me exactly what this means? The device supports both command classes, but devices arenāt normally identified by command class (normally device classes).
so i checked my dimmers and the one that is reporting status is ZMNHDD with firmware version 1.1 and the one that does not report status is ZMNHDD (the same) with firmware version 3.5. So the problem is that the newer one is using multichannel association but is not fully compatible with OH2 ? Do I understand it correctly ?
node9.xml (14.0 KB)
node15.xml (13.8 KB)
Iāve attached the two node files. Node 9 is working as expected, node 15 is only reporting when polling.
Can you have a look at the log and see if any data is reported from node 15 when the device state changes locally. If so, please provide the short log.
The other thing that would be useful is to delete the XML for both of these devices and restart the binding and also provide the debug log.
Thereās really nothing that stands out between the two devices so I donāt think thereās any particular reason one works and the other doesnāt, but if I can get the above logs, maybe I can see whatās up.
Maybe 
. Iām not sure itās necessarily as simple as just saying that itās a version issue - you might be right in that thereās something different in the versions that makes it not work, or it might be something else. As suggested above, if you can remove the two XML files for the two devices, restart the binding and send me the log, I will take a look.
Does this mean you still need to do some work on the binding to get Qubinos to report states?
Here is the log file from locally pushing the button (light on / light off). It is renamed to .xml due to upload restrictions.
Node16.log.xml (10.4 KB)
The node number has changed from 15 to 16 as I have excluded and reincluded the device it in the meanwhile.
The other log follows laterā¦
Well, letās say that given you guys are telling me itās not working properly, I would have to say yes . I think it should work though, but if itās not, then we need to do some work to find out why notā¦
I assume this is from the ZMNHSD?
So, the reports are there, so just need to have a think about a few things. I might look at some of the other logs Iāve also been sent and then think about the best approachā¦ Either I need to change the way the device is configured, or change the way I handle the reports, or maybe bothā¦
For my later reference -:
Here are the log files from the restart of the binding. As requested Iāve deleted the xml files for node 9 and 1 shortly before the restart.
zwave.log.zip.xml (945.6 KB)
The restart took an unusually long time and wasnāt 100% finished, but the relevant parts should be there.
Thank you, and yes, I can assure you that it is not working 
How do you want to proceed, and how can we assist you?
Well, thatās what weāre doing . Iām looking through the logs that people have sent me today and Iāll hopefully be able to make some (positive) changes.
Hi!
I have 30+ modules form Qubino, different type.
And the same problem with module state updates.
Im working on OH2 testing and can help you on testing
I also have the same issues with Qubino devices. Even the dual relay switches keep being initialized as static. is there something i can do about that?
Ok excluding and including the device back in solved the static issue.
If it helps to solve the problem:
Status updates from manually switching the relays do work with me as written here with the relais of Qubino āZMNHBD Flush 2 relaysā. I am running 2.1.0-SNAPSHOT Build #927 on OS X version 10.10.5. Inclusion was done with Z-Stick Gen5.
I still get lots (just cleaned out ~1700) of those āghostā group associations in the /userdata/org.eclipse.smarthome.core.thing.Thing JSON file with my ca 10 Zwave devices as described here. I get duplicate āghostā association entries even when just working in Habmin. This might be a connected problem, maybe?
I have seen your post previously and have also tried that, probably followed every reasonable suggestion in the forum in over 40 include/exclude etc. attempts. I also have Z Stick Gen5 and also am only using the Switch1/2 channels, not the ālegacyā ones. In an earlier releases I at least had a Flush 1 Relay working (but this only was because I used the legacy channel), now it doesnāt work anymore either. Part of the problem is regression related, I am pretty sure about that (bugs introduced in the context of code changes).
I think the problem is pretty much narrowed down to a problem with association groups in the context of multi channel association at this point. As a point in case, This is nicely visible in the channel settings of the device. Association group fields generally are all blank, and if I try to add the controller to Group 1 / Lifeline it vanishes again at some point. More importantly, NOTHING gets written to org.eclipse.smarthome.core.thing.Thing.json, even though this is what I set in Habmin:
(this setting will go away latest at next reboot)
You can check my org.eclipse.smarthome.core.thing.Thing.json here, the screenshot above corresponds to node 26:
I am afraid itās not that simple, at least not in current snapshot 2.2.0. With no lifeline association with controller, updates are not going to workā¦ 
@Chris will hopefully solve this at some point.
Ah, finally someone else is having this issue 
We also discussed this here, but nothing came out of it (back then). Iām still looking for a solution and am still offering to test.
I think Iāll need to buy a Qubino device to resolve this 
. Iām a little hesitant to do this as Qubino were not very supportive when I tried to discuss this with them some time back (unlike a number of other manufacturers that are really helpful).
