Status updates for Qubino Relays/Dimmers generally do not work

Is it already merged? I can do some testing

Just click on the link and take a look if it says “Merged” … :grinning:

Yes - but note that it’s merged into the development branch.

See here -:

It gets hard to keep track on all those changes :sunglasses: … not only with the zwave binding.

Hi Chris

First of all, many, many thanks for the work you put into this. :grinning: I saw you had to change quite a bit of code, and really appreciate your work. I am sure that all the Qubino users are equally grateful for any progress we can make with regards to device support.

Now I am not quite sure what needs to be done to successfully implement your fix:

  • Swap jar with the one you provided in the link in your post above. Do I have to do a bundle:uninstall org.openhab.binding.zwave in Karaf or is it enough to just trade the jars (including restart of OH)?

  • Do I need to delete existing Things including xml’s (I would suppose so).

  • Do I need to do anything else?

Thanks for pointing me in the right direction and perhaps providing some instructions on how to implement your improvement correctly.

Yes “unfortunately” I’ve put this into the development version which means you will need to change to use this. If you take a look at the top of the thread below (say, the first 5 or 6 messages) then you’ll see what’s needed to install.

Fundamentally, you will need to change over the JAR to the new JAR, delete all your things and add them back again (no need to exclude the devices - just remove the things). The XMLs can be deleted, but the format is very slightly different so in any case they will be regenerated - if you delete them, then you will avoid seeing an error in the log to say that it couldn’t be read properly.

In the link below there’s a link to the latest JAR with these changes, so please use this instead of the one at the top of the thread (I will likely update this shortly). I certainly welcome any feedback - I tested this against a 2 relay switch, so I hope it also works for you :slight_smile: .

Updated yesterday from 2.1 dev to 2.2 dev and no issues so far … :grinning::+1:

Thanks @sihui - did you previously have issues with the Qubino dimmers (ie has it solved this problem for you?).

Argh, really sorry, misunderstanding: my post was meant as a general remark to the 2.2 dev binding. I don’t have any Qubino devices :joy::sunglasses:

Im using SNAPSHOT version, will the automatic update work and give me version?

I got this error when try to manualy add JAR:

2017-10-06 15:35:02.419 [WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.zwave-2.2.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zwave [15]
  Unresolved requirement: Import-Package: com.google.common.collect

        at org.eclipse.osgi.container.Module.start(Module.java:444) [?:?]
        at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) [?:?]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1253) [8:org.apache.felix.fileinstall:3.6.0]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1225) [8:org.apache.felix.fileinstall:3.6.0]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:512) [8:org.apache.felix.fileinstall:3.6.0]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:361) [8:org.apache.felix.fileinstall:3.6.0]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:312) [8:org.apache.felix.fileinstall:3.6.0]
2017-10-06 15:35:03.422 [WARN ] [org.apache.felix.fileinstall        ] - Error while starting bundle: file:/usr/share/openhab2/addons/org.openhab.binding.zwave-2.2.0-SNAPSHOT.jar
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zwave [15]
  Unresolved requirement: Import-Package: com.google.common.collect

        at org.eclipse.osgi.container.Module.start(Module.java:444) [?:?]
        at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) [?:?]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle(DirectoryWatcher.java:1253) [8:org.apache.felix.fileinstall:3.6.0]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles(DirectoryWatcher.java:1225) [8:org.apache.felix.fileinstall:3.6.0]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:512) [8:org.apache.felix.fileinstall:3.6.0]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:361) [8:org.apache.felix.fileinstall:3.6.0]
        at org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:312) [8:org.apache.felix.fileinstall:3.6.0]

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