OCPP Diagnostics and Log Retrieval: Getting Data Out of a Charger

OCPP messages cover the protocol-level interactions between charger and CSMS. But chargers run firmware that does many things below the OCPP layer — vehicle communication negotiation, internal state machines, hardware control, error handling. When something goes wrong at this lower level, OCPP messages may give you hints but not the full picture.

That’s what logs are for. Chargers maintain internal logs of detailed operational events. OCPP provides messages to retrieve these logs for offline analysis.

This article covers GetDiagnostics (1.6), GetLog (2.0.1), the upload pattern, and the operational patterns that make log retrieval useful.

The basic concept

The CSMS asks the charger for its log files. The charger uploads them to a URL the CSMS specifies. The CSMS reviews the log file separately.

The CSMS doesn’t pull the log; the charger pushes it. This is because:

• Charger may be behind NAT (can’t be reached directly).
• Log files can be large; HTTP upload from charger is simpler than CSMS-side download.
• Upload semantics work in cellular environments more reliably than pull.

sequenceDiagram
    participant CSMS
    participant Charger
    participant Store as Upload URL
    CSMS->>Charger: GetDiagnostics with URL
    Charger-->>CSMS: fileName
    Charger->>Charger: Collect and compress
    Charger->>Store: Upload log file
    Charger-->>CSMS: Status Uploading
    Charger-->>CSMS: Status Uploaded

OCPP 1.6: GetDiagnostics

Request:

{
  "location": "https://logs.example.com/upload/charger-12345",
  "retries": 3,
  "retryInterval": 60,
  "startTime": "2026-06-26T00:00:00Z",
  "stopTime": "2026-06-27T00:00:00Z"
}

• location — URL where the charger should upload the log.
• retries / retryInterval — retry policy on upload failure.
• startTime / stopTime — date range to include in the log.

Response:

{ "fileName": "diag-charger-12345-20260627.tar.gz" }

The charger reports the filename it’ll use. Then it asynchronously:

1. Collects the relevant log data.
2. Compresses (typically tar.gz).
3. Uploads to the specified URL via HTTP PUT or FTP.

During and after this process, the charger sends DiagnosticsStatusNotification messages reporting status: Uploading, Uploaded, UploadFailed, or Idle. If you need the charger to re-send its current status on demand, TriggerMessage ^{(coming soon)} can prompt a fresh DiagnosticsStatusNotification.

OCPP 2.0.1: GetLog

Similar concept, slightly different structure:

{
  "log": {
    "remoteLocation": "https://logs.example.com/upload/charger-12345",
    "oldestTimestamp": "2026-06-26T00:00:00Z",
    "latestTimestamp": "2026-06-27T00:00:00Z"
  },
  "logType": "DiagnosticsLog",
  "requestId": 9876,
  "retries": 3,
  "retryInterval": 60
}

• logType — DiagnosticsLog (general diagnostics) or SecurityLog (security-related events).
• requestId — correlation ID, returned in subsequent status notifications.

Response:

{
  "status": "Accepted",
  "filename": "log-charger-12345-20260627.tar.gz"
}

Statuses during upload reported via LogStatusNotificationRequest.

The upload URL

The CSMS provides a URL where the charger uploads. A few practical notes.

HTTP PUT is most common. The charger does an HTTP PUT to the URL with the log file as the body.

FTP/SFTP is sometimes used. Especially for OEMs that built around FTP historically.

Pre-signed URLs work well. Generate a temporary URL (e.g. S3 presigned URL) that the charger can upload to. Avoids exposing your storage endpoint widely.

HTTPS required for sensitive logs. Always.

Per-charger paths. Use the charger’s identity in the URL to organize. https://logs.example.com/upload/${chargerSerialNumber}/${timestamp} is a common pattern.

What’s in a log

The exact content varies by OEM. Common things you’ll find:

Operational events:

• Power-on and power-off events.
• WebSocket connection attempts (success and failure).
• OCPP messages sent and received (sometimes redacted for size).
• Authorization decisions.
• Session start/stop with internal timestamps.

Hardware events:

• Contactor open/close events.
• Voltage and current measurements (with high granularity).
• Temperature sensor readings.
• Lock motor activations.
• ISO 15118 communication events.
• Pilot pin state changes.

Firmware events:

• Boot sequence details.
• Memory and storage status.
• Watchdog timer events.
• Crash dumps (if any).

Network events:

• Cellular signal strength.
• IP address changes.
• DNS resolutions.
• TLS handshake details.

Errors and warnings:

• All errors with stack traces or context.
• Warnings about marginal conditions.

The combination gives you a deep look at what happened on the charger during a specific time window.

When to retrieve logs

A few scenarios where log retrieval is the right move.

Suspected firmware bug. OCPP messages show something unexpected. Need internal details to diagnose.

Customer dispute. “I was charged for X kWh but my car says Y.” Logs show what the charger actually delivered.

Recurring fault investigation. A charger keeps going Faulted with the same errorCode. See common OCPP errors explained ^{(coming soon)} for how to read those codes; logs show what was happening at the time.

Pre-replacement diagnosis. Before sending a tech to replace hardware, pull logs to confirm the diagnosis.

Post-incident forensics. Something went wrong; need to know exactly what.

Vendor support escalation. OEM asks for logs to diagnose an issue. Standard ask.

When NOT to retrieve logs

Cases where log retrieval is overkill.

Routine monitoring. Logs are too detailed for daily ops. Use OCPP messages and dashboards.

Network-constrained scenarios. A cellular charger with limited data shouldn’t be pulling MBs of logs frequently. Save for genuine investigation.

Already-fixed issues. If you know what happened from OCPP messages alone, don’t waste time on logs.

Fleet-wide pulls. Don’t pull logs from every charger nightly “just in case.” Too much data; signal-to-noise is poor.

Operational patterns

A few patterns for using log retrieval effectively.

Reactive (problem investigation)

Charger has an issue. Operations team requests logs for the time window around the issue. CSMS sends GetDiagnostics. Charger uploads. Engineer reviews offline.

The most common use.

Proactive (suspected pattern)

Operations team notices a pattern (several chargers with similar issue). Pulls logs from affected sample. Identifies common root cause.

Valuable but requires effort to do well.

Scheduled (firmware update validation)

After pushing new firmware, pull diagnostics from a sample of chargers to verify the firmware is working correctly. Catch issues early before broad rollout.

On-demand (vendor support)

Vendor support team needs logs for ticket investigation. Operations facilitates the pull.

Practical considerations

A list of things to know.

Logs can be large. A week’s worth of detailed logs from a busy charger can be tens of MB. Plan storage.

Compression matters. Logs compress well (10x or more). Most chargers compress before upload.

Time-window selection. Narrow time windows = smaller logs = faster upload. Use as narrow a window as your investigation needs.

Upload bandwidth on cellular. A 50 MB log over cellular can take 10+ minutes and use significant data allowance. Avoid for routine pulls.

Logs may not include everything you want. Vendor decides what to log. If a specific event isn’t logged, you can’t retrieve it after the fact.

Retention on the charger. Chargers don’t store logs forever. Typically days to weeks of detail. For long-running issues, pull early.

Security and privacy

Logs can contain sensitive information.

Personal data. User identifiers (RFID UIDs), session details that may identify users.

Payment metadata. Sometimes — depends on what the charger logs.

Network credentials. Sometimes — depends on log verbosity.

Hardware identifiers. Always — serial numbers, MAC addresses, IMEI.

Handle logs accordingly:

• Store encrypted at rest.
• Limit access to those who need it.
• Define retention period.
• Honor user data-deletion requests by purging relevant logs.
• For GDPR / similar regulations, document what’s in logs and how it’s protected.

Common pitfalls

A few things that go wrong with log retrieval.

Upload URL not reachable. Charger tries to upload, can’t reach the URL. Firewall, DNS, TLS issue. Verify upload endpoint from the charger’s network perspective.

Upload partial / corrupt. Network interruption mid-upload. Charger reports UploadFailed; need to retry.

Authentication mismatch. Upload endpoint requires auth that the charger doesn’t have. Pre-signed URLs avoid this.

Log filling local storage on charger. Some chargers rotate logs aggressively; long-window requests may return less than requested.

Vendor-specific log format. Each OEM has its own format. Parsing requires vendor-specific tooling or knowledge.

Privacy violations. Operator pulls logs containing user PII without proper handling. GDPR exposure.

What good log management looks like

For CSMS operators with mature log retrieval:

1. On-demand pulling via operations dashboard. Operator selects charger, time range, clicks “Get Logs.”
2. Pre-signed URLs generated automatically for the upload endpoint.
3. Status tracked via DiagnosticsStatusNotification. Operator sees upload progress.
4. Logs stored in object storage with per-charger organization.
5. Vendor-specific parsing tooling to extract insights.
6. Searchable across logs. Common patterns surface across many chargers.
7. Retention policy enforced (e.g. 90 days for routine, longer for incident investigations).
8. Access controls. Only certain roles can pull logs; access is audited.

This level of maturity is common in larger operators. Smaller operators do it manually.

The honest summary

OCPP log retrieval is a powerful diagnostic tool that should be used deliberately. It’s overkill for routine monitoring but essential for investigation. Build solid tooling around the upload pattern, handle the privacy considerations carefully, and use it when OCPP messages alone don’t tell the whole story. Most production charger fleets pull logs occasionally; the discipline of doing it well separates effective operations from struggling ones.