Status updates for Qubino Relays/Dimmers generally do not work

Add-ons Bindings
1

Hi,

I have implemented over 20 Qubino devices including:

  • ZMNHAD Flush 1 relay
  • ZMNHBD Flush 2 relays
  • ZMNHCD Flush Shutter
  • ZMNHSD DIN Rail Dimmer

NONE of these devices report back switch states unless I poll them. The Relays will only report back switch statuses on the legacy Switch channels, but not on the Switch 1 and Switch 2 channels. The dimmers will not report back switch states at all.

I would be grateful if some could tell me if:

  • I am doing something wrong
  • It is a bug in the ZWave binding/database/etc.
  • Qubino is simply not fully supported by OH2

I am using openHAB 2.2.0 Build #994

Many thanks in advance

2

It might be option #4, the Qubino devices do not themselves report the switch state at all. There are a number of Zwave devices that do not report the physical switch state when it is flipped.

It is unlikely you are doing anything wrong.

There might be a channel that the devices use that is not in the database. You will have to review the device’s manual and technical information and compare them to the database and see if one is missing.

3

Well, I have ZMNHDD dimmers, and they report back, the dim levels. But maybe you are talking about input 2 and 3?
I have no knowledge about the relays.
Did you set association groups->controller updates to openhab (lifeline)?

4

@rlkoshak: Rich, thanks for your thoughts. I have mailed Qubino to get a statement on whether or not they support reporting back status infos. If there is a channel mismatch, would I still see some data in the karaf debug log? I tried logging, but did not see any updates coming through in karaf when manually switching the switch/dimmer (see a lot of other stuff going on though).

@vespaman: Micael, thanks for your feedback. On the ZMNHDD Din Dimmer there is only one input. I am really only talking about very simple on/off or dim level status reporting if I manually switch/dim via the button input. This is not reported in OH2 and I don’t see anything in logs, not even debug. Association groups per default are empty (this seems to be normal, is like this on all devices), and I never set anything there. I tried setting “Group 1: Controller Updates” to “OpenHAB Controller”, this brought no change in behavior.

5

If you put the ZWave binding into debug it trace mode you should see the messages coming in on the logs.

In Having there is a nice ZWave log viewer that makes it easier to read through the ZWave binding logs. You will need to copy and paste the logs in I think, or maybe load a file. I don’t remember. Search the forum for “taming logging” and you should find a paying showing how to configure logging to put zwave binding logs in its own file.

6

Many thanks for your taming post. I implemented ZWave logging as you proposed. I am now logging the ZWave output in debug mode to a separate log, which is really helpful for getting at with grep. I am focusing on the ZMNHSD Din Dimmer at the moment, perhaps solving that one will help solve the others.

Even though I am not sure yet about the ZMNHSD reporting back switch/dimmer states (still waiting for an answer from Qubino support), I am 100% sure that the ZMNHSD supports reporting power, either based on % change in power levels, or at a fixed interval.

For fun, I forced it to report back power levels every 5 seconds, and sure enough, nothing is updated in OH2. However, the debug log shows the unsuccessful attempts the dimmer is making to communicate with OH2:

2017-08-01 19:03:38.535 [icationCommandMessageClass] - NODE 63: Transaction not completed: node address inconsistent.  lastSent=63, incoming=255
2017-08-01 19:03:54.435 [icationCommandMessageClass] - NODE 63: Transaction not completed: node address inconsistent.  lastSent=63, incoming=255
2017-08-01 19:04:05.995 [icationCommandMessageClass] - NODE 63: Transaction not completed: node address inconsistent.  lastSent=63, incoming=255
2017-08-01 19:04:44.438 [icationCommandMessageClass] - NODE 63: Transaction not completed: node address inconsistent.  lastSent=63, incoming=255
2017-08-01 19:05:04.474 [icationCommandMessageClass] - NODE 63: Transaction not completed: node address inconsistent.  lastSent=63, incoming=255
2017-08-01 19:05:22.298 [icationCommandMessageClass] - NODE 63: Transaction not completed: node address inconsistent.  lastSent=63, incoming=255
2017-08-01 19:05:24.440 [icationCommandMessageClass] - NODE 63: Transaction not completed: node address inconsistent.  lastSent=63, incoming=255
2017-08-01 19:05:26.046 [icationCommandMessageClass] - NODE 63: Transaction not completed: node address inconsistent.  lastSent=63, incoming=255

…and it goes on like this. I also set the polling interval to 10 mins, and the only time anything gets updated in OH2 is when the device gets polled. This is not the way things are supposed to work, and as far as I can tell, there is definitely something going wrong here. Any idea what it may be? Binding issue, config issue?

PS: Just in case, I have not configured anything in the associations section, all settings there are blank.

7

This sounds like a job for @chris.

If you can, please post your full log as I’m certain he will want to see what is going on around the binding start up and other message traffic associated with that node.

8

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.

9

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.

10

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.

11

OK, no worries!

I’ll be following this thread, since it might be something wrong with the ZMNHDD’s as well.

12

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.

13

I have the impression that this thread is related to this one, which IMO was not resolved: How to access different endpoints?

14

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 :frowning: ).

Can you also provide a shorter log please - the one above is 82MB and it’s too large to process.

15

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.

16

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 ?

17

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.

18

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
19

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 ?

20

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.