Charging station detected issues
The platform watches each charging station for faults, misconfigurations and communication problems that can affect charging, connectivity or reliability, and raises each one as a detected issue with a type and a severity. Open issues are shown in the dashboard and available through the EVSE Issues API.
How issues are detected
Detection runs on a schedule, not the instant something happens on a station. Two checks run in the background: connectivity is checked every ten minutes, and every other kind of issue hourly. Each run looks at the station's current state and the last 24 hours of its activity, so an issue can take up to an hour to appear after the condition first arises, and up to the next run to clear once it is fixed.
Most thresholds are fixed, and several scale with the station's connector count (a four-socket station is allowed more traffic than a single). The one setting you control is the connectivity window: how long a station may be silent before it counts as offline, set per provider and 24 hours by default.
Severity
Every issue carries a severity, low, medium, high or critical, fixed by its type. Severity drives how it is surfaced, and in particular whether it is emailed (see notifications).
The issues
| Issue | Severity | What it means |
|---|---|---|
| No connectivity | Low | The station has not been in touch for longer than the provider's connectivity window (24 hours by default). |
| Socket error | Medium | A connector reports a fault, other than under-voltage or a power-meter failure, over StatusNotification. |
| Under voltage | High | A connector reports an under-voltage fault. |
| Power meter failure | High | A connector reports a power-meter failure. |
| Authorisation failures | Medium | The station's recent authorisations were refused repeatedly (four or more in a row) with no successful charge after them. |
| Concurrent transaction | Medium | A token was refused for trying to start a second session at the same time, a sign of possible misuse. |
| Command errors | Medium | Two or more OCPP commands returned errors in the last 24 hours. |
| Too many commands | Medium | The station sent far more messages than expected for its connector count in 24 hours. |
| Too many sessions | Critical | The station recorded far more sessions than plausible for its connector count in 24 hours. |
| Double OCPP identity | Critical | Another live station is using the same OCPP identity. |
| Double OCPP identity by serial number | Critical | Two hardware serial numbers have booted under one OCPP identity, a sign of a swapped or cloned unit. |
| Cost settings not configured | Medium | One or more connectors have no valid tariff. |
| Issues reported by the station | Medium | The station itself reported a fault it has not since cleared (NotifyEvent on OCPP 2, or a station-level fault on 1.6). |
| Transaction start point misconfigured | Medium | On OCPP 2, the station's TxStartPoint is set to a value the platform does not support (ParkingBayOccupancy or Authorized). |
| Invalid start date and time | Medium | The station started a session with a timestamp that is in the future, before the station existed, or implausibly old. |
| Invalid timestamp received | High | A start or stop message carried a timestamp the platform could not read. |
| Long connector ID | High | A connector ID is longer than nine characters. |
| Security policy violation | Critical | The station's connection does not meet its required security profile, usually the wrong credentials, or an insecure connection where a secure one is required. |
A few conditions have a name in the model but are not raised today: a boot loop, an idle fee incompatible with the EVSE's settings, and connectors that are not yet configured. Treat them as reserved rather than active.
Notifications
The platform emails an issue when it is first raised. It is not a digest, and a recurring or long-running issue is not re-sent, so the dashboard is where you see what is currently open. Whether an email goes out, and to whom, depends on the issue:
- Loss of connectivity emails the station's owner, at most once every seven days per station. A provider can turn owner notifications off, and an account can turn them off or redirect them to its field-service contact.
- Field-service faults (loss of connectivity, under-voltage, a power-meter failure, and faults the station reports itself) email the station's maintenance account, when it has issue notifications enabled.
- Critical issues (a duplicated OCPP identity, an implausible number of sessions, a security-policy violation) email the provider's issue mailing list.
Everything else is shown in the dashboard and the API but sends no email. The recipients and toggles are settings on the provider (the issue mailing list, and whether owners are notified) and the account (whether to notify, and whether the owner or the field-service contact receives it).
Resolving issues
An issue opens the first time its condition is detected and closes when the condition clears. Most issues resolve themselves: the next scheduled check sees the problem gone and marks the issue resolved. You can also resolve one by hand, from the dashboard or the API, but resolving an issue whose cause is still present only clears it until the next check finds it again. For a few types the platform stays quiet for 24 hours after a manual resolve, but the real fix is always to clear the underlying condition.
What that means in practice for the common ones:
- No connectivity: restore the station's link, its power, its mobile signal, or the backend address it connects to. It clears once the station is back in touch.
- Socket error, under-voltage, power-meter failure: a hardware fault at the connector. Clear it on site and the station reports itself healthy again.
- Double OCPP identity, or by serial number: two units are answering to one identity. Give each its own OCPP identity, or remove the stale duplicate.
- Security policy violation: bring the connection up to the station's required security profile, the right credentials and, where the profile demands it, an encrypted connection.
- Cost settings not configured: set a valid tariff on every connector.
- Transaction start point, long connector ID, invalid timestamps: correct the station's configuration, its start-point setting, its connector numbering, or its clock.