Philips Hue Motion quicker reaction

Hi Guys,

i have read through many threads and tried many things until i have adapted the right solution of @Skylord123 so that it works correctly with the new Home-Assistant.io version

problem:
Philips Hue has a response time of up to 5 seconds if you simply integrate this via the integration.

Application area:
Since my automations often use the motion sensors, a reaction time of 5 seconds is really miserable.

Solution:
The solution goes via Node-RED and MQTT.

What do you need:
Node-RED:

  • node-red-contrib-huemagic

MQTT ( in my case the Mosuitto broker )

How do you do:


–> Link to my configuration: https://pastebin.com/aDxGdngN

  • Hue Magic Motion Node
    –> configure the HUE bridge in the node and select the sensor
  • Function Node
    –> Adapt the sensor_id
    —> Number: Sensor ID of HUE (to be seen in the motion node when it is saved)
    —> Sensor meaning for the MQTT mapping
  • MQTT out Node
    –> MQTT Server
  • Debug Node

Home Assistant:
Create a binary_sensor for mapping with MQTT

# Motion MQTT HUE Sensor
  - platform: mqtt
    name: KMotionNRed
    state_topic: 'home/kitchen/sensor/motion
    payload_on: "true
    payload_off: "false"
    value_template: '{{{ value }}'
    device_class: 'motion'.

The display remains the same but is now as fast as in the HUE app.

I hope I can summarize it with this post and help people who have the same problems as I have with the HUE motion sensor.

1 Like

Both HueMagic and Home Assistant’s Philips Hue integration talk to the Hue bridge the same way, via Hue’s API. I wonder why HueMagic detects motion events faster? Because it polls more frequently?

I don’t have extensive knowledge of their API but it’s my understanding that you have to poll Hue devices to get their status. You can see that in the Hue integration’s source code for sensors where it polls every 5 seconds (and explains why you noticed it can take up to 5 seconds before a motion event is reported):

If HueMagic reports it faster than 5 seconds, I assume it means that it is polling faster, perhaps every second.

In other words, HueMagic’s operation generates 5 times more network traffic than Home Assistant’s Philips Hue integration. I realize there’s plenty of bandwidth available, and the payloads are small, nevertheless HueMagic’s improved timeliness doesn’t come without a (hidden) cost.

The real culprit is the Hue API which, at least to my knowledge, doesn’t tell you when a motion event occurs, but requires that you repeatedly ask if one has occurred.

I suppose you could duplicate the performance of HueMagic by changing the Hue integration’s SCAN_INTERVAL to 1 second.

2 Likes

FYI the Hue bridge supports HomeKit and the bridge pushes state updates via HomeKit…so if you connect the bridge to Home Assistant via HomeKit Controller you can get state updates pushed to Home Assistant. This includes the motion sensor and—hopefully soon since a PR for it was merged recently—button presses on the Hue remotes. The only downside is that HomeKit doesn’t appear to report when lamps are unreachable like the Hue integration can (but it’s possible I just didn’t wait long enough during my testing).

If you connect the bridge via the Hue integration and HomeKit Controller, it will mean you have duplicate entities for all of your Hue stuff, but that doesn’t really bother me (and you can disable any unwanted duplicate entities). Plus it eliminates the need to hammer the bridge every 1 second (or, in the case of one custom integration I saw, 0.5 seconds). You also need the Hue integration in order to use the hue.hue_activate_scene service.

Why Philips doesn’t support pushing updates with their own API is beyond me especially since their HomeKit implementation supports it. I’m planning on making a forum topic with this info as a heads-up sometime in the next day or two.

4 Likes

In addition to lacking the equivalent of hue.hue_activate_scene, the HomeKit Controller integration has no access to Hue groups (my guess is because the Hue bridge doesn’t report its groups as HomeKit accessories). For example, the Philips Hue integration reports one of my Hue groups as light.dining but there’s no equivalent entity reported by HomeKit Controller.

In addition, the Philips Hue integration retains the original names of Hue devices whereas HomeKit Controller assigns generic names (numbered sequentially). It means there’s a bit of experimentation required to determine the true identity of each generically-named device.

If you choose to run both integrations but don’t want duplicated entities, you can use Home Assistant’s ability to disable individual entities.

Screenshot from 2020-09-14 15-05-13

2 Likes

Ah yes, forgot to mention those lovely details…an unfortunate discovery for sure, but still worth it in my mind. I’ll definitely be mentioning this when I make the topic.

HomeKit Controller provides most of the functionality of the Philips Hue integration, without polling and better performance. However, if someone really needed hue.hue_activate_scene it seems a shame to install the Philips Hue integration for that one service call.

You got me thinking that there’s probably a way to create an equivalent service call using a RESTful Command. After all, activating a Hue scene is done via the Hue (REST) API.

The only missing piece is exposing Hue groups as entities. I guess you could probably hard-code each group as a RESTful Switch. EDIT: Nope, that’s insufficient because it can’t support all the things you can do with a Hue group, like set brightness, color, etc.


EDIT

FWIW, acquiring an API token (“username”) from the Hue bridge is probably a procedure that’s a bit more involved than one would normally expect of the average user.

I hadn’t even considered that actually. I use a REST switch to manually enable/disable one of my Hue motion sensors for a very specific use case, so I know what I’m going to look into tonight :smile:

Ok so I took a deeper look at the Hue API and, yeah… this would not be fun to do with REST commands. Each group (room) has its own ID which is just an integer. Each scene has its own unique ID which appears to be a random 15-character string, and it also has a reference to the group that it’s part of. Here’s an example of a room:

	"1": {
		"name": "Living room",
		"lights": ["9", "12", "20", "28"],
		"sensors": [],
		"type": "Room",
		"state": {
			"all_on": false,
			"any_on": false
		},
		"recycle": false,
		"class": "Living room",
		"action": {
			"on": false,
			"bri": 254,
			"hue": 8616,
			"sat": 121,
			"effect": "none",
			"xy": [0.4450, 0.4070],
			"ct": 343,
			"alert": "none",
			"colormode": "xy"
		}

And here’s an example of a scene:

	"Eer3ZeZ0Noo7Vae": {
		"name": "Relax",
		"type": "GroupScene",
		"group": "1",
		"lights": ["9", "12", "20", "28"],
		"owner": "some_kind_of_id",
		"recycle": false,
		"locked": false,
		"appdata": {
			"version": 1,
			"data": "iZ3CQ_r02_d01"
		},
		"picture": "",
		"image": "a1f7da49-d181-4328-abea-68c9dc4b5416",
		"lastupdated": "2020-07-30T02:47:21",
		"version": 2
	}

Now, I did create the following rest commands to set a scene, turn a light on, and turn a light off:

rest_command:
  hue_activate_scene:
    url: &url "http://10.0.3.40/api/YOUR-HUE-API-USERNAME/groups/{{ group_id }}/action"
    method: put
    payload: '{"scene": "{{ scene_id }}"}'
  
  hue_light_on:
    url: *url
    method: put
    payload: '{"on": true}'
  
  hue_light_off:
    url: *url
    method: put
    payload: '{"on": false}'

As you can tell, they require the group ID and/or scene ID. The rest command to activate a scene doesn’t find the appropriate scene ID based on that group name and scene name that you provide like the hue.hue_activate_scene service does. As such, the service calls would look like this:

- service: rest_command.hue_activate_scene
  data:
    group_id: 1
    scene_id: Eer3ZeZ0Noo7Vae

- service: rest_command.hue_light_on
  data:
    group_id: 1

They do work but yeah… you’d need to grab all the group and scene IDs that you want and keep track of them. Using secrets for that would make it easier but this doesn’t seem practical.

I concede it takes a bit of exploration to get the required group and scene identifiers; it’s not nearly as convenient as using hue.hue_activate_scene. Messy as it may be, it gets the job done without requiring the Philips Hue integration.

In my case, I use very few scenes so it’s not much effort to create a rest_command for each one (and so the cryptic scene identifier is hard-coded into the command).

rest_command:
  pool_blue:
    url: !secret hue_group_pool
    method: put
    payload: '{"scene": "123AbCdEfGhI"}'
  
  pool_white:
    url: !secret hue_group_pool
    method: put
    payload: '{"scene": "StUvWxYz123"}'

The secrets.yaml file contains:

hue_group_pool: http://BRIDGE_IP_ADDRESS_OR_FQDN/api/YOUR_HUE_TOKEN/groups/YOUR_GROUP_NUMBER/action

Example:

hue_group_pool: http://philips-hue.local/api/XaYbZcGibBeriSh/groups/4/action

Indeed–I don’t actually many scenes either, so I could see myself going down this route. Just wanted to emphasize to anyone else who might read this that there’s unfortunately no drop-in replacement for the hue.hue_activate_scene service.

The only thing that I’d miss is being able to tell when lights are unreachable…not that I expect it to happen often, but it’d still be nice to know.

I take it you already knew about getting push updates by connecting the bridge via HomeKit Controller? Until sometime earlier this year HKC was polling only even if the devices supported push, so I didn’t even think to connect the Hue bridge to it. I have my Ecobee thermostat and Abode security system connected via HKC too. Ecobee’s API is too slow and unreliable, so I just created automations in Home Assistant for my thermostat schedule and control it locally.

I have several ecobee Switch+ devices and all are integrated with Home Assistant via HomeKit Controller. Initially, each switch’s motion sensor was of limited use because HomeKit Controller also used polling. Earlier this year it was completely overhauled and polling was replaced by an event-based model. That’s when I started using their built-in motion sensor to trigger automations.

For the moment, I mostly rely on the Philips Hue integration for controlling lighting. Its polling-based model is adequate for that purpose. I have several Hue Dimmer Switches but I haven’t bothered to use them in any automations. Whenever I get around to it, I’ll compare the performance of the two integrations and see which works best (my guess is HomeKit Controller).

As for the lack of unavailable status, I imagine some form of polling is needed in order to monitor a device’s status. Without polling a device (or the device periodically reporting that it’s alive and well) there’s no way to know if and when a device falls off the network. Just a guess but maybe the HomeKit protocol supports some form of status-monitoring but Philips/Signify hasn’t implemented it.

My impression is that people see “Apple HomeKit” and think it works exclusively with Apple products (wrong). What they should be seeing is that “Apple HomeKit” means the device supports an open communications protocol that is developed and supported by Apple (unlikely to disappear any time soon).

v2021.12 now has instant events for button presses, this include Friends of Hue; maybe motion is now faster also?
2021.12: New configuration menu, the button entity, and gorgeous area cards! - Home Assistant (home-assistant.io)

I will test that tonight

Can confirm with the new update the Philips Hue Integration is way more faster than before !

That is awesome.

My Hue seems to be a bit dodgey since 2021.12 (currently 2021.12.2).

Seems like it can still control things, but the states aren’t being updated in HA.

So triggering things based on motion doesn’t always work.

Rebooting HA seems to fix it… sometimes…

For me, the Hue integration went from being rock solid to completely unreliable.