1 of 1 people found this helpful
The time-weighted total will assume the units of the input values are in [units]/day, so if the tag as a rate unit of something different, then an appropriate conversion factor can be applied client-side once the result is received. I don't believe a conversionFactor query parameter actually exists. See the Remarks PI Web API GetSummary and the corresponding AF SDK call AFData.Summary Method .
For instance, if the tag has units of gal/min, the conversion factor would be min/day = 1440.
2 of 2 people found this helpful
To get the Summary Type "Total" to work with the WebAPI could you try including the "calculationBasis". The following seemed to give a good response:
Note that ...&startTime=y&endTime=t also worked.
Note also that the defaults for calling Summary use summarytype of Total, calculationBasis of TimeWeighted, startTime of '*-1d' and endTime of '*'.
Hope you can resolve it from here. Good luck.
I also have a question related to this post.
I am attempting to calculate the average of a forecast of MWh production for a time period of 'T+23h' to 'T+47h' within the PI system.
The above works as it should for '*-1d' etc. On reading the PI Web API Reference it outlines the availability as an example "T-3d", which works as a start time.
However, another example outlined is the "Monday+8h", which once put into the exact same query as above, returns:
"'Monday 8h' is not a valid timestamp."
The negative sign works fine when used within the time range query, however I am unable to get the positive sign to work?
Has anyone come across this issue, or am I missing something obvious?
My reasoning for doing this is that I cannot seam to find the ability within any of the PI client tools to calculate the average of a forecast range? (Apart from locking a Coresight screen to a time range relative to 'T' and using the coresight option to include average within a table of outputs for a tag/attribute. I have used PI data reference to perform simple calculations on my forecast data and provide a roll up output, which does not allow for future time ranges as inputs. AF analysis will only kick off the calculation of the average of the time range once it becomes present from what I have tested.
So I am left with using the Web API to replicate the call which coresight is making to the Web API to access the average value for the time range within the future time period. It must work as Coresight is providing the output on the screen, so I'm guessing I am missing some syntax specifics?
Thanks for any help.
Hmm, odd. "Monday+8h" Should work: https://techsupport.osisoft.com/Documentation/PI-Web-API/help/topics/time-strings.html
... but as the + sign is missing from the error message, some issues in the call? Does "Monday-8h" work? Could you post the call to the WebAPI?
Thanks for the speedy reply.
Yes, "Monday-8h" works.
Here are some of the calls I have been using:
This returns the same Error above.
Also, when using:
Returns the same Error.
However, If I use this:
The correct output is provided.
Ultimately what I need is
As these calls are set to align daily time periods, I have to use T, or Today within the call and a + sign. The use of * would not return a continuously changing value over a set time period.
Thanks for any input Roger.
3 of 3 people found this helpful
Found the issue: this is due to the +-sign is a reserved characted in an URL.
Use a URL encoder to encode your strings: HTML URL Encoding Reference or read: Percent-encoding - Wikipedia, the free encyclopedia
E.g. to get results for "T+1h" use "T%2B1h".
2 of 2 people found this helpful
This worked out perfectly. Also, very useful.
Just a quick FYI for anyone attempting to do the above:
Once I was able to attain the average summary calculation from the Web API it differed from that displayed within Coresight.
After spending a bit of time looking into it, Coresight's average calculation is based on 'TimeWeightedContinuous' rather than the default within AF and the Web API of 'TimeWeighted', leading to the slight discrepancy due to interpolation at both ends of the range.
This is possible to change within the query through the use of '&calculationBasis=TimeWeightedContinous'