AVEVA™ PI System™ Feedback Portal

Welcome to our feedback site!


We created this site to hear your enhancement ideas, suggestions and feedback about AVEVA products and services. All of the feedback you share here is monitored and reviewed by the AVEVA 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 AVEVA PI System. For links to our other feedback portals, please see the tab RESOURCES below.

Add a new idea Subscribe
Status No status
Product AVEVA™ Adapters
Categories AVEVA Adapter for MQTT
Created by Daniel Lopez
Created on Mar 30, 2026

RELATED IDEAS

Allow session persistence to support true QoS 2 data collection and backfill of events after a data source disconnection

It appears that regarding Session Persistence (persistent vs clean session), the Adapter hardcodes setting the Clean Session Flag for the generic data source (Sparkplug doesn’t QoS 2 nor session persistence) to true.


This should be a user-defined parameter for the generic data source in the Adapter. Without session persistence, it means that all messages sent to the broker while the Adapter is disconnected will be not be retrieved upon reconnection. If it were user defined, and a site had a broker that supports session persistence, it would allow that when the Adapter reconnects to its persistent session, all subscriptions are reinstated and all stored messages are sent to the client. This also allows for some history recovery capabilities.

When looking at other vendors, almost all of them support this. The library that is likely being used in the Adapter does support setting up this parameter, but it appears that it is simply hard-coded to be cleanSession = true. Not having this as a user selectable parameter means that this Adapter may not provide the degree of robust, fault-tolerant data collection that a site needs.


This has been confirmed as a practical requirement by a notable user group within oil and gas, both in September 2022 and March 2026.

  • Attach files
  • Matthew Kishe
    Sep 29, 2026

    Adding my support for this request and flagging it as a high-priority data integrity gap.

    Because the Adapter hardcodes CleanSession = true for the generic MQTT data source, any message published to the broker while the Adapter is disconnected (network interruption, Adapter restart, upgrade, or failover) is permanently lost. On reconnect, the broker has no session state to resume, so no queued QoS 1/2 messages are delivered and no subscriptions are restored. In practice this creates silent gaps in the PI historian that cannot be backfilled from the source.

    This matters most for sites that depend on continuous, complete data collection, such as regulated manufacturing and process monitoring, where missing data can affect trending, analytics, and process/quality review. Planned maintenance windows and routine restarts are enough to trigger the loss, so it is not limited to rare failure scenarios.

    Requested change: expose Clean Session (persistent vs. clean) as a user-configurable parameter on the generic data source, along with a stable, configurable Client ID (required for the broker to associate the client with its persistent session). Defaulting to the current behavior (clean = true) would keep this backward compatible, while allowing sites with session-persistent brokers to achieve true QoS 1/2 delivery and backfill after a disconnect. The underlying MQTT client library already supports this setting, so the change should be small relative to the resilience benefit.

    Reply