AVEVA™ PI System™ Feedback Portal

Welcome to our new feedback site!


We created this site to hear your enhancement ideas, suggestions and feedback about AVEVA products and services. All of the feedback you share here is monitored and reviewed by the AVEVA product managers.

To start, take a look at the ideas in the list below and VOTE for your favorite ideas submitted by other users. POST your own idea if it hasn’t been suggested yet. Include COMMENTS and share relevant business case details that will help our product team get more information on the suggestion. Please note that your ideas and comments are visible to all other users.


This page is for feedback specifically for AVEVA PI System. For links to our other feedback portals, please see the tab RESOURCES below.

Add a new idea Subscribe
Status Completed
Product AVEVA™ PI System Access (PSA)
Categories PI Web API
Created by Guest
Created on Aug 23, 2022

RELATED IDEAS

Add mechanism to detect connection loss with PI Web API Channels

Add mechanism to detect connection loss with PI Web API Channels PI Web API Channels allows to sign-up for updates (new values) of selected Data Items identified by their Web ID. PI Web API Channels is based on websockets. The client does not actively scan but is awaiting new values provided through the web socket. When there is no new data coming through the web socket sign-up a client cannot know if there are simply no new values or if the connection was lost. RFC 6455 suggest using Ping (section 5.5.2) /Pong (section 5.5.3) Frames which are unfortunately not supported with the OWIN web socket implementation PI Web API Channels builds on. Offer a mechanism to reliably allows a client to detect a lost web socket connection. One option which I can think of is sending an update on the web socket client every few seconds (configurable) with a heartbeat (e.g. UpTimeInMinutes from /piwebapi/system/status).
  • ADMIN RESPONSE
    Aug 23, 2022
    Here's what we did in PI Web API 2017 R2: when you open a Channel, you can now add the parameter heartBeatRate to your URL. What this does is tell the PI Web API server to send an empty message at a specific rate if there are no data values to send to the client. The value of heartBeatRate is an integer multiple of underlying AF Data Pipe polling interval. For example, if you pass "heartBeatRate=5", an empty message will be sent after 5 polls assuming no other data values arrive. A heartBeatRate value of 0 means no heartbeat messages. This has the same effect as not specifying the URL parameter at all. We hope this helps. For technical reasons, we are unable to implement the web socket standard RFC6455 "Ping" and "Pong" features to ascertain health. RFC6455: web socket definition. See Sections 5.5.2 and 5.5.3 on Ping and Pong: https://tools.ietf.org/html/rfc6455
  • Attach files
  • Guest
    Reply
    |     Aug 23, 2022
    This is currently the only blocker to us moving to use Channels in most of our use cases. We would love to have access to live data, and some of our use cases are critical level, so, for now, we have to stick to polling which is less efficient and more prone to misses, but we at least know when a connection error/disconnect happens and can handle it gracefully. For some of our less critical level use cases, this is fine but does potentially cause frustration to our users.
  • Guest
    Reply
    |     Aug 23, 2022
    Hello Steven, For completeness, please allow me to mention the 2 workarounds we suggested. 1. Querying the PI Web API status (https://../piwebapi/system/status) The idea is to do this in an open https connection every 5~10 seconds. The response contains a State which should be Running and UpTimeInMinutes which should continuously increase; it’s a kind of heartbeat indicating the PI Web API servers health. One can assume a connection issue if the call for the status fails or times out. Besides that any State other than Running and / or a decreased UpTimeInMinutes indicates a situation where your websocket sign-up may have become lost e.g. because the service have become restarted. The response is small and the suggested query frequency is low enough that throughput shouldn’t be a concern. 2.Create or use a fast changing signal as watchdog through PI Web API Channels One can create a counter or heartbeat on the PI Server which is used as a watchdog. This counter or heartbeat doesn’t have to be a PI Point. It can be an AF Attribute serviced e.g. by Asset Analytics. It can be an integer reporting the elapsed seconds of the minute or a complete timestamp (DateTime type). I suggest updating this watchdog every 3~5 seconds. By including the watchdog with the websocket sign-up, one can expect a callback with the frequency the watchdog updates. After missing an update for 2~3 cycles, one can assume the connection lost.