Qubino dual relay module

The reason I am sure that it will work is that Indigo DOES reflect the correct on/off state when I poll the device.
I'd rather not set my polling to "as often as possible" (and the other options are useless imo), so I just wait patiently untill Matt comes up with something to test.

Yepp but if the firmware 1.01 that both you and Colly have on your devices is buggy and does not broadcast state changes properly then a new version of the Z-Wave plugin will not help.
Lets wait and see if Colly's devices starts to work properly after the firmware upgrade. I really believe that the issue is solved after that since you can get state change update when you poll the device. This clearly indicates that the ZMNHBD with firmware 1.01 has a bug compared to my ZMNHBD:s that has firmware 1.02.

@PeteVis: I looked through this thread and couldn't any info if you had mentioned what part number you have on the back of your device. Mine are marked with H1S5P1. What can you see on the back of your ZMNHBDx:s?

I have sent an email to Qubino asking them for the difference between firmware 1.01 and 1.02 for the ZMNHBD:s and if there was a state change broadcast issue on firmware 1.01.


EDIT: @PeteVis: Sorry found now that you have H1S2P1. You need to get it firmware upgraded to H1S5P1

About the immediate (or not) state changes : prior to the current version of Indigo, I saw immediate zwave messages pop up in the debug log.
It is only after upgrading to Indigo 7.0.3 that the zwave messages appeared to be wonky. So this too is not a problem with the device or it's firmware version.

Let's just wait untill Matt jumps in before we jump to conclusions

So this too is not a problem with the device or it's firmware version.
Let's just wait untill Matt jumps in before we jump to conclusions

I agree that we wait for Matt to comment but there IS a difference between H1S4P1 and H1S5P1 how state changes are report due to different implementations by Qubino of multi-end-point encapsulations.

There has been a similar discussion about those firmware differences in OpenZwave user forum: H1S4P1 versus H1S5P1

I have an answer about S5 firmware for this module, it's not a bug but a different way using multichannel associations:

(Answer from Qubino:)
As you’ve noticed there is a difference between the way the S4 and S5 versions send unsolicited (Reports sent without preceding Get commands) reports to controllers.
On S4 the module reports the status of the switches to the controller on every change, regardless of the way the single channel or multi channel lifeline associations were set. We implemented this in a way similar to other manufacturers, but later on had a discussion with Sigma Designs, where they explained to us the recommended way of sending unsolicited reports (they require strict separation between single channel and multi channel contexts on z-wave plus products), which we implemented in the S5 version in such a way:
If a single channel lifeline association (group 1 associated to the controller) is set then the module shouldn’t report unsolicited Multi channel Encapsulated Reports, which means only the root device will report it’s states without a Get request, not the endpoints (these need to be polled in order to receive reports). From the module’s standpoint this means the controller either doesn’t support multi channel context or the module was integrated in a non-multi channel context.
On the other hand, if a multi channel lifeline association (group 1 on each endpoint is associated to the controller’s endpoint 0 or 1, depending on integration) was set the module will report unsolicited reports from all the device’s endpoints, but not the root device. This will result in the endpoint’s statuses being reported via unsolicited reports also, not just Get commands via polling.

And as I understand the latest Z-Wave plugin is based on how S5 firmware devices works, causing S4 or older not work properly due to the above statement from Qubino.
@Matt: Please correct me if I am talking rubbish here...

I have received a reply back from Qubino now as well and they say S4 or older devices should be sent in to distributor for firmware upgrading.

And it looks like the SAME type of problems with older firmwares S1, S2, S3 and S4 are for users in the HomeSeer world as well:
Qubino ZMNHBDx needs firmware S5

I just had all of my Qubino Z-Wave Plus Flush 2 modules upgraded from S2, S3 and S4 to S5 and it resolved most of my issues.

I don't understand all of it, but it basically states that S5 is fully Z-Wave Sigma Designs compliant wrt multi-channel. And that explains why the S5 version works better with HS3 than the previous version (instant status and instant watt reporting per channel).

It is messy for developers like Indigo Domotics to make it easy when the device manufacturer suddenly changes the method to report Z-Wave device state changes...

The users at the HomeSeer forum have also noticed the quite long delay on state change updates from the device to the controller.

Hi CrazyFin,

See paramaters 11 - 15 below
Z-Wave retrieved parameter 11 value: 0 (size 2)
Z-Wave retrieved parameter 12 value: 0 (size 2)
Z-Wave retrieved parameter 13 value: 0 (size 2)
Z-Wave retrieved parameter 14 value: 0 (size 2)
Z-Wave retrieved parameter 15 value: 0 (size 1)

Have you tested the stability issues you mention by using a monostable switch instead of a bi-stable switch by setting param 1 and 2 to 0? I am using mono-stable switches and have not seen those kind of stability issues of the output state that you mention above

I haven't any mono stable switches at the moment but will look at getting one for my new test environment!

It would be good if you could test your devices that way too.

This is where I am going to totally get out of my comfort zone..
I notice a difference between your device and mine - see below.

Mine - Multi-Endpoint Classes: 1:[5E 86 25 20 27 85 8E 59 32], 2:[5E 86 25 20 27 85 8E 59 32]

Yours - Multi-Endpoint Classes: 1:[5E 86 25 20 27 85 8E 59 32], 2:[5E 86 25 20 27 85 8E 59 32], 3:[5E 86 31 85 8E 59]

What's the significance of the 3:[5E 86 31 85 8E 59]??

This may or may not be of any use to @Matt or @CrazyFin

My starting position here is that the "Master Bathroom" Light is "On" from an earlier Indigo command - wall switch is "Off"

Code: Select all

Z-Wave                          sent "Master Bathroom" off
   Z-Wave Debug                    queueing energy request of "031 - Master Bathroom" (activity detected)
   Z-Wave Debug                    RCVD requestAlarmSensorStatus: 01 10 00 04 00 1C 0A 71 05 00 00 00 FF 07 00 01 08 78
   Z-Wave Debug                    . .  requestAlarmSensorStatus: node 028, endpoint None, cmdClass 71, type 0, value 0, classSubKey 710000
   Z-Wave Debug                    . .  requestAlarmSensorStatus: typeExt 7, valueExt 0, classSubKeyExt 7100000700
   Z-Wave Debug                    . .  requestAlarmSensorStatus: defnStatusByte 0
   Z-Wave                          sent "Master Bathroom" off
   Z-Wave Debug                    ignoring duplicate energy request of "031 - Master Bathroom" (activity detected)
   Z-Wave Debug                    RCVD requestAlarmSensorStatus: 01 10 00 04 00 1C 0A 71 05 00 00 00 FF 07 00 01 08 78
   Z-Wave Debug                    . .  requestAlarmSensorStatus: node 028, endpoint None, cmdClass 71, type 0, value 0, classSubKey 710000
   Z-Wave Debug                    . .  requestAlarmSensorStatus: typeExt 7, valueExt 0, classSubKeyExt 7100000700
   Z-Wave Debug                    . .  requestAlarmSensorStatus: defnStatusByte 0
   Z-Wave Debug                    filtering duplicate command -- old: 710000, 7100000700, 0, new: 710000, 7100000700, 0 (0.1964 secs)
   Z-Wave Debug                    RCVD sensorSetLevel: 01 09 00 04 08 1C 03 20 01 00 C4
   Z-Wave Debug                    . .  sensorSetLevel: node 028, endpoint None, cmdClass 20, value 0
   Z-Wave                          received "Master Bathroom" energy total to 5.7 kWh
   Z-Wave Debug                    SENT requestMeterLevel: 01 0E 00 13 1F 07 60 0D 01 01 32 01 10 25 D9 48
   Z-Wave Debug                    RCVD multiEndPointPacket: 01 14 00 04 00 1F 0E 60 0D 01 01 32 02 21 34 00 00 02 71 00 00 C5
   Z-Wave Debug                    . .  multiEndPointPacket: node 031, endPoint 1
   Z-Wave Debug                    RCVD requestMeterLevel: 01 10 00 04 00 1F 0A 32 02 21 34 00 00 02 71 00 00 FF
   Z-Wave Debug                    . .  requestMeterLevel: node 031, endpoint 1, meterType 01, raw value 3400...
   Z-Wave Debug                    . .  requestMeterLevel: 62.5 W (float: 62.500000)
   Z-Wave                          received "Master Bathroom" power load to 62.5 W
   Z-Wave Debug                    SENT setRelayValue: 01 0E 00 13 1F 07 60 0D 01 01 25 01 00 25 DA 4C
   Z-Wave                          sent "Master Bathroom" off
   Z-Wave Debug                    queueing energy request of "031 - Master Bathroom" (activity detected)
   Z-Wave Debug                    polling status of node "031 - Master Bathroom" (post-activity energy request)
   Z-Wave Debug                    SENT requestMeterLevel: 01 0E 00 13 1F 07 60 0D 01 01 32 01 00 25 DB 5A
   Z-Wave Debug                    RCVD multiEndPointPacket: 01 18 00 04 00 1F 12 60 0D 01 01 32 02 21 24 00 00 00 39 00 01 00 00 00 39 B7
   Z-Wave Debug                    . .  multiEndPointPacket: node 031, endPoint 1
   Z-Wave Debug                    RCVD requestMeterLevel: 01 14 00 04 00 1F 0E 32 02 21 24 00 00 00 39 00 01 00 00 00 39 FF
   Z-Wave Debug                    . .  requestMeterLevel: node 031, endpoint 1, meterType 01, raw value 2400...
   Z-Wave Debug                    . .  requestMeterLevel: 5.7 kWh (float: 5.700000)
   Z-Wave Debug                    SENT requestMeterLevel: 01 0E 00 13 1F 07 60 0D 01 01 32 01 10 25 DC 4D
   Z-Wave Debug                    RCVD multiEndPointPacket: 01 14 00 04 00 1F 0E 60 0D 01 01 32 02 21 34 00 00 02 74 00 00 C0
   Z-Wave Debug                    . .  multiEndPointPacket: node 031, endPoint 1
   Z-Wave Debug                    RCVD requestMeterLevel: 01 10 00 04 00 1F 0A 32 02 21 34 00 00 02 74 00 00 FF
   Z-Wave Debug                    . .  requestMeterLevel: node 031, endpoint 1, meterType 01, raw value 3400...
   Z-Wave Debug                    . .  requestMeterLevel: 62.8 W (float: 62.800000)
   Z-Wave                          received "Master Bathroom" power load to 62.8 W
   Z-Wave Debug                    SENT setRelayValue: 01 0E 00 13 1F 07 60 0D 01 01 25 01 00 25 DD 4B
   Z-Wave                          sent "Master Bathroom" off
   Z-Wave Debug                    queueing energy request of "031 - Master Bathroom" (activity detected)
   Z-Wave Debug                    SENT setRelayValue: 01 0E 00 13 1F 07 60 0D 01 01 25 01 00 25 DE 48
   Z-Wave                          sent "Master Bathroom" off
   Z-Wave Debug                    ignoring duplicate energy request of "031 - Master Bathroom" (activity detected)
   Z-Wave Debug                    polling status of node "031 - Master Bathroom" (post-activity energy request)
   Z-Wave Debug                    SENT requestMeterLevel: 01 0E 00 13 1F 07 60 0D 01 01 32 01 00 25 DF 5E
   Z-Wave Debug                    RCVD multiEndPointPacket: 01 18 00 04 00 1F 12 60 0D 01 01 32 02 21 24 00 00 00 39 00 01 00 00 00 39 B7
   Z-Wave Debug                    . .  multiEndPointPacket: node 031, endPoint 1
   Z-Wave Debug                    RCVD requestMeterLevel: 01 14 00 04 00 1F 0E 32 02 21 24 00 00 00 39 00 01 00 00 00 39 FF
   Z-Wave Debug                    . .  requestMeterLevel: node 031, endpoint 1, meterType 01, raw value 2400...
   Z-Wave Debug                    . .  requestMeterLevel: 5.7 kWh (float: 5.700000)
   Z-Wave Debug                    SENT requestMeterLevel: 01 0E 00 13 1F 07 60 0D 01 01 32 01 10 25 E0 71
   Z-Wave Debug                    RCVD multiEndPointPacket: 01 14 00 04 00 1F 0E 60 0D 01 01 32 02 21 34 00 00 00 00 00 00 B6
   Z-Wave Debug                    . .  multiEndPointPacket: node 031, endPoint 1
   Z-Wave Debug                    RCVD requestMeterLevel: 01 10 00 04 00 1F 0A 32 02 21 34 00 00 00 00 00 00 FF
   Z-Wave Debug                    . .  requestMeterLevel: node 031, endpoint 1, meterType 01, raw value 3400...
   Z-Wave Debug                    . .  requestMeterLevel: 0.0 W (float: 0.000000)
   Z-Wave                          received "Master Bathroom" power load to 0.0 W
   Z-Wave Debug                    RCVD requestAlarmSensorStatus: 01 0F 00 04 00 1C 09 71 05 00 00 00 FF 07 08 00 65
   Z-Wave Debug                    . .  requestAlarmSensorStatus: node 028, endpoint None, cmdClass 71, type 0, value 0, classSubKey 710000
   Z-Wave Debug                    . .  requestAlarmSensorStatus: typeExt 7, valueExt 8, classSubKeyExt 7100000708
   Z-Wave Debug                    RCVD requestAlarmSensorStatus: 01 0F 00 04 00 1C 09 71 05 00 00 00 FF 07 08 00 65
   Z-Wave Debug                    . .  requestAlarmSensorStatus: node 028, endpoint None, cmdClass 71, type 0, value 0, classSubKey 710000
   Z-Wave Debug                    . .  requestAlarmSensorStatus: typeExt 7, valueExt 8, classSubKeyExt 7100000708
   Z-Wave Debug                    RCVD requestAlarmSensorStatus: 01 0F 00 04 00 1C 09 71 05 00 00 00 FF 07 08 00 65
   Z-Wave Debug                    . .  requestAlarmSensorStatus: node 028, endpoint None, cmdClass 71, type 0, value 0, classSubKey 710000
   Z-Wave Debug                    . .  requestAlarmSensorStatus: typeExt 7, valueExt 8, classSubKeyExt 7100000708
   Z-Wave Debug                    RCVD requestAlarmSensorStatus: 01 0F 00 04 00 1C 09 71 05 00 00 00 FF 07 08 00 65
   Z-Wave Debug                    . .  requestAlarmSensorStatus: node 028, endpoint None, cmdClass 71, type 0, value 0, classSubKey 710000
   Z-Wave Debug                    . .  requestAlarmSensorStatus: typeExt 7, valueExt 8, classSubKeyExt 7100000708
   Z-Wave Debug                    RCVD sensorSetLevel: 01 09 00 04 08 1C 03 20 01 FF 3B
   Z-Wave Debug                    . .  sensorSetLevel: node 028, endpoint None, cmdClass 20, value 255


What happened here is the light switched back on 5 times before eventually staying Off. Each "Off" command I gave was from Indigo.
As I'm still a relatively newcomer to HA - just imagine how easy it is convince my wife that it's the way to go!!

[matt (support)]

About the immediate (or not) state changes : prior to the current version of Indigo, I saw immediate zwave messages pop up in the debug log.
It is only after upgrading to Indigo 7.0.3 that the zwave messages appeared to be wonky. So this too is not a problem with the device or it's firmware version.

Hi Pete,

I think the history here is that:

1) Originally Indigo used a normal (not endpoint) association command for adding the association from group #1 back to the Z-Stick. In that case the module would instantly report Relay 1 and Relay 2 changes, but it would not report which endpoint to use for the command (endpoint of None), thus it was impossible for Indigo to know which relay had changed. The result was probably that Relay 1 would gets its state / UI changed regardless of which relay was controlled.

2) We then, after a few iterations, in 7.0.3 modified Indigo so that it would use the endpoint association command during sync only and would expect the module to send the updates encapsulated with endpoint 1 (for Relay 1) or endpoint 2 (for Relay 2). Apparently this works with firmware 1.02 but not 1.01.

With firmware 1.01 the module doesn't send out any commands when we add the endpoint association for group #1 (lifeline). After you added other associations it started sending out the relay broadcasts (relaySetLevel in log) but it fails to wrap it with an endpoint so Indigo ignores it.

In summary, if I'm correct about the above (and I'm not positive I am), I think that although you did see previous instant broadcasts from the module before those commands aren't useful in that they weren't wrapped with an endpoint so Indigo cannot know which relay has changed. I'm not sure if it is possible to get firmware 1.01 to work correctly. Based on the permutations of associations and the debug logging I've seen, it doesn't look like it.

As a workaround you could add a Trigger of type Z-Wave Command Received for the device and use the Match Raw Packet type with match bytes like this:

* 03 20 01 *

which corresponds to the relaySetLevel commands you are seeing when changing Relay 1 (I1). You can then have an action that sends a status request to that device. It sounds like right now the module isn't broadcasting anything for Relay 2 (I2) though. If it was before, then I think the trick is going to be some combination of setting the correct association groups. Based on the manual I'd start with groups #2 and #5, but you may have already tried those.

[matt (support)]

Mine - Multi-Endpoint Classes: 1:[5E 86 25 20 27 85 8E 59 32], 2:[5E 86 25 20 27 85 8E 59 32]

Yours - Multi-Endpoint Classes: 1:[5E 86 25 20 27 85 8E 59 32], 2:[5E 86 25 20 27 85 8E 59 32], 3:[5E 86 31 85 8E 59]

What's the significance of the 3:[5E 86 31 85 8E 59]??

Hi Colly,

I'm pretty sure that difference is just because CrazyFin has a temperature sensor connected to his (endpoint #3 is the temp sensor, but is only defined if it is connected during inclusion).

Regarding the behavior of your modules not remaining OFF – I'm not sure if that is a firmware bug in 1.01 or if that is a hardware malfunction. You might want to ask them before they update the firmware. I'd hate for you to get them back and still have that problem.

Just to double check before I start to dig into the light switches:
1. If I don't have version S5 on the units I need to get them upgraded (by Qubino, if they approve). So this have nothing to do with v1.01 or v1.02? (I have both with similar issues)
2. the only way to know the version of each unit is to look at the actual unit. It's not possible to see through the Indigo UI.
3. Matt, I understand your post above that you are not sure if you will be able to fix the problems for older versions (<S5)

// Mattias

Regarding the behavior of your modules not remaining OFF – I'm not sure if that is a firmware bug in 1.01 or if that is a hardware malfunction.

I decided to swap over some modules that were behaving well on other circuits in the house with the most problematic one, previously I just used a new module out of the box to double check. The erratic behaviour started with the previously good module more or less straight away. I think I've got to the bottom of it but I'm awaiting on Qubino to confirm. For the dual relay which shows the most erratic behaviour one of the circuits is a fluorescent fitting. The other is an LED circuit. I happen to have a few circuits like this which has probably added to my problems. I have since found a reference to a similar issue with Qubino relays on the Zipato forum. I have now removed a number of my dual relays and will ship them off early next week.

[matt (support)]

1. If I don't have version S5 on the units I need to get them upgraded (by Qubino, if they approve). So this have nothing to do with v1.01 or v1.02? (I have both with similar issues)

I think that 1.02 is S5 and 1.01 is S4 or earlier, but I'm not positive. Do you think that is correct CrazyFin?

I think that 1.02 is S5 and 1.01 is S4 or earlier, but I'm not positive. Do you think that is correct CrazyFin?

Yes, S5 = firmware version 1.02 shown in Indigo. Anything lower than 1.02 shown in Indigo or anything lower than S5 shown on the back of the device = send your device in for a firmware upgrade. See my posts above about the BIG difference of how Qubino does endpoint status reporting before S5 firmwares... It just wont work if you are on S4 or lower... Sorry.
This is NOT an Indigo issue. I have seen a LOT of other users in other forums having similar issues with firmwares lower than S5.
Look for example in this thread at the HomeSeer forum: https://board.homeseer.com/showthread.php?t=175043&page=2
And you MUST read the thread at OpenZWave forum https://groups.google.com/forum/#!msg/openzwave/Xm8yQWl58Yk/zAEKQrVZCwAJ
All this explains why you MUST have S5 firmware on the ZMNHBDx devices.

@Mattias: So you have devices with S5 on the back of the device that you have problems with?
Mattias, are you located in Sweden? If so, I am happy to test your device here in my "test lab" if you want. I am located in Haninge outside Stockholm.

Great, Thank you. I only tested on one of 1.01 relays (thinking that 1.02=S2), but i'll try to reset a 1.02 relay to see if they work.
(And yes, i also live in sthlm, so i might use your test invitation if i can't get the stuff to work

Matt, thanks for explaining. I'll not take up your time anymore for this device.
I'll see if I can find the courage to disconnect my device and send it back for upgrading.

I will add though, that I have been trying (and not succeeding) with the match raw zwave command, like you suggested.

The command works fine with other zwave devices (so I know my trigger is correct), just not this qubino... it just wont work, which is odd as this command seems to be perfectly tailored for unsupported devices...

[matt (support)]

Press the ON/OFF buttons on it a few times, then from the Trigger's setting dialog press the button to write to the Event Log the most recently received Z-Wave commands. Copy/paste those results into a reply for me and we'll see if we can figure it out.