Aaron Rosenthal
My feedback
-
15 votesAaron Rosenthal
supported this idea
·
An error occurred while saving the comment An error occurred while saving the comment Aaron Rosenthal
commented
Some sort of error handling is definitely needed for this scenario. Currently it's hard to separate rollup analysis errors when attributes can't be found from legitimate rollup analysis errors. At a minimum, there should be a way to ignore/hide this error, but it would be better if rollup analysis was able to use a default value or just gracefully skip over attributes that don't exist.
Aaron Rosenthal
shared this idea
·
-
22 votes
Can you clarify if your use case has 1 output PI Point or multiple PI Point(s)?
Is there any reason why you are not using RDBMS interface to bring your table data into the PI System? That would remove a lot of complexity and greatly improve performance.
Aaron Rosenthal
shared this idea
·
-
23 votes
An error occurred while saving the comment Aaron Rosenthal
commented
I wanted to add to this issue. The entire streamset request will also fail if any of the streams return data that isn't supported by the PI Web API. This makes it very difficult to debug in production systems because we cannot determine which stream is the culprit.
Aaron Rosenthal
shared this idea
·
-
6 votes
This item is under review. Currently considering the following behavior for attributes links:
Current behavior:
Error returned: “Unsupported data type: ‘OSIsoft.AF.Asset.AFAttribute’.”
Similar error for AFElement.Change under consideration:
Value link for Attributes of value type “Attribute” returns the referenced attribute’s GET response (“/attributes/[webid]”)
Value link for Attributes of value type “Element” returns the referenced element’s GET response (“/elements/[webid]”)Aaron Rosenthal
supported this idea
·
-
14 votesAaron Rosenthal
shared this idea
·
In response to Rick Davin, "The use-case is having a Rollup Analysis..."
Exactly. This can also cause problems when the AF hierarchy changes over time. If at one time a parent had child elements, then the rollup analysis on the parent element could have value X. Then, if the AF hierarchy is changed so that the parent element no longer has child elements, the rollup analysis will fail, and the attribute value on that parent element will be stuck at value X forever. If the attribute values on the parent elements are used as inputs to rollups further up the hierarchy, this can really corrupt your data.
I have this exact situation currently as my AF hierarchy changes every week, and I have to run custom scripts to detect rollup analysis in a failed state but with an output that has "good" quality. I have to get a list of the PI tags for those outputs and reset their values using piconfig.