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.

Add a new idea Subscribe
Status Declined
Product Developer Resources
Categories Open Message Format (OMF)
Created by Guest
Created on Aug 16, 2022

RELATED IDEAS

Send only data that has changed.

When transferring data via satellite it is necessary to keep bandwidth usage to a bare minimum. Currently OMF must send all values regardless of whether they have changed or not. If it could send only the data parameters that have changed that would be very helpful.
  • ADMIN RESPONSE
    Aug 16, 2022
    A TYPE should represent dependent properties. For example, Longitude and Latitude or X, Y, and Z, where sending only a subset of the values does not really make sense. While I understand this could be useful in the PI System, we want to keep the implementation as similar to OCS as possible. Because the shape of the data is already defined, we always have to write a value to each property when a data message is sent. For these reasons, I am setting this idea to declined
  • Attach files
  • Guest
    Reply
    |     Aug 16, 2022
    Agree. This also applies to data being transmitted by cell. One of the high value aspects of the Win-based interfaces is that you can poll at a higher frequency to capture transients - yet not consume a large bandwidth during steady state conditions.
  • Guest
    Reply
    |     Aug 16, 2022
    Kevin I believe what the voters on this topic want is "partial update" support. My understanding is that as of OMF 1.1 if a property is omitted from a data message it will be assumed to be a default value such as 0. So if we have a type with "Property1" and "Property2" which have default values of 0, and the previous update to this container had "Property1" with a value of 1 and "Property2" with a value of 2. Then we send a data message that only has "Property1" with a value of 3.. Currently the behavior to my understanding would be that "Property1" would be updated to 3, while "Property2" would be updated to 0 since that is the default value and it was not specified in the data message. Whereas the behavior voters on this topic want is that "Property2" would retain its previous value of 2 since the new data message did not specify a new value. The alternative for now is to define single-property containers so that any property may be updated independently.
  • Guest
    Reply
    |     Aug 16, 2022
    I have built exception functionality into our mCore device which has a PI Connector that can send data via OMF or MQTT. The issue with OMF is that the parameters must be in single containers as the relay will write a "0" into the archive for those parameters that are null.
  • Guest
    Reply
    |     Aug 16, 2022
    In OMF v1.1, the concept of nullable types was introduced. To borrow from an earlier comment, consider the situation where we have a type with "Property1" and "Property2" which have default values of 0, and the previous update to this container had "Property1" with a value of 1 and "Property2" with a value of 2. Then we send a data message that only has "Property1" with a value of 3. If "Property2" was designated as a nullable type, it would currently be interpreted as "No Data" in the PI Data Archive, or "NULL" in OCS. If it was not designated as nullable, then the default value of 0 would be written. While this is certainly more helpful than the default value of 0, I believe that the desired behavior being requested is for "Property2" to be written with a value of 2 for this data message. Please confirm if this is the desired functionality, or if these nullable types meet your requirements.
  • Guest
    Reply
    |     Aug 16, 2022
    in our use case, it would be better, that properties simply keep their latest event in PI Data Archive, in case of no new data. Nullable feature seems to be the right approache, but "No Data" indicates that someting is wrong. In all of our use cases, it is the natural behaviour of IoT devices, that we receive sometimes only partial data updates, Our desired behaviour would be, that PI Point will not be updated with "No data".
  • Guest
    Reply
    |     Aug 16, 2022
    Completely agree with the others: Standard behavior should be that if no data is sent, then simply no value should be sent through the entire PI system and the various queues. This is especially important as values sent via OMF and the PIWebAPI do not go through any exception testing on the PI side of things at all (only compression testing is applied before storing data in the PI Data Archive). This requires us to do exception testing ourselves before sending the values via OMF and PIWebAPI into the PI system. Luckily for us, we are actually currently sending every value as it's own container, so we aren't hit by this problem right now.