Unifying Modbus, BLE and MQTT in One Backend

The dashboard should consume one common model while retaining source identity for troubleshooting. Think of it like an interpreter at a UN summit: every delegate speaks their own language, but what reaches the notetaker is always one common language.

The way there is a layered design: per-protocol adapters at the edge, a normalization layer in the middle, and one common data model that everything downstream reads. I used exactly this to connect 8+ device categories across Modbus, MQTT, BLE, and WebSocket into single dashboards.

The layered shape

Each adapter knows the quirks of its protocol, and nothing else. The normalization layer knows the canonical model, and nothing about wires.

Adapters: isolate the protocol mess

Each protocol has its own awkwardness, and the adapter is where it stays contained:

• Modbus — poll devices on a schedule, read holding/input registers, and map raw register values to meaningful readings (scale, offset, data type). The trade-offs of scheduled reads are covered in Modbus polling vs event-driven ingestion.
• BLE — handle short-range wireless through a gateway that bridges devices to the backend. Deal with connect/disconnect churn there.
• MQTT — subscribe to topics and parse incoming payloads into events.

The rule: protocol-specific code lives only in its adapter. Nothing downstream should contain an if (protocol === ...).

The common data model is the contract

Every adapter emits the same shape — device ID, metric name, value, unit, and timestamp. Once telemetry is in that canonical form, storage, dashboards, alerts, and APIs all work against one model. Adding a new protocol later means writing one new adapter, not touching the dashboard. For how this canonical model feeds real-time delivery in practice, see building MQTT and WebSocket backends for real-time IoT.

Why this pays off

A normalized model is what makes the rest cheap. A new device category, a new report, a new alert rule — none of them care how the data arrived. Adapters contain protocol-specific behavior. New devices may still need new metrics, quality flags, or UI behavior even when the telemetry model can be reused.

The takeaway

Put protocol-specific code in adapters. Normalize to one common model. Let everything downstream depend only on that model. That single decision is what turns a pile of incompatible devices into one coherent system.

This is one piece of a larger system. See the complete guide to IoT backends, the case study, or the IoT backend development service if you want one built.