Reading Events, Timelines, and Daily Records in a Storage EMS

How do you plot any value the EMS records?

The dashboard answers what the site is doing now with a fixed set of series. Charts answer a specific question: did the PCS follow the setpoint it was given, does the interconnection meter agree with the inverter, what did state of charge do overnight on the fifth. Every measurement read from every device and every command written out to a device can be placed on a chart, given its own axis, style, and color, compared against any other value, and exported. The layout you build persists between sessions once saved.

The picker lists values grouped by device and tagged as measurement or control. Site level totals such as total battery power and total state of charge are computed by the EMS; the remaining groups are values read from an individual device. The quickest check that a device is following its commands is to put the control value and the matching measurement on the same axis and look for the gap between them. Values with different magnitudes, state of charge against kilowatts, go on the right axis so neither is flattened.

• Live mode follows the present over a window of 15 minutes, an hour, a day, or a week, re read on a poll interval from one to sixty seconds. Pause before reading numbers off a chart; a one second poll on a fast moving site redraws under the pointer.
• Historical mode shows a fixed window in the past and does not poll. The time bar states the span of stored data available, so check it before entering dates.
• Each chart exports its data as CSV or its picture as PNG, and Download All exports every chart on the page in one action.
• Check units before comparing two state of charge series. The site level aggregate is a fraction from 0 to 1, while the value read from a BMS is a percentage.

What does the event log record?

Everything the EMS notices is written to one event log: device alarms raising and clearing, devices going offline and coming back, tasks starting and failing, and the control system itself starting and stopping. Every entry carries one of five levels that sets the color of the row. Critical is a condition demanding immediate attention, such as a protective trip. Error means something failed: a task raised an exception, or a device event of alert severity was raised. Warning means something needs attention but operation continues: a device alarm at advisory severity, a communications failure, a device dropping offline. Info is normal activity worth recording, and debug is diagnostic detail.

The event type says what produced the entry. System events come from the control system itself; task events from the scheduler; device events from device communications; device status events from the device state machine, such as a transition from on to communication error to offline; and device alarm events from a device’s own alarm bits, with the alarm name, its severity, and the register it was read from. A device going away usually produces more than one entry, a device entry describing the failure and a status entry recording the transition, and reading the pair is how you tell a momentary blip from a sustained outage.

How do you tell an active alarm from one that has cleared?

A device alarm produces two entries. One is written when it raises, with kind activated, meaning the condition became true at the timestamp of the entry. The other is written when it clears, with kind cleared, and the entry keeps the original activation time so the two timestamps together give the duration. An alarm with an activated entry and no matching cleared entry is still active. The log is a record of what happened rather than a worklist: entries are added, never edited, and there is nothing to dismiss. To act on a condition, fix it at the equipment and confirm the cleared entry arrives.

The payload fields used most are the device identifier, the alarm name as the device reports it, its severity, the device’s own description of the condition, the status register it was read from, which is the fastest route to the manufacturer’s documentation, and the activation time. A device alarm configured as caution is logged at level warning; an alarm configured as critical is logged at critical.

How does the timeline give context?

An event on its own tells you what happened. The timeline tells you what the load, the PV, and the battery were doing at that moment. It draws a window of time as a stack of lanes: measured values in the upper lanes, an all events lane that places log entries on the same axis as bubbles colored by the most serious level inside them, and an all device events lane that draws each alarm as a bar spanning from the moment it activated to the moment it cleared. Windows of 15 minutes to six hours are one click away, a custom range takes exact dates, and follow live keeps the window sliding forward to the present.

The playhead is a vertical line marking one instant, and everything in the moment panel describes that instant. Clicking an event bubble moves the playhead to that event and flags every value at that time. Expanded, the moment panel has four columns: every value lane and its reading at the playhead, log entries within two minutes either side, commands written out to devices in the same window, and every device alarm active at that instant, each with its device, severity, source register, and how long it has been active. That last column is the direct answer to what is wrong right now.

• The lanes are yours to choose. The picker lists every source the EMS records: system data, the event log, commands, device events, and device status transitions. A lane arrangement built for a particular investigation can be saved as a preset.
• Download exports whatever is in view as a single JSON analysis bundle or as one CSV per source. For an incident, place the playhead on the event, set a window that brackets it, and download the bundle; it contains the values, log entries, commands, and device events for exactly that period, which is what an incident review needs and what a colleague can open without access to the site.

How are whole days summarized?

Where the dashboard shows the present and events show individual incidents, records show whole days. Every day the site has operated is summarized into a single status, its energy figures, and an event count, and those summaries are laid out as a calendar in three views. Ribbon shows a whole year as twelve rows of day cells, the view for spotting patterns across a year, with a second switch that colors cells by status, by PV generation intensity, or by load intensity. Month shows a conventional grid with each day’s generation and a proportional bar. Year shows twelve month cards headed with each month’s generated total.

A day’s status follows the worst of its hours. A day that ran normally except for one hour with an error is an error day in the calendar, and opening the day shows which hour it was. A day with no records is not a fault; it is a day the system was not running, which is worth confirming against the run state history before treating it as data loss.

What does opening one day show?

Opening a day gives its complete record. Four tiles head the panel: energy generated and consumed in kWh, the peak power reached in kW, and uptime as the proportion of the day the system was in operation. An hourly status strip divides the day into twenty four cells colored by the status of each hour. Beneath it, power and state of charge plot the whole day as a stack of charts sharing one time axis, battery state of charge, net import and export, PV power, load power, and battery charge and discharge, each headed with its statistics for the day.

The right hand column reports availability: every device grouped by the equipment it belongs to, with a bar showing when it was on through the day and its availability percentage, and every task that ran, with when it was running and its average and maximum execution time. The day’s events are listed in time order. Clicking one hour in the status strip rescales the device and task bars to that hour and narrows the event list to it, which is the fastest route from something happened on the fourth to the equipment state and the events at the minute it happened.

How do reports leave the system?

The export dialog produces the daily summary, aggregate totals, the hourly status grid, and the event log for any period, as CSV or JSON. The time range is this month, the last three months, this year, or a custom range. CSV produces a spreadsheet ready file per section; JSON produces one structured file for machine processing. Two combinations cover most of what a site is asked for. For a monthly operations report, choose this month, leave daily summary and totals ticked, and export CSV. For an incident review, set a custom range around the day in question and add the hourly status grid and the event log.

Events are held for the retention period configured under storage, and the audit record has its own retention. An exported file is the only copy that survives retention, so anything needed beyond those periods is exported from the timeline’s download menu, the records report, or the audit log’s CSV export.