I’ve been running some version of “make the lights match the time of day” in my house for over a decade. It started as a handful of automations, became a 150-line Jinja monster I was scared to touch, and has been rewritten more times than I’d like to admit.
It feels like this integration is the final form of how I’ve been running my lights so I’d like to share it more widely. First it needs a few brave souls to help me iron out any remaining kinks.
What makes it different
Most adaptive lighting maps brightness and colour temperature onto the sun’s position — one continuous curve from sunrise to sunset. That tracks the daylight beautifully, and the daylight isn’t my schedule. The two drift furthest apart in exactly the months I spend all day indoors.
FLARE works from your schedule instead, splitting the day into four named phases:
- Morning — bright and cold, at a fixed time before you’re normally up. The same wake-up light in December as in June.
- Day — the long middle, gradually warming toward evening so the handover isn’t abrupt.
- Evening — the one phase that does track the sun, anchored to your actual sunset, clamped between an earliest and latest bound so a 4pm winter sunset doesn’t start your evening while you’re still at work.
- Night — dim and warm, the lighting you want at 3am without waking yourself up further.
Each phase has its own brightness, colour temperature, and a transition saying how long before the phase ends to start easing into the next one.
The quickest way to understand it is the interactive playground — it runs the real dashboard card, and every boundary and value is a slider you can drag.
What it actually does
- Keeps lights where they should be. Commands go missing on a Zigbee mesh; FLARE re-checks on a timer and re-sends anything that drifted or never arrived, rather than assuming a command landed.
- Handles lights on a physical wall switch. Cut power to a room and restore it and it catches each bulb as it reappears, putting it straight onto the current phase instead of leaving it at whatever it powered up as.
- Gets out of the way. Change a bulb yourself — app, switch, another automation — and FLARE stops driving that bulb until the room next goes dark. It doesn’t fight you.
- Hands off to scenes. A scene can own part of a room while FLARE keeps the rest on the curve.
- Copes with awkward bulbs — ones that can’t take brightness and colour in one command, ones that round values off, ones that lie about their supported colour range.
- Two ready-made dashboard views, added with a few lines of YAML. They build themselves from whatever you’ve set up, and a schedule you add later just appears.
- Occupancy turns rooms on and off as people come and go, with a configurable wait.
- Everything is a plain Home Assistant action. The blueprint is a worked example, not the product — the curve maths, the grouping and the override protection are all services you can call from your own automations if you’d rather build your own thing.
About the code
I’ve been running the integration in my own house for over a month and I think I’ve (got Claude to) solve all the bugs now.
And yes — currently this is all vibe coded. I work full time, have two young kids and we’re trying to renovate the house, so free time isn’t something I have in spades. Now that the implementation has largely settled down I’ll try to find time to go through and review all of the code properly. If you’re not happy running AI-generated code, wait until then — no hard feelings, that’s a completely reasonable line to draw.
What being a beta tester means
Mostly: install it, use it, and tell me when it does something stupid.
- You install it through HACS as a custom repository — it’s not in the default store yet, and won’t be until it’s had some real use on machines that aren’t mine.
- Bug reports on GitHub are ideal, but a reply on this thread is completely fine. What helps most: what your bulbs are, what you expected, and what happened instead. If you can grab an automation trace, that’s gold.
- Breaking changes are possible. It’s pre-1.0, and while it’s below 1.0 a minor bump is where breaking changes land. The changelog calls them out explicitly, and there are two halves (integration and blueprint) that deploy separately, so occasionally you’ll need to update both.
Links
- Documentation — quickstart, dashboard, full blueprint reference
- Interactive curve playground — start here
- GitHub — issues, code, changelog
. I can bore anyone at length about the intended architecture, but I’ve given the code itself very little oversight so far, which is why I felt like I needed to call it out.