Charger history and logs

Every charge box keeps a record of when it was connected, what state its EVSEs reported, and every OCPP message it exchanged with the platform. All of it is readable in Connect.

​

Overview

When a charger misbehaves, the question worth answering first is which layer is broken. A charge box holds its own history at three levels of depth, and each one rules something in or out. Work down the list rather than starting at the bottom. A charge box that was offline for the hour in question explains itself, and reading OCPP messages to discover that takes far longer than reading connectivity history. All three open from the three-dot menu, and which object you open it on depends on the record you want.

​

Connectivity history

The charge box’s connectivity history records when it connected to the platform and when it dropped. It also shows whether a drop is a one-off or a pattern. A charge box that has reconnected fifteen times this week is telling you something different from one that dropped once. The first is usually a network or power problem at the site; the second may be nothing at all. History goes back to the charge box’s first connection. Reaching an older event means paging back to it, since there is no date filter here.

​

Status history

An EVSE’s status history records its charging status over time, and when each change happened. Where connectivity history tells you whether the charge box was talking, status history tells you what it was talking about. This is where you separate a fault from a driver’s experience of one. An EVSE that moved to Preparing and back to Available without charging did not fail in the way an EVSE that reported Faulted did, and the two need different conversations with the hardware manufacturer. Status history has the same shape as connectivity history: back to the first record, by paging.

​

OCPP logs

OCPP logs are the full message-level record of a charge box’s conversation with the platform. Each entry carries the request and the response as JSON, so you can see precisely what was asked and what came back. Spirii keeps every message. Recent entries load with the page; anything older than the last couple of days is retrieved from storage, so use the timestamp filter to reach it and expect the query to take longer than a page of recent traffic. Two filters narrow the list:

• Timestamp — the window you care about, and the way to reach older records
• Message type — any of the OCPP 1.6 message types

The JSON appears as the charge box sent it, including the token identifiers carried in authorisation requests.

​

A worked example

A driver reports that a charger at Munich DC Hub would not start a session on Tuesday afternoon. Connectivity history on the charge box shows an unbroken connection across that window, so the charge box was reachable and the problem is not the site’s network. Status history on the EVSE shows it moved to Preparing at 14:11 and back to Available at 14:13, with no charging in between. The driver plugged in and the charger acknowledged it, so the cable and the socket did their job. OCPP logs, filtered to that two-minute window, show the authorisation request the charge box sent and the response it received. That is the exchange that decided whether the session began.

​

Dependencies & limitations

• Everything is kept. Connectivity history, status history, and OCPP logs go back to a charge box’s first record.
• Older records take longer. Recent OCPP entries load with the page; reaching further back means using the timestamp filter and waiting for the query.
• History pages rather than filters. Connectivity and status history have no date filter, so an older event is reached by paging to it.
• Message types follow OCPP 1.6. The message type filter offers the OCPP 1.6 set.
• Logs and history are read in Connect. Both are viewed in the platform rather than pulled out of it.

​

Related

If you arrived here from an alert, start with connectivity history and work down.