I have the impression that this thread is related to this one, which IMO was not resolved: How to access different endpoints?
Can you provide the XML for this device. I know some devices don’t report that they support the multichannel command class in the NIF. This can then cause the binding problems as it thinks it’s not supported, and therefore can’t be used. When the device then uses it, things get confusing. I’m not sure if this is what the Qubino does, but if so it might explain the issue (IMHO this would make the device non-compliant to the standard, but there’s plenty of non-compliant devices out there that we have to deal with 
).
Can you also provide a shorter log please - the one above is 82MB and it’s too large to process.
Hi Chris
Thanks for taking a look at this. In the linked zip, you will find:
- node25_ZMNHAD Flush 1 relay.xml => example of a flush 1 relay which does not report back manual state changes
- node63_ZMNHSD DIN Rail Dimmer.xml => xml of the DIN dimmer which belongs to the logs posted earlier and below
- zwave_example_start.log => first log when starting up OH2
- zwave_example_tx_incomplete.log => one of the logs that has the " Transaction not completed" errors for Node 63
Notes:
- All Qubino devices do not report back manual state changes or power consumption, so I have more examples if needed
- Qubino 1 Relay used to report back state changes in an earlier OH2 release (I think it was 2.0 or 2.1 snapshot), this may be a regression problem
- I am seeing less “Transaction not completed” errors for Node 63 today, and increasingly believe that these errors are not the root cause, but possible a side effect or a totally different problem
Please let me know if you need anything else.
Hi,
I have the same problem with ZMNHDD Flush Dimmer. Actually I have two of them, first one was included using openhab 1 and the second one with openhab 2. the first one reports back the status in openhab 2 (and it worked with openhab 1 without any problems) but the second one does not (everything works except manual state changes are not sent back to the openhab). Maybe it’s the problem with OH2 inclusion ?
No. The issue is in the way that the multichannel association works. There is no difference in the inclusion.
OH1 doesn’t support the multichannel association at all. OH2 adds this, but the way it works with the very latest ZWave spec is not straight forward.
As @chris has now confirmed “multi channel association” to be at the core of this issue, I tried reading up on it a little. Being a ZWave newbie, I must admit that I currently do not really understand the background of this problem. In case others are following this thread, are in the same position and are wondering why this stuff doesn’t just work, here are some links that helped me in appreciating the complexity of what Chris is dealing with:
The basics: http://www.vesternet.com/knowledgebase/technical/kb-86
LifeLine, Notification Events & Encapsulation: http://forum.z-wavepublic.com/t/lifeline-and-notification-events/40
Evolving standards: https://github.com/OpenZWave/open-zwave/issues/976
1 Like
so is it possible in OH2 to do the association in the way OH1 did ? I mean is there some workaround for this problem ? Since one of my qubino works in OH2 and other not i believe this should be possible. Or maybe just use OH1 to configure the dimmer and the use it in OH2 ?
Well, OH1 does not support the multichannel associations, so it won’t work in this case. It would only work for Qubino devices that don’t support multichannels - we had lots of problems with Qubino devices on OH1.
OH2 uses either the multichannel association, or association classes depending on the device.
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?):
- The reporting one has been identified as BINARY_SWITCH
- The non-reporting device has been identified as MULTILEVEL_SWITCH.
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?