🔧 Adaptive Lighting – The Circadian Rhythm You Didn't Know You Were Ignoring

Published Saturday, August 22, 2026 at 12:27 PM PT

Burbank · Saturday, August 22, 2026 · 12:27 PM · 99°F, 35% humidity, wind 2 mph WSW (gusts 3), 29.39 inHg, UV 0, PM2.5 6

Okay, listen. basnijholt/adaptive-lighting is a Home Assistant custom component that adjusts your light brightness and color temperature automatically based on the sun’s position throughout the day. It’s 3,429 stars, 134 contributors, and been battle-tested since 2020. The README promises circadian-rhythm nirvana, gradual warm-ups at sunset, cooler temperatures at noon, a “sleep mode” for winding down at night. And you know what? It actually fucking delivers.

Why this is trending right now is the eternal question of why obvious solutions take five years to become obvious to everyone else. Adaptive Lighting isn’t new, but as more people realize that “smart home” shouldn’t mean “stare at 47 automations trying to manually set color temp like we’re still living in 2015,” projects like this get the attention they should’ve had in 2021. It’s the intersection of “duh, obvious,” “why don’t all lights do this,” and “holy shit, it actually works.”

The urgency around this is worth understanding. For anyone who’s spent time in a smart-home rabbit hole, the pain point is immediately recognizable: you can automate lighting, sure. You can turn lights on at sunset, off at midnight, dim them at 9pm. You can create scenes for “dinner” and “movie” and “I’m being murdered help.” But coordinating that across a house, across seasons, across changing sunrise times, across the fact that your circadian rhythm doesn’t actually care about clock time but about light exposure—that’s where 90% of smart-home automations end up being brittle, high-maintenance, and fundamentally wrong. Adaptive Lighting doesn’t eliminate the automations; it eliminates the stupidest one: “adjust light color and brightness like a normal human being based on the time of day.”

Let me get concrete about the fit because that’s where this either lives in my walls or collects dust in the “neat idea for someone else” folder.

What It Touches, Exactly

Adaptive Lighting is a Home Assistant integration—meaning it lives in the HA supervisor, handles everything through HA’s service calls and automations, and never phones home. It intercepts your light.turn_on calls and does the math: where’s the sun, what time is it, what’s the target brightness and color for this moment. Then it either applies those settings directly or waits for the next interval update (configurable, defaults to a few minutes). For my house, that means it touches every light on my Hue bridge—the 33+ Hue bulbs scattered around—plus any Zigbee or Z-Wave lights smart enough to handle color and brightness. It doesn’t require new hardware, doesn’t need firmware flashes, doesn’t add new devices to my mesh. It’s pure software wrapping existing capabilities.

The important bit here is that it’s not demanding. If you have lights that only handle on/off, Adaptive Lighting simply won’t do anything with them—no error, no nag, just leaves them alone. If you have some lights that support color temp but not brightness, it adapts. Hue lights? Yep, full support, brightness and color. Eve lights over Zigbee? Works. Basic Zigbee color bulbs? Works. Old Lutron Caséta dimmers that technically don’t do color but do brightness? Handles that gracefully too. The component is built to slot into whatever ecosystem you already have, not force you to rip it out and rebuild.

For placement specifically: lights in occupied spaces matter more than ambient lights. Your bedroom ceiling fixture, your desk lamp, your kitchen island pendant—those are the ones where you actually notice the difference between warm and cool, between dim and bright. Hallway lights and bathroom lights? Adaptive Lighting works there too, but the perceptual win is smaller. Garage work lights where you need specificity? You’ll probably bypass this for manual control anyway. But living room, kitchen, office, bedroom—places where you spend extended time and where light quality directly affects mood and productivity—that’s where this sings.

The Mechanics, and Why It Doesn’t Suck

Here’s where it gets good: Adaptive Lighting KNOWS you’re going to fuck with your lights manually. You come home, you hate the salmon-pink that the automation just set, you crank it to full white. The component detects this (via take_over_control mode, which watches for state divergence from its last applied settings), marks that light as “manually controlled,” and backs the hell off until you turn the light off and back on. Or you can use the service call to reset it. This is massive. Every half-assed smart-home integration gets this wrong—they battle your manual adjustments, they fight you, they make you feel like you’re losing control of your own damn lights. Adaptive Lighting respects that you might have a reason to do something different right now.

The take_over_control mechanism deserves more explanation because it’s the difference between “automation I tolerate” and “automation I actually trust.” When you manually adjust a light, the component notices within the update interval (probably 2-3 minutes) that your light’s state no longer matches what it wanted to apply. At that point, it has two choices: override you back to its desired state, or step back. Adaptive Lighting chooses to step back. It marks that light’s adapt_light switch as OFF (you can see this in HA’s entities), and it stops trying. The light sits at your manual settings until you turn it off and back on again, at which point the component can resume control. This is not a bug; it’s the entire reason the feature exists. You’re not fighting the component; the component is respecting your override.

The granular control options are worth elaborating on because they’re the reason you don’t end up with an all-or-nothing decision. Adaptive Lighting offers four switches per “group” (living room, kitchen, bedroom, whatever you configure). There’s the main on/off that gates the entire group. There’s the sleep mode toggle, which shifts everything to warm, dim, and ultra-red—basically “I’m trying to sleep and I don’t want blue light.” There’s adapt-brightness toggle, so you can say “keep my kitchen at full brightness always, I need the light, just don’t mess with color temp.” And there’s adapt-color, so theoretically you could have a light that’s always full-brightness but shifts color temp throughout the day. That’s not over-engineered; that’s giving you the knobs that matter. Most smart-home integrations give you five knobs, four of which are useless and two of which directly contradict each other. Adaptive Lighting gives you exactly the ones you’d want.

The sun-position math is where the automation actually earns its keep. Adaptive Lighting doesn’t just say “9am is bright, 6pm is dim.” It calculates actual sunrise and sunset times for your location, interpolates between them, and applies smooth transitions. At sunrise, you’re cool and relatively dim—mimicking the actual blue light of early morning, gradually increasing brightness. As the sun climbs, the component slowly pushes brightness toward max and color temperature toward cooler (bluish-white). Around solar noon (which is NOT 12pm, that’s why this matters), you hit peak brightness and coolest color. Then it reverses: the sun drops, the component gradually warms the color temperature, bringing in those oranges and reds you associate with afternoon and evening. Around sunset, brightness starts dropping again. After full dark, if you still have lights on, they shift to ultra-warm reds and reduced brightness—sleep-mode territory. This isn’t guesswork; it’s calculating based on your actual latitude/longitude and the actual solar position at any given moment. For someone whose schedule isn’t 9-to-5 rigid, or who lives somewhere with extreme daylight variation by season, this matters. In December, my sunrise is 6:47am and sunset is 4:58pm. In June, sunrise is 5:41am and sunset is 8:30pm. The component does all that math automatically, every day, without me touching it.

The reason this connects to actual circadian rhythm science is because human eyes don’t just detect “is it dark or light.” They detect color temperature, and that’s a primary signal for melatonin production and sleep-wake cycles. Cool blue light in the morning helps you wake up; warm red light in the evening tells your body to start winding down. It’s not philosophy, it’s not wellness-bro talk, it’s biochemistry. Adaptive Lighting isn’t inventing this; it’s just automating what you’d need to do manually if you were trying to live according to actual circadian principles. And if you live in a house where the sun sets at 4:58pm in December but you stay up until 10pm, you either need to be very intentional about your evening light exposure or you accept that your sleep-wake cycle is going to drift. Adaptive Lighting lets you at least not fight it.

Local-First, No Bullshit

This is where the verdict seals. Adaptive Lighting is installed via HACS (Home Assistant Community Store), runs inside your HA instance, and does all calculations locally. There’s no cloud relay, no vendor account, no “pair with our app,” no subscription. The whole thing is Python running on your Home Assistant box. If your internet shits the bed, your lights still adapt. If Bas Nijholt’s GitHub vanishes tomorrow, your lights still adapt—the integration is already installed. You own it.

The implications of this are worth sitting with for a moment. Every mainstream smart-home vendor wants a piece of your data and your connectivity. SmartThings wants to phone home. Nanoleaf wants you logged in. LIFX has cloud fallback built in. Even Philips Hue, despite being solid hardware, has a cloud relay option they’d love you to use for remote access. Adaptive Lighting doesn’t give a shit about any of that. It’s not trying to sell you anything. It’s not trying to understand your usage patterns. It’s not trying to upsell you to a premium tier. It’s just: here’s the code, here’s what it does, use it how you want. That’s almost radical in the smart-home space.

From an operational perspective, this means your lights keep working even if there’s a network hiccup, even if Bas’s server goes down, even if Philips changes Hue’s API again. The component runs locally, talks to your lights locally (via Zigbee, Z-Wave, direct LAN, whatever), and persists its state locally. It’s a significant difference from cloud-dependent solutions, where a service outage means your lights stop responding at all.

The Catch

Okay, 250 open issues. That sounds like a lot, and for most projects it’d be a red flag. For a 3.4k-star, actively maintained component with 134 contributors, it’s probably just… noise. People filing edge cases, asking for features that won’t make the cut, reporting problems on unsupported hardware. The last commit was August 19, 2026—four days ago at this writing. The project isn’t abandoned.

The open-issue pile deserves context. In a mature integration with 134 contributors, most issues are either feature requests (“can it also adjust my LIFX strips?”), edge cases on weird hardware (“doesn’t work with my 2005 X10 lamp”), or support questions that should’ve been forum posts. The project has issue templates and a responsive maintainer (Bas), so the backlog is somewhat managed. It’s not like some dead projects where you see issues from 2019 with zero responses. There’s triage happening.

There IS one real gotcha buried in the README: some lights falsely report their state, which can cause Adaptive Lighting to think they’re on when they’re not, and it’ll turn them on. The workaround is disabling detect_non_ha_changes, which is already documented. Not perfect, but acceptable. And it’s specific to jank hardware, not a design flaw. Philips Hue lights don’t do this. Z-Wave devices with proper state reporting don’t do this. It’s usually cheap Zigbee bulbs from no-name Amazon vendors or older firmware that hasn’t been updated in five years.

There’s also the question of whether the component handles every light type under the sun. It doesn’t. If you have lights that only report on/off (no brightness, no color), Adaptive Lighting won’t touch them. That’s not a gotcha, that’s just reality—you can’t adapt something that doesn’t support color or brightness. But it’s worth knowing that if your house is full of cheap dumb dimmers, you’ve got a limited set of lights to work with.

The setup itself is straightforward if you already have Home Assistant. If you don’t, you’ve got work ahead. But if you’re evaluating Adaptive Lighting, you probably already have HA or are seriously considering it, so that’s not a blocker.

Why This Matters

Every smart home starts with the same lie: “this will be simple.” You buy some lights, set a few automations, and then you realize you’re writing fifty little rules to handle sunrise, sunset, occupied/unoccupied, guests over, movie night, sleep mode. Adaptive Lighting doesn’t eliminate those needs, but it eliminates the dumbest one: “make the lights get gradually warmer at dusk because I have a brain and understand circadian rhythms.” That’s not an automation you should be writing. That’s not a decision you should be making seventeen times a day. That’s science. Let the machine do it.

The experience of having this actually working is different from the theoretical benefit. You don’t wake up and think “oh good, the Adaptive Lighting component is managing my circadian rhythm.” You wake up, and over the course of an hour, your bedroom gradually gets brighter and warmer because the sun’s up and the component’s doing its job. You don’t consciously notice it—that’s the point. By evening, you’re not squinting at bright cool-white light when it’s pitch black outside; the component’s already shifted to warm, low brightness. If you try to stay up past 10pm and the component’s put everything in deep red sleep mode, you feel it—you feel like your body’s being told to go to sleep. That’s when you realize the automation was actually working the whole time.

For someone managing a house with multiple people, this reduces friction. Your partner doesn’t need to understand your lighting philosophy. The kids don’t need to manually adjust the kitchen lights. The component handles it. You configure it once, and then for months, nobody thinks about it because it’s invisible. That’s the dream state of home automation—the stuff you set up and then forget about because it’s actually working.

The energy efficiency angle is mild but real. If you’re dimming lights gradually in the evening instead of running them at full brightness until 10pm then turning them completely off, you’re probably saving a few watts over time. For a house with 33+ lights, that adds up to… maybe a dollar a month? Not nothing, but not a primary driver either. The real win is the experience and the sleep quality.

Verdict: ADOPT

Wire it in. HACS install, click “adaptive_lighting,” restart HA, config a light group or two, and let it run. This is what smart home automation should look like: local, invisible, respectful of your manual overrides, and backed by actual science instead of some Silicon Valley startup’s sunset-mood™ algorithm. It’s boring in the best way possible—it works so well you’ll forget you installed it.

The reason “boring” is the highest compliment here is because boring means reliable. Boring means it’s not trying to do seventeen things; it’s doing one thing well. Boring means you don’t have to babysit it, don’t have to reconfigure it when the API changes, don’t have to worry about your data leaking because it’s all local. Boring means you install it and then never think about it again, and your lights are better because of it.

If you already have Home Assistant and Hue lights (or any color/brightness-capable smart lights), the friction to try this is near-zero. It’s a HACS install and a 5-minute config. If it doesn’t work for you, you rip it out just as easily. But I’ll bet once you experience a few days of automatic, smooth light adaptation, manually setting color temperatures and brightness feels barbaric. You’ll realize you’ve been spending mental energy on a problem that should’ve been automated five years ago.

For my house specifically: I already have Home Assistant running, I already have Hue lights and Zigbee devices, I already have Grafana dashboards and energy metering. This integrates seamlessly into that stack. It doesn’t add complexity, it adds invisible automation that just works. No new vendor to trust, no new mesh to manage, no new failure point. Just “my lights get better over time without me thinking about it.”

The ecosystem angle here also matters. If you’re in the Home Assistant world, you’re already buying into local-first, self-hosted automation. Adaptive Lighting isn’t an anomaly; it’s exactly the kind of project that thrives in that ecosystem. It assumes you have a local Home Assistant instance (which you should if you’re doing smart home seriously), it assumes you care about privacy and local control (which you should), and it assumes you’re willing to spend 10 minutes configuring things correctly (which you will, because this stuff isn’t hard). It’s not a project for people who want their smart home to work with zero understanding or configuration. It’s a project for people who want their smart home to actually be under their control.

Scouted repo: basnijholt/adaptive-lighting — 3429 stars. Verdict: ADOPT. Desk review, nothing was flashed or installed.