As a programmer I want the PI Web API to expose an endpoint for reading UOM Groups and UOM Group mappings. This would allow javascript based web applications to read the UOM Groups and mappings in order to use the mappings in subsequent data stream requests. Then the end users could see all data in familiar UOMs according to their selected UOM Group.

UOM Groups was introduced in PI AF 2017 R2 and is supported in AF SDK 2.9.5+.

The endpoint could e.g. be at
https://host/piwebapi/assetservers/{assetServerId}/uomgroups/ and https://host/piwebapi/assetservers/{assetServerId}/uomgroups/{groupId}/mappings/

A similar request exist under PI Vision product and maybe they can be combined. It would also be sensible to implement the additional endpoint in PI Web API first and then make changes to PI Vision later.

Example Scenario:

We want to know the Specific Electricity Consumption (kWh/mt) over a time period (selected by users).

Specific Electricity Consumption = (Electricity Consumption(kWh)) / (Raw Feed Consumed(mt))

Where, Electricity Consumption (kWh) and Raw Feed Consumed (mt) are both attributes with PIPoint data reference, using value retrieval method: TimeMethod = Time Range; TimeRangeMethod = Total; EventWeighted

Then, Specific Electricity Consumption is attribute with Formula data reference, simply: A=Electricity Consumption; B=Raw Feed Consumed;[A/B]

So, on PI Vision, it can display the specific electricity consumption with the correct values. However, if we query through PI Web API for our own webpage, it is not able to do so.

For the specific electricity consumption attribute, we are only allowed to use GetValue and GetInterpolatedValue, which does not provide us the correct value.

Posted on behalf of customer:
We are currently using the PI Web API 2021 SP1, version 1.15.0.162. We're using it to develop a proprietary C++ software.

One of our customers has PI Servers all over the world and wants to see the time stamps in the time zone of the PI Server. I'm aware that the PI Data Archive always saves the time as UTC, and I'm also aware that the time zone of the PI Server (or, better said, the time zone of the computer containing the PI Data Archive) might not be the same as the time zone of the collected data, but that is usually the case, at least for our customer. Because of this, it makes sense for our customer to see the time in the time zone of the PI Server / PI Data Archive.

Currently, our C++ software uses std::chrono::zonedtime (part of C++20 - https://en.cppreference.com/w/cpp/chrono/zonedtime) to allow the user to change the time zone. That allows us to either let the user choose the "local time zone" of the computer (std::chrono::currentzone()), or let him/her choose from a list of time zones from the IANA time zone database (std::chrono::gettzdb()). However, this also means that the user must know exactly in which time zone the data is collected (or, for our customer, where the server exists in the world) and choose the correct time zone. That's still a lot better than not being able to choose the time zone at all, but does not allow our customer to simply "use the time zone of the PI Server", as there's currently no possibility to query it using the PI Web API. It is possible to query the server time as UTC (by querying /piwebapi/system/status), but not the server's time zone.

However, I found out that it is possible to query the time zone of the PI Server / PI Data Archive when using the Asset Framework SDK instead of the PI Web API: https://docs.osisoft.com/bundle/af-sdk/page/html/P_OSIsoft_AF_PI_PIServer_ServerTimeZone.htm

So what we would need would be a way to query the IANA Time Zone of the PI Server. For some other people, it may also make sense if you additionally provided the Windows Time Zone, but we need the IANA time zones to be able to use it with std::chrono::zoned_time. Suggestion: both the IANA Time Zone and the Windows Time Zone of the PI Server (PI Data Archive) could be provided when querying /piwebapi/system/status.

So, to summarize:

1. We think it makes sense to only provide access to the UTC time when responding to REST requests, as the data is always only saved as UTC in the PI Data Archive.

2. Customers might, nevertheless, still want to see the time stamps in the time zone of the PI server, so we would need access to the IANA time zone of the PI Server. We would then add the time zones to the UTC time ourselves (by using std::chrono::zoned_time), so we don't expect the PI Web API to return the time stamps with a time zone, as they are not saved with a time zone in the PI Data Archive anyway.

Posted on behalf of a customer:

We are currently using the PI Web API 2021 SP1, version 1.15.0.162. We're using it to develop a proprietary C++ software.

One of our customers has PI Servers all over the world and wants to see the time stamps in the time zone of the PI Server. I'm aware that the PI Data Archive always saves the time as UTC, and I'm also aware that the time zone of the PI Server (or, better said, the time zone of the computer containing the PI Data Archive) might not be the same as the time zone of the collected data, but that is usually the case, at least for our customer. Because of this, it makes sense for our customer to see the time in the time zone of the PI Server / PI Data Archive.

Currently, our C++ software uses std::chrono::zonedtime (part of C++20 - https://en.cppreference.com/w/cpp/chrono/zonedtime) to allow the user to change the time zone. That allows us to either let the user choose the "local time zone" of the computer (std::chrono::currentzone()), or let him/her choose from a list of time zones from the IANA time zone database (std::chrono::gettzdb()). However, this also means that the user must know exactly in which time zone the data is collected (or, for our customer, where the server exists in the world) and choose the correct time zone. That's still a lot better than not being able to choose the time zone at all, but does not allow our customer to simply "use the time zone of the PI Server", as there's currently no possibility to query it using the PI Web API. It is possible to query the server time as UTC (by querying /piwebapi/system/status), but not the server's time zone.

However, I found out that it is possible to query the time zone of the PI Server / PI Data Archive when using the Asset Framework SDK instead of the PI Web API: https://docs.osisoft.com/bundle/af-sdk/page/html/P_OSIsoft_AF_PI_PIServer_ServerTimeZone.htm

So what we would need would be a way to query the IANA Time Zone of the PI Server. For some other people, it may also make sense if you additionally provided the Windows Time Zone, but we need the IANA time zones to be able to use it with std::chrono::zoned_time. Suggestion: both the IANA Time Zone and the Windows Time Zone of the PI Server (PI Data Archive) could be provided when querying /piwebapi/system/status.

So, to summarize:

1. We think it makes sense to only provide access to the UTC time when responding to REST requests, as the data is always only saved as UTC in the PI Data Archive.

2. Customers might, nevertheless, still want to see the time stamps in the time zone of the PI server, so we would need access to the IANA time zone of the PI Server. We would then add the time zones to the UTC time ourselves (by using std::chrono::zoned_time), so we don't expect the PI Web API to return the time stamps with a time zone, as they are not saved with a time zone in the PI Data Archive anyway.

Currently, when a response to a Stream or Stream Set controller encounters an error, an 'Errors' field will be included in the response, and when no error is encountered the 'Errors' field will be absent in the response. This behavior can impact applications that depend on a defined set and/or number of properties to be included in a response. For such cases it would be beneficial to have the ability to either configure PI Web API, or provide a URL parameter setting (e.g. a "selectedFields" setting), to always, or never, include an 'Errors' field in the response, regardless of whether an error is encountered. If no error is encountered the 'Errors' property could just be "null".