Voice AI Hub - Safety-Critical IoT + AI
Construction workers carry ESP32 edge devices (sensors + mic + speaker). The devices react in milliseconds to dangerous readings locally, stream telemetry to a central Hub, and let workers ask questions by voice using a local LLM.
A key design decision here is the tiering: conversational AI must never sit on the safety path. The architecture uses three latency tiers so a sub-10ms safety alert can never be blocked by AI, with a zero-download demo so anyone can run it offline with no model downloads.
Personal project - source code and an interactive demo (mock data plus a hosted LLM chat interface) are coming soon.
Interactive Architecture
Click on a tier below to highlight its components
Key Architecture Decisions
Why Tiered Latency?
Safety alerts must NEVER be blocked by AI processing. Tier 0 fires in under 10ms on-device. Tier 2 (LLM) is on a completely separate path - chat load cannot delay a safety alert.
Why NL-to-SQL with validation?
Read-only DB user + SQL parser + table/column whitelist + forced LIMIT. LLM output is untrusted - defense in depth prevents injection, resource exhaustion, and data exposure.
Why provider pattern?
LLM, STT, TTS, vector store, DB are all swappable behind abstract interfaces. Demo profile uses offline fakes - RUNS ANYWHERE with zero downloads. Swap to Ollama/Qwen3 for full mode.
Why MQTT over HTTP?
MQTT is designed for constrained devices - lightweight binary protocol, persistent connections, QoS levels, and pub/sub decoupling. ESP32 devices have limited memory and unreliable connectivity.