AdminKevin Geneva
(Admin, OSIsoft)
My feedback
-
19 votes
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.
An error occurred while saving the comment -
17 votesAdminKevin Geneva
(Admin, OSIsoft)
supported this idea
·
-
41 votesAdminKevin Geneva
(Admin, OSIsoft)
supported this idea
·
-
40 votesAdminKevin Geneva
(Admin, OSIsoft)
supported this idea
·
-
273 votesAdminKevin Geneva
(Admin, OSIsoft)
supported this idea
·
-
3 votesAdminKevin Geneva
(Admin, OSIsoft)
shared this idea
·
-
1 voteAdminKevin Geneva
(Admin, OSIsoft)
shared this idea
·
-
16 votesAdminKevin Geneva
(Admin, OSIsoft)
shared this idea
·
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.