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. PI Adapter for MQTT should include MQTT broker

    Having to deal with a MQTT broker between the data source and the PI Adapter adds a single point of failure to the data handling and weakens the data flow end-to-end.
    From the data source we can guarantee that the data will reach the MQTT broker, but we cannot guarantee that the PI Adapter will in turn reach the broker.
    Goal is to secure the MQTT data collection end-to-end (equipment to PI Data Archive) with reliable SW built, maintained and supported by OSIsoft.

    8 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 →
  2. 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.

    8 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 →
  3. PI Adapter for SNMP

    Write a PI Adapter that supports the SNMP protocol and is capable of writing data to EDS, PI, and OCS.

    8 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 →

    At this time we have decided to pause development of the PI Adapter for SNMP. Please continue to share your use cases with us as we may consider PI Adapter for SNMP for release in the future.

  4. Add another Archive Mode option for the PI Interface for UFL

    There should be a way to configure the PI UFL interface to both discard duplicate events (same value at the same timestamp) and record multiple unique values for the same timestamp when these events come from multiple data files.

    For example, if multiple data files contain the following entries:

    (Timestamp)  (Value)
    11:00:00      ABC
    11:00:00      ABC
    11:00:00      XYZ

    The following data should be archived:

    (Timestamp) (Value)
    11:00:00 ABC
    11:00:00 XYZ

    8 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 →

    This feedback item has been moved from the PI Interfaces forum to the PI Adapters forum.

    We are continuing to support PI Interface for UFL with stability and security releases. However, for feature enhancements, we are starting to develop PI Adapter for Structured Data Files. We would like to hear more about your use cases for this functionality, so please share with us in the comments.

  5. 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 →
  6. 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 →
  7. Stream-level debugging

    As a PI System Administrator, I'd like to be able to trace values being received, and subsequently being sent by the Adapter, similar to PI Interfaces.

    Having the ability to trace/log timestamps and values for specific streams would greatly help in troubleshooting data issues, without requiring a network trace or other troubleshooting tools.

    4 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. PI Adapter for (generic) MQTT to enable auto-discovery of key value pairs using wildcards

    When reading from a generic MQTT broker, we currently need to specify explicitly each key value pairs we want to collect inside the data selection json configuration file. This prevents us from really being agile at the time of the initial setup and for each new information we want to collect, as we need to explicitly define the information manually into the Adapter.

    We would like the PI Adapter for (generic) MQTT to be able to capture automatically exposed key value pairs in the MQTT broker following a wildcard pattern. For instance take this example payload:
    {
    "EquipABC.Location": "0020121047111948",
    "EquipABC.Status":…

    4 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 →
  9. PI Adapter for Azure Event Hubs

    Write a PI Adapter that supports the Azure Event Hubs protocol and is capable of writing data to EDS, PI, and OCS.

    4 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 →

    The Lighthouse version of the PI Adapter for Azure Event Hubs is now available. If you are interested in participating in the Lighthouse Program, please reach out to your Account Manager or Customer Success Manager.

  10. PI Interface DNP3 - unsolicited data listen only mode of operation requested

    Is there an option in DNP3 driver (In fact at TCP level) to make it listen on a certain (usually 20000 for DNP3)? In era of IoT devices, most devices are sleeping devices, they wake up usually once a day and push data to DNP3 Master (PI), however DNP3 PI collector doesn't support this model. As an enduser I would like to utilize this mode of operation at our plant. FYI, there are other products e.g. Citect SCADA and ClearSCADA use two separate ports for Inbound and outbound DNP3 traffic to use the both modes simultaneously.

    4 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 →

    This item has been moved from the PI Interfaces forum to the PI Adapters forum as we will be focusing on the PI Adapter for DNP3 for future feature enhancements.

    We would like to learn more about the different scenarios in which this specific retrieval of unsolicited data is needed. Please continue to share your comments below.

  11. PI Adapter for OPC UA data conversion

    As a PI System Administrator, I would like to be able to apply conversion factors to the data that is being gathered from our OPC UA server. This would allow us to get data in the format/units we'd like, without requiring extra tags and/or calculations.

    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 →
  12. PI Adapteur for OPC UA should support Specific DA Tag Naming

    As we are using an ISO based tag naming, we would like the PI Adapters to be able to write OPC UA Tag value into Specific tags in DA and not only in automaticaly created tags. Automated DA tag creation should be a possible choice, not the standard.

    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 →
  13. EdgeCmd option to add to PATH during installation

    Provide an option to add the EdgeCmd directory to PATH during the installation process on Windows.

    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 →
  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. 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 →
  16. PI Adapter for OPC UA data filtering based on OPC status codes

    Currently, the PI Adapter for OPC UA sends good quality data to the configured data endpoint with no way to filter on different good quality statuses. There are several OPC status codes that fall under the Good Quality Data classification.

    When the status code changes from "Good" to "GoodOverload" because they fall under the OPC Good Quality Data classification, both are being sent to the configured data endpoint.
    User would like to have the option to filter good quality data. For example, send only data with "Good" status code to the endpoint and filter out "Good
    Overload" data.

    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 →
  17. 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…

    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. 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)

    1 vote

    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 →
  19. 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.

    1 vote

    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 →
  20. PI Adapter for EtherNet/IP

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

    1 vote

    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 →
  • 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