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.
Since OMF is just a specification that can be used to create data acquisition applications, it does not seem appropriate to add this feature here. However, I am curious, what are the roadblocks from introducing this rule into your application? OMF does not control what gets posted and what doesn’t, but an application could introduce a register for the last value sent and compare that to the current value before posting or ignoring the data.
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".
AdminKevin Geneva (Admin, OSIsoft) commented
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.
David Krenek commented
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.
Matthew Hostetler commented
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.
David Krenek commented
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.