Project notes / Home Assistant
The details behind
a familiar switch.
A useful smart home has to make sense in the moment someone uses it. My Home Assistant work connects physical controls, lighting, and AI assistance, with attention to the behavior between a button press and the result.
01 / Physical controls
More than “turn the light on.”
The nursery lighting project started with a practical need: familiar on/off control, dimmable white light, and a preset red scene. The interesting work was defining exactly how those choices should behave.
Setup established
A physical switch with configurable behavior
I added an Inovelli Blue switch and an Inovelli bulb to Home Assistant through ZHA and enabled smart-bulb mode. This separates the control interaction from simply cutting power to the bulb.
It gave me a way to treat the paddle and the configuration button as inputs to the experience, with Home Assistant coordinating the lighting behavior.
Interaction requirements
The next action should be understandable
- Select before activating. Use the macro/configuration button to choose the next-on scene.
- Show the selection. Use the switch LED to indicate which scene the next on press will apply.
- Control the first visible state. Activate red directly, without a flash of the previously used scene.
The troubleshooting behind the controls
The expected “Up single pressed/clicked” event was not initially available in the interface. I worked through the switch-event setup with AI assistance, including a prompt for Hermes to use the Home Assistant API.
The useful distinction was between the behavior I wanted and the events the integration actually exposed. I continued with ZHA while evaluating whether a move to Zigbee2MQTT would solve a concrete limitation.
Scene control progressed, but the red-first transition and LED behavior are documented here as interaction requirements. A final state looking correct is only part of the acceptance check.
The product decision: the LED should communicate the next action. That requires treating the selected scene and the current light output as separate pieces of state.
02 / Interactive design walkthrough
Explore the edge cases.
These are the intended interactions and acceptance checks behind the project. The walkthrough is an illustration of the design.
Interaction specification
Selection and activation are different actions.
The light is off. Someone wants to choose the scene that will be used next.
- Input
- Press the macro/configuration button.
- Expected behavior
- Advance the selected scene without turning the fixture on. The main paddle remains the familiar way to activate it.
- Visible feedback
- The switch LED represents the selected next-on scene, so the next action is visible before the light changes.
Acceptance check
With the light off, changing the selection should leave it off. The next on press should apply the scene represented by the LED.
Interaction specification
The transition is part of the experience.
The fixture was previously white, is now off, and red is selected for the next activation.
- Input
- Press the on paddle.
- Expected behavior
- Apply the intended red color and brightness as part of activation, rather than restoring the old white state first.
- Visible feedback
- The visible result should be red from the start. A brief flash of the prior scene still fails the interaction requirement.
Acceptance check
Repeat white → off → select red → on. Observe the first visible output as well as the final state.
Interaction specification
Two bulbs should present one useful control.
Two Inovelli Zigbee bulbs are installed in a single two-bulb fixture.
- Input
- Use the grouped light control.
- Expected behavior
- Address the fixture as one lighting target, keeping the individual bulbs available for device-level investigation.
- Visible feedback
- The person using the room should be able to identify the fixture without needing to understand the coordinator that owns the group entity.
Acceptance check
Check group on/off and scene behavior, then inspect the entity and device representation separately. A group existing is not the same as an intuitive fixture interface.
03 / Device and entity modeling
One fixture. Two bulbs.
A small abstraction that matters.
When I added two Inovelli Zigbee bulbs to one fixture, the goal was a single useful control for the room.
Observed in the setup
The group worked differently in the interface
After creating the group, I noticed that its light entity appeared under the Zigbee coordinator rather than as a separate fixture device. That raised another design question: how should the household recognize and use it?
The group, the individual devices, and the fixture people think about are related, but they are different layers of the model.
The user's mental model comes first
A person using the room thinks “this light fixture,” not “two bulbs managed by a coordinator.” Grouping provides a shared target; naming and presentation still need to make that target understandable.
I pay attention to both the functional result and how Home Assistant represents it. This is the same kind of distinction I work through in business systems: a technically correct model needs an interface people can use.
The actual devices installed in one fixture.
A shared target, shown under the coordinator in my setup.
The control and name someone expects when using the room.
The systems lesson: device ownership and useful presentation are separate questions. I noticed the mismatch because I was looking at the experience as well as the configuration.
04 / AI as part of the workflow
Instructions deserve the same care as controls.
I use AI assistance to work through Home Assistant configuration, and developed instructions for a ChatGPT-based Home Assistant assistant. The prompt itself became a design problem.
Prompt developed
Precise behavior in a limited space
I iterated on machine-readable instructions, asking for shared rules and more precise wording while preserving meaning. A related Home Improvement / Home Assistant project prompt had a 7,900-character limit.
The goal was dense, usable instructions with clear relationships between rules. Character count was a real constraint; shorter wording alone was not proof of fewer tokens or better behavior.
Make the assistant's reasoning actionable
- Inspect before acting. Ground actions in the devices, entities, and capabilities actually exposed.
- Keep intent and observation distinct. A requested result and a verified result should be described differently.
- Verify after acting. Use the resulting system state to determine whether the intended change happened.
These are instruction-design principles, rather than a claim that the prompt guarantees every live action.
The common thread: whether the input comes from a paddle or an AI assistant, the intent, available action, and observable result need to line up.
05 / An ongoing project
Room to keep building.
The lighting and assistant work are part of a growing Home Assistant environment. These are research directions I have begun exploring.
Exploring
A voice interface built around Home Assistant
Researching a custom, Google-Home-like speaker that fits the Home Assistant environment.
How can a spoken request become a clear, verifiable action without making voice the only useful way to control the home?
Exploring
Whole-home energy visibility
Researching ways to bring total household power consumption into Home Assistant.
Which measurements would help explain household consumption and support useful decisions?
What this brings to my product work
Clear requirements, attention to transitions and feedback, investigation across system layers, and an interface shaped around how people actually use it. The home gives me a place to practice those habits with consequences I experience directly.
Explore my professional work