PI Adapters

Welcome to the PI Adapters feedback page!

We created this forum to hear your ideas, feature suggestions and feedback on PI Adapters. Please suggest your most important features and design change ideas on this site, and vote for your favorite ideas.

Please note that your ideas and comments posted here are visible to all other users.

  • For bugs, please open a case with OSIsoft Tech Support through myOSIsoft Customer Portal (https://my.osisoft.com) instead of sharing them on this site.
  • For documentation feedback and bugs, please report to documentation@osisoft.com instead of sharing them on this site.

  1. Support writing SYSTEM digital states when a bad status is received by PI Adapter for OPC UA

    Currently if PI Adapter for OPC UA received a status other than "Good" for an event, it will not write the data to its endpoint. PI Adapter for OPC UA should be able to write a SYSTEM digital state that indicates the status it received.

    28 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Flag idea as inappropriate…  ·  Admin →
  2. Enable the use of gMSA for PI Adapters running on Windows

    In our environment, we plan to deploy PI Adapters on Windows Server class OS. We are in a strict minimum privileges environment hence we only make use of gMSA on all PI services.

    We do not want to make use of a domain service account where the password is known (by a few) and can be impersonated. PI Adapters should be enabled to make use of such gMSA type of account to run the service in a secure manner.

    22 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Flag idea as inappropriate…  ·  Admin →
  3. 23 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Flag idea as inappropriate…  ·  Admin →
  4. Enable adding prefix to health & diagnostic PI tags

    We make use of strong naming convention for all our tags, using sets of prefixes/sufixes to properly position our PI tags in AF hierarchies.

    We are making use of the PI Adapter against the PI WebAPI endpoint. Now with the PI Adapter health & diagnostic PI tags that are auto-created when 'EnableDiagnostics' is set to "True" in the auto-created AF DB for this purpose, the auto-naming of these PI tags does not permit a configuration of the naming using a set of prefixes that would help us locate better in our data landscape the position of the PI Adapter.

    What…

    22 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  5. Allow remote configuration

    Adapters are currently only listening on localhost (127.0.0.1) causing them to be only accessible locally. For docker containers, they can only be accessed from within the container or directly on the host (with the --network host switch which results in not containerizing the container's networking) but they cannot be accessed for elsewhere (not able to bind them to 0.0.0.0)
    This makes adapter management very difficult in distributed environment.

    17 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  Flag idea as inappropriate…  ·  Admin →
  6. Enable OmfEgress component to be configurable by instance (by component)

    In our process we wish to send a different set of data to different PI environments. For instance we would like all data to egress to the PROD environment while only egress a subset of data to the DEV environment, in which we don't need all the data.

    By removing a PItoPI link between PROD and DEV, this would largely reduce the complexity of the setup (especially when you have > 50 sites) while keeping a lower more manageable volume of data for development purposes.

    Currently when we setup PI Adapters, the OmfEgress component is configured for all instances on…

    17 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  7. PI Adapter for OPC UA should be able to poll data from the OPC UA Server

    Currently the PI Adapter for OPC UA only collects unsolicited advised data that is different from the previous value. We would need to see a polling feature to be able to:
    - Refresh slow moving streams with updates with the same value but different timestamp
    - Get the information in the OPC UA Server at a defined time stamp

    This polling feature could pave the way to more features like setup the equivalent of "Trigger event tags" offered by the old PI OPC DA Interface technology

    44 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  8. Support Failover for PI Adapters

    As a customer, I need to ensure that the primary instance of the adapter fails over to a secondary instance to minimize data loss.

    50 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  Flag idea as inappropriate…  ·  Admin →
  9. Allow MQTT adapter to parse timestamps in local time without specifying a timezone suffix to each timestamp

    We would like the MQTT Adapter to be able to interpret timestamps in local time without needing to explicitly state the timezone or UTC offset in each timestamp, but for the adapter to always interpret the timestamps as being in a specific timezone (such as the adapter box's timezone or a timezone specified to the adapter's configuration)

    3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  10. PI Adapter for OPC UA should poll a series of items based on a trigger events

    Same as the PI Interface for OPC DA feature with "Trigger Tags", the idea is to poll for updates on a series of item streams (tags) only when a certain item stream updates.

    The benefit of this is to create timestamp alignments between a series of data points, when a cycle begins or ends for instance. This is very useful for analysis and visualzation of production cycle efficiencies.

    32 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  11. PI Adapters should accept a StreamID longer than 100 characters when writing to PI WebAPI OMF endpoint

    Currently a StreamId cannot have more than 100 characters because of a limitation in PI Cloud for this type of object. Nevertheless for PI Cores and PI Data Archive, the PI tag limit of characters is 1024.

    PI Adapters when writing to a PI WebAPI OMF endpoint should accept StreamID with more than 100 characters length to take into account a future migration path for customers currently using PI Connectors and working with existing PI tags with long tag names.

    26 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    2 comments  ·  Flag idea as inappropriate…  ·  Admin →
  12. PI Adapter for OPC UA should be able to write outputs to the OPC UA Server

    The PI Adapter should be able to create a data pipe listener on certain streams (unsolicited reads) that would trigger the writes back to the OPC UA Server.

    This is useful when providing set points to the equipment without the need of establishing a second (DA to UA) data flow in parallel.

    24 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  13. Allow the MQTT Adapter to use Client Certificate Authentication when connecting to the Broker

    The PI Adapter for MQTT only supports username and password authentication from the adapter to the broker, so it will not be able to connect to an MQTT broker that requires client certificates in order to authenticate client connections.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  14. PI Adapter for MQTT's Sparkplug B component should allow for data messages to be sent without metric names

    According to the Sparkplug™ MQTT Topic & Payload Specification Rev 2.2 on page 43 (https://www.eclipse.org/tahu/spec/Sparkplug%20Topic%20Namespace%20and%20State%20ManagementV2.2-with%20appendix%20B%20format%20-%20Eclipse.pdf), metric names should only be included in birth messages and for data messages, the metric alias should be used. The way the Sparkplug B component currently works is it looks at the metric name rather than the alias, which will mean that any client that sends data following the Sparkplug spec will not have its data messages read by the adapter.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  15. Allow PI Adapter for MQTT (Generic) to process non-json payloads

    Some MQTT devices do not send json payloads; for example, some devices send a single value as the payload for a specific topic.

    It would be beneficial for the adapter to be able to handle this rather than to convert these payloads into json before they get to the adapter.

    6 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  16. Enable Auto Discovery for PI Adapter for MQTT SparkplugB to always listen for Birth and Death messages

    When utilizing the SparkplugB protocol for MQTT, it would be beneficial for the adapter to be always listening for birth and death messages from specific Edge of Network nodes.

    This way, the device can send a birth message to have itself added to the data selection array, then a death message to have itself removed. This would enforce a data selection array that's always reflecting the current state of devices connected to the broker, doesn't miss any data messages, and doesn't bloat over time.

    5 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  17. PI Adapter for EtherNet/IP

    Develop a PI adapter to talk directly to Rockwell PLCs using EtherNet/IP without requiring an OPC UA server.

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  18. PI Adapter for Structured Data Files

    Create a PI Adapter that supports parsing data from simple file formats (CSV, XML, JSON, plain text) and is capable of writing data to EDS, PI, and OCS.

    17 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    5 comments  ·  Flag idea as inappropriate…  ·  Admin →
  19. PI Adapter for OPC UA Array Support

    As a PI System Administrator, I would like for the PI Adapter for OPC UA to support array data types from the OPC UA Server. A large amount of our data may be contained within arrays on our OPC UA Server, so we would not currently be able to collect that data.

    9 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  Flag idea as inappropriate…  ·  Admin →
  20. Include information from Json body in the stream name created by the MQTT Adapter

    As a system admin I would like to send mqtt messages from multiple devices to a single topic on an mqtt broker. Each message would contain data for the device along with a field to say which device the data has come from. Then I would like to use the mqtt adapter to read in the messages from this topic and to split the data into different streams depending on which device is referenced in the message. This is preferable to sending to individual topics per device since it would require less configuration on the mqtt broker since there could…

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
← Previous 1 3
  • Don't see your idea?

PI Adapters

Categories

Feedback and Knowledge Base

Posted ideas will have one of the following statuses.
Full definition of these statuses can be found on the Home Page.
No status
TELL US MORE
EVALUATING
PLANNED
IN DEVELOPMENT
COMPLETED
DECLINED