I want my home automation to handle an ordinary situation well: walk into a room, sit down, and have the lights stay on without periodically waving at a sensor. When I leave, they should turn off. When I disable automation, that decision should take effect immediately.
That sounds straightforward until the system has to decide whether a quiet room is empty or someone is simply sitting still.
In my earlier event-hub project, I explored how sensor events could feed a Go application that controls the response. The Go dashboard work extended that idea to another event consumer. This project further develops the sensing side, bringing embedded firmware, occupancy logic, and enclosure design together in a dedicated presence sensor.
The hardware combines an ESP32, a millimeter-wave radar sensor, a PIR sensor, and a physical switch. I use the two sensing methods as complementary inputs to an occupancy decision. The interesting work is deciding how that evidence should affect the room over time.
The firmware interprets sensor observations and reports state changes. My automation, written in Go, handles the lighting response. That includes allowing a period of uncertainty before switching lights off, responding to renewed activity, and respecting the physical override. Repeated readings should not produce a stream of redundant commands to my IoT lights.
This division gives the project room to evolve. I can adjust the lighting policy without treating every change as a firmware release. Logs around state transitions help explain why the system made a decision, which matters when the behavior differs from what someone in the room expected.
The enclosure has become one of my favorite parts of the work.
I enjoy CAD because it lets me turn a spatial idea into explicit geometry. A mounting post has a defined center and height. A sensor opening has a position relative to the board behind it. Component placements share a coordinate system, so I can track how an adjustment affects the rest of the assembly.
Moving a sensor to improve separation also changes its relationship with the face opening and supports. The switch needs an accessible actuator and a mounting surface. The USB opening needs to accommodate an actual cable being inserted. The enclosure has to leave room for wiring and come apart when something needs servicing.
Those relationships make the mechanical model useful long before printing. I can inspect alignment, revise clearances, and check whether the parts have a plausible assembly path. Small placement decisions become much easier to reason about when they are recorded as dimensions.
This is still a prototype, but the workflow I am using for this project allows me to follow a decision across the whole system. For example, a sensor's placement affects what it observes. Firmware interprets those observations. Go applies the automation policy. The person in the room experiences the result, which can be as simple as whether the lights behave sensibly.
If anyone is interested in my design/approach, I may follow up with a build-focused post once the final material list, design, and behavior have had more time in production use.
AI-Assisted CAD Development
While I didn't want to use token quotas for this specific CAD Build, there are quite a few MCP plugins for CAD software that help automate much of the cognitive work, like auto-aligning parts into an assembly and doing the math to ensure correct geometry.
Adam Zewe | MIT News
Anne Wilson | Department of Mechanical Engineering
