Thanks for your prompt responses and help, Rich. I have provided the zwave debug log in the following link, as you have requested:
Hi @chris
Please let me know if you need any further info or have any questions.
There are infact 3 inputs on the ZMNHDD dimmers. (There’s only one output).
Yesterday, I only checked on my closest ZMNHDD before posting (which works). But just now, I walked a little bit further to another one, and that one gives me a differnt behavior (button two (input 2) updates, but input 1 does not. Not sure if this is some configuration error on my side, or if there something strange going on here, so I will see if I can get it going as it should.
I seem to get strange result when editing the associations in habmin, it seams that other fields than the ones I am editing, also seems to change. Did I not have enough coffee this morning??
The one working is a little bit older than the non-working one, so I guess this could also be firmware related.
Sorry, we were not talking about the same thing. The product I am focusing on at the moment is the ZMNHSD, which is this one:
https://i.imgur.com/0hptm7G.png
It only has one input (“I”, bottom right).
I mistakenly then started repeating your mentioned product code in my posts, need to correct that. Have not got around to verifying exactly what is going on with the ZMNHDD dimmer yet, am focusing on the DIN dimmer at the moment (ZMNHSD). Have also started looking at logs for the ZMNHAD 1 Relay, and it appears that it may not be the same problem.
OK, no worries!
I’ll be following this thread, since it might be something wrong with the ZMNHDD’s as well.
I just had a very friendly call with Aleš Humar from Qubino support. He said that all Qubino devices support reporting back manually changed states (e.g. switching/dimming via button input). If it is not working, then there is a problem with multichannel association with lifeline groups or association with lifeline group, depending on the product. He said that this normally should be set correctly during inclusion. In some cases/gateways, it may have to be set manually.
As said earlier, all association fields are blank on my setup. I tried to set them manually (see screenshot), but this does not seem to have any effect:
Looking at the logs of my ZMNHAD 1 Relay, I don’t see the previously reported errors that I am seeing in the logs for the ZMNHSD Din Dimmer. Instead, I am seeing these errors:
10:35:32.623 [WARN ] [ng.zwave.internal.protocol.ZWaveNode] - NODE 29: Unsupported multi instance command version: 0.
I am only seeing this error on one of my ZMNHAD Flush 1 relays, the other ZMNHAD’s don’t show such errors in the logs. Therefore I suppose this is not the root cause either.
After analyzing the complete log file which I posted earlier using Excel, I see that all of my Qubino devices are affected by the “Transaction not completed: node address inconsistent.” error:
- ZMNHAD Flush 1 relay
- ZMNHBD Flush 2 relays
- ZMNHCD Flush Shutter
- ZMNHSD DIN Rail Dimmer
The only other ZWave device I have, a Aeon Labs ZW100 MultiSensor 6, is not affected. It also does not have any problems with updates like the Qubinos. Interestingly, this is the only device I have which has “OpenHAB Controller” set in the field “Association Group 1” (not sure how that setting got there). I will be adding a Sensative Strip shortly, so I will have some more input in a few days.
In summary, I am pretty clueless atm regarding how to get status reporting to work on these Qubino devices with OH2. I have tried both inclusion via Controller (Aeon ZStick Gen5) and via Habmin, have included many devices so far, nothing makes a difference. None work as expected with regards to status reporting with OH2. My guess is that the problem has something to do with the association groups (like Aleš from Qubino says), but is not user fixable at this point, perhaps due to some specifics of the Qubino devices (multichannel?) which are not fully supported by the binding. I hope @chris will be able to bring some light into this.
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?