Rules triggered with delay when using a Qubino with Z-wave plus chip.
Hello all,
I have the
following situation: In the bedroom I have 2 Philips hue bulbs which are always
powered on. The double wall switch in the room is connected to a Qubino module
with Z-wave plus chip. Nothing is connected to the output of the module. The
Qubino is used to trigger a rule to turn on/off the lights.
When I use
the zipato app to turn on and off the qubino, the rule is triggered almost
instantly and the lights directly turn on/off. The problem is when I use the
wall switch. If I use the wall switch you can directly hear the click of the
relay but it takes 2-3 seconds before the rule is triggered and the light is
turned on/off.
I have
multiple Qubino’s installed in the house with the z-wave plus chip. And all are
directly connected to a light so I’ve never noticed this delay, but when I use
these modules to trigger a rule I see the same delay of 2-3 seconds. There are
also a few Qubino’s with old z-wave chip installed and these don’t have the
delay. Because it’s seen on all the Qubino’s with z-wave plus chip it’s safe to
say I can rule out a defective module, problem with the range or defective
wires.
Are
there more people who she this problem? Apparently Zipato has never heard this
complaint. But like I said normally the module is used to directly turn the
lights on/off so it’s not strange that it has not been noticed before. It would
be great if a few people could test with their Qubino’s with new z-wave chip to
trigger a rule using the wall switch and check if you see the same delay.
Thanks for
any help!!!
The same problem 
I had similar situation and reducing overall intensity of power consumption reporting helped a bit. Now it's about 1 second to see results with about 40 modules in home. I've set reporting on power change to 100% instead of 10% on all modules.
I had similar situation and reducing overall intensity of power consumption reporting helped a bit. Now it's about 1 second to see results with about 40 modules in home. I've set reporting on power change to 100% instead of 10% on all modules.
Hi Ronald,
I have several new qubino modules, Flush 1 and 2 relays. When you use the I1 (or I2 if it is a Flush 2) there is no delay since the module is switched by hardware. I have noticed a delay when the relays are triggered through rules or web interface, I assumed the delay was caused due the distance (some relays are further than others and noticed closer ones react a bit faster), I perfrormed a network heal and got a little better, some of them were hard and I literally had to open the switch and let the qubino hang out free while doing the network heal otherwise it faulted during the update.
Also it could be what Tomasz is mentioning, if we have many modules sending reports very often the box will be slowed down, I will try to modify my settings for reporting on power change and wattage report delay and see if it gets better. So far the slowest relay I have is about 1.5 seconds, I honestly can live with that.
Hi Ronald,
I have several new qubino modules, Flush 1 and 2 relays. When you use the I1 (or I2 if it is a Flush 2) there is no delay since the module is switched by hardware. I have noticed a delay when the relays are triggered through rules or web interface, I assumed the delay was caused due the distance (some relays are further than others and noticed closer ones react a bit faster), I perfrormed a network heal and got a little better, some of them were hard and I literally had to open the switch and let the qubino hang out free while doing the network heal otherwise it faulted during the update.
Also it could be what Tomasz is mentioning, if we have many modules sending reports very often the box will be slowed down, I will try to modify my settings for reporting on power change and wattage report delay and see if it gets better. So far the slowest relay I have is about 1.5 seconds, I honestly can live with that.
Hello Tomasz,
Thanks for your comment, i've changed the setting to 100% for this specific device but unfortunately it did not help with a quicker response.
Hello Alberto,
It looks like we both have a different problem then :), When the relay is triggered though the web UI the rule is excecuted directly. I assumed it was so quick because the zipato directly knows the new status and therefore does not have to wait for the signal from the module. When I use the wall swith I do have the delay.
The strange thing is that I have this problem with all Qubinos with new z-wave chip. does not matter if it's close or far from the Box. So it's not distance related. Next to that the Qubino's with old z-wave chip reacts almost directly on the wall switch so it's also not caused by all the wattage reporst or rules since the same rules triggerd by the Qubino with old chip is excecuted instantly.
It realy looks isolated to the Qubino with new z-wave plus chip. But it's strange to hear that you have the problem the other way around :). Than i'm afraid it has no use to ask you if you could try the experiment by triggering a rule while using the Qubino with z-wave plus chip and a wall switch.
The problem is Livable(ish), but waiting every time 2-3 seconds before the lights turns on is annoying :). Probably going to buy a fibaro module if this problem stays to check if that will solve it.
Thanks both for your support!
Hello Tomasz,
Thanks for your comment, i've changed the setting to 100% for this specific device but unfortunately it did not help with a quicker response.
Hello Alberto,
It looks like we both have a different problem then :), When the relay is triggered though the web UI the rule is excecuted directly. I assumed it was so quick because the zipato directly knows the new status and therefore does not have to wait for the signal from the module. When I use the wall swith I do have the delay.
The strange thing is that I have this problem with all Qubinos with new z-wave chip. does not matter if it's close or far from the Box. So it's not distance related. Next to that the Qubino's with old z-wave chip reacts almost directly on the wall switch so it's also not caused by all the wattage reporst or rules since the same rules triggerd by the Qubino with old chip is excecuted instantly.
It realy looks isolated to the Qubino with new z-wave plus chip. But it's strange to hear that you have the problem the other way around :). Than i'm afraid it has no use to ask you if you could try the experiment by triggering a rule while using the Qubino with z-wave plus chip and a wall switch.
The problem is Livable(ish), but waiting every time 2-3 seconds before the lights turns on is annoying :). Probably going to buy a fibaro module if this problem stays to check if that will solve it.
Thanks both for your support!
I think I see the problem. My qubinos work instantly since I connect the bulb to the output and the switch to the corresponding input in the qubino (Flush 1 to I1, Flush 2 - I1 is hardwired to O1, and I2 to O2). If you are not using the output then it makes sense.
When you trigger the output from the controller, the signal goes only one way (controller process, then command to qubino), when you press the switch, it goes two ways (qubino updates the controller with the status of the input, controller runs the rule, controller sends command to the qubino).
In my case since I wire the bulbs to the outputs the switch is done locally in the qubino and it is almost instantly. I have an average of 1 second or less for switching while done through web interface or app. Motion activated lights (using fibaro motion sensors and qubino) is between 1 and 2 seconds (same reason as mentioned above).
I have one case like yours, in the kitchen I have one qubino F1 that controls my kitchen main lamp, and also I have a LED strip on the kitchen counter (controlled by a independent Fibaro RGBW), on the switch (where the qubino is) Input 1 and is wired to the main lamp and so does O1, Input 2 is wired to the second switch. I use this second switch to turn ON/OFF the LED strip, my first attempt was to create rules that monitor this I2 and turns ON/OFF the fibaro RGBW but indeed was slow, sometimes up to 3 seconds (it's somewhat far from the controller).
What I ended up doing is to create a direct association between the qubino and the fibaro RGBW so when the qubino detects the change of state in I2 it sends a basic SET command to the RGBW to turn ON/OFF, this reduced the time to 1 second approximatelly. I also redesigned the rule so if I2 is ON but intensity of the RGWB is below 1 then it sets intensity to 100 and viceversa, just as a backup rule, it works good, 98% of the time the qubino operates the RGBW without the need of the controller.
I think I see the problem. My qubinos work instantly since I connect the bulb to the output and the switch to the corresponding input in the qubino (Flush 1 to I1, Flush 2 - I1 is hardwired to O1, and I2 to O2). If you are not using the output then it makes sense.
When you trigger the output from the controller, the signal goes only one way (controller process, then command to qubino), when you press the switch, it goes two ways (qubino updates the controller with the status of the input, controller runs the rule, controller sends command to the qubino).
In my case since I wire the bulbs to the outputs the switch is done locally in the qubino and it is almost instantly. I have an average of 1 second or less for switching while done through web interface or app. Motion activated lights (using fibaro motion sensors and qubino) is between 1 and 2 seconds (same reason as mentioned above).
I have one case like yours, in the kitchen I have one qubino F1 that controls my kitchen main lamp, and also I have a LED strip on the kitchen counter (controlled by a independent Fibaro RGBW), on the switch (where the qubino is) Input 1 and is wired to the main lamp and so does O1, Input 2 is wired to the second switch. I use this second switch to turn ON/OFF the LED strip, my first attempt was to create rules that monitor this I2 and turns ON/OFF the fibaro RGBW but indeed was slow, sometimes up to 3 seconds (it's somewhat far from the controller).
What I ended up doing is to create a direct association between the qubino and the fibaro RGBW so when the qubino detects the change of state in I2 it sends a basic SET command to the RGBW to turn ON/OFF, this reduced the time to 1 second approximatelly. I also redesigned the rule so if I2 is ON but intensity of the RGWB is below 1 then it sets intensity to 100 and viceversa, just as a backup rule, it works good, 98% of the time the qubino operates the RGBW without the need of the controller.
It's very interesting to read that you have also to the same 3 sec delay in the same situation of triggering a rule by using the input of the qubino only. That means that it's not only related to my situation only and Zipato should be able to reproduce this delay in the lab. It's unfortunately that you don't have an Qubino with Old z-wave chip so that you could see/check if that one does not have the delay.
That second one is indeed a good idea and I was also thinking about that one. But unfortunately the Hue bulbs are not on the Z-wave network but zigbee so it's not possible to associate them.
It's very interesting to read that you have also to the same 3 sec delay in the same situation of triggering a rule by using the input of the qubino only. That means that it's not only related to my situation only and Zipato should be able to reproduce this delay in the lab. It's unfortunately that you don't have an Qubino with Old z-wave chip so that you could see/check if that one does not have the delay.
That second one is indeed a good idea and I was also thinking about that one. But unfortunately the Hue bulbs are not on the Z-wave network but zigbee so it's not possible to associate them.
Still you could wire the bulb to the output, that way it would be very fast and you would have a way to physically turn on the bulbs if your box or bridge dies.
Still you could wire the bulb to the output, that way it would be very fast and you would have a way to physically turn on the bulbs if your box or bridge dies.
Exactly same problem there. I also have a Zipabox but this is not the problem. I've only 2 qubino zw+ flush relay. They are really near, about 2m whiteout any wall. On first I don't use output but only input and on the second I only use output and no input. If I use my handy to switch, almost instantly. But if I use the input on first qubino, about 3-4s latency. I try direct native association and shut down the zipabox to be sure, and same result. I guess qubino has a delay of 3s before it send is state.
Exactly same problem there. I also have a Zipabox but this is not the problem. I've only 2 qubino zw+ flush relay. They are really near, about 2m whiteout any wall. On first I don't use output but only input and on the second I only use output and no input. If I use my handy to switch, almost instantly. But if I use the input on first qubino, about 3-4s latency. I try direct native association and shut down the zipabox to be sure, and same result. I guess qubino has a delay of 3s before it send is state.
Hi. I have a similar thing. However with the Qubino single relais the delay is mostly below 1s, but with the double relais 2..4s. I know from a collegue of mine using fibaro relais and vera controller, that the delay with fibaro is even worse. Apparently he mentioned this has to do with the relais and its z-wave status reporting priority (that sadly cant be changed). For just trigger purpose a wall switch without relais should be preferred.
Hi. I have a similar thing. However with the Qubino single relais the delay is mostly below 1s, but with the double relais 2..4s. I know from a collegue of mine using fibaro relais and vera controller, that the delay with fibaro is even worse. Apparently he mentioned this has to do with the relais and its z-wave status reporting priority (that sadly cant be changed). For just trigger purpose a wall switch without relais should be preferred.
Replies have been locked on this page!