The home is where the privacy argument for edge AI is strongest — people don't want bedroom audio or hallway video leaving their walls. On-device intelligence isn't a feature here; for a growing share of buyers it's the purchase criterion.
This guide covers what actually runs on-device in smart home products: voice, presence, audio events, and the architectures that keep it local.
Local wake words and commands
Always-on voice is the flagship home use case — and it's entirely a TinyML problem. A keyword-spotting model runs on the device's MCU at microwatts, waking the product only for the trigger phrase; downstream command models (10–50 intent phrases) fit the same silicon for products that want fully local control.
The architecture decision is what happens after the wake. Fully local products keep command inference on-device — lights, locks, thermostat intents all work with the internet down. Hybrid products hand off to cloud ASR for open-ended requests; the honest implementation makes local control complete and cloud the enhancement.
Presence sensing: beyond PIR
Passive infrared detects motion, badly — it misses seated people, can't count, and can't tell human from pet. ML on better sensors changes the product: mmWave radar detects breathing-level micro-motion through materials; ultrasonic and audio models infer occupancy; IMU + PIR fusion cuts false triggers.
A presence model that knows 'someone is quietly reading in that chair' versus 'the cat walked through' is the difference between a thermostat that learns and one that fights its owners. These models are small — mmWave point-cloud classifiers and audio presence models run in tens of KB.
- Wake words + local commands — voice that works offline
- mmWave/audio presence — detects stillness PIR misses
- Audio event detection — glass break, smoke alarm, baby cry, water
- On-device means the footage/audio never leaves
Audio event detection
A microphone plus a small model replaces dedicated sensors: glass-break detection, smoke-alarm-beep recognition, baby-cry and cough detection, running-water and appliance anomalies — all single classes on a compact audio model, all private because the audio never leaves the room.
The engineering is the standard audio pipeline (MFCC → small CNN) scaled to the deployment: duty-cycled listening on battery products, continuous on powered ones, with the false-alarm tuning that determines whether 'smart' means useful or annoying.
The privacy-first architecture
The winning product pattern: raw sensor data stays on the device, period. Events go upstream — 'occupancy in living room', 'alarm sound detected' — as compact derived data. Cameras that infer locally send 'person detected', not video; mics that infer locally send class labels, not audio.
This isn't just ethics — it's product economics. Every megabyte not transmitted is radio power saved, cloud storage not paid for, and a privacy liability not created. Edge-first homes are cheaper to run, harder to breach, and easier to sell.
Frequently Asked Questions
Can smart home voice control really work without the cloud?
For fixed command sets, absolutely — keyword spotting plus intent classification on tens of phrases runs entirely on-device and keeps working in outages. Open-ended natural language ('what's the weather', arbitrary requests) still needs cloud ASR. The good products make everything the device itself can do (lights, locks, temperature) fully local.
What's better for occupancy: radar, audio, or PIR?
mmWave radar is the strongest single sensor — detects micro-motion (breathing) through materials, counts people, works in darkness, and preserves privacy. Audio adds event context but raises privacy sensitivity. PIR is cheapest and fine for motion-triggered lights; it just can't detect stillness. Fusion (PIR wake → mmWave confirm) is the efficient pattern.
How do on-device models handle different homes?
Home environments vary wildly — room acoustics, layouts, noise profiles. Models train across diverse data, then tune thresholds per deployment (often with a brief in-app calibration). Anomaly-detection patterns that learn the specific home's normal adapt better than fixed supervised models for occupancy and audio events.
Does on-device AI make smart home devices more expensive?
Marginally on BOM — a slightly larger MCU or a small NPU adds cents to dollars — but it eliminates per-device cloud inference and storage costs that accrue forever. Over the product's service lifetime, local inference is usually cheaper, and the 'nothing leaves your home' story increasingly commands premium pricing.
Building something that should run AI on-device?
Edgehound designs, compresses, and deploys TinyML models on microcontrollers — from feasibility audit to field-ready firmware.