Improved support for HomeKit scenes

[ebaauw]

When activating a HomeKit scene that contains multiple changes to a single light (e.g. power, brightness, and colour) while the light is off, homebridge-hue used to report

hue bridge error 201: parameter, bri, is not modifiable. Device is set to off.

This is because the Hue bridge tries to execute the change for bri, before it has executed the change for on. See also issues #15, #16, #28, #57.

As an example, here's the debug log output of homebridge, when activating a HomeKit scene which sets the power, brightness and colour of six lights: apart.txt. Some observations:

• To my pleasant surprise, HomeKit actually sends the Power change before Brightness, Hue, and Saturation. I'm testing on iOS 10.3 beta 2, not sure if this was the case on iOS 10.2 and earlier;
• However, due to the asynchronous nature of NodeJS/homebridge/homebridge-hue and/or the Hue bridge, the requests are handled out of order by the Hue bridge, causing the 201 bridge errors. Notice the order of the request ok messages;
• There's a total of 24 changes from HomeKit, resulting in 24 requests to the Hue bridge, resulting in 24 messages on the Zigbee network;
• Note that xy is updated twice for each light: once because of the change to Hue and once because of the change to Saturation. When the bridge request for the Hue change is handled after the Saturation request, this results in the light having the wrong colour, even thought there were no errors for those requests;
• Visually, lights 1, 5, and 6 have the correct setting; light 2 has the wrong colour (request 115 before 114), light 3 has the wrong brightness (error 201 for request 112), light 4 has the wrong brightness (error 201 on request 109) and wrong colour (request 123 before 122).

Combining the changes to different characteristics for the same light into a single Hue bridge request not only prevents the 201 bridge error, it also reduces the load on the Hue bridge (and slightly on the Zigbee network). Here's the corresponding debug log: combined.txt. Again, some observations:

• Still the same 24 HomeKit changes (in different order, but still Power before Brightness before Hue before Saturation);
• Now only 6 requests to the Hue bridge and no 201 errors. These result in 18 messages on the Zigbee network.
• Indeed, visually, all lights have the correct setting.

Technically, after receiving the first characteristic change for a light, homebridge-hue waits a little while before sending the corresponding request to the Hue bridge. If another change arrives, it is combined into the same request. The time (in milliseconds) homebridge-hue waits is configurable by the timeWaitUpdate parameter in config.json.

I'll include these changes in the next release of homebridge-hue.

[ebaauw]

Released v0.2.3. Seems to work on my server. Reset my entire HomeKit configuration and re-created the test scene. Now changes are sent to homebridge-hue in a different order, on iOS 10.2 as well as on iOS 10.3 beta 2 (on same iCloud account).

I did find sometimes a manual change flips back and forth. This is due to a timing issue, which occurs more often with faster heartbeats (2 sec):

• Switch light on manually from HomeKit app;
• Homebridge-hue stores desired state, sets timeout to send request to bridge;
• Heartbeat kicks in: old value is read from bridge and HomeKit value is changed back to old value;
• Request is executed and HomeKit value is changed back to new value.

Solution: v0.2.4 suppresses updating the HomeKit value from the Hue bridge during update.

[nriley]

I had thought this was #40 but was confused by the order of log messages, and it turned out not to be…now I can finally see to make my coffee in the morning as the light above the sink isn't impossibly dim. Thanks!