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 
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ā¦ā )
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ā¦
Thanks. Iāll try a completely different configuration tonightā¦
Hi,
I am also having issues with my Qubino flush relais I am trying to add it to my fresh openhab installation however it does not get recognized shows as āNode 2ā I used the test version from above however no success. Also there is no XML created for the node.
Appreciate your guys help!
Christian
01:23:06.468 [INFO ] [ig.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:af64e359:node2' to inbox.
01:23:06.470 [INFO ] [smarthome.event.InboxAddedEvent ] - Discovery Result with UID 'zwave:device:af64e359:node2' has been added.
01:23:06.479 [INFO ] [smarthome.event.BindingEvent ] - org.openhab.binding.zwave.event.BindingEvent@105a657
01:31:56.878 [INFO ] [smarthome.event.InboxRemovedEvent ] - Discovery Result with UID 'zwave:device:af64e359:node2' has been removed.
01:31:56.968 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:af64e359:node2' changed from INITIALIZING to OFFLINE (BRIDGE_OFFLINE): Controller is offline
01:31:56.970 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:af64e359:node2' changed from UNINITIALIZED to INITIALIZING
01:31:57.005 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:af64e359:node2' changed from OFFLINE (BRIDGE_OFFLINE): Controller is offline to ONLINE```
01:41:28.391 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:af64e359:node2' changed from REMOVING to REMOVED
01:41:28.401 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:af64e359:node2' changed from ONLINE to REMOVING
01:41:28.441 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:af64e359:node2' changed from REMOVED to UNINITIALIZED
01:41:28.538 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'zwave:device:af64e359:node2' changed from REMOVED to UNINITIALIZED (HANDLER_MISSING_ERROR)
01:41:37.522 [WARN ] [zwave.discovery.ZWaveDiscoveryService] - NODE 2: Device discovery could not resolve to a thingType! 7FFFFFFF:7FFFFFFF:7FFFFFFF::0.0
01:41:37.545 [INFO ] [smarthome.event.InboxAddedEvent ] - Discovery Result with UID 'zwave:device:af64e359:node2' has been added.
01:41:37.544 [INFO ] [ig.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:af64e359:node2' to inbox.
01:41:37.583 [INFO ] [smarthome.event.BindingEvent ] - org.openhab.binding.zwave.event.BindingEvent@1a041d8
01:42:07.558 [INFO ] [smarthome.event.BindingEvent ] - org.openhab.binding.zwave.event.BindingEvent@167b65cIt looks like the device isnāt communicating and the binding hasnāt downloaded the manufacturer information. This is not related to the issue being discussed here regarding status updates though.
Hmmm - me thinks this device does not comply with the standards!
As specified by the Multi Channel Command Class, a Root Device must not use Multi Channel
encapsulation when communicating to another Root Device, i.e. if both End Points are zero. It does
however still make sense to create an End Point Association from one Root Device to another Root
Device, e.g. a gateway.
Currently this is what Iām doing (ie creating the endpoint association), but the device is encaspulating even though the source and destination endpoints are 0 -:
I think somewhere you sent me the XML for this device but I canāt find it - can you take a look and see if the multi instance association command class version is 3? Iām reasonably sure it was, but I canāt find the file. If it is, then IMHO the device is not compliant to the standards based on what I read above and Iāll have to see if I can make it work another way 
.