For a long time, room lighting was not a real pain point for me, except for one thing: being able to switch all lights off at once. That was ultimately what pushed me toward smarter lighting in the first place. At the same time, it mattered to me that the wall switches should keep working exactly like normal, including for guests or other people in the household. I do not want to live in a system that only works when everything lines up perfectly.
What annoyed me more was something else: those small repetitive decisions in daily life.
Do I need light here? How bright? Which scene right now?
Smart bulbs do not remove that. They just hide it. You no longer walk to the switch, but you are still making the decision in your head.
I wanted to think that through properly once and then stop spending mental bandwidth on it, so I could move on to the next daily-life problem instead.
So the idea was not to make lights switch on automatically somehow.
It was this: I want to walk into a room and the light should simply fit.
And if it does not, I need to be able to override it at any time without friction. If needed, in the most ordinary way possible.
To make that manageable, I reduced the problem to two simple questions:
How much light does the room actually need right now, and which concrete lighting follows from that?
The outside world and reality in the room
The more interesting of those two questions is the first one. Before deciding which lamp should turn on, you need to know whether any additional light is needed at all and how much.
The basis is an outdoor brightness sensor. I do not use the raw Lux readings directly. Instead I translate them into a rough human scale: bright, dim, dusk-like, dark, pitch dark. For the automation it does not really matter whether the sensor reads 187 or 214 Lux. What matters is how the room actually feels.
Of course, a single sensor is not a particularly stable foundation. That is why there is a fallback based on the sun position. It is less precise, but it keeps the logic alive when the sensor fails or reports values that are obviously implausible. A lighting system should not fall apart because one measurement is missing.
Over time it also became clear that the same Lux value does not always feel the same. On grey overcast days, a room feels much darker than it does under a clear sky. So cloud cover from the weather service also feeds into the logic and shifts the thresholds dynamically. That is not cosmetic tuning. It makes a noticeable difference in daily life.
The chart reflects the actual threshold values used in the lighting logic.
And this is exactly where simple models start to break apart: shutters.
If the summer sun is hammering the outside wall, the outdoor sensor may still report “bright” while the room itself is half dark because the shutters are closed.
That is why each room ends up with its own derived brightness value instead of blindly trusting the outdoor sensor. If the shutters are open, outdoor brightness can affect the room normally. If they are closed, the room value is downgraded accordingly, in extreme cases all the way to “pitch dark”.
Indoor state and use
Outdoor brightness alone is not enough. A system that gives you the same lighting on the way to the bathroom at night as it does while cooking in the late morning may be technically consistent, but it is very wrong in human terms.
So there is a second perspective: the indoor state.
In the simplest version I derive that from the sleep situation, meaning whether someone is still asleep, has just got up, or has been awake for a while. That gives the automation a second axis: not only how dark it is, but also how much light is actually appropriate.
As soon as more than one person lives in the household, this gets more interesting immediately. One single state is no longer enough because different situations can exist at the same time, one person is still asleep while another is already moving around. In those situations the logic cannot just let the loudest state win. It has to react more conservatively.
With guests it gets even messier. Sensors are missing, routines do not line up, and expectations are unclear. That is exactly why it makes sense to keep the automation simpler in that mode: more defensive defaults, clear manual override, and no attempt to fake perfection.
Combining both sides into a target value
In the end both perspectives come together: outside conditions and indoor state produce a shared lighting intent.
For implementation, a simple encoding turned out to be surprisingly practical. Outdoor brightness gets values from 1 to 5, while indoor states use larger jumps like 1, 10, and 100. That gives each combination a unique value.
| Outside state | Outside value | Bed occupied | Bed empty for a short time | Awake |
|---|---|---|---|---|
| Bright | 1 | 1 | 10 | 100 |
| Dim | 2 | 2 | 20 | 200 |
| Dusk-like | 3 | 3 | 30 | 300 |
| Dark | 4 | 4 | 40 | 400 |
| Pitch dark | 5 | 5 | 50 | 500 |
This is not particularly elegant in a mathematical sense, but it is easy to read in real use. You see the value and immediately know which combination you are in, and you can make adjustments without having to redesign the full logic.
What it looks like in practice
Only at this point does the actual automation come in.
In the kitchen it works roughly like this:
- the door contact notices entry early and switches light quickly
- the presence sensor confirms shortly afterwards that someone is really there
- the calculated target value selects a suitable lighting scene
- changes are adjusted dynamically while presence is still detected
There is also a second safety layer for false triggers. If the door only moved briefly, the automation checks again a few seconds later whether presence is actually there. That way a gust of wind does not turn into permanent lighting.
The switch-off logic is intentionally separate:
- no more presence
- or enough brightness available
That makes the whole thing more robust than packing everything into one huge automation.
There is still an escape hatch for real edge cases:
A long button press disables the automation for that room.
From that point on, everything behaves like a completely normal light switch again.
You rarely need that, but that is exactly why it matters that it exists.
Conclusion
The real strength is not that something somewhere is labelled “smart”.
What I like about it is that I took the question apart properly once and now do not have to answer it myself every day.
The system breaks down into manageable pieces:
- understand outdoor brightness
- account for room-specific effects
- interpret indoor states in a sensible way
- derive a decision from that
That is exactly what makes the whole thing more complex, but also much more usable.
And in the end that is the only currency that matters in daily life.