TriggerMessage is the diagnostic primitive in OCPP. When you need a fresh value from a charger — current status, latest meter reading, heartbeat — without waiting for its next scheduled report, TriggerMessage is the request.
It’s a small message with outsized operational value. This article covers what it does, the diagnostic patterns it enables, and the gotchas that come up in production.
The basic mechanics
The CSMS sends TriggerMessage to a charger with a specific message type to trigger:
{
"requestedMessage": "Heartbeat"
}Or with a specific connector context:
{
"requestedMessage": "StatusNotification",
"connectorId": 2
}The charger responds with one of:
- Accepted — the charger will send the requested message shortly.
- Rejected — refusing to send it for some reason.
- NotImplemented — does not support TriggerMessage at all.
Then the charger sends the requested message as if it were a normal scheduled send.
What you can trigger (OCPP 1.6)
The 1.6 spec defines these triggerable message types:
- BootNotification
- DiagnosticsStatusNotification
- FirmwareStatusNotification
- Heartbeat
- MeterValues
- StatusNotification
Some chargers support additional vendor-specific triggers via the same mechanism.
What you can trigger (OCPP 2.0.1)
OCPP 2.0.1 expanded the list significantly. Triggerable messages include:
- BootNotification
- LogStatusNotification
- FirmwareStatusNotification
- Heartbeat
- MeterValues
- SignChargingStationCertificate
- SignV2GCertificate
- StatusNotification
- TransactionEvent
- SignCombinedCertificate
- PublishFirmwareStatusNotification
The expanded list reflects 2.0.1’s richer protocol. You can ask for transaction event data, signed certificates, firmware status — all on demand.
Diagnostic patterns
The patterns I use most in production.
”Is this charger really alive?”
Send TriggerMessage with requestedMessage=Heartbeat. If the charger responds Accepted and then sends a fresh Heartbeat within a few seconds, the WebSocket connection is genuinely alive. If the trigger fails or no Heartbeat follows, the connection is dead or stale.
This is more reliable than just checking last-heartbeat-time, which only tells you the past. For how the Heartbeat and WebSocket keep a session alive in the first place, see the Heartbeat and connection lifecycle (coming soon) walkthrough.
”What’s the actual connector state right now?”
When the dashboard shows a connector as Faulted but the operator suspects it cleared, send TriggerMessage with requestedMessage=StatusNotification and the specific connectorId. The charger sends fresh state. If the returned state still looks wrong, the common OCPP errors (coming soon) reference can help decode what the charger is reporting.
Useful when your StatusNotification stream has gaps or you suspect state staleness.
”Is the meter working?”
Trigger a MeterValues message during an active session. If meter values come back zero, or stuck at a single value, the meter likely has a problem. If the values look reasonable and changing, the meter is healthy.
This is a quick health check without waiting for the next scheduled meter sample.
”Did the firmware update actually complete?”
After pushing a firmware update, trigger FirmwareStatusNotification (1.6) or LogStatusNotification (2.0.1) to get the current status. Useful when the update process seems stalled.
”What’s the diagnostic log status?”
Trigger DiagnosticsStatusNotification (1.6) or LogStatusNotification (2.0.1) when you’re investigating an issue. Helps confirm whether the charger has logs ready to upload.
”Force a re-registration”
Trigger BootNotification to make the charger re-register. Useful after a CSMS configuration change that requires the charger to be aware of new settings.
Patterns that don’t work
A few things people try with TriggerMessage that don’t work.
Forcing a transaction to start. TriggerMessage cannot start a transaction. Use RemoteStartTransaction (1.6) or RequestStartTransaction (2.0.1) instead.
Forcing connector unlock. TriggerMessage cannot unlock a connector. Use UnlockConnector instead.
Pushing configuration. TriggerMessage cannot change configuration. Use ChangeConfiguration (1.6) or SetVariables (2.0.1).
Forcing data extraction. TriggerMessage triggers a single message type. To get rich data (e.g. comprehensive diagnostics), use GetDiagnostics (1.6) or GetLog (2.0.1).
The general rule: TriggerMessage is “send this OCPP message now.” Anything beyond that needs a different OCPP message.
Operational considerations
A few things to know when using TriggerMessage in production.
Rate limiting
A flood of TriggerMessages can stress a charger. If your diagnostic tooling is triggering 50 messages per minute on a single charger, you may degrade its operation.
Use sparingly. Cache results when appropriate.
Vendor implementation variation
Some chargers implement TriggerMessage well — they send the requested message promptly and correctly. Others have bugs:
- Send the wrong message type.
- Send the message after significant delay.
- Send stale data instead of fresh.
- Return Accepted but never actually send.
Test with each OEM in your fleet before relying on TriggerMessage for critical diagnostics.
Race conditions
If you trigger a StatusNotification and a real state change happens simultaneously, you may get two StatusNotifications close together — one from the trigger, one from the real event. Your CSMS should handle this gracefully.
Connector ID specificity
Some triggers (StatusNotification, MeterValues) accept a connectorId. Some don’t (BootNotification, Heartbeat — these are charger-level).
If you specify connectorId=0, you get the charger-level state. If you specify connectorId=1, 2, etc., you get per-connector state.
A useful diagnostic workflow
When investigating a charger issue, my workflow:
flowchart TD
A[Check last state<br/>in dashboard] --> B[Trigger Heartbeat]
B --> C{Charger alive?}
C -->|No| Z[Connection dead<br/>or stale]
C -->|Yes| D[Trigger StatusNotification<br/>per connector]
D --> E{Active session?}
E -->|Yes| F[Trigger MeterValues]
E -->|No| G[Trigger diagnostics status]
F --> G
G --> H{Logs ready?}
H -->|Yes| I[GetDiagnostics<br/>pull logs]
H -->|No| J[Escalate or<br/>revisit later]
style Z fill:#fde,stroke:#c66
style I fill:#dfe,stroke:#6a6-
Check last known state in the CSMS dashboard. Is the charger online? When was the last message? What was the last status?
-
TriggerMessage Heartbeat. Is the charger reachable now?
-
TriggerMessage StatusNotification for each connector. What’s the current state per connector?
-
If charger has an active session, TriggerMessage MeterValues. Is the meter responding?
-
TriggerMessage DiagnosticsStatusNotification. Are logs available?
-
If logs available, GetDiagnostics. Pull the logs for offline analysis.
This sequence tells you most of what you can know about a charger remotely without physical access.
The 2.0.1 expansion
OCPP 2.0.1’s TriggerMessage expanded what can be requested. The most operationally interesting additions:
TransactionEvent. Force a fresh TransactionEvent (Updated) for an active session. Useful when you suspect the session has gone quiet for the wrong reason.
Signed certificate triggers. SignChargingStationCertificate, SignV2GCertificate — useful for testing the certificate-signing flow without waiting for a real renewal event.
LogStatusNotification. Separated from DiagnosticsStatusNotification — log retrieval has its own status flow.
The expanded list reflects how 2.0.1’s more granular event model benefits from more granular triggering.
Integration with monitoring
TriggerMessage works well as a tool for ad-hoc diagnostics. For ongoing monitoring, design your normal message flows to give you what you need without constant triggering.
A common pattern:
- Heartbeat every 5 minutes — gives you regular liveness.
- StatusNotification on state change — gives you accurate per-connector state without polling.
- MeterValues during transactions at 60-second intervals — gives you regular session updates.
With this baseline, TriggerMessage becomes the exception, not the routine. Used for genuine investigation, not routine state queries.
What it tells you about charger quality
A charger’s TriggerMessage implementation quality is a decent proxy for overall implementation quality:
- Good implementation: responds promptly, sends fresh accurate data, handles edge cases (concurrent triggers, invalid requests) gracefully.
- Mediocre implementation: responds but with delays, occasional bugs, missing some edge cases.
- Poor implementation: NotImplemented, or buggy enough to be unusable.
When evaluating new charger hardware, test TriggerMessage handling specifically. A vendor whose TriggerMessage works perfectly probably handles other diagnostic interactions well too.
The honest summary
TriggerMessage is a small but useful OCPP feature. It enables on-demand diagnostics without changing the charger’s operational behavior. Use it for investigation when something looks off; don’t use it as a substitute for properly-designed normal message flows. Implementations vary in quality — test with your specific hardware before depending on it for critical diagnostic workflows.