Connect MQTT to OpenAI
You're building an OpenAI Assistants agent or a Custom GPT that should answer questions about live equipment — and your sensors, PLCs, and edge devices publish data over MQTT. MQTT is the messaging protocol of choice across modern OT environments: lightweight, real-time, and ubiquitous on the plant floor. But it's a push-based pub/sub protocol with no query interface and no history store. OpenAI function calling needs an HTTPS endpoint the model can call on demand — a fundamentally different model. Bridging the two requires solving problems that neither OpenAI documentation nor MQTT documentation addresses directly.
The barriers below are what makes this integration harder than it looks.
Why it's hard
Seven reasons connecting an OpenAI agent to MQTT data is harder than expected.
Function calls need an HTTPS endpoint — MQTT is push-based with no REST interface
OpenAI Assistants and Custom GPT Actions retrieve data by calling HTTP endpoints defined in function schemas or OpenAPI specs. MQTT is a publish/subscribe messaging protocol — devices push payloads to a broker, and consumers subscribe to topics. There is no HTTP endpoint to call and no query mechanism. Turning MQTT data into something an OpenAI function can retrieve requires an intermediary that subscribes to topics, caches current values, accumulates history, and exposes an HTTPS API.
MQTT brokers sit on OT networks — OpenAI calls from its own cloud
Industrial MQTT brokers run on OT or plant floor networks, isolated from the internet. OpenAI's function calling infrastructure makes HTTP requests from OpenAI's servers — it can't subscribe to a broker on a restricted OT network, and it doesn't speak the MQTT protocol. Even if the broker were internet-accessible, OpenAI's infrastructure doesn't maintain persistent broker subscriptions between function calls.
MQTT has no history store — the model can't answer questions about the past
MQTT brokers deliver messages in real time and retain only the last published value per topic (if retain is enabled). There is no built-in historian. If a user asks what a sensor read two hours ago, or how a process variable trended over a shift, MQTT has no answer. The function endpoint needs a time-series store that accumulates MQTT payloads — which has to be built, deployed, and maintained separately.
MQTT payloads are raw encoded data — the model receives binary or unstructured JSON
MQTT payloads are application-defined. In industrial environments they're often compact JSON objects, Sparkplug B encoded messages, or raw binary. Topic names follow device-specific hierarchies — plant/line1/motor1/speed — that are meaningful on the OT side but opaque to the model. Without payload parsing and topic-to-description mapping, the model receives data it can't interpret or present in a meaningful response.
Exposing the broker to the internet is a security risk most OT teams won't accept
Even if you could get OpenAI's infrastructure to subscribe to an MQTT broker, opening the broker to inbound internet connections puts OT infrastructure in contact with external networks. MQTT brokers connected to sensors and controllers are part of production infrastructure. Any internet-facing path increases the attack surface in ways most OT security policies prohibit.
High-frequency MQTT data fills the context window and drives up token costs
Industrial sensors publish at sub-second to per-second rates. A function that returns raw cached MQTT history for even a short window sends thousands of timestamped records to the model. This fills the context window rapidly and drives up token costs. Aggregation has to happen server-side before the function responds — the model shouldn't receive raw pub/sub message logs.
Custom GPT Actions require a public OpenAPI spec — hard to maintain against evolving topic hierarchies
Custom GPTs retrieve data using Actions defined by an OpenAPI spec hosted at a public URL. MQTT topic structures change as devices are added, renamed, or reconfigured. Keeping an OpenAPI spec and function descriptions aligned with an evolving topic hierarchy adds ongoing maintenance overhead. A spec that drifts from the live topic structure produces unreliable agent behaviour.
What teams usually try
MQTT subscriber service that caches values and exposes an HTTPS API
Build a service that subscribes to the broker, parses payloads, caches the latest value per topic, and exposes an HTTPS endpoint that OpenAI function calls can reach from the cloud.
The catch: The service needs an internet-accessible path from inside the OT network — a security change that OT teams have to approve. Payload parsing, topic mapping, and cache management all add implementation complexity. Historical queries still require an additional time-series store. The service adds ongoing infrastructure overhead.
Cloud MQTT broker with bridge from OT broker
Bridge the on-premise broker to a cloud MQTT broker (AWS IoT, Azure IoT Hub, HiveMQ Cloud). Build a cloud-side subscriber and HTTPS API. The function schema points to the cloud service — no plant network path from OpenAI's side.
The catch: Bridging requires an outbound MQTT connection from the OT network — a network change that still needs OT approval. Cloud broker adds licensing cost. Payload parsing and topic semantics still have to be handled. Historical queries still require a time-series store. Token costs still scale with unshapeded data.
Upload MQTT log files to Assistants
Log MQTT data to files and upload them as Assistants file attachments. The model reads file content to answer equipment questions.
The catch: High-frequency MQTT data produces very large files. File retrieval in Assistants chunks across large numerical logs poorly. The model answers questions about past snapshots — not current equipment state. Real-time monitoring use cases are entirely unsupported. Token costs scale with file size.
How TrendOps solves it
TrendOps Edge runs on-premise alongside your MQTT broker — subscribing to topics, parsing payloads, mapping topic hierarchies to named data points, accumulating history, and forwarding structured data to TrendOps Platform over its own outbound MQTT connection. Your OpenAI agent calls TrendOps Web API as a function endpoint or Custom GPT Action. No broker exposed to the internet, no cloud-side MQTT subscription, no raw payload parsing in the function layer, no raw message history filling the context window.
The function schema points to TrendOps Web API — a cloud-accessible HTTPS endpoint. No MQTT subscription from OpenAI's cloud, no broker port open to the internet, no inbound path to OT network infrastructure.
TrendOps Edge decodes MQTT payloads and maps topic paths to human-readable descriptions. Function responses include labelled values and context — not raw topic strings and binary payloads the model can't interpret.
TrendOps accumulates MQTT data over time. Function calls can request time-range history — what a sensor read over the last shift, how a value trended — not just the last retained topic value.
TrendOps aggregates MQTT data server-side. Function responses return interval summaries — not thousands of high-frequency pub/sub messages that exhaust the context window and drive up token costs.
TrendOps Edge forwards data out over its own outbound MQTT connection. No inbound path from OpenAI's cloud to the OT broker. The agent's function calls never reach the plant floor network.
TrendOps normalises MQTT data alongside AVEVA PI, FactoryTalk, DeltaV, and SQL sources. One function endpoint gives the agent a unified view across real-time and historian data sources.
What you end up with
OT MQTT broker stays closed — the agent never connects to it directly.
Current values and historical trends — not just the last retained message.
Payloads decoded, topics mapped — the model receives readable, labelled responses.
One endpoint, every OT source — MQTT alongside historian and SQL data.
Don't want to build your own AI agent integration?
TrendGuru — TrendOps's built-in AI agent — already has access to your plant data. Ask questions about your MQTT-connected equipment in plain language and get answers instantly, deployed directly in Microsoft Teams. No function definitions to write, no OpenAPI spec to maintain, no token costs to manage.
Learn about TrendGuru →Your OpenAI agent shouldn't need to subscribe to an OT broker to answer a question about equipment data
TrendOps gives your OpenAI agent a clean function endpoint for MQTT data — decoded, mapped, and queryable — without exposing the broker to the internet.
Book a Demo