Status updates for Qubino Relays/Dimmers generally do not work

any more breaking changes to expect if I switch to the dev binding now?

I will Need to Switch to the dev Version Soon…

Probably not for a little while, but yes, I do have other changes in mind which will require a reconfiguration (ie it is a breaking change).

You need to uninstall the old binding first, then drop the new binding in your addons folder.
Depending on your installation you also may need to install the serial binding:

OK @chris , so last night I upgraded from 2.1 release to snapshot, and also the zwave binding, to see if my Qubinos would start to behave more rationally.

While everything is working, the Qubino dimmer that I was testing, did not seam to change by simply updating. Do I need to delete the thing, or exclude the Qubino for the changes to take effect?

Is there a known issue with debug outputs on this release? The zwave binding does not spit out any debug information, even though I have set it to ‘DEBUG’ level? It is totally silent in Karaf/log:tail. I still get info from other bindings…

If you are updating to the development version for the first time, then yes, all ZWave things must be deleted or they won’t work. The configuration is quite difference in this version.

No - it should work fine.

Sorry, should have mentioned that I was using the development 2.1 binding before going for the 2.2.

Do I still have to delete or exclude the Quibinos?

No, but you will need to reinitialise them - either by using the reinitialisation option in the menu, or by deleting the XML files before starting the binding. Otherwise it will skip past the part that initialises the lifeline that (hopefully) does all the magic :wink: .

6, almost 7 hours has passed, after I deleted two qubino dimmers xmls. One of them, node 79 has still not come out of initialisation - it seams to be stuck at “ASSOCIATIONS”. This node has second button as input to an OH rule controlling the other Qubino dimmer, not that I think this is relevant.

Now, it always takes a lot of time for my zwave network to come back after a restart and be responsive, but this seams a bit too long for the one node.
There’s still two battery nodes that are also waiting, which is normal - but could they hinder node 79 to progress in its init sequence?

If I control it from webui, the node works - i can dim it up and down, and its second button does control the other light over an OH rule.

Sounds too long… If you have a log, feel free to send it over (create a ticket on my website). If it’s stuck in a specific place, then if you can get a log showing a few cycles of repetition that would be good.

I have try to manually add JAR, but the ZWAVE devices was not working at all, I have switch back to my SNAPSHOT: unstable/main openhab2 all 2.2.0~20171008013406-1

This works fine, but does it have Chris qubino FIX?

I experience the exact same issue with qubino dimmers.

now i’m using openhabian with OH 2.1 stable, does switching to OH 2.2 unstable using openhabian-config result in using fixed z-wave development version ? or I have to install the jar manually ?
PS. I understand that it is not possible to use fixed z-wave binding with OH 2.1 ?

No, you need to install it manually.

There are three version of the zwave binding: stable, snapshot, development.

If you are on a stable openHAB2 runtime version, you cannot update to the snapshot or development version of the zwave binding (and it does not make sense because changes in the binding do not match the openHAB runtime)

If you are on a snapshot openHAB runtime, you can update the snapshot zwave binding with simply uninstalling it through PaperUI, wait a minute, install it again.

If you are on a snapshot openHAB runtime, you can update to the zwave development version of the binding by uninstalling the snapshot zwave binding, download the development version of the zwave binding and drop it into the addons folder. In this case you may also need to install the serial transport dependency manually through the console.

I know it gets complicated sometimes, but all this is necessary to not break the system for users using openHAB stable and at the same time implement new features/fixes for users on unstable openHAB2 runtime versions so they can test it (for the benefit of the next stable release).

1 Like

perfectly clear for me, thanks :slight_smile:

After my initial test of develoment and qubino response

i deleted the things, removed zwave binding(paper-ui),deleted zwave xml’s, stopped openhab2 service, copied new zwave jar, started service, logged on console and feature:install openhab-transport-serial
my 3 units of flush2relay works right away
my only flushdimmer does not work
a whole bunch of flush1relay does not work
Not tested yet flush1d and flush shutter DC

Then i had some new units newer used before.
Started with a flush1relay and it is working!
Next i tried a flushdimmer and that also worked!

What am i missing or what can i try?
Do you want any logs of this and what should they contain?

Thanks for looking into this, Chris! I have one Flush 2 relays unit that I’ve never got switch status updates from in OpenHAB and I hoped your fix would solve it. Unfortunately, this is not the case, yet.

According to the instructions in this thread, I have removed the unstable variant of the Z-Wave binding and dropped your jar file into addons. This works fine, and after removing devices in Paper UI and re-adding them from the inbox I can control Z-Wave devices from my main UI. Other devices, such as a NodOn wall plug, sends a status update when I switch it directly on the plug and the UI is updated within a seconds. However, the Flush 2 relays status is not updated at all.

It should be noted that even though I set the log level for the Z-Wave binding to DEBUG, there are no log messages at all when I switch one channel on the Qubino device using a wall switch.

I recall reading that Qubino devices may behave differently depending on how the controller was acting when it was included in the Z-Wave network. So, despite your instructions earlier, is it possible that I actually have to exclude and re-include the Qubino device? I have not managed to get exclusion working from Habmin, so before trying that, it would be good to know if there is a chance that it solves the problem.


There must be something wrong with your setup or the way it’s configured since logging should work. You need to find out what’s up with this first.

It’s unlikely unless you have changed the configuration (ie the endpoints - added thermometers or something).

Sorry - I’m a bit confused what’s wrong. Do you mean that new devices work, and old ones dont?

There must be something wrong with your setup or the way it’s configured since logging should work. You need to find out what’s up with this first.

Sorry for being unclear. Logging works fine when e.g. changing a switch in the UI. It’s when I push the switch on the wall (and the lamp lights up) that nothing is seen in the log. I suspect this is because the Qubino device actually doesn’t send any messages.

It’s unlikely unless you have changed the configuration (ie the endpoints - added thermometers or something).

No, I haven’t changed anything in the configuration.

Ah - ok, sorry, my misunderstanding :blush:.

So, in that case I suggest to reinitialise the device and send me the log. I want to see what happens during the initialisation. Best is to create a ticket on my website ( and you can attach large files there (you’ll need to register to see this option to open a ticket).