Before we
build, let's
justify the stack.

Grant graduated on May 8. One of the main goals of this project was for him to jump right into relevant and useful work.

It was fun watching him walk across the stage in a standing-room-only fieldhouse, thinking about that accomplishment and already impatient to get started, with the hardware already sitting in a box at home. Clearing four years of coursework and finals is pretty taxing, so we figured taking a week and a half off made sense -- starting refreshed made more sense. There's a version of building a business where you never stop moving and quietly burn out. We're not doing that version.

He also moved out of his apartment, which meant getting everything into a new space and standing up the dev environment. Just like any new job orientation, that takes a few days. By the time the tooling was working and the environment was clean, we had real momentum again -- and a clearer sense of what to write about next.

Before we get into hardware and sensors: we're building this for elder monitoring -- specifically to help my mom, Grant's grandmother, continue living safely on her own. Real information instead of just camera snippets, and two-way communication so she can get timely prompts and reminders. The protocol and server choices below exist because of that. This post covers the two questions that keep coming up on the technical side: what software is running the show, and what protocol(s) make sense?

Our short answer for a server solution is Home Assistant. The longer answer explains why the others didn't make the cut.

The requirement we kept coming back to was local control. Not "local control with a cloud fallback." Not "works offline unless you need this feature." Actually local -- running on hardware we own, no dependency on a vendor staying in business or keeping a free tier alive. For a monitoring system that a family is actually depending on, that's not a small thing.

// Options we evaluated

Home Assistant runs on a Raspberry Pi 5, an Intel NUC, a VM, or dedicated hardware like a Home Assistant Green. We're running it on a small dedicated machine so we're not competing with other workloads. The key thing is that it never needs to phone home. Automations run locally and data stays local. Internal alerts can fire without an internet connection -- external notifications obviously still need some form of functioning connection to reach you.

Zigbee, Z-Wave, WiFi, Matter/Thread. You'll hear strong opinions about all four. Our hardware is already mixed across protocols -- the stack will be too, using whatever is most cost-effective and gets the job done. Here's what each one actually is and where it fits.

A protocol is just the language devices use to talk to the hub. Your choice here affects what sensors and switches you can use, how reliable they are through walls, whether they need batteries, and how dependent you are on the cloud. Getting this wrong means replacing hardware later. Worth thinking through before ordering.

The short version: our hardware is already mixed, and the stack will be too -- using what's most cost-effective and gets the job done at each layer. Zigbee covers sensors well, Z-Wave is worth considering for locks and higher-stakes devices, wired PoE handles cameras, and Matter is worth monitoring as the ecosystem matures. No single protocol covers everything. Knowing where each one fits keeps you from painting yourself into a corner later.

Knowing whether someone is home, where they are, and what they're doing is harder than it sounds. There are several techniques and the right one depends on what you actually need to know.

The simplest approach is a passive infrared (PIR) motion sensor -- inexpensive, battery-powered, and reliable for detecting movement. The Aqara FP1E we ordered goes further with millimeter-wave radar, which can detect someone sitting still in a chair rather than just walking past. Both are easy to integrate and good starting points. But they have limits: they can't tell you who is present, and they can't give you much context beyond "something moved" or "something is here."

WiFi network tracking watches which devices are connected to the home network -- no extra hardware needed. The catch is that the most common implementations only work if the person carries their phone around with them. That doesn't apply here: my mom keeps her phone on the charger by her chair most of the day. Not useful for this install, though it could work well in other situations. There are also passive techniques that watch for Bluetooth or WiFi signals from nearby devices without requiring an active network connection -- still on the list to look into properly. She does wear a Fitbit, which only emits Bluetooth, but polling the Fitbit service could give useful information on movement and daily activity levels. We haven't dug into what their API actually exposes, or how current the data is. Another thing to figure out.

Cameras open up a lot more options but come with tradeoffs. With enough processing, camera feeds can support fall detection without any wearable device, tell individuals apart, and build up a picture of daily patterns. The tradeoff is bandwidth, processing power, and privacy -- none of which simpler sensors have to worry about. For fall detection specifically, cameras may be the only practical option that doesn't require the person to remember to wear something. Worth exploring carefully.

We expect audio -- notifications out loud and some form of voice interaction -- to be a significant part of what this system actually does. A phone alert is fine for the family member checking in remotely. It doesn't help when the house needs to get someone's attention.

A door left open, an unusual sensor reading, a reminder -- for those, the right output is a clear spoken alert in the room where the person is, not a vibration on a phone sitting on the charger across the room. That changes what the hardware requirements actually are.

Volume needs to be loud and clear enough to cut through across a room, over a TV or audio running in the background. Microphones need to be placed where the person actually spends time -- living room, kitchen, bedroom -- not wherever happens to be convenient to wire. Background noise, and a TV running most of the day is exactly that, affects both how well audio alerts are heard and how reliably a microphone picks up voice.

We've ordered a couple of Waveshare ESP32-S3 boards with dual microphones and noise reduction to start experimenting with this. They're development hardware and we don't know yet what we'll end up with. There are also off-the-shelf smart speaker options worth testing. We want to understand what actually works in a real living space before we commit to anything.

For now, the goal is to get a base system running with the simpler sensors -- door contacts on the exterior doors and fridge, temperature sensors in a couple rooms, basic motion or presence detection in the main living areas. The software on top needs to watch for patterns that actually mean something: is she up at her usual time, is the fridge getting opened, is the temperature staying in range. Getting something real running will teach us more than just planning on paper.

None of that is possible with a Nest camera and a subscription. Here it's possible because we own the stack. Audio, camera-based fall detection, Fitbit integration -- those are on the roadmap. The starting line is just getting something working and seeing what it shows us.

Grant has been driving the configuration side since the dev environment came up. The pace should be faster now that graduation and a short break are over.

The original cart was the baseline. A few additions have come in since then.

Some are exploratory -- testing categories we haven't committed to yet. Others are things that could have been in the first order, or just good to have for exploring a broader range of devices.

More will come as we get further into configuration. We're buying hardware both to solve known needs and to get exposure to the whole ecosystem. Some things might prove useful in ways that aren't obvious from a first look.