feat(api): expose reconnectable charge point and OCPP event streams

[juherr]

Parent

Part of #1000.

Problem

The REST API is request/response only. External systems that need to react to charge point activity must poll transactions or other resources. Polling cannot reliably observe short-lived connection and connector transitions, and it adds unnecessary load.

Useful real-time events include charge point connection changes, BootNotification, Heartbeat, connector status, transaction lifecycle, MeterValues, reservations, firmware and diagnostics status, OCPP task completion, CALLERROR, and communication exceptions.

Proposal

Expose a server-sent events stream:

GET /api/v1/events

SSE is suggested because this requirement is a unidirectional server-to-client stream and it supports standard HTTP authentication, proxies, and automatic reconnection.

Suggested filters:

chargeBoxId
eventType
action
taskId

Example:

GET /api/v1/events?chargeBoxId=CP001
Accept: text/event-stream

Example event:

id: 184467
event: connector.status.changed
data: {
  "timestamp": "2026-07-11T16:04:50.024Z",
  "chargeBoxId": "CP001",
  "connectorId": 1,
  "previousStatus": "Preparing",
  "status": "Charging"
}

Every event should contain a stable event ID, timestamp, type, charge box ID where applicable, and connector, transaction, task, or OCPP message references where applicable.

Reconnection

Clients should be able to reconnect using:

Last-Event-ID: 184467

The server should either resume from the next retained event or return a documented signal that the requested position has expired.

The stream should carry references to persisted OCPP message records rather than requiring every subscriber to retain full payloads itself. #2071 tracks the structured OCPP message history API.

Acceptance criteria

• Clients can subscribe using API authentication.
• Events can be filtered by charge point.
• Connection, connector, transaction and task events are emitted.
• Events have stable IDs and timestamps.
• Last-Event-ID reconnection behavior is supported and documented.
• Slow consumers cannot block OCPP processing.
• Retention and replay limits are documented.
• The endpoint is included in OpenAPI.

Non-goals

• Accepting commands over the event stream.
• Replacing the OCPP WebSocket connection.
• Guaranteeing unlimited event retention.