Connected IoT device: firmware, cloud pipeline, fleet portal, and OTA updates.
Situation
An OEM built a connected industrial appliance: sensor-driven, with actuators (motion, relays/heating) and explicit safety states — but without an existing cloud platform.
The goal was a complete path: the device publishes telemetry, the backend stores history, operators see online status and versions in a portal, and updates roll out in a controlled way — without field service.
Solvetronix covered the full path: firmware fundamentals (network, provisioning, safety), MQTT telemetry and control topics, cloud ingestion into PostgreSQL, an ops portal, and an OTA artifact server for both application and filesystem images.
Approach
Firmware foundation (network, safety, telemetry)
- Device identity (chipId), boot logging, resilient network connect
- Safety interlocks: defined fault states disable actuators
- JSON telemetry: states, measurements, error codes, build/environment
MQTT model + bidirectional control path
- Topic conventions: environment (dev/prod), chipId, dataType
- Telemetry channels (e.g. devinfo, errors) plus control topics (update/Wi‑Fi)
- JSON is intentionally extensible — backend accepts additional fields
Cloud ingestion → PostgreSQL
- MQTT subscriber parses topic → (chipId, dataType, env)
- UPSERT device registry with ON CONFLICT to avoid race conditions
- Persist JSON history in device_data with received_at timestamp
Ops portal (fleet view)
- Device list: last_seen, firmware_build, env, OTA flag
- Detail view: telemetry history and status per device
- Fleet operations: verify versions, trigger updates
Staged OTA: build + filesystem
- Artifact server lists dev/prod builds (folder per build timestamp)
- HTTP download: firmware.bin + filesystem image (e.g. LittleFS)
- Update trigger via MQTT control topic; device confirms with new build in devinfo
End-to-end acceptance
- Telemetry → DB → portal: the same device becomes visible in UI
- OTA folder → control command → reboot → new build shows up in the portal
- Negative paths: cloud/queue outages do not block local safety
How the solution works
The core of this case is the complete operating path: the device publishes telemetry, the cloud stores it, the portal shows fleet status — and OTA can roll out versioned builds (anonymized, no product names).
Data path
Main path (acceptance)
- 1 · Telemetry
The device joins Wi‑Fi and publishes devinfo (build/env) and status data on MQTT topics.
- 2 · Persistence
The ingestion service upserts the device (chipId) and stores the JSON message into PostgreSQL as history.
- 3 · Portal
In the ops portal the device shows as online (last_seen) with the current firmware build and environment.
- 4 · OTA
Portal/backend selects a build folder, sends update control via MQTT; device downloads firmware + filesystem, reboots, and confirms the new version.
Additional tested paths
Update/Wi‑Fi commands are stored as their own data type (not mixed into devinfo) to keep analytics stable.
JSON may contain new fields; ingestion stores them without schema breaks. Parallel packets do not create duplicates due to UPSERT.
Safety states (interlock faults) disable actuators locally, regardless of cloud availability.
Acceptance checklist (staging)
- MQTT devinfo appears at broker
- PostgreSQL: device + device_data for chipId
- Portal overview: last_seen + firmware_build
- OTA API: list dev/prod build folders
- Update control → reboot → new build in portal
Results
Technologies
Planning an IoT device — but no fleet ops?
In 30 minutes we clarify whether an MQTT→PostgreSQL→portal path with staged OTA is realistic for your fleet — including a safety and update strategy.
Request a free assessment