Add basic support for Hue Dynamic Scenes #8014
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
'setLightState()' calls out to this new helper method when dealing with a Hue light that supports effects with a request that contains only items that can be handled by the manufacturer-specific command. The new method will eventually build a '0x00' command from the '0xfc03' cluster to control the light, mimicking what the Hue Bridge.
The new method will be responsible for building a '0x00' command from the '0xfc03' cluster and queuing a task for it to be sent out the radio. The method signature is expected to change to allow passing payload items and their content descriptor easily.
Use a quint16 enum, wrapped in QFlags, to track which items are present in the payload of a ‘’0xfc03’ 0x00’ command.
For Philips Hue lights that support the ‘0xfc03’ cluster, handle changes to their “on” state using the manufacturer-specific cluster.
Hue lights leverage a manufacturer-specific cluster - `0xfc03` and some manufacturer-specific commands in ZCL clusters to enable scenes that cycle through colors and/or use Hue light effects. This additional REST API endpoint will expose that functionality without compromising the existing `group` and `scene` endpoints.
Playing a Hue Dynamic Scene first recalls a “regular” scene and then instructs the members of that scene to begin playing the ‘dynamic palette’. The effect works best when the recalled scene puts its member lights into a state that is identical to one of those provided in the ‘dynamic palette’. The light’s firmware takes care of playing the scene starting from the lights current state. The equivalent of the contents of the ‘palette’ object in the CLIP v2 API must be provided to the ‘recall’ endpoint of ‘hue-scenes’ every time - it is not stored by the API. Currently only a payload of colors is supported.
The code can be reused by the manufacturer-specific way of defining the state of a Hue light in a scene, which will be added next.
This includes heavy refactoring that was needed to enable code reuse and hopefully make ‘hue.cpp’ easier to navigate by grouping similiar functions together.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Requires:
This PR adds rudimentary support for Dynamic Scenes for Philips Hue lights that support them. It leverages manufacturer-specific commands to provide two things:
* Defining a light's state in a scene using the manufacturer-specific payload used by the
0xFC03clusterTo keep this separate from other endpoints while testing, the functionality is tucked away behind the (hopefully only temporary)
hue-scenespath, the endpoint for this feature being/api/<apikey>/hue-scenes/groups/<group_id>/scenes/<scene_id>/lights/<light_id>/state. Currently, it is best to first create an empty scene and use this endpoint only to overwrite the states of lights that are members of the scene. The manufacturer-specific way of setting the state of a light in a scene has some advantages over the standard way of doing it:on,bri,ct,xy, andtransitiontimeparameters are supportedeffectis a valid attribute (as areeffect_durationandeffect_speed), allowing scenes where lights are recalled to effectsgradientis a valid attribute, allowing scenes where lights are recalled to gradients (not supported at the time of writing this)N.B. because of potential format incompatibilities, modifying a light's state in a scene via this command does not currently persist the value of the light's state for the scene to the API.
* Recalling Dynamic Scenes
Like the above, this too sits behind the
hue-scenespath at/api/<apikey>/hue-scenes/groups/<group_id>/scenes/<scene_id>/play. This command will firstly recall<scene_id>and then provide that group and scene with the "dynamic palette" that makes up the Dynamic Scene. This palette is provided in the body of the request and is not stored by the API. Currentlybri,transitiontime,effect_speed, andxyare supported.xymust be a list of colors (up to 9). e.g., the Halloween-themed "Glowing Grins" dynamic scene available in the mobile app would be played by the following request body:{ "bri": 120, "xy" : [ [0.657060, 0.295434], [0.630906, 0.333872], [0.593867, 0.378974], [0.535248, 0.403478], [0.313381, 0.592306] ], "transitiontime": 4, "effect_speed": 0.75 }The effect looks best if the recalled scene
<scene_id>puts the scene lights to the same brightness and to one of the colors included in the dynamic palette. The light's firmware sorts out playing the effect from the closest color to the current one.ctandeffectcan also be supported as payload for the dynamic palette, but are currently not supported.