Hi, I have extended from Hue only, to Homey recently. However, I have a problem getting the Hue lights to work well. I have tried both direct (Philips Hue zigbee-app) and via Hue Bridge (Philips Hue-app)
Direct seems unreliable. When going direct, I experience that a lot of the commands is not executed. Like if I have a flow that triggers enabling 6 lights in the same room, only 4 of the lights is lit up. Maybe next time all is executed, then only 5 of them (not the same each time).
I then tried via Hue bridge, and then all commands work. However, I get a delay. When I had a room with Hue motion detector and a hue light, with a rule set up in the Hue app for triggering the light when there is motion, the light always came on after less than a second. Then when I tried triggering the same via a Homey flow, it varies from 1 to 5 seconds before the lights turn on. Like when I have a night rule turning the light on low when I go to the bathroom during the night, I am almost through the whole living room before the lights comes on, and that is a bit annoying.
I have asked on a facebook group, and a lot of people say they run Hue-commands from flows via bridge and get no such delay (<1sek every time). So I am trying to find a solution to my problem. I would prefer to go direct (so I can eliminate the need for the Hue bridge), but if that is not possible, I can accept the Hue bridge, just not the delay. So, is there any way to debug/troubleshoot the zigbee setup in more detail? An app, tool or a kind of log where I can see detailed timestamps for when every event happened, error messages if the commands where not completed or such? Connection strengths so I can see if any part of the mesh is suboptimal… Signal conflicts or other possible reasons for my delay issue?
I have also considered replacing all the Hue lights with Lifx or other alternatives, but it feels wrong before I have actually confirmed that Hue is the problem…
This (most likely) isn’t related to Hue, but to Homey’s inability to send a lot of Zigbee/Z-Wave commands from a flow at the same time. That’s why most people add delays between each action card:
turn on lamp 1
turn on lamp 2 with a 1 second delay
turn on lamp 3 with a 2 second delay
…
The delay here isn’t so much caused by sending the “turn on” command, but by the signal of the motion sensor getting delayed because the Hue bridge app needs to poll the bridge periodically (somewhere between 2 and 5 seconds).
Perhaps you can let Homey handle the motion sensor directly, but let the bridge handle the lights?
Is this because zigbee does not confirm package delivery the same way as wifi? So Homey can’t really know how many of the commands actually reached their targets…?
Is there a type of max commands per second in cases like that? I mean, if I know this is the reason for commands not being executed, that is an acceptable limit due to the protocol. But if I have a room with 8 lights, I would want them to turn on as fast as possible, so one per second (taking 8+ seconds to turn on all the lights) is a bit unpractical. But if I know that 3 light commands simultaneously works well (more or less) every time, I can enable 3 lights, then next 3 after 1 second and so on, which should be possible to live with.
@robertklep That’s an interesting solution! It sort of makes the Hue bridge a secondary relay device (like a repeater) without being dependant on it.
How would you set up hue controls like this? Direct, via bridge or a combination, base on your experience?
No, I think there’s an inherent issue with how flows are implemented that are causing these problems. Before firmware v2, flows were handled differently and the number of “missed” commands was much lower. In v2, flow handling was “optimized” and in the process, something broke. It has been an issue ever since.
There isn’t really a hard limit of what will still work, and what won’t. I don’t have a Hue bridge, but from what I know, you can combine multiple lights together into one group, in which case Homey would only need to send a single command to the bridge (“Turn on group X”).
Homey doesn’t support Zigbee grouping, another possible fix for this issue (with Zigbee grouping, devices are assigned to a particular group ID, and a Zigbee controller would send a single “turn on all devices with group ID X” command and be done with. I don’t think the Zigbee rewrite of v5 implements this.
I’m not sure what you mean with “hue controls”, but in general, every Hue input device (devices that cause messages to be sent to the bridge, like a motion sensor that sends a message that it detected motion, buttons/remotes, etc) should ideally be handled by Homey directly to work around the polling delay.
I was just wondering, as you obviously knows a lot about this, what kind if setup you would choose if you where to have rooms with Hue lights, motion sensor and switches. All directly or input devices directly and lights via Hue Bridge…
Another issue I experienced when I tried setting the devices up directly, was trying to add flows for the dim up/down buttons on Hue Dimmer Switch. I tried to ser the buttons to trigger flows with i.e +20% light actions… That worked ok with 1 light, but when dimming 4-6 lights with one switch, it was awful. Dimming went extremely slow and unevenly.
That would work the fastest (in theory) if the input devices (motion sensors and switches) are directly connected to Homey, because then you don’t have the polling delay.
That sounds like the dimming is being done by Homey, in which case you’re starting 4-6 dimmer timers at the same time, which is something that Homey appears not to be able to handle very well. It sounds like the same issue as with just turning on/off multiple lights from a flow: Homey just cannot handle those kinds of flows very well.
Perhaps a Homey Pro might be able to do a bit better, or this issue is solved by the Zigbee rewrite of the upcoming v5 firmware, but no guarantees. Homey can only deal with a few (1, 2, perhaps 3) devices at the same time.
You might want to consider switching to deconz for your zigbee devices. Delays are a lot better, if there at all. Supports a wide range of devices from most brands and has a great integration with homey.
Back in the day when I was using the bridge I was annoyed by the delays as well, that was my major motivation to switch to another system. Homey didn’t cut it so switched to deconz. Nobody knows how homey will perform with the v5 but id advise to see if deconz is a option.
I have a similar setup and similar issues, but I’m afraid there is no solution.
I have a Hue bridge to handle my Zigbee devices, some exceptions because they are not supported by Hue, or for testing purposes. These (3) exceptions are on the Homey Zigbee network.
Reason for not using Homey zigbee more; bad reviews for Homey Zigbee implementation, and Hue simply works.
BUT Hue motion detectors (2 outside and 2 inside) experience delays in activating HUE flows. I was in touch with Hue support, did some optimizations but still no real improvement. By the time I’ve crossed the hall way the lights go up.
The outside dimmers react faster.
Why do I think there is no solution?
As said I was in contact with Hue support, and no real solution came out the discussion (works as designed was the conclusion).
On internet you find a lot of delay complaints on the Hue sensor. With no relation to Homey, so it’s not Homey related I think.
And some testing;
I made a flow in Homey “when motion is detected, notify me”. The Homey notification was faster than the Hue flow to activate the light. So its probably not the polling that causes the delay.
As said the outside sensor is faster. But the Homey flow activates the outdoor light faster, than the Hue flow. I have outdoor Hue lights and Shelly controlled lights, both are activated by motion detected by the Hue sensor. But the Shelly controlled lights go more and faster on
I think the Hue bridge wants to be sure it’s not a false alarm, and waits for a confirmation, a second motion detection. Homey just gets a motion detected ping and the related flow is activated. Otherwise I cannot explain the delays in the different tests and setups I did.
I plan to test other sensors just to be sure it is the Hue sensors/bridge.
This is a common problem with the Hue bridge app for Homey: because it has to poll the bridge (periodically ask the bridge is something has changed), you will always get a delay before Homey knows that a sensor has triggered. It may take up to a few seconds.
It’s not strictly an issue with Homey, it applies to all clients that connect to it locally. It’s up to the client to set the update interval though.
Running all Hue components directly does not work very well. Hard to get lights added, often get error messages when trying to trigger them after they are added as device and have to add lots of delays if controlling many lights is to work. Not sure if the Homey driver, zigbee protocol, Hue devices or my usage of them is the cause of this.
Running all Hue components via Hue bridge does not work very well because of the polling issues described in this thread (for input devices).
Connecting input devices (like motion detectors) directly and lights via Hue Bridge seems to work well. But this required many hours of testing and troubleshooting, and it still feels a bit stupid to have to run a “second brain” (Hue Bridge) beside Homey.
So, maybe I should use motion detectors from other brands (not Hue) and if I find good light alternatives with the same quality as Hue that works well with Homey, I might consider replacing all Hue devices. Lifx seems to be a popular alternative, but that is not even supported by Homey (unless you go via their cloud service which kind of defeats the limit of getting rid of the Hue Bridge )
I like Homey. I like the flexibility and the possibility to write your own code for it (apps). But it has some limitations, and based on my research and inquiries in the community, finding a more stable alternative for handling wireless home automation devices, that does not require much more fiddling, has an awful GUI or much more limited automation possibilities or device support, does not seem to exist today.
Just be aware that using Homey directly comes with its own set of problems (like I mentioned before, sending commands to multiple devices from the same flow can cause problems that, AFAIK, have not been fixed in firmware v5).
Basically all devices that connect to Homey through some sort of radio (Zigbee, Z-Wave, WiFi). Sending commands to multiple devices (well, starting perhaps at 3 or 4 devices, not sure) will cause commands to get missed (so if you turn on 5 lights from a flow, not all lights will actually turn on). That’s why a lot of people use delays in between each command (turn on light 1, wait a second, turn on light 2, etc…).
Well, personally I prefer to have HUE components standalone from Homey running on the hue bridge.
I set a lot of lighting scenes and have around 40 hue bulbs that it would take more time to manage with Homey than Hue. Especially more so when I’m using Hue sensors for light triggers. The IConnecthue app that I’m using on IOS is easier to use vs setting up flows when you have some more complex automations that you want to match with the dimmer switch.
I found that this way, it’s easier to just add the device into homey via the bridge for the other automation and this frees up homey to do other stuff better. Adding HUE direct to homey is just more painful for me.
When I had a zwave issue a month back and had to decommission homey for a week to troubleshoot it, I was glad my lights ran independently, or else I would have gotten an earful from the missus.
Yes, hopefully that will be fixed when/if they start supporting zigbee grouping. And delays is an acceptable solution. But yesterday I tried yet again to add a couple of my Hue lights to Homey directly. Other than having to try 5-10 times before succeeding in adding the device to Homey, I got a lot of red error messages saying messages did not get delivered even after adding them. Seems unstable. Is there any tool that can show connection strengths for each device in the mesh or something like that? In case that is the problem causing these error messages.
as explained Homey (flows) reacts faster than Hue, so the polling time seems not to be the issue. I don’t think Homey is the issue, it is more how Hue reacts to a dimmer event. And during my discussion with the Hue support desk 1 remark did stick “the sensor is not intended as a security device”.
Therefore my (simple) conclusion is the Hue sensor is “to blame”.
)
)