Status updates for Qubino Relays/Dimmers generally do not work

Please use the latest version that I’ve just posted and if (probably when) it doesn’t work, please send me a complete log of the startup. You must reinitialise the device, so either delete the XML before restarting the binding, or, wait until things have initialised, then use the “reinitialise” option in the thing menu to perform a reinitialisation.

I’ve added a bit more debug into the binding so hopefully this will help me see what’s happening.

Hi Chris,
Followed your instruction.

Node4: Living Room Ceiling light: Qubino Dimmer Zwave+
Node7: Lounge Ceiling Light: Qubino Dimmer Zwave+
Node24: Kitchen Ceiling Lights: Qubino Flush 2 relay

xml:s deleted
Nodes re-initialized

Openhab restarted 17:12

Results:
Nodes 4 and 24 seems to intialize correctly.
Node 7 is stuck at “initializing endpoints” in Habmin.
No xml created for Node 7.

Node 4, 7 and 24 has full functionality from PaperUi.
None of the nodes updates status in openhab when the “hardware inputs” are used.

I created a ticket and uploaded a log to http://www.cd-jackson.com

Thanks. Unfortunately the log seems to start after the initialisation is complete (sorry).

Ok. I see. The log rotation must have happened right at that moment… :tired_face:
Will do another try. Sorry for that.

1 Like

New log uploaded.

Please try this version. I’ve given this a new name just for now in case this has some strange side effects.

@Matt77 you might also want to try this as it has an attempt to also fix your door sensor which is related I think.

Delete the XML file before restarting so that it reinitialises the device and hopefully sets the associations this time! If not - it’s more logs please :wink:

Hi
Tried the “TEST” binding.
In Habmin in looks fine, unfortunately no change in behaviour.
(uploaded new logs)

Would it make any difference if I exclude and include the devices from the z-stick?
(it is a bit tedious to to that, since the qubinos are a but kinky when it comes to inclusion/exclusion)

No- it won’t make any difference.

Thanks for the logs - I’ve made another update (same link as previous)…

Unfortunately no difference in behavior.
New log uploaded.

The setting looks ok this time (at least on 4 and 24) but I don’t see any association messages being received.

Can you grab a short log with just the manual change of the switches?

Thanks.

@chris
with the test binding i got issues with the DanaLock so i deleted the xml to re-initialize the lock.
also deleted the XML for the door/window contact.
current status. no XML generated lock (node32) and door/windows sensor (noe34) hanging in “node initializing: Set_Association”

openhab.xml (899.5 KB) ZIP file

Interesting one… I’ve made a change that I hope will fix the issue here…

No action/loggs on physical inputs. Uploaded a log for toggling the nodes via openhab.

Please try again with the latest update - remove the XML and restart so everything reinitialises…

the “node initializing: Set_Association” is fixed. however my initial problem is still the same (node 36) COMMAND_CLASS_MULTI_CHANNEL not found
openhab.xml (672.1 KB) ZIP file

And another version… Again- delete XML etc so it completely reinits…

There are so many (too many!) damn combinations of single instance, multi-instance options…

Still no difference.
I awaiting further directives from you Chris.
(even if it is -“Scrap the qubinos and get yourself fibaros…” :wink: )

No - this needs to get resolved as I think Fibaro is also now using this new strategy.

Can you provide the log again. I think the issue now (maybe!) is that the lifeline group needs resetting and I want to see if this is being sent. If it is, then my next course of action is to speak to Qubino again…

same here with the fibaro, COMMAND_CLASS_MULTI_CHANNEL not found

openhab.xml (929.8 KB)