Status updates for Qubino Relays/Dimmers generally do not work

ok, working with association groups meakes the thing better, here the latest results.
i’m working with the latest cloudbees 2.3.0 zwave binding.
note: using habmin i can see the applied setup (in example correct values in association groups), while using paper ui, when i choose a value from the dropdown fields, the value is empty after saving. so it’s better with habmin.

Phlio PAN04-1B: the same results with any combination of association groups: any switch i change i can only see “switch_binary” channel changes so i don’t know which channel is up and which is down. the same i can see consumption but i down’t know which channel is using that power.

Qubino ZMNHBD1: setting only “default reporting group” to “openhab controller” make it works perfectly on both channels: output state and consumption

Qubino ZMNHAD1 Flush 1 relay: setting only “default reporting group” to “openhab controller” (other combinations have the same effects) no way to know if relay is on or off. triggering i3 i can see “switch_binary” tigger, triggering i2 i can see both “switch_binary” and " sensor_binary" triggering so it’s confusing. triggering i1 i can’t see anything.

for all devices i’ve configured any given channel and if i trgger switch from ui any relay triggers correctly, so it’s only in receiving datas.

hope this helps.

I am having problems with the Qubino Fluss Dimmer with firmware V3.7, which I posted here:

Does someone experience the same behaviour?

@chris So, I finally found some time (and nerves) to get back to my beloved Qubino ZMNHSD1 DIN dimmers: I recently set up a new openHAB 2.2 installation and realised that status updates and wall switch presses are still missing for my dimmers. So, I manually updated the Z-Wave binding to 2.3, but still no luck. Even after excluding the dimmers, resetting them and including them again - no updates. No matter what I did with the association groups, no updates.

Yesterday I found this guide that describes how to setup (compile) the Open Z-Wave Control Panel on my Raspberry Pi / openHABian installation. So I did that out of interest, to diagnose my setup. After stopping openHAB and starting OZCP, I pressed the wall switches and got the following log events:

2018-05-13 14:07:51.534 Detail, Node017,   Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x11, 0x07, 0x60, 0x0d, 0x01, 0x00, 0x20, 0x01, 0xff, 0x52
2018-05-13 14:07:51.534 Error, Node017, Received a MultiChannelEncap for endpoint 1 for Command Class 32, which we can't find
2018-05-13 14:07:52.233 Detail, Node017,   Received: 0x01, 0x0d, 0x00, 0x04, 0x00, 0x11, 0x07, 0x60, 0x0d, 0x01, 0x00, 0x20, 0x01, 0x00, 0xad
2018-05-13 14:07:52.278 Error, Node017, Received a MultiChannelEncap for endpoint 1 for Command Class 32, which we can't find

Something was indeed happening, but not in the right kind of way. I decided to exclude/reset/include my dimmers using OZCP. Finally, status updates arrived in a way that didn’t register as errors in the OZCP log (no on/off switch events, but at least power output dropped to 0):

2018-05-13 19:24:08.933 Detail, Node019,   Received: 0x01, 0x10, 0x00, 0x04, 0x00, 0x13, 0x0a, 0x32, 0x02, 0x21, 0x34, 0x00, 0x00, 0x00, 0x32, 0x00, 0x00, 0xe5
2018-05-13 19:24:08.934 Detail, 
2018-05-13 19:24:08.934 Detail, Node019, Refreshed Value: old value=false, new value=false, type=bool
2018-05-13 19:24:08.935 Detail, Node019, Changes to this value are not verified
2018-05-13 19:24:08.935 Info, Node019, Received Meter report from node 19: Power=5.0W
2018-05-13 19:24:08.936 Detail, Node019, Refreshed Value: old value=5.5, new value=5.0, type=decimal
2018-05-13 19:24:08.936 Detail, Node019, Changes to this value are not verified
2018-05-13 19:24:08.937 Detail, Node019, Notification: ValueChanged
2018-05-13 19:24:08.937 Info, Notification: Value Changed Home 0xf248b5ca Node 19 Genre user Class METER Instance 1 Index 32 Type bool
2018-05-13 19:24:08.937 Detail, Node019, Notification: ValueChanged
2018-05-13 19:24:08.938 Info, Notification: Value Changed Home 0xf248b5ca Node 19 Genre user Class METER Instance 1 Index 8 Type decimal

I stopped OZCP, started openHAB, which immediately detected the new things. Even before adding them, I could see status updates in the log. Already enjoying my victory, I added the things using Paper UI and merely edited the location. After saving, the party was over. No more updates, no matter what I do in Paper UI or HABmin.

When the status updates were working, I could see that the lifeline was set in the OZCP log:

2018-05-13 19:22:48.542 Info, Node019, Adding the controller to group 1 (Lifeline) of node 19
2018-05-13 19:22:48.542 Info, Node019, MultiChannelAssociation::Set - Adding instance 0 on node 1 to group 1 of node 19
2018-05-13 19:22:48.543 Detail, Node019, Queuing (Send) MultiChannelAssociationCmd_Set (Node=19): 0x01, 0x0b, 0x00, 0x13, 0x13, 0x04, 0x8e, 0x01, 0x01, 0x01, 0x25, 0xbd, 0xe7
2018-05-13 19:22:48.543 Info, Node019, Get MultiChannelAssociation for group 1 of node 19
2018-05-13 19:22:48.544 Detail, Node019, Queuing (Send) MultiChannelAssociationCmd_Get (Node=19): 0x01, 0x0a, 0x00, 0x13, 0x13, 0x03, 0x8e, 0x02, 0x01, 0x25, 0xbe, 0xe0
2018-05-13 19:22:48.544 Detail, Node019,   Expected reply and command class was received
2018-05-13 19:22:48.544 Detail, Node019,   Message transaction complete

If I now view the logs in OZCP, I get the errors shown in the first code block again (MultiChannelEncap for endpoint 1 for Command Class 32). No lifeline message. So, what’s the Z-Wave binding doing differently?

Wow. Didn’t expect no reaction. Anyways, I updated my installation to openHAB 2.3 stable (including the Z-Wave binding), excluded/included one of the DIN dimmer, but still no updates.

Sorry - I missed your previous message. I’ll try and have a read tomorrow…

As I’ve said elsewhere, this is quite a complex topic - there are MANY different ways to configure associations now, and different devices tend to want the configuration done differently (I think this is a mess in ZWave, but hey…).

Can you provide a debug log from the binding and I’ll have a look. Best thing to do is to click on the “reinitialise” button for the device in HABmin and send the log for the next 30 seconds or so.

Hi @chris, thank you very much for looking into this! I’ve sent you the logs via e-mail.

Thanks for the log. In this log, there are no commands from the binding to set the associations. There is an association already set in group 1 to report to node 1:0. This is an endpoint association and this looks fine to me and is inline with the latest ZWave spec for version 3 of the MULTI_CHANNEL_ASSOCIATION command class (which is what the device is reporting).

Below is the relevant section of the standards -:


What this tells me is that if I set a node:endpoint of 1:0 (as we see in the log above), then I believe the last line in the table is applicable (since we have an endpoint association type). In this case, the device should send non-encapsulated for anything coming from the root (ie endpoint 0), and it should be sent encapsulated if the data is coming from an endpoint other than 0.

If you read the above table different to me, then I’m happy to hear a different interpretation :wink: . This is all part of the mess that I refer to above - there are many options for setting the associations, and depending on how they are set, there are different options for how the data is then sent… :roll_eyes:

So, the next question is - what is the device sending? Does it send anything (there’s nothing in the log you sent)? I guess it is sending something as you showed some logs in the OZW log - it would be good to see what these are in the OH log (just because there was an error in the OZW log, doesn’t necessarily make it wrong for OH).

So, the next question is - what is the device sending? Does it send anything (there’s nothing in the log you sent)?

I just sent you another set of debug logs containing device inclusion, association setting and wall switch triggering. The binding only detects the presses, if I put the controller into association groups 2 or 3. But the associated items aren’t triggered.

I’ve just realised that you’re not using the latest version of the binding that has had the work to try and solve this. I think it will likely solve the issue here. The problem is that the device doesn’t report that it supports multiple channels in the NIF, so the binding doesn’t know about the other channels, and yet the device sends multi-channel data. The device then doesn’t decode this.

The new version should fix this issue as it adds a check to ensure that there are multiple channels before using the multi-channel-association class.

The manually installing the version here -:

You might need to exclude the device again to ensure it’s cleanly reset. If the problems still persist, then please provide a new log…

Oh, sorry. I thought I made it clear that I am/was using the OH 2.3 stable including the stable Z-Wave binding. I’ll install the test binding and report back (around the end of the week).

You may well have and I could well have just missed it (it’s quite likely), so I was just meaning that I’d only just realised.

Let me know if it helps (or not :wink: ).

Let me know if it helps (or not :wink: ).

I finally came around to testing this: You were right, after exluding/including the device with the/a test binding, button presses are finally detected as well. Thank you very much! :grinning:

I’m also having some troubles with ZMNHDD firmware 3.5 (status doesn’t work).

After the initiation the lifeline association is blank. If I set it to “OpenHAB controller” and then restart the service, the field is empty.

I’m using 2.4 0626 snapshot.

As @Nyarly states it works with the development version of the zwave binding I suggest changing to that one:

1 Like

Ok, they’re dated to the same date. Will check and report back. Is it enough to install the binding or do I need to reinit?

Edit: @nyarly excluded and included again.

As @sihui stated, I’ve used (or am currently using) the development binding dated June 19th 2018 with openHAB 2.3 stable.

I only had to delete and re-add the things for my fibaro roller shutters, motion sensors und rgbw controllers. My Qubino DIN dimmers and everspring plugs, however, had to be exluded, reset and re-included to work properly.

There is a somewhat recent discussion in that thread about the steps needed.

Yeah, cloned development and compiled with maven. Will check tonight.

Or just download the jar from the first post.