Skip to main content


Contributors: Tyler Engelhardt

PI2eLogger Overview


PI2eLogger is an integration application that listens to data events from OSIsoft's PI Data Archive to automate the logging of plant events into eLogger. Using websockets, connections are made to specified Asset Framework attributes linked to PI Points.

New, updated, and deleted values from PI Points can be read in real time through websocket connections to the PI Web API for the connected PI Points. This allows processing of the value to determine the requisite action to perform. The application is configured through a JSON file and does not require a database as a configuration storage mechanism.

PI2eLogger is a nodejs application that hosts the websocket connection service. It also contains an NodeJS Express API to allow viewing system events and current status through a ReactJS client. Email notifications can be sent when websocket connections are terminated, and there is also an email notification for database cleanups which are scheduled through cron jobs.

The application reduced manual logging requirements of operators by upwards of 90% during startups, shutdowns, trips, and routine plant operations.


The goal of PI2eLogger was to use PI data to automate the manual logging of plant events. Common events include breaker status changes, pump starts / stops, gas turbine flame on / off, and gas turbine start / stop signals to name a few. Automation of plant event logs could increase operator awareness of plant conditions by allowing the focus to be on the plant rather than on logging the actions taken to the plant.

Plant trips tend to include numerous events that require logging that can be captured through listening to PI data events. Automating logs can reduce the effort needed to backfill logs when reviewing the events that occurred during a trip since focus during a trip is always going to be on the plant and not logging.


There were multiple challenges in building the PI2eLogger application. The first challenge encountered was in listening to the data events emitted from the websocket connection. When a value is deleted from the Data Archive, it has a different schema from new and updated data events. Additionally, Digital sets have a different schema for the value compared to regular data types like number or string. Since the PI Web API has limited documentation and is not strongly typed from a consumer standpoint, these differences had to be determined so they could be handled appropriately when parsing a data event.

Another challenge was in reading stepped values from the Data Archive. When a point received a step value and had exception deviation turned on for its interface, the value would be logged in the Data Archive, but it would not be pushed through the websocket connection until the exception deviation max was reached. This means that if the exception deviation had a max time of 10 minutes, the initial step change would not be pushed through the websocket connection, and thus an incorrect timestamp would be read. These types of points tended to have little data flow and could have exception turned off to allow the correct data point (and thus timestamp) to be read.