Skip to Main Content
Data services feedback portal

Welcome to our feedback site!


We created this site to hear your enhancement ideas, suggestions and feedback about CONNECT products and services. All of the feedback you share here is monitored and reviewed by the CONNECT product managers.

To start, take a look at the ideas in the list below and VOTE for your favorite ideas submitted by other users. POST your own idea if it hasn’t been suggested yet. Include COMMENTS and share relevant business case details that will help our product team get more information on the suggestion. Please note that your ideas and comments are visible to all other users.


This page is for feedback specifically for CONNECT data services. For links to our other feedback portals, please see RESOURCES below.

Status No status
Created by Guest
Created on Mar 28, 2026

Native MQTT Publishing (Egress) to Support Unified Namespace (UNS) Architectures

Description & Use Case: As the manufacturing industry shifts toward Industry 4.0 and Unified Namespace (UNS) architectures, data must flow seamlessly between all systems in a publish/subscribe model. The AVEVA PI System is exceptional at ingesting data (acting as an MQTT subscriber via PI Adapters), but it lacks a native, lightweight, and efficient way to publish real-time data and contextual models out to an external MQTT broker.

We need a native PI component (e.g., a "PI MQTT Publisher") that can listen for data changes in the PI Data Archive and asset changes in PI Asset Framework (AF), and automatically publish those updates to an external MQTT broker (like HiveMQ, EMQX, or Mosquitto). Ideally, this should support the Sparkplug B specification to automatically communicate asset hierarchy and data types.

Why is this needed? (The Problem): Currently, to make the PI System a "first-class citizen" in a UNS (meaning it can both consume and produce data), we are forced to rely on inefficient workarounds:

  • Custom Middleware: Writing and maintaining custom C# or Python scripts using the PI AF SDK or PI Web API Channels (WebSockets) to poll for changes and push them to MQTT.

  • Costly Third-Party Tools: Paying for external DataOps platforms just to bridge the gap between PI and our MQTT broker.

  • Heavy Polling: Continually polling the PI Web API, which degrades system performance and defeats the purpose of an event-driven pub/sub architecture.

Without native MQTT egress, PI risks becoming a data silo rather than an active, collaborative node in our modern industrial data stack.

Proposed Solution: A native feature or adapter provided by AVEVA that enables:

  1. Event-Driven Tag Publishing: Select PI Points to automatically publish to defined MQTT topics upon value change.

  2. AF Context Egress: Publish AF Element structures and Attributes as MQTT payloads (JSON or Sparkplug B) so external systems understand the context of the data.

  3. Sparkplug B Compatibility: Allow PI to act as an Edge Node (EoN) that can publish its namespace and state changes natively.

  4. Store and Forward: Built-in buffering in case the connection to the external MQTT broker drops.

Business Value & Impact: By adding this feature, AVEVA will ensure the PI System remains the central, indispensable historian of choice for companies adopting UNS. It reduces total cost of ownership (TCO) by eliminating custom middleware, lowers architectural complexity, and unlocks PI data for real-time consumption by ML models, ERPs, and edge applications across the enterprise.

  • Attach files