Aeion Smart Spaces + MQTT & IoT Sensor Protocols
MQTT is the live workhorse — a real `mqtt.js` ingestion client that buffers and batch-flushes telemetry, plus a per-tenant control publisher that reads back device acknowledgements. It runs directly from the server, no gateway required. HTTP/REST sensors are live too, and Bluetooth LE occupancy beacon scanning is real through Aeion Bridge. The rest of the sensor and lighting protocols — Zigbee, Z-Wave, DALI, KNX, Matter, Thread, LoRaWAN, OPC-UA, EnOcean, Wi-Fi — are declared protocol types with an honest transport-not-configured fallback. This page is candid about which is which.
What Connects — Live vs. Roadmap
`
MQTT — The Live Path, Both Directions
MQTT is the one sensor protocol wired end-to-end for both reading and writing, and it needs no gateway.
HTTP/REST & Bluetooth LE — The Other Live Legs
HTTP/REST — live, no gateway. The most complete adapter in the module. Control does a real fetch (POST/PUT/PATCH) against the device endpoint with a hard timeout, auth headers from the device's transportConfig, and JSON acknowledgement parsing (tolerating 204 No Content and plain-text OK bodies). The ping side does a real reachability check with measured round-trip time. Use it for any webhook-capable or cloud-connected sensor.
Command Envelope & Honesty Signal
```typescript
What It Does NOT Do
Precise, so you can plan around it:
FAQ
MQTT (ingestion and control, no gateway needed) and HTTP/REST (control and ping) run directly from the server. Bluetooth LE occupancy beacon scanning is live through Aeion Bridge. Everything else in the list is roadmap.
They are declared protocol types with real metadata (transport family, port, encryption), but no working transport is behind them yet. A command returns an honest `transport_not_configured`. We'd rather tell you that plainly than have a "queued" command silently go nowhere.
The ingestion client buffers readings and flushes them in batches (every second or every 100 messages), so there's no per-message database write. Readings are stored append-only for tamper-proof ESG and AI-training integrity. See Tech Specs for the ingestion architecture.
No. MQTT ingestion and control run from the server against your broker — cloud-hosted or a bridged local broker, your choice. Bridge is required for the physical-radio legs like Bluetooth LE occupancy scanning.
It doesn't throw. `IoTControlService` returns `transmittedToDevice: false` with `reason: "transport_not_configured"`, writes the audit row, and emits the event. Your dashboards see the gap instead of a false success.
MQTT that's live end-to-end — and a straight answer on the rest.
Real mqtt.js ingestion with buffer-and-batch-flush, per-tenant control with true device acknowledgements, live HTTP/REST and BLE occupancy scanning, and an honest transport-not-configured signal for everything still on the roadmap.