Lag in execution flow command

Hi, I’m new in the community. After reading about compatibility with a lot of devices and about high degree of customization of routines i bought a Homey Pro to improve my Philips Hue system.
So I’ve connected my Hue hub to Homey, added some new INNR lights and plugs SP220 and started creating routine to improve advanced automatism but very soon i have met some problems.
I’ve been a developer for many years and to create automatism with flow it’s very easy even if the debug operation are difficoult without the right tools.
The main problem is the lag time between the instruction setted in the flow. I’ve read in some tother topic about the lag time when you switch on a light ( with HUE it was very fast, now it took minimum 2 seconds) but when you build up a set of instruction lag time add up. Some instructions take really a lot of time and when i start a routine, even if the command set is correct, for some seconds the room lights go on and off like a christmas tree and final result is also not correct!
Some commands are so slow that subsequent instructions are executed first. this is clearly unacceptable. So i’had to add some delays to obtain the desired final result but in the end i’ve added extra lag to the existing lag. This is not nice, and 4/5 seconds to switch on a light set is not rewarding.
And if you add some kind of incompatibility of some devices (for example INNR bulb added with the INNR app have clear management problems, sometimes they work properly, sometime they flashes before switch on or off and sometimes they do not work at all) the general experience is not very positive.
Just to give a better information, on my homey there are only 10 apps installed to control about 30 devices (20 lights, 4 motion sensor, 3 sonos devices and 3 plugs). And I’was not able to connect my new Sony android tv. The app cannot find it on the lan!
This is my situation after a week of attempt and settings.
Am I the only one or this is the normal situations for every one? Is there some kind of solution to increase performance and solve the problems?
Thank you all for the help and comments you will like to make.

This indeed is a problem. You can group some devices which will solve some problems. I think there is an app Grouping. I myself use scenes in the Philips Hue app from Philips(not Homey) in these i have grouped some bulbs and added the brightness and colour. In Homey you can use these scenes.

I only have innr smartplugs added to philips hue. This works ok, i do not use the innr devices in the innr app but use the Philips Hue app from Homey.

Delays is a problem. I the hue bridge and delay is up to 3 seconds. This is not always a problem, but in those cases it is a problem i use the Pilips Hue app from Philips( not Homey) to turn the light on. Light off i use Philips Hue app from Homey.

You can try to use the Philips Hue app without the bridge. Some like this more, i did not give it a try.

Really happy to read an answer so soon.
In my short experience grouping devices brings bigger lag (from Jamie peake). If you have to manage few lights there are no big problems but if you have many lights in the same room building scenes and use them brings a lot of problem.
Using hue app through homey means to have only hue bulbs but one of the reasons I bought homey was the possibility to use different kind and brands of devices.
I also have Plugs innr in hue app (was not possible to add sp220 in innr app even if it is written they are supported) and they works ok but innr bulbs in Hue app are not well supported (lag, short zigbee range, flashes when switched) but also problems are present in innr app…
Using hue app to switch on and homey to switch off I think will bring heavy limitations to customation of the routines. I will think about but if it is like this also the second reason that brings me to buy homey would die.
Reading some topics using the bulbs without hue hub seems to bring more problems, I would like to hear someone experience before changing all the configuration.
Thanks

Reading the issues, it sounds like @Carlo_Gabucci is switching multiple devices from flows at once (please correct me if I’m wrong).

This is still a problem for Homey, that’s why people have started adding delays in between the different action cards so mitigate the problem (as @Carlo_Gabucci has already found out) . Grouping won’t help because under the hood, you’re still switching multiple devices.

I have grouped my hue bulbs and innr plugs in the Philips Hue app from Philips. It is called scenes. You can group bulbs and lights, set the color temperature or colour and brightness. With the Philips Hue app you have an action card scenes. This way you have a group without the delays.


True, if you let another device perform the grouping you won’t have the issues mentioned before (or at least less issues). That way, Homey becomes a very expensive flow runner :stuck_out_tongue:

1 Like

I already knew the fast switching behavior via scenes from the all4hue app (Android Hue Bridge programming).
Unfortunately, querying the Hue motion sensors Homey> Hue Bridge causes a long delay in the switch-on behavior of the corresponding lamp (s). As already discussed in another thread (I think Robert Klep was in the discussion), I can confirm that after updating a 1st motion sensor, additional Hue motion sensors “switch” much faster when there is movement.

Hence my idea, questions about it:
Is there a query / command / card that Homey can send to get Homey to actively poll the sensor?
The only purpose of this query is to wake up the sensor practically before the actual flow through polling and to get the status faster> thus also faster switching.
So you could set an “activation wake up flow” or something similar in front of the desired flows.
How long would such an active polling (activation - wake up flow) on the part of Homey> Bridge be active in order to have a quick activation with further sensors?

Some weeks are gone. I tried different solution. I waited for v5 update but the problem is not solved. The delays in command execution seems cannot be cancelled. Between the sensor fell the presence and the light switch on there are always minimum 2 seconds. In many situations with more lights and complex flows 3 or 4 seconds.
It is really not acceptable.
Is really everyone in the community accepting this heavy limitation? Or I’m doing something wrong?
Homey is really nice. A bridge between different protocols and a high grade of customize. But the low performance are giving no sense to everything.
I’m really thinking to go back to hue bridge where the performance were much better.

1 Like

I think it works 1-way. Sensors report something and Homey responds. Homey does not, and cannot (a.f.a.i.k.) ‘read’ or poll sensors…

idk what u r used to, for me it is sort of logical that a wired switch switches a light on instantly,
and a wireless ‘thingy’ with a little computer (Homey) in between takes a while for the light to switch on.
And i also kind of like it when all the lights switch on at dusk f.i., they ‘pop-up’ with delays in between (and programmed that way on purpose).
If you want fast instant light, go back to wired (just a thought, not an order :wink: :wink: )
Cheers

I guess different people have different standards. I would be properly annoyed if it would take more than half a second (yes, half a second) for lights to come on after I pressed a button or initiated an action. My Zigbee devices (not managed by Homey) react almost instantaneous, at least without any noticeable delay.

Like u said, it’s personal. As all my lights dim fairly smoothly to their dimlevel (by built-in design), it doesn’t annoy me.
Other things do annoy me:
I have a car, and throttle by wire. Yes wire😅, but it takes almost a second b4 the engine responds. That annoys me, and other drivers don’t get what my problem is with it😆

Hope your brakes don’t take a second too, that’s 27,7 meters at 100km/h :scream:

Luckily they’re hydraulic powered and not by wire (thank some person in heaven)

That’s almost always intentional (for reasons of fuel economy and “smoothness”).

But the ‘gap’ still annoys me, when one is used to carburettor- and diesel engines with cable throttles
:wink:

The lag with Homey isn’t intentional, though :stuck_out_tongue_winking_eye:

1 Like

Different standards?it depend what you are talking about. When you enter in a dark room and light switch on when you are gone or you have to stop and wait that the light comes, it is not something that can be considered good enough. If this happen it is much better the old and stupid wall switch.

But thinking to a solution what do you mean with “not managed by homey”? Do you have a working solution?

Perhaps “sunk cost fallacy” is a better term to describe it: people have spent so much time and money on their device that they start seeing “shortcomings” as “features” :stuck_out_tongue_winking_eye:

I don’t use Homey for my Zigbee (or home automation, for that matter). For that I use deCONZ, which is very stable and fast. There’s a Homey app for it as well.

However, to get it up and running, you need to spend money on a deCONZ USB stick and, possibly, something like a Raspberry Pi to run its software on (see “sunk cost fallacy” above).

Hi, to everyone. I come back with this topic because of the new Homey Pro 2023.
In these two years I have simply lived with the limitations regarding the delay in activating devices following an event (sensors, switches…). That doesn’t mean I’m okay with it or that I’m used to it.
My question now is the following: is the new Homey Pro capable of significantly reducing delays?
The deConz solution seems too complicated to me and overlaps with the Homey functions