Get MQTT Data into Power BI
MQTT is the protocol your devices already speak — lightweight, efficient, and widely supported across industrial hardware and IoT platforms. The problem is that MQTT is a real-time message bus, not a queryable data store. Power BI can't subscribe to a topic. Before a single dashboard can be built, the data needs somewhere to land — and getting it there cleanly is where most teams hit a wall.
If you've already tried something and hit a wall, the list below is probably why. The challenges are mostly about the protocol itself, not the destination — and they tend to compound.
Why it's hard
Seven reasons MQTT data doesn't flow into Power BI without deliberate infrastructure between them.
MQTT has nowhere to land — Power BI can't subscribe to a broker
Power BI is a pull-based reporting tool. It connects to a data source, queries it, and loads the results into a model. MQTT is a push-based pub/sub protocol — messages arrive in real time and are gone if nothing is listening. Power BI has no MQTT connector and no way to subscribe to a topic. Before any reporting is possible, the MQTT data needs to land in something Power BI can query — a database, a REST API, or a cloud data platform.
You need a broker — and it needs to be reachable from both sides
MQTT requires a message broker (Mosquitto, HiveMQ, AWS IoT, Azure IoT Hub, or similar) to receive published messages and route them to subscribers. Deploying and managing a broker is a standalone infrastructure project. The broker also needs to be reachable by publishers on the OT network and by subscribers or data consumers on the IT or cloud side — which means careful network planning at the OT/IT boundary.
Getting MQTT traffic across OT/IT network boundaries is a security conversation
OT networks are isolated by design. Allowing MQTT publish traffic out of the OT environment — or broker connections in — requires deliberate firewall rules and security review. If the broker is cloud-hosted, the OT device needs an outbound internet path. If it's on-premise, it needs to be reachable from IT systems without exposing OT infrastructure. Neither is plug-and-play, and both require OT security team sign-off.
MQTT payloads carry multiple data points — parsing logic is required for each topic
A single MQTT message often carries a JSON payload with multiple values: temperature, pressure, flow rate, and status flags all in one message. Extracting individual data points requires payload parsing logic specific to each device or topic's schema. Different devices publish differently — there's no standard payload structure. Every unique publisher needs its own parsing rule before data can be stored as individual, queryable records.
Different topics carry different schemas — each needs routing rules
A plant with dozens or hundreds of MQTT publishers will have dozens of topics, each with its own payload structure, update frequency, and units. Subscribing to all of them and routing each message type to the right table, schema, or record format requires a topic routing layer. Without it, data from different sources gets mixed, misinterpreted, or lost. Building and maintaining that routing logic is an ongoing engineering task.
MQTT is real-time only — missed messages are gone
MQTT delivers messages to subscribers that are connected at the time of publication. If the subscriber or the persistence layer is down — for maintenance, a crash, or a network interruption — messages published during that window are lost. MQTT's QoS levels can reduce (but not eliminate) this risk, but only if the broker and subscriber are configured correctly. For historical reporting in Power BI, you need a persistence layer that captures every message reliably over time.
High message volume creates throughput and storage pressure before Power BI is even involved
Industrial MQTT publishers can generate thousands of messages per second. At high update rates across many topics, the volume of incoming messages quickly exceeds what a naive persistence layer can absorb — broker queues back up, messages are dropped, and storage grows faster than expected. Aggregating and downsampling before storage requires engineering work that most broker configurations don't include out of the box.
The approaches teams usually try
Three common paths to bridge MQTT to Power BI — and where each one runs into trouble.
Broker + subscriber service + SQL database + Power BI gateway
Deploy a broker on the OT or DMZ network, write a subscriber service that parses payloads and writes to SQL, then connect Power BI via an on-premises gateway. This is the full-stack custom approach most teams end up building.
The catch: You've built four components — broker, subscriber, SQL, gateway — each of which needs to be deployed, monitored, and maintained. Payload schema changes break the subscriber. Gateway failures break the reports. And the engineering effort required to get here is often more than anyone budgeted for when someone said "the devices already speak MQTT."
Cloud IoT platform (AWS IoT, Azure IoT Hub)
Route MQTT messages to a managed cloud IoT platform that handles broker, ingestion, and storage. Azure IoT Hub or AWS IoT Core can receive MQTT, persist messages, and forward to downstream analytics services that Power BI can connect to.
The catch: Cloud IoT platforms are powerful but complex to configure for non-standard payloads and multi-topic industrial use cases. They still require payload parsing rules, device provisioning, and a network path from OT to the cloud endpoint. Cost scales with message volume, and Power BI still needs a connector to whatever storage the IoT platform routes data into.
Time-series database as the landing layer
Route MQTT messages into a time-series database (InfluxDB, TimescaleDB) via a subscriber service, then connect Power BI to the database. Time-series databases handle high-frequency data better than standard SQL and have aggregation functions built in.
The catch: The time-series database still needs a subscriber service in front of it to parse payloads and write records — the parsing and routing problems don't go away. The database needs to be deployed and managed. Power BI's native support for time-series databases is limited, and connecting Power BI Service to an on-premise time-series database requires a gateway.
How TrendOps solves it
TrendOps Edge is an on-premise MQTT subscriber — it connects to your broker, subscribes to configured topics, parses each payload according to your rules, and forwards individual data points to TrendOps Platform in the cloud. Power BI connects to the platform API directly. No custom subscriber code, no separate database, no gateway.
TrendOps Edge subscribes to your MQTT topics, parses each payload, and writes individual data points to TrendOps Platform. No custom subscriber service to write, deploy, or maintain.
Configure TrendOps Edge with the JSON path, field names, and units for each topic your devices publish. Each payload is parsed according to its own rule — multiple data points per message are extracted into individual, named telemetry records.
Subscribe to multiple topics and define routing rules that map each topic to the right tag, unit, and context in TrendOps Platform. Different devices, different schemas, different frequencies — all handled in one place.
TrendOps Edge subscribes to your broker from the OT side and forwards data to the cloud over outbound MQTT. No inbound ports on the OT network, no cloud IoT platform reachable from your devices.
TrendOps Platform stores every data point that Edge forwards. Historical data is available to Power BI regardless of when the dashboard is opened — real-time messages become queryable history without any additional persistence infrastructure.
Data is in the cloud before Power BI asks for it. Power BI Service connects to the TrendOps Web API directly — no gateway to deploy, register, or maintain.
High-frequency MQTT data is normalised to a configurable forwarding interval before it reaches TrendOps Platform. Power BI gets a data model it can work with — not a raw message stream at full device update rate.
MQTT data lands in TrendOps Platform alongside historian data from AVEVA PI, DeltaV, FactoryTalk, SQL databases, and any other connected source. One Power BI dataset — not one per protocol.
What you end up with
MQTT device data in Power BI — parsed, stored, and queryable — without a custom subscriber service, a separate database, or an on-premises gateway.
Payload parsing, topic routing, and persistence handled by TrendOps Edge — no subscriber service to build.
Power BI Service connects to the cloud API — no on-premises gateway to deploy or maintain.
Every message persisted in the cloud — real-time MQTT becomes queryable historical data.
MQTT alongside historians and SQL data — one Power BI dataset for every OT source.
Your devices already speak MQTT — getting that data into Power BI shouldn't require building custom infrastructure
TrendOps Edge subscribes, parses, and forwards MQTT data to the cloud so Power BI can query it directly — no subscriber service, no database, no gateway.
Book a Demo