This is probably not the right category, please move if you wish.
Put aside your pre-conceptions of smart lighting control for a moment and look at it as a clean fresh problem. So you aren’t starting with an existing way of controlling your lights and adapting to it or it to you. I mean asking the basic questions.
It’s clear that different lights have different requirements, so keeping that in mind, lets focus on basic overhead room lighting. Even then different rooms have different requirements. How can we meet them all in a sensible way? Let’s look at a few use cases for a bedroom overhead light.
When I enter the room I would like the light to come on automatically.
When I leave the room I would like the light to go off automatically.
I would like a way to turn the light OFF fully when I go to bed.
I would like the light to “re-automate” at a certain time in the morning.
I would like a way to tell the light to just stay on.
I would like the light to adapt it’s brightness based on the outside brightness or time of day.
I would like the light to adapt it’s colour temperature based on time of day.
Ideally I would like to adjust, or cycle through themes of temperature, brightness or in case of RBG colours and dynamic themes.
Having been through one or two of these designs, the first thing that jumps out at me, is there is a mixture of potentially conflicting sources of control. You have manual control, sensor/information/decision control AND you have time based scheduling.
I mean it isn’t any good if you press the “OFF” switch, the light goes off, but the motion sensor turns it back on. Ad inf.
In the past I have chosen to place a layer of abstraction between the “requests” and the “control”. So, for example, the MQTT topic for the light switch is NOT directly (or indirectly) connected to the MQTT topic for the bulb. In fact the light switch input or motion sensor or schedule could be accepted or ignored due to some current condition. So the system can run a set of rules and determine the correct state/parameters based on those rules. That refined, coorelated state and parameters is sent to the bulb.
At the moment I have automated lights which have motion sensors, but no manual switches (Hallway / Bathroom) and non-automated lights which have ON/OFF switches.
Given the list of requirements above, I have a long way to go. First step is to figure out the best, most flexible way to separate the “wants” of the system and the user with the practical output to the bulb.
Rules. I hate rules engines. Then I end up writing my own badly done one over and over. My heating system has all too complicated methods of OOP code doing the same, but the lighting problem is more complicated still.
What does this relate to Home Assistant? Well HA would be one of the control inputs. Either making requests by publishing to a topic “it thinks” is a light, but is just an input. Gaining information by subscribing to input, process and output topics. Or providing the handy colour wheels for RGB lights states… I would expect that most manual intervention from somewhere like HA would be considered direct priority. It could also be possible to toggle AUTO/MANUAL mode on lights, use HA to setup schedules based on all the information there. As long as your schedules send the appropriate MQTT message into “the system” it will perform the expect output.
The rules engines. I would be writing them in Python. However I am exploring NodeRed as an interface layer, to allow parts and components in the system to be replaced by other MQTT components. It would also be much more “consumable” for edge-controllers. For when “the system” does not speak the same JSON or topic format or even protocol to the device. Examples I already have are for things like HttpController, RestController, MqttController and specifics like BoilerController(HttpController). Of course… all of those could be done by HA, receive an MQTT message, activate a device.
If I get tumble weed I’ll take the hint, but if there is interest I’d like to “open design” the system in this thread. Consider it a “build thread”.