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.
-
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 votesWe are currently considering the future development of this functionality. Please share your use cases here.
-
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 votesWe are currently considering the future development of this functionality. If you have additional information to share, please post them in the comments.
-
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 votesAt 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.
-
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 votesWe are currently considering the future development of this functionality. Please continue to share additional use cases with us.
- Don't see your idea?