Status updates for Qubino Relays/Dimmers generally do not work

[domoticaundici (Stefano Pecoraro)]

hello,
i’m doing tests over tests with my RPI3 + AeonLabs Z-Stick gen5. i’m trying with openhab version 2.2.0 release build and 2.3 snapshot. it seems 2.3 zwave binding going better, updates regulary device parameters while 2.2.0 gives an error.
Qubino ZMNHBD1: channels switch_binary and switch_binary3 switches both relays. when an input is pressed the relative channel (switch_binary1 or switch_binary2) is not updated, the only one updates is switch_binary. for the power metering is the same.
Phlio PAN04-1B: behaviour is exactry the same as for Qubino ZMNHBD1
Qubino Smart meter: the only way to make it works is been polling the device instead of wait for datas. received datas are correct but it’s not possible to imagine to poll for any device.
Finbaro Dimmer2 FGD-212: currently i have no push button on input, i only change dimming value from interface. here, as before, the only way to get updated power consumption is to poll the device.

how to fix this behaviour?
thanks

[domoticaundici (Stefano Pecoraro)]

also:
Qubino ZMNHAD1 Flush 1 relay: no way to get input states for i2, i3

checking communication by openzwavecontrolpanel the results are the same.

in habmin, association groups seems to be ok:
qubino devices: lifeline -> openhab controller

phlio devices: relay1+2 -> openhab controller as well as relay1 and relay2

[Kjamsek]

For most of the issues mentioned by @domoticaundici the cause of the issue is in setting the singlechannel or multichannel lifeline associations that are used by Z-Wave devices to report unsolicited state changes.

In case a device support the MultiChannel CC, and as such implements endpoints, then a multichannel lifeline should be set via the use of Multichannel Association Set multichannel Node ID and endpoint fieldcombinations.

In case a device doesn’t support Multichannel CC, and as such does not implement endpoints, then a singlechannel lifeline association should be set via the use of Association Set and Node ID fields.

Without these two association settings in place (depending on which one applies to your device) you WILL NOT see state changes being reported to the controller on any Z-Wave Plus device.

[stefan.hoehn (Stefan Höhn)]

I documented how I did update to 2.3.0 as openhabian-config did not work for me:

see here:

First major update in 2.3.0-SNAPSHOT

Even though I couldn’t get it to run through the openhabian-config, @omr was so kind to explain to me how it could be done manually cat /etc/apt/sources.list.d/openhab2.list shows the old content. Change the file (e.g. with nano) to have the following content deb http://openhab.jfrog.io/openhab/openhab-linuxpkg unstable main After changing file, do: sudo apt-get update sudo apt-get upgrade What could have worked though in openhabian config is to go into 40 openhab-related and then switc…

and here

How to use the Fibaro Keyfob and to manage challenges around it

Certainly: (I only know ‘how to’ with ubuntu-server 16.04 LTS, but is probably the same) OH2: omr@shs2:~$ cat /etc/apt/sources.list.d/openhab2.list deb http://openhab.jfrog.io/openhab/openhab-linuxpkg unstable main omr@shs2:~$ After changing file, do: sudo apt-get update sudo apt-get upgrade Z-wave binding: First uninstall from PaperUI. Download from here Goes into: /usr/share/openhab2/addons/ Do not re-install from PaperUI You might need to install this from karaf: (if no nodes are…

[domoticaundici (Stefano Pecoraro)]

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.

[aveseli (Adnan)]

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

Qubino Dimmer Firmware 3.7 reporting wrong status

Forgot: I am running OH 2.2 stable with an Aeotec Gen5 USB Stick.

Does someone experience the same behaviour?

[Nyarly (Jan)]

@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?

[Nyarly (Jan)]

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.

[chris (Chris Jackson)]

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

[chris (Chris Jackson)]

@Nyarly

So, what’s the Z-Wave binding doing differently?

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.

[Nyarly (Jan)]

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

[chris (Chris Jackson)]

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 . 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…

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

[Nyarly (Jan)]

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.

[chris (Chris Jackson)]

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 -:

OH2 Z-Wave refactoring and testing... and SECURITY

The latest version of the development binding dated 8th Sep 2018 is here. Toward the end of last year I spent some time doing some initial refactoring of the ZWave binding in OH2. This focussed on rewriting the way transactions work as this is an enabler for other areas of the code. At the same time I also restructured the different layers of the binding to make things cleaner, and done some changes to support a system of autocoding the command classes directly from the Z-Wave standard which s…

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…

[Nyarly (Jan)]

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

[chris (Chris Jackson)]

@Nyarly

I thought I made it clear that I am/was using the OH 2.3 stable including the stable Z-Wave binding.

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

[Nyarly (Jan)]

Let me know if it helps (or not ).

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!

[EdgeSystems (Niclas Larsson)]

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.

[sihui]

@EdgeSystems

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:

OH2 Z-Wave refactoring and testing... and SECURITY

The latest version of the development binding dated 8th Sep 2018 is here. Toward the end of last year I spent some time doing some initial refactoring of the ZWave binding in OH2. This focussed on rewriting the way transactions work as this is an enabler for other areas of the code. At the same time I also restructured the different layers of the binding to make things cleaner, and done some changes to support a system of autocoding the command classes directly from the Z-Wave standard which s…

[EdgeSystems (Niclas Larsson)]

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.