Hi there, I’ve just installed a second Qubino Flush 2 Relay and added it to my Zwave network. I’m now having trouble receiving status updated for the two separate switches it contains when using the hardware switch.
When toggling the switch, the Qubino correctly toggles the connected light. The Zwave binding receives a status update for switch_binary. However, this channel reports changes for either of the hardware switches. There are separate channels switch_binary1 and switch_binary2, but those never get updated.
I’ve tried adding the controller to all of the 8 available association groups, but this changes nothing. Stupid thing is, I’ve got another Qubino connected and that one is working fine. The difference is the version of the devices: the working one is reported as Type / ID 0002:0001, Firmware Version 1.12, while the misbehaving one is reported as Type / ID 0002:0051, Firmware Version 1.2. The node XMLs are different, but I’m not sure if the differences have anything to do with the problem.
Anyone having the same problem? Or better, know how to fix?
There is a known issue where the Qubino don’t use the multi_instance class, and this is likely the issue here, but please provide a logfile of the data that is received.
I have a feeling that this might be solved in OH2 with the recent addition of the multi_instance_association, but I don’t have the device to test…
@chris Sorry, forgot to mention. I’m using the latest OH2 snapshot from August 3.
You can find a log file at https://dl.dvelop.nl/oh2/openhab.log. The problematic node is 12. I’ve first toggled the hardware switch ON on 15:39:26, you can see the event come in. At 15:40:53 I used the web interface to turn ON again (it didn’t know it was on) and then OFF. This works fine.
Sorry - I’ve not had teh chance to look through the logs as I’ve been working on other things. As I stated above, this is a known issue - it has also been an issue with other controllers, so isn’t just a problem with OH (I know at least OZW also can’t get this feedback properly with Qubino).
I read something that said that Qubino devices might change into multi instance mode if they are sent a frame with the multi instance association, but I can’t currently confirm this.
Anyway, I will take a look over your log in the coming days - please be patient.
I’ve had a look through the log and it’s as I expected. The device is not using the multi instance mode to send these notifications, so there’s no way to distinguish between the two switches.
I’ve read something somewhere that (I think) stated that you can enable multi instance mode in these switches by sending a multi instance association message (or something), but I can’t find this message now. I’ve recently added multi instance association capability to the binding, but it’s not well tested.
Unfortunately I’m still trying to sort out some other issues, but when I get some time I will try and look into this further - I need to get a new switch anyway so will order one of these an hope I can get it working!
The device will send unencapsulated reports (which in a multi channel context would correspond to endpoint 0 – the root device) in case no Multichannel Association is set on the device. This was done in order to ensure max interoperability of legacy controllers as instructed by Sigma designs support, since the module cannot know whether that class is supported by the controller.
When a Multi Channel Association is set to either one of the lifeline groups or a specific group on an endpoint then the data would arrive encapsulated. If endpoint 1 (that is controlled via I1) would report data it would report it to node 1 (the controller) in an encapsulated message with the source endpoint being 1 and destination ednpoint 0. If I2 would be triggerred then reports would arrive encapsulated with source endpoint 2. Endpoint 3 would send encapsulated data to the controller in case a temperature sensor is connected.
Ok - thanks. I think currently the binding will use the single instance association most of the time unless it’s actually wanting to set a destination instance that is not the root. I will change this and we can see if it helps.
I’ll try and do this today - it should be a quick change.
That was fast I’ve created a build of the binding and got it running in OH2 (I confirmed this by seeing the newly added “Synchronize network” action for the controller and checking the OSGi bundle version).
Unfortunately the behaviour seems to remain the same. I’ve tried re-adding the device in OpenHAB, and used the re-initialize action a couple of times.
Unfortunately it didn’t set the association since it is already set - I think you need to force it… The issue is that the binding sees that its node is already set in the device, but it doesn’t know that it was set previously using the single instance, and it needs to set it again using the multi-instance (if that makes sense). Basically, the single and multi instance versions map to each other as required in the zwave standard…
I would try setting the lifeline group to another node, then setting it back to the controller. This should update the device with the multi-instance version. Grab the log and send it over again if it doesn’t work…
Wouldn’t removing the thing completely from OpenHAB also force this? Anyway, I did as you suggested, setting all associations to another node and then back to the controller. No change in behaviour, this is the log: https://dl.dvelop.nl/oh2/oh-associate.log
Is there anything else I could force to refresh/reload?
I’ve got two more Qubino’s, I’ll also try adding one of those today.
No - removing the thing will make no difference to the configuration inside the device. If you exclude the device from the network, and include it again, then yes, this will do it.
This time it has sent the multi-instance set for group 1, but there are two versions of this command and since this one has apparently not worked (you didn’t say, but I assume the reports are still using not using multi instance encapsulation?) I will change the system to use the other alternative.
Give me 10 minutes or so and I’ll create a new PR.
Edit:
Additionally something else seems to go on. I can’t change the Default reporting group association to the controller anymore. Either updating the association or displaying it (in HABmin) fails. I changed it to Node2 and now it’s stuck there. Not sure if this has anything to do with your changes.
I’ll need to spend a bit more time to look at this, but at least now we have it reporting endpoints which is a BIG step forward. From here, I’m sure we can solve this.
I’ll try and take a look at this later this evening if I get the other stuff I’m working on sorted…
Well, I removed the code producing the log message about swapping endpoints (ZWaveMultiInstanceCommandClass:454-465), and now it works!
I’m sure it was added for a reason :p, but Git history is lost with the repository switch.
Let me know if I can do anything else to help determining the right way to do this.
This was added to support a specific device - I forget what one now (it wasn’t added by me but I know who so I can find it). I’ll take a look over the next few days, but given this is working ,you have something to use and I’m happy for now (as I’m sure are you ).
Regarding this comment - is this covered in your log? If not, can you provide an updated log please. The multi-instance association stuff is pretty new, so it’s quite possible there are issues here.
I’ve created a build of the binding and got it running in OH2 (I confirmed this by seeing the newly added “Synchronize network” action for the controller and checking the OSGi bundle version).