Status updates for Qubino Relays/Dimmers generally do not work

[chrisfuss (Christian)]

@chris

ok thx… I just replaced the relais with a second one brand new out of the box… could this be caused by the TEST version of the binding?

[chris (Chris Jackson)]

No - this should have nothing to do with the test binding. All changes in the test binding are after the device data is downloaded from the device.

[Matt77 (Matt)]

That’s strange cause it’s working perfectly fine with the binding included in snapshot version

[chris (Chris Jackson)]

I don’t think it’s strange. The point is I’m trying to modify the binding to use the new concepts that ZWave has defined so that it works with all devices. They have stated that we should now use the multi-channel association, and that it should work in a specific way, so I’m trying to do this so that Quibino and Fibaro devices will work properly.

The old binding only uses the old command class - the new binding uses the new concepts (or that’s what I’m trying to get right) so it’s now exposing problems with the implementation in the device.

I can change the binding to use the old system for this device, but it makes things mighty complicated to try and work out what system to use with what devices - especially when devices don’t work as they should. There are many combinations to support .

[Matt77 (Matt)]

Thanks for the clarification. I totally agree with you that it would not make sense to integrate the old way for this or any devices. It would only mixup things.
Thanks a lot for your efforts to get this integrated

[sihui]

@Matt77

Thanks a lot for your efforts to get this integrated

+1

[chrisfuss (Christian)]

@chris

ok so i downgraded to the snapshot version and see there its being recognized but no xml being generated.

thx for working on this!

13:16:15.593 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 2: Command received zwave:device:66a19f81:node2:switch_binary --> REFRESH
13:16:15.600 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling intialised at 1800 seconds - start in 50 milliseconds.
13:16:15.607 [INFO ] [thome.event.ItemChannelLinkAddedEvent] - Link 'Zw_sw_FF_FrontDoorLights_All_Switch-zwave:device:66a19f81:node2:switch_binary' has been added.
13:16:15.652 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling...
13:16:15.659 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 2: Polling deferred until initialisation complete
13:16:19.462 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 2: Command received zwave:device:66a19f81:node2:switch_binary --> ON
13:16:19.470 [DEBUG] [ndclass.ZWaveBinarySwitchCommandClass] - NODE 2: Creating new message for application command SWITCH_BINARY_SET
13:16:19.479 [DEBUG] [tocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
13:16:19.478 [DEBUG] [ave.internal.protocol.ZWaveController] - Message queued. Queue length = 1. Queue={}
13:16:19.486 [DEBUG] [zwave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0A 00 13 02 03 25 01 FF 25 4B 52 
13:16:19.492 [DEBUG] [ding.zwave.handler.ZWaveSerialHandler] - NODE 2: Sending REQUEST Message = 01 0A 00 13 02 03 25 01 FF 25 4B 52 
13:16:19.509 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8 
13:16:19.513 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'Zw_sw_FF_FrontDoorLights_All_Switch' received command ON
13:16:19.518 [DEBUG] [ave.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
13:16:19.523 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 4B 00 00 02 A2 
13:16:19.528 [DEBUG] [zwave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8 
13:16:19.535 [DEBUG] [ave.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8 
13:16:19.541 [DEBUG] [ave.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, callback=0, payload=01 
13:16:19.546 [DEBUG] [ol.serialmessage.SendDataMessageClass] - NODE 2: Sent Data successfully placed on stack.
13:16:19.552 [INFO ] [smarthome.event.ItemStateChangedEvent] - Zw_sw_FF_FrontDoorLights_All_Switch changed from NULL to ON
13:16:19.558 [DEBUG] [ave.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
13:16:19.562 [DEBUG] [zwave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 4B 00 00 02 00 00 AC 
13:16:19.564 [DEBUG] [ave.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 4B 00 00 02 00 00 AC 
13:16:19.567 [DEBUG] [ave.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=4B 00 00 02 
13:16:19.570 [DEBUG] [ol.serialmessage.SendDataMessageClass] - NODE 2: SendData Request. CallBack ID = 75, Status = Transmission complete and ACK received(0)
13:16:19.573 [DEBUG] [l.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Set, dest=2, callback=75, payload=02 03 25 01 FF 
13:16:19.576 [DEBUG] [l.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=4B 00 00 02 
13:16:19.579 [DEBUG] [l.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=SendData, callback id=75, expected=SendData, cancelled=false        transaction complete!
13:16:19.581 [DEBUG] [ave.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
13:16:19.584 [DEBUG] [ialization.ZWaveNodeInitStageAdvancer] - NODE 2: Node advancer - STATIC_VALUES: Transaction complete (SendData:Request) success(true)
13:16:19.586 [DEBUG] [ialization.ZWaveNodeInitStageAdvancer] - NODE 2: Node advancer - checking initialisation queue. Queue size 36.
13:16:19.589 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
13:16:19.592 [DEBUG] [tocol.ZWaveController$ZWaveSendThread] - NODE 2: Response processed after 94ms/2242ms.
13:16:20.975 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 2: Command received zwave:device:66a19f81:node2:switch_binary --> OFF
13:16:20.981 [DEBUG] [ndclass.ZWaveBinarySwitchCommandClass] - NODE 2: Creating new message for application command SWITCH_BINARY_SET
13:16:20.988 [DEBUG] [tocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
13:16:20.988 [DEBUG] [ave.internal.protocol.ZWaveController] - Message queued. Queue length = 1. Queue={}
13:16:20.996 [DEBUG] [zwave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0A 00 13 02 03 25 01 00 25 4C AA 
13:16:20.998 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'Zw_sw_FF_FrontDoorLights_All_Switch' received command OFF
13:16:21.001 [DEBUG] [ding.zwave.handler.ZWaveSerialHandler] - NODE 2: Sending REQUEST Message = 01 0A 00 13 02 03 25 01 00 25 4C AA 
13:16:21.011 [INFO ] [smarthome.event.ItemStateChangedEvent] - Zw_sw_FF_FrontDoorLights_All_Switch changed from ON to OFF
13:16:21.023 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8 
13:16:21.028 [DEBUG] [ave.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
13:16:21.033 [DEBUG] [zwave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8 
13:16:21.038 [DEBUG] [ave.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8 
13:16:21.040 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 4C 00 00 02 A5 
13:16:21.043 [DEBUG] [ave.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, callback=0, payload=01 
13:16:21.049 [DEBUG] [ol.serialmessage.SendDataMessageClass] - NODE 2: Sent Data successfully placed on stack.
13:16:21.053 [DEBUG] [ave.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
13:16:21.059 [DEBUG] [zwave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 4C 00 00 02 00 00 AB 
13:16:21.064 [DEBUG] [ave.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 4C 00 00 02 00 00 AB 
13:16:21.069 [DEBUG] [ave.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=4C 00 00 02 
13:16:21.074 [DEBUG] [ol.serialmessage.SendDataMessageClass] - NODE 2: SendData Request. CallBack ID = 76, Status = Transmission complete and ACK received(0)
13:16:21.079 [DEBUG] [l.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Set, dest=2, callback=76, payload=02 03 25 01 00 
13:16:21.085 [DEBUG] [l.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=4C 00 00 02 
13:16:21.090 [DEBUG] [l.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=SendData, callback id=76, expected=SendData, cancelled=false        transaction complete!
13:16:21.095 [DEBUG] [ave.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
13:16:21.100 [DEBUG] [ialization.ZWaveNodeInitStageAdvancer] - NODE 2: Node advancer - STATIC_VALUES: Transaction complete (SendData:Request) success(true)
13:16:21.103 [DEBUG] [ialization.ZWaveNodeInitStageAdvancer] - NODE 2: Node advancer - checking initialisation queue. Queue size 36.
13:16:21.106 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 2: Got an event from Z-Wave network: ZWaveTransactionCompletedEvent
13:16:21.109 [DEBUG] [tocol.ZWaveController$ZWaveSendThread] - NODE 2: Response processed after 95ms/2242ms.```

13:29:11.961 [DEBUG] [tocol.ZWaveController$ZWaveSendThread] - NODE 2: Timeout while sending message. Requeueing - 0 attempts left!
13:29:11.967 [DEBUG] [ol.serialmessage.SendDataMessageClass] - NODE 2: Got an error while sending data. Resending message.
13:29:11.975 [DEBUG] [ave.internal.protocol.ZWaveController] - Message queued. Queue length = 1. Queue={}
13:29:11.981 [DEBUG] [tocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
13:29:11.990 [DEBUG] [zwave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0E 00 13 02 07 60 0D 01 01 59 01 05 25 58 AA 
13:29:11.999 [DEBUG] [ding.zwave.handler.ZWaveSerialHandler] - NODE 2: Sending REQUEST Message = 01 0E 00 13 02 07 60 0D 01 01 59 01 05 25 58 AA 
13:29:12.017 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8 
13:29:12.024 [DEBUG] [ave.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
13:29:12.031 [DEBUG] [zwave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8 
13:29:12.035 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 58 00 00 02 B1 
13:29:12.038 [DEBUG] [ave.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8 
13:29:12.046 [DEBUG] [ave.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, callback=0, payload=01 
13:29:12.052 [DEBUG] [ol.serialmessage.SendDataMessageClass] - NODE 2: Sent Data successfully placed on stack.
13:29:12.058 [DEBUG] [ave.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
13:29:12.064 [DEBUG] [zwave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 58 00 00 02 00 00 BF 
13:29:12.071 [DEBUG] [ave.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 58 00 00 02 00 00 BF 
13:29:12.077 [DEBUG] [ave.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=58 00 00 02 
13:29:12.083 [DEBUG] [ol.serialmessage.SendDataMessageClass] - NODE 2: SendData Request. CallBack ID = 88, Status = Transmission complete and ACK received(0)
13:29:12.093 [DEBUG] [l.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Sent Message: class=SendData[0x13], type=Request[0x00], priority=Get, dest=2, callback=88, payload=02 07 60 0D 01 01 59 01 05 
13:29:12.099 [DEBUG] [l.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: Recv Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, callback=0, payload=58 00 00 02 
13:29:12.105 [DEBUG] [l.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=SendData, callback id=88, expected=ApplicationCommandHandler, cancelled=false      MISMATCH
13:29:17.009 [DEBUG] [tocol.ZWaveController$ZWaveSendThread] - NODE 2: Too many retries. Discarding message: Message: class=SendData[0x13], type=Request[0x00], priority=Get, dest=2, callback=88, payload=02 07 60 0D 01 01 59 01 05

[chris (Chris Jackson)]

@chrisfuss

i downgraded to the snapshot version

Why? I’m not sure what the point of this is?

[Alexus1211 (Alex)]

@Daniel_Linder @chris:
I want to share some information regarding Qubino devices, especially when it comes to inclusion/exclusion procedures. These devices are really very sensible when it comes to this and somehow they showed different behaviours when:

• auto Inclusion is done / manual inclusion through toggling I1 3 times fast.
• manual inclusion using service button

the second procedure managed always to get me into problems and the recognition procedure always hanged at some point (mostly at initialising endpoints). I managed to overcome this by doing:

• hard reset using service button (long press above 6s)
• disconnect from power
• activate inclusion on opnehab
• connect to power
• wait for auto-inclusion to start
• bare in mind that sometime it took up to 10mn until the device is completely recognised.
• what helped also that switch on I1 is not set
• qubino device is near to openhab controller up to 1m range.

Please note that I’ve been using the dev branch since December last year and that this info is long before Chris started doing the latest modifications. The qubinos I used are all single relays, dimmers or rollershutters and one smart meter. All of these devices are fully functional (controllable, they send W and kWh reports) except for the one issue mentioned earlier in this blog regarding the smart meter. I guess I should test with a flush 2-Relais device to see if any issues might occur.

Hope this helps

[fremel75 (Fredrik Melin)]

Uploaded my debug log to your site

I used your latest test version.
Deleted xml files and logs and restarted

Node 5 a flush dimmar hangs on Node initialising: Endpoints
Node 17 a flush 1D also hangs at Node initialising: Endpoints
node 6, 7, 19 the Flush 2 relays are working correct with physical button and response back

[chris (Chris Jackson)]

Thanks - I’ll take a look tomorrow. I’m encouraged by the fact that at least some devices are working .

[chrisfuss (Christian)]

I did that because with the TESTING version my qubino nodes hang unrecognized no matter how often I tried to exlude or include… removed the testing version of the binding installed the one from the openhab snapshot via paper ui and there you go it recognizes the qubino nodes… why? i dont know im am just trying to get them to work… now i can switch the lights on and off via openhab but the switches connected to the node are not sending anything to openhab

seems like i am not the only one with recognizing problem

[chris (Chris Jackson)]

Ok, that’s fine if you want to go back to the old version, but it doesn’t help at all with the testing so I’m a bit confused what the logs you posted are…

[chrisfuss (Christian)]

just thinking this might be helpful with what you are doing but…
ok i just replicated it… i can include a quibo switch with the snapshot release that comes with openhab and it will be available after i update to your testing version, then i try to include another switch with the new testing version and it will be stuck not being recognized showing as nodeXX…
i can switch the switch by software but the hardware switch does have zero effect…

[Daniel_Linder]

Hi all,
I have taken a day off from openhab,
Will start testing again today, and get Chris some logs.
One thing that I’ve been thinking about is whether we might sit on different firmware revisions - what causes different behaviour?
When checking “upgradeability” with Qubino, they made it clear that it could be done by them - but I have to send the switches back to the retailer (in my case m.nu) who in turn has to send them to Qubino.

[automatic (Allen)]

@Alexus1211

hard reset using service button (long press above 6s)

Qubino clearly warns not to use the Service Button for modules which are connected to mains voltages. The following warning can be found in all Qubino manuals that I have seen so far:

Are you perhaps using 24V connected devices?

I have tried exactly what you are stating above many times, except that I did reset by pressing I1 five times within within 3 seconds (as the manual recommends for mains connected devices). This has not solved the reporting problems in my case.

Please let us know if your devices are connected 24V, maybe that makes a difference. If not connected to 24V, I’d be surprised that you didn’t blow up your Qubinos by pressing the Service Button like you are recommending

[chris (Chris Jackson)]

I’ve made another update. It might help in some instances as it improves the order that initialisation is performed on some command classes that are dependant on each other. It won’t help the devices that are stuck on initialisation though - I’ve asked Qubino what is happening here as the device is just not responding to a request that is mandatory in the requirements.

I also rechecked everything with my double relay (ZMNHDB) and it’s working fine. I will try and get hold of some other devices to test…

@Matt77 please also try this new version as I now use the old command class in some instances to try and avoid the problem we see above.

Please provide debug logs if it doesn’t work…

[Matt77 (Matt)]

@chris it’s working now for me. thanks a lot

[chris (Chris Jackson)]

Thanks. One down…

[automatic (Allen)]

@chris

I’ve made another update.

Hi Chris,
I would like to test your latest version. Is the below still the valid link, or can I just update my snapshot repo apt installation?

Status updates for Qubino Relays/Dimmers generally do not work

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