Motivated by Signify announcing the upcoming requirement to register for an account to use the Hue bridge, I looked into how that feature could be recreated in HA. The result is this custom component.
While still very much WIP, with a GUI done, I thought it made sense to post it here.
You get a new button in the sidebar that takes you to a custom page where you select targets and then tap on one of the scene images to apply that scene to those targets.
Features
It comes with all the scenes from the official Hue App scene gallery (snapshot 2023-09-28) manually extracted in a clean-room way by setting a group of lights to a scene and then noting the different x,y values + its name.
Furthermore, it comes with AI-generated picture reimaginations for all of them.
It provides a few custom services to apply scene presets that could conceivably be used in automations and/or bound to e.g. a Zigbee button.
I’m pretty sure that there will be breaking changes to those in the future though.
Install
Installations as a HACS custom repository should be possible. You can then set it up via a config flow that does nothing.
Misc
While I’m probably going to clean this up in the future, right now it’s just a bodged together prototype. Still, it provides value to me and I assume it also might for other people.
No warranties though, as always. Provided as-is.
With hue (and probably other vendors as well), when you apply a random color with a transition (especially long ones), it can happen that the light turns to white and brightly illuminates the otherwise rather dark and moody room.
This happens, because the transition feature basically just moves from one coordinate in the CIE1931 color space to another. So if you for example do a transition from turquoise to red, that transition would move right through the area where white is and thus unexpectedly illuminate the whole room.
Smart shuffle solves that issue by taking the current color of each light and then filtering the set of colors in the preset to only leave those that would result in a transition that doesn’t move through white.
It works by:
taking the coordinates of a point in the middle of the white area
drawing a line from the current color coordinates
drawing a line from the possible next color coordinates
looking at the angle between those two lines
a. If the angle is > 150°, the transition will be considered as moving through white
b. If the angle is < 2°, the possible next color will be considered the same color
If any of those two criteria matches, the color will not be selected as the next random color for that light.
In the end, it selects a random option out of that filtered set
If the filtered set is empty, it just picks a random color from the whole preset
The exact angles (150, 2) are subject to change. I just picked them mostly at random.
Anyway, while this does work great with the right set of colors, you can create a set where you accidentally partition your lights, causing them to just cycle through the same subset of colors of the whole preset all the time.
I’ve noticed that happening with the CGA preset I’ve added recently.
Because of that, it’s now a toggle that can be disabled if the algorithm doesn’t work well with the preset.
While adding that, I’ve also made the regular shuffle a bit better for this feature then before. Instead of just pulling n colors (with n being the count of lights) out of the set of the preset colors at random (and thus giving no guarantees that they will be evenly distributed on a single apply) the code now
Takes the set of all colors in the preset
Creates enough shuffled duplicates of that set so that the length of those combined is longer than n
Picks the color for each light based on its index in that new set
This ensures that if you have 6 lights and apply a preset with 5 colors, you will get all 5 colors on 5 lamps + 1 repeated one for the 6th lamp.
Previously, you could by random chance get 6 lights in the same color.
Unlikely but possible.
At least that’s how it works at the time of writing (2023-12-09). It might change in the future if I come up with different ideas or notice other issues
This is a cool idea but it doesn’t really work for me. I’ve added 3 lights, each of which have a color support, selected a scene but it all it does it sets the initial color and doesn’t do any transitions
The UI just applies a preset. Once
It does not do dynamic scenes that periodically change colors.
How could it? There are no controls that would allow stopping a dynamic scene.
In the future there might be a UI for that, but now there is not.
If you want to use that dynamic scene feature, you need to call the relevant services exposed by the custom_component directly. There’s no documentation for that yet for the same reason that there’s no UI for it yet. But I’m sure you’ll figure it out.
This script might do what you’re looking for.
In this example, it applies the preset 10 times, waiting 5 seconds between each one.
When @Hypfer said to call the relevant services, they were probably talking about: scene_presets.apply_preset
(and others under scene_presets)
If you modify the script to repeat forever (or more times) and hook that script up to a standard button in the dashboard, it will act like a toggle switch, repeating until you press the button again (and turn the script off, canceling the loop/repeat).
alias: Hue Tokyo Scene Example Script
mode: single
sequence:
- repeat:
sequence:
- service: scene_presets.apply_preset
data:
preset_id: Tokyo
brightness: 255
smart_shuffle: true
targets:
entity_id: group.living_room
transition: 4
shuffle: true
- delay:
seconds: 5
count: 10
Does scene_presets.start_dynamic_scene basically do what my script does?
(In that, it’s not using the hue dynamic functionally, but it’s sending new color data to each light for each `interval, ’ right?)
Also, does get_dynamic_scenes only return the dynamic scenes currently active via this integration? (so it would return nothing unless you’d used start_dynamic_scene?)
This custom_component has absolutely nothing to do with Hue other than that it implements a feature similar to what the hue bridge seems to offer.
Honestly I don’t even know how similar it even is. I’ve never used the Hue bridge and only went by descriptions and youtube videos of that functionality.
I don’t use vendor apps.
Hello! I made an account for the sole purpose of letting you know that this integration is absolutely brilliant. I have wanted to ditch the Hue hub for a while, and their recent decision really made it a top priority for me. Your work has been the final step that allowed me to do so with confidence.
One thing that Phillips did well was the scene-designing interface. You’ve replicated it very nicely. The use of AI re-imagining for the scene pictures was clever!
You’ve noted that it’s “just a bodged together prototype” but it seems to me that this was a lot more work than you’re letting on. Just wanted to let you know how much I apppreciated it, as putting something out into the world can be frustrating if you’re hit with nothing but critiques and support requests. This integration is appealing and easy to use. Really great. Thanks to the hard work of the Zigbee2Mqtt team, Nabu Casa, and you, I now actually own the products I have paid for. Thank you, Hypfer!
Just going to reaffirm what @juggernaught has said. Although still a work in progress it works absolutely well for all my HUE lights. A little confusing to setup when starting out however once you get the hang of what the scene_presets do and assign that to buttons it works pretty much close to the HUE app. Finally I can remove all the HUE bridges from my network.
I just pushed a breaking change so sorry for those of you who had already built scripts and other things that call the services directly.
Starting with v1.0.0, presets are now called by an ID and not their name anymore.
It should’ve been like that from the start but I was just very very lazy. This change was bound to happen eventually and it’s better to do that now before even more people build on that incorrect previous implementation.
Hopefully, this should be the only major breaking change but you never know.
With this change also came a new feature:
It is now possible to mark presets as favorites. Having options is nice but I think most people will eventually settle on their favorites and that should make the UX for that much better than having to scroll through all of them every single time.
Furthermore, there are now buttons that reset the targets selector and the tunables section. I wish I had the former one back when I tested with 30 entities and had to remove all of them with 30 clicks.
Although I only had a few automations with the old ID changing to the new ID was simple enough however with just an ID number it’s difficult to tell what presets are being used in now in automations without having to look up every time and takes a few extra steps. Just a suggestion maybe have the id as their group name and then scene name like: defaults_bright / partyvibes_fairfax etc.
Also I like how we can add our own custom scenes now. Took a while to figure out the structure but for a future enhancement would it be able to add timings to the scene inside the custom presets? For example I want to make Forest Scene where 4 of the colours are a shade of green to simulate the forest and 1 white colour to simulate the clouds/sun. When running the scene I would like it to cycle through the 4 green colours and every so often (random time) the white will come in. Just an idea.
Installations as a HACS custom repository should be possible. You can then set it up via a config flow that does nothing.
Really pleased I found this, thank you!
So, newbie question time…please can you explain how I “set up via config flow”? I have the HACS install done (and rebooted), with the repository sitting under config / custom_components, but cannot find an “idiot’s guide” to this next step.
Still, it’s a pretty cool project, thanks for your reply!
