Status updates for Qubino Relays/Dimmers generally do not work

rozpruwacz · January 7, 2018, 6:26pm

no need for any step from 1 to 5. you have to

enable the i2 endpoint
exclude the device BUT WITHOUT RESETTING IT ! this is important because if You reset the device it will disable the i2 endpoint, and it is easy to accidentally reset the device (5 click instead of 3 - well i thing that the qubino designers ware drunk when they was designing this device …)
include the device
add it as new thing

after that you should have new thing in OH (new z-wave node ID).
Before you do all of this read carefully the user manual to make i2 endpoint configuration properly.

Personally I believe that this is totally over complicated but this is how the qubino dimmer is designed …

smar · January 7, 2018, 6:35pm

@chris I’m still struggling getting endpoints to report on ZMNHBD Flush 2 relays, firmware 1.1 (I note you did your testing on 1.2). I have just factory reset the device and re-included it - the newly assigned node number is 42 in the attached logs.

It is recognised as a multichannel device. However, pressing the physical switches are only being reported on endpoint 0 (see at log times 18:09:50) instead of endpoint 2, which is the switch being pressed. I have tried adding the controller to to the Q1 and Q2 Switch binary associations, but still no luck - see 18:14:37.

Is there anything else I can try or any other logs I can give you to help in finding a solution?

network_ede3f11f__node_42.xml (25.6 KB)
zwave.log.zip.xml (496.0 KB)

Daniel_Linder · January 7, 2018, 6:45pm

I have never managed to get my flush 2 relays firmware 1.1 to report on anything but endpoint 0. Not with Openhab nor with Vera.
Replaced one device with a new one (firmware 5.0). It immidiately worked, reporting on the individual switches. I reported this back to where I bought the qubinos 18 months ago. Was immidiately offered replacements FOC. I believe the firmware 1.1 devices are bad, and a waste of time.

ypoosn · January 7, 2018, 8:59pm

Hi,

enable the i2 endpoint

exclude the device BUT WITHOUT RESETTING IT ! this is important because if You reset the device it will disable the i2 endpoint, and it is easy to accidentally reset the device (5 click instead of 3 - well i thing that the qubino designers ware drunk when they was designing this device …)

include the device

add it as new thing

after that you should have new thing in OH (new z-wave node ID).
…

the problem is that I don’t manage to exclude the device without resetting it.
The last thing I already did several times but the exclusion without losing settings
does not seem to work with triple click I1.

This is from the qubino manual:

connect module to power supply
bring module within maximum 1 meter (3feet) of main controller
enable add/remove mode on main controller
press push I1 five times (in this case only 3 times not to reset parameter) within 3s in the first 60 seconds after the module is connected to the power supply

Executing Step 3) doesn’t seem to work properly because I get an error in the log when I activate
Habmin → Remove Device from Controller.

I am using the Z-Wave USB Stick.

So the following step 4) is not recognized by the module properly.

Here is the log:

21:44:51.257 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 15: Configuration update received
21:44:51.285 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 15: Configuration update action_remove to true
21:44:51.299 [DEBUG] [lmessage.RemoveFailedNodeMessageClass] - NODE 15: Marking node as having failed.
21:44:51.306 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 255: Adding to controller queue
21:44:51.311 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 255: Added to queue - size 1
21:44:51.316 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start
21:44:51.321 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction from controllerQueue
21:44:51.327 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - getTransactionToSend 6
21:44:51.336 [DEBUG] [zwave.internal.protocol.SerialMessage] - Assembled message buffer = 01 06 00 61 0F 01 22 B4 
21:44:51.343 [DEBUG] [ding.zwave.handler.ZWaveSerialHandler] - NODE 255: Sending REQUEST Message = 01 06 00 61 0F 01 22 B4 
21:44:51.350 [DEBUG] [ding.zwave.handler.ZWaveSerialHandler] - Message SENT
21:44:51.358 [DEBUG] [ve.internal.protocol.ZWaveTransaction] - TID 63: Transaction Start type RemoveFailedNodeID 
21:44:51.366 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
21:44:51.377 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=null[0x00], type=ACK[0x02], dest=255, callback=0, payload=
21:44:51.368 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 63: [WAIT_RESPONSE] requiresResponse=true callback: 34
21:44:51.384 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=null[0x00], type=ACK[0x02], dest=255, callback=0, payload=
21:44:51.384 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: expected cmd class: null
21:44:51.390 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=null[0x00], type=ACK[0x02], dest=255, callback=0, payload=
21:44:51.397 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - lastTransaction null
21:44:51.400 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Received msg: ACK
21:44:51.390 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: expected cmd: null
21:44:51.404 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
21:44:51.408 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage Transactions outstanding: 1
21:44:51.410 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start
21:44:51.414 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Start transaction timer to Sun Jan 07     21:44:53 CET 2018 - 1999ms
21:44:51.418 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage lastTransaction: TID 63: [WAIT_RESPONSE] requiresResponse=true callback: 34
21:44:51.423 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - STOP transaction timer
21:44:51.432 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Start transaction timer to Sun Jan 07     21:44:53 CET 2018 - 1982ms
21:44:51.438 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction lastTransaction outstanding...
21:44:51.438 [DEBUG] [erialmessage.IsFailedNodeMessageClass] - NODE 15: Requesting IsFailedNode status from controller.
21:44:51.444 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - STOP transaction timer
21:44:51.445 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 61 08 93 
21:44:51.449 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Start transaction timer to Sun Jan 07     21:44:53 CET 2018 - 1964ms
21:44:51.452 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
21:44:51.460 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=RemoveFailedNodeID[0x61], type=Response[0x01], dest=255, callback=0, payload=08 
21:44:51.464 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 255: Adding to controller queue
21:44:51.468 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=RemoveFailedNodeID[0x61], type=Response[0x01], dest=255, callback=0, payload=08 
21:44:51.470 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 255: Added to queue - size 1
21:44:51.473 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=RemoveFailedNodeID[0x61], type=Response[0x01], dest=255, callback=0, payload=08 
21:44:51.475 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 1 out at start
21:44:51.478 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - lastTransaction TID 63: [WAIT_RESPONSE] requiresResponse=true callback: 34
21:44:51.492 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
21:44:51.499 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Last transaction: TID 63: [WAIT_RESPONSE] requiresResponse=true callback: 34
21:44:51.504 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction lastTransaction outstanding...
21:44:51.512 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - STOP transaction timer
21:44:51.518 [DEBUG] [ave.internal.protocol.ZWaveController] - Incoming Message: Message: class=RemoveFailedNodeID[0x61], type=Response[0x01], dest=255, callback=0, payload=08 
21:44:51.532 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Start transaction timer to Sun Jan 07     21:44:53 CET 2018 - 1882ms
21:44:51.530 [DEBUG] [lmessage.RemoveFailedNodeMessageClass] - Got RemoveFailedNode response.
21:44:51.541 [ERROR] [lmessage.RemoveFailedNodeMessageClass] - NODE 15: Remove failed node failed as node not found
21:44:51.550 [DEBUG] [ve.internal.protocol.ZWaveTransaction] - TID 63: Transaction COMPLETED
21:44:51.556 [DEBUG] [ave.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveNetworkEvent
21:44:51.563 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 15: Got an event from Z-Wave network: ZWaveNetworkEvent
21:44:51.565 [INFO ] [smarthome.event.BindingEvent         ] - org.openhab.binding.zwave.event.BindingEvent@1289019
21:44:51.567 [DEBUG] [ve.internal.protocol.ZWaveTransaction] - TID 63: TransactionAdvance ST: DONE
21:44:51.576 [DEBUG] [ve.internal.protocol.ZWaveTransaction] - TID 63: TransactionAdvance WT: null {}
21:44:51.581 [DEBUG] [ve.internal.protocol.ZWaveTransaction] - TID 63: TransactionAdvance RX: Message: class=RemoveFailedNodeID[0x61], type=Response[0x01], dest=255, callback=0, payload=08 
21:44:51.585 [DEBUG] [ve.internal.protocol.ZWaveTransaction] - TID 63: TransactionAdvance TO: DONE
21:44:51.590 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 255: Response processed after 232ms
21:44:51.592 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 255: TID 63: Transaction completed
21:44:51.596 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 255: notifyTransactionResponse TID:63 DONE
21:44:51.604 [DEBUG] [ave.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
21:44:51.608 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
21:44:51.611 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start
21:44:51.615 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction from controllerQueue
21:44:51.622 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - getTransactionToSend 6
21:44:51.626 [DEBUG] [zwave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 00 62 0F 96 
21:44:51.633 [DEBUG] [ding.zwave.handler.ZWaveSerialHandler] - NODE 255: Sending REQUEST Message = 01 04 00 62 0F 96 
21:44:51.661 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 06
21:44:51.673 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=null[0x00], type=ACK[0x02], dest=255, callback=0, payload=
21:44:51.677 [DEBUG] [ding.zwave.handler.ZWaveSerialHandler] - Message SENT
21:44:51.689 [INFO ] [smarthome.event.ThingUpdatedEvent    ] - Thing 'zwave:device:15ff39b3682:node15' has been updated.
21:44:51.711 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=null[0x00], type=ACK[0x02], dest=255, callback=0, payload=
21:44:51.721 [DEBUG] [ve.internal.protocol.ZWaveTransaction] - TID 64: Transaction Start type IsFailedNodeID 
21:44:51.730 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: TID 64: [WAIT_RESPONSE] requiresResponse=true callback: 0
21:44:51.734 [INFO ] [smarthome.event.ConfigStatusInfoEvent] - ConfigStatusInfo [configStatusMessages=[]]
21:44:51.736 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 62 00 98 
21:44:51.746 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: expected cmd class: null
21:44:51.760 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage started: expected cmd: null
21:44:51.759 [DEBUG] [ZWaveSerialHandler$ZWaveReceiveThread] - Response SENT 6
21:44:51.775 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - processReceiveMessage input 1<>127 : Message: class=IsFailedNodeID[0x62], type=Response[0x01], dest=255, callback=0, payload=00 
21:44:51.780 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=IsFailedNodeID[0x62], type=Response[0x01], dest=255, callback=0, payload=00 
21:44:51.763 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage Transactions outstanding: 1
21:44:51.791 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - STOP transaction timer
21:44:51.806 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Start transaction timer to Sun Jan 07     21:44:53 CET 2018 - 1985ms
21:44:51.818 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage lastTransaction: TID 64: [WAIT_RESPONSE] requiresResponse=true callback: 0
21:44:51.826 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - STOP transaction timer
21:44:51.836 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Start transaction timer to Sun Jan 07     21:44:53 CET 2018 - 1956ms
21:44:51.846 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Received msg (1): Message: class=null[0x00], type=ACK[0x02], dest=255, callback=0, payload=
21:44:51.856 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - lastTransaction TID 64: [WAIT_RESPONSE] requiresResponse=true callback: 0
21:44:51.864 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Received msg: ACK
21:44:51.873 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=IsFailedNodeID[0x62], type=Response[0x01], dest=255, callback=0, payload=00 
21:44:51.884 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - lastTransaction TID 64: [WAIT_RESPONSE] requiresResponse=true callback: 0
21:44:51.891 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Checking outstanding transactions: 1
21:44:51.899 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Last transaction: TID 64: [WAIT_RESPONSE] requiresResponse=true callback: 0
21:44:51.909 [DEBUG] [ave.internal.protocol.ZWaveController] - Incoming Message: Message: class=IsFailedNodeID[0x62], type=Response[0x01], dest=255, callback=0, payload=00 
21:44:51.916 [DEBUG] [erialmessage.IsFailedNodeMessageClass] - NODE 15: Is currently marked as healthy by the controller
21:44:51.923 [DEBUG] [ve.internal.protocol.ZWaveTransaction] - TID 64: Transaction COMPLETED
21:44:51.927 [DEBUG] [ve.internal.protocol.ZWaveTransaction] - TID 64: TransactionAdvance ST: DONE
21:44:51.935 [DEBUG] [ve.internal.protocol.ZWaveTransaction] - TID 64: TransactionAdvance WT: null {}
21:44:51.945 [DEBUG] [ve.internal.protocol.ZWaveTransaction] - TID 64: TransactionAdvance RX: Message: class=IsFailedNodeID[0x62], type=Response[0x01], dest=255, callback=0, payload=00 
21:44:51.950 [DEBUG] [ve.internal.protocol.ZWaveTransaction] - TID 64: TransactionAdvance TO: DONE
21:44:51.955 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 255: Response processed after 234ms
21:44:51.958 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 255: TID 64: Transaction completed
21:44:51.963 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 255: notifyTransactionResponse TID:64 DONE
21:44:51.967 [DEBUG] [ave.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
21:44:51.974 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
21:44:51.979 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start
21:44:51.983 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction from controllerQueue
21:44:51.988 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage nothing
21:44:51.994 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - STOP transaction timer

This triple click thing for inclusion and exclusion is really bad design

best,

Guido

rozpruwacz · January 7, 2018, 9:06pm

I also had problems with that. I did exclusion without OH. I have aeotec z-stick witch allows exclusion / inclusion without any controller software. I just unpluged the z-stick and went to my qubino dimmer holding z-stick close to dimmer the exclusion (without reseting) was succesfull. But event with this method it is not always easy …

vossivossi · January 7, 2018, 9:36pm

This is indeed tricky. My experience was that you can control it more precisely if you use the Service Button S instead of the switch attached to I1. I know that the manual says “Service button S must NOT be used when module is connected to 110-230V power supply.” but klicking it with an isolated screw driver worked fine for me already several times.
I demounted the devices, put them on my desk beside my Z-Stick and my Notebook, wired them temporary on my desk and did the reconfiguration. Even like this I sometimes needed 2-3 tries before getting it correctly done.
The procedure by Qubino is a real pain the ass…

ypoosn · January 7, 2018, 10:12pm

So I got it finally working.

Thanks for all hints.

Module exclusion from the Z-Wave USB-Stick was done using a PC-tool named Z-Wave PC Controller.

The rest was a piece of cake and worked as described.

best,

Guido

smar · January 8, 2018, 6:12pm

I used to have it working with the 2.0 binding, though using a bit of a juggling in rules/item definitions to correctly interpret responses. In those days, the first switch would report on switch_binary (i.e. the endpoint 0), with nothing coming through on endpoint 1, and the second switch would correctly report on endpoint 2.

Daniel_Linder · January 8, 2018, 7:00pm

Ok, interesting.
If you ever get them up and running - I would be most thankful for a some feedback.
I have a few just acting “dust collectors”. I am sure I could find some use for them eventually…

vossivossi · January 8, 2018, 8:23pm

I think without these “pending database updates” it will NOT generally work at the moment as our tests here have clearly shown. The current dev version (201801021718) will ONLY work if you have activated additional endpoints in the configuration (which is not the default configuration of the device).
So please @chris could you integrate these “pending database updates” soon? Thanks!

smar · January 9, 2018, 10:59am

I contacted Qubino recently, and they said that if I wanted a firmware upgrade, to return the relays to the supplier I bought them from, and they would organise with Qubino for an upgrade. This may be worth doing if Chris isn’t able to find a work around for these older 1.1 firmware units.

shorty707 · January 9, 2018, 4:27pm

For the DIN DIMMER ZMNHSD Qubino says the current version is:
H1S2P2
( A newer version H1S3P2 is on the way but not yet released)

Just if somebody wonders what the current version is

mdnx · January 10, 2018, 11:00pm

Today I exchanged my Qubino Flush Dimmer (with newest firmware) with a Fibaro Dimmer 2 - what a relief.
Plug and Play - it works on first try with several parallel moment switches, is immediately found and integrated into the Zwave network, the device (as all other Fibaro devices I have) reports automatically - everything works just out of the box.

I don’t now why I obtained a Qubino, when all my Fibaro devices work brilliantly and I was actually aware of this threat - However For anyone considering buying a Z-wave Dimmer or relay: - so far 292 entries on a basic functionality of any Z-wave device should be a warning in itself

vossivossi · January 10, 2018, 11:27pm

Well, careful! The electric properties of the Qubino Flush Dimmer are more than excellent! Dimming even a load of just 4W LED is no problem at all, while the Fibaro (from my tests 1,5 years ago) was never working reliable for its MAIN PURPOSE which is dimming anf switching a light. And dimming loads < 50W is only possible with the extra installation of a bypass (which the Qubino does not need). So there are already very good reasons to consider the Qubino.
AND: the ONLY problem with the Qubino Flush Dimmer is the use of aditional endpoints. The normal operation for 1 load works without any problems and this is probably the most frequently used configuration for all users. (The only unlucky exception is for dimmers which are included for the first time now with the most recent dev binding 20180102, which in contrary will only make dimmers work with activated additional endpoints; I already shouted to @chris to bring back the normal switch_dimmer channel, but so far no updates)

chris · January 10, 2018, 11:29pm

Sorry - I’ve been rather busy over the past few days and haven’t had the time. I’ll try and update this over the next couple of days unless of course someone else wants to add it before I get there…

vossivossi · January 10, 2018, 11:31pm

I would be happy to do it, but I am not sure what to do exactly.

chris · January 10, 2018, 11:36pm

Actually it looks like I already updated the database… I’ll do a binding update tomorrow if I get time, otherwise Friday.

houz · January 11, 2018, 9:40am

@chris:
Could you summarize for me what the current status is? I am using DIN rail Qubino dimmers, type ZMNHSD1 H1S2P1, firmware 1.1. I am running openHAB snapshots from the raspi packages, so no dev version. I don’t have temperature sensors attached to the dimmers.

Is there any chance to receive status updates in openHAB when dimming or switching the lights with the physical button attached? There has been so much going on here that I totally lost track.

sihui · January 11, 2018, 11:18am

Take a look at @vossivossi’s post, that should be all you need.

houz · January 11, 2018, 11:53am

I only understand half of that. What are activated additional endpoints? Isn’t that the temperature sensors you can attach? And isn’t he talking about how well the dimmer works? I was asking about how well openHAB works.