Get MQTT Data into Excel
Your devices publish MQTT. Your analysts use Excel. The gap between those two statements is larger than it looks. Excel has no MQTT subscription capability — it can't connect to a broker, it can't parse a topic, and it has no way to receive a push-based real-time stream. Before MQTT data can appear in a workbook, it needs to land somewhere first — and building that landing place is where most teams discover how much infrastructure they've taken on.
If you've already tried something and hit a wall, the list below is probably why. The challenges are about the protocol, not Excel — and they exist regardless of which workbook tool you're trying to use.
Why it's hard
Seven reasons MQTT data doesn't flow into a workbook without deliberate infrastructure between them.
Excel has no MQTT connection — the data has nowhere to land
Excel's data connection library covers SQL databases, REST APIs, CSV files, and cloud services. It does not cover MQTT. There is no MQTT broker connector in Power Query, no topic subscription in Excel's data model, and no way for Excel to receive push-based messages. Before any data can appear in a workbook, it needs to be captured by a subscriber, parsed, and stored in something Excel can actually query.
You need a broker — and it needs to be reachable from both sides of the network
MQTT requires a broker to route messages between publishers and subscribers. Deploying and managing a broker is a standalone infrastructure task. It also needs to be reachable by OT-side device publishers and by the subscriber or persistence layer that will eventually feed Excel — which typically means bridging the OT/IT network boundary in a controlled and audited way.
MQTT payloads carry multiple data points — each topic needs its own parsing rule
An MQTT message from a field device typically carries a JSON payload with multiple values packed together — temperature, pressure, flow, status. Extracting individual measurements requires parsing logic that's specific to each publisher's payload schema. Different devices publish differently. Without per-topic parsing rules, the data comes through as raw strings that Excel can't work with.
Different topics carry different schemas — routing rules are required for each
A plant with multiple MQTT publishers has multiple topics, each with its own payload structure, units, update frequency, and data type. Subscribing to all of them and routing each message to the right named record requires a topic routing layer. Without it, data from different devices is mixed or discarded, and there's no way to tell in Excel which value came from which source.
MQTT is real-time only — missed messages are gone, and Excel needs history
MQTT delivers messages to active subscribers. If the subscriber service is down, messages published during that window are lost. Excel workbooks aren't connected in real time — they pull data when a user opens or refreshes them. That means you need a persistence layer that captures every message over time, not just a live data stream. Building reliable persistence on top of an MQTT subscriber adds significant complexity.
High message volume overwhelms naive storage before data even reaches Excel
Industrial MQTT publishers can produce thousands of messages per second. At that rate, a simple subscriber writing to a database or flat file can fall behind — queues back up, messages are dropped, and storage grows unexpectedly fast. Even if all messages are captured, pulling full-resolution data into Excel produces row counts that cause the workbook to time out or freeze on refresh.
Whatever you land the data in, Excel for the Web probably can't reach it
If the persistence layer that captures MQTT data is a SQL database or file share on the OT or corporate network, Excel on the web — in SharePoint Online, Teams, or a browser — can't connect to it. Any workbook built against an on-premise MQTT persistence store is desktop-only, which limits sharing, collaboration, and any mobile or remote access use case.
The approaches teams usually try
Three common paths to get MQTT data into Excel — and where each one runs into trouble.
Broker + subscriber service + SQL database + Power Query
Write a subscriber service that listens to the broker, parses payloads, and writes to a SQL database. Connect Excel via Power Query to the SQL database. Full control over what gets stored and how.
The catch: You're building and maintaining a four-component pipeline before Excel is even involved. Payload schema changes break the subscriber. The SQL database needs to be on a network Excel can reach. High message volumes require aggregation logic in the subscriber. And workbooks won't work in Excel for the Web if the database is on a private network.
Cloud IoT platform → exported CSV or API → Power Query
Route MQTT to AWS IoT or Azure IoT Hub, use the platform's export or API features to pull data into Excel via Power Query. Offloads broker management to a managed service.
The catch: Cloud IoT platforms require device provisioning, payload rules configuration, and cost scales with message volume. The Power Query connection to the IoT platform's API is non-trivial to set up, and the data still needs to be parsed and structured before Excel can use it meaningfully. Workbooks that rely on cloud IoT APIs often break silently when API versions change.
Flat file export from MQTT subscriber to shared folder
Configure the MQTT subscriber to write CSV or flat files to a shared network folder on a schedule. Analysts open or import those files into Excel manually or via Power Query.
The catch: Flat files accumulate fast at high message rates. Combining files across time ranges requires manual work. The shared folder needs to be reachable from every analyst machine. And workbooks built on file imports have no live refresh path — the data is always as stale as the last export cycle.
How TrendOps solves it
TrendOps Edge is an on-premise MQTT subscriber that connects to your broker, parses each payload according to per-topic rules, and forwards individual data points to TrendOps Platform in the cloud. TrendOps Link — a Microsoft 365 Excel add-in — then surfaces that data in any workbook, desktop or web, without any broker access or custom infrastructure from the analyst.
TrendOps Edge subscribes to your MQTT broker, parses each payload, and writes individual data points to the cloud. Analysts never need to know the broker exists — they query TrendOps Link like any other data source.
Configure Edge with the JSON paths and field names for each topic. Multi-value payloads are parsed into individual named telemetry records — one row per measurement, not one row per raw message.
Subscribe to multiple topics and define routing rules that map each to the right tag name, unit, and context. Different devices, different schemas, all handled in TrendOps Edge configuration — not in application code.
TrendOps Link is a Microsoft 365 web add-in. Because data is in the cloud, workbooks can be opened, refreshed, and shared in SharePoint Online, Teams, or a browser — no on-premise data source in the path.
TrendOps Platform stores every data point Edge forwards. When an analyst opens a workbook, they can query any time range — not just the last live message. No additional persistence infrastructure required.
High-frequency MQTT message streams are normalised to a configurable forwarding interval before reaching TrendOps Platform. Workbook refreshes pull summarised data at sensible resolution — not a full-rate message dump that locks up Excel.
TrendOps Edge subscribes from inside the OT network and pushes data to the cloud over a single outbound MQTT connection. No inbound ports, no cloud IoT endpoint reachable from your devices, no OT exposure to the internet.
MQTT data lands in TrendOps Platform alongside historian data from AVEVA PI, DeltaV, FactoryTalk, and SQL databases. One TrendOps Link connection gives analysts access to all of it in a single workbook.
What you end up with
MQTT device data in any Excel workbook — parsed, stored, and queryable — without a subscriber service, a database, or custom infrastructure on the analyst side.
Desktop, browser, SharePoint, Teams — TrendOps Link works wherever Excel does.
Payload parsing, topic routing, and persistence handled by TrendOps — no subscriber service to build or maintain.
Every message persisted in the cloud — analysts query any time range, not just live data.
MQTT alongside historians and SQL data — one workbook for every OT source on the plant.
Your devices already speak MQTT — getting that data into Excel shouldn't require building a subscriber service from scratch
TrendOps Edge subscribes, parses, and stores MQTT data in the cloud so any analyst can pull it into any Excel workbook — no infrastructure required on the analyst side.
Book a Demo