I’ve been experiencing problems with the sensor for motion sensor on the Philips Hue Motion Sensor. It’s been “slow”. In summary it now takes maybe 2-5 seconds before Home Assistant picks up that the state is “on” compared to before when it took .5 to 1 seconds.
I started experiencing some slight problems around 0.91 or so with the custom component. But since 0.93 when the sensor is now built in to Hassio the problem has escalated. I tried to narrow down the problem with some testing. I have tested moving the sensor, restarted the Intel NUC and the Hue Bridge. I also used the Hue app to see if the sensor in itself was slow to detect motion, but it’s close to instant. So I moved on to checking the state in Home Assistant and my automations connected to the motion is instant but the state is not. As I said it usually takes 2-5 seconds for it to change state after I walk in front of the sensor.
I have version 0.93.1 running in Docker on an Intel NUC running Ubuntu Server 19.4. Both the NUC and the Bridge is connected with ethernet cables. The motion sensor itself is located in my bathroom, the primary use is to be able to have a “night light” when going peeing at night, but also regular motion detecting to turn on lights during daytime. Not very useful for the lights to turn on when you’re already standing at/sitting on the toilet. I haven’t been able to find any documentation that points toward this being a known problem and most forum posts I find say that the Hue motion sensor is among, or the, fastest one to detect motion.
Has anyone here heard of this problem? Is it a known problem or what ways could I go further to troubleshoot. I suspect the problem lies with the communication between the bridge and Hassio. At least it seems that way. Insights that could help me imrpove or completely solve the problem is highly appreciated, thanks!
There are other people complaining about the delay with the official implementation. They also state the reason for this. Currently it looks like the best would be to use the custom component.
I can recommend deConz or zigBee2MQTT and get rid of the native hue bridge altogether. All changes of bulbs, motion sensors etc. are pushed to HA instead of pulled from the Hue Hub, which means immediate response, no delay at all.
If these alternative solutions are using the REST API of the Hue hub, then they are also polling, but at a high rate so the result appears instantaneous. The official HA integration make the decision not to poll too frequently as this can result in the hub experiencing issues. This trade off was made to minimise the negative impact on some users but is not optimal for other users. Devs always face trade offs so it’s useful to understand these when weighing the options on the table
No these are not using the hue hub. Deconz and ZigBee2MQTT need a hardware stick, which replaces the hue hub. The best thing about this is, that you can also integrate a lot of other ZigBee devices, e.g. Xiaomi sensors.