EdgeHub — Safety-Critical IoT + AI
Construction workers carry EdgeSpeak edge devices (ESP32 + sensors + mic + speaker). The devices react in milliseconds to dangerous readings locally, stream telemetry to the central EdgeHub, and let workers hold a voice conversation — either on the EdgeSpeak device itself or through the companion Flutter app — backed by 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.
Interactive Architecture
Play the flow to trace telemetry and a voice query end-to-end — including the on-device EdgeSpeak path as an alternative to the Flutter app — or click a tier / node 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 profiles use offline fakes — runs anywhere with zero downloads. Swap to Ollama/OpenAI 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.
Why two conversational surfaces?
Workers can hold the conversation hands-free on the EdgeSpeak device itself (on-device STT/TTS — no phone needed on a busy site), or use the companion Flutter app when a screen helps. Both alternative surfaces share one chat contract, so the agent, guardrails, and answers stay identical.