UnlockConnector is one of the simpler but emotionally significant OCPP messages. When a user can’t pull the cable out — session ended, but the connector lock won’t release — this is the message that helps.
It’s also the message you don’t want to need. A properly-functioning charger releases the cable automatically when the session ends. UnlockConnector is the safety valve for when the normal flow breaks.
This article covers how it works, when to use it, and why it should be a last resort.
Why connector locks exist
EV chargers physically lock the cable into the connector during charging. This serves several purposes:
Safety. Pulling a high-current cable while energized would create an arc, potentially damaging connectors and posing a risk to the user. The lock ensures the cable can’t be removed while current is flowing.
Theft prevention. Without a lock, anyone could unplug your car and steal the cable.
Session continuity. The lock prevents accidental disconnections that would interrupt charging.
The lock engages when charging starts. It should disengage when charging ends and current has fully stopped.
The normal release flow
A well-functioning session ends like this:
- User stops the session (via app, RFID re-tap, or full charge reached).
- Charger ramps down current to zero.
- Contactor opens; circuit is now de-energized.
- Charger sends StopTransaction (1.6) or TransactionEvent (Ended) (2.0.1).
- Charger releases the connector lock (motor disengages).
- User pulls the cable.
flowchart TD
A[User stops session] --> B[Current ramps<br/>to zero]
B --> C[Contactor opens<br/>circuit de-energized]
C --> D[Charger reports<br/>session ended]
D --> E[Lock motor<br/>disengages]
E --> F[User pulls cable]
E -. flow breaks .-> G[Cable stuck<br/>send UnlockConnector]
style G fill:#fde68a,stroke:#d97706The transaction messages in step 4 differ by protocol version — see Start / Stop Transaction (coming soon) for 1.6 and TransactionEvent in 2.0.1 (coming soon). The lock release itself is automatic. UnlockConnector is for when this flow breaks.
When the cable gets stuck
Several scenarios cause the lock to stay engaged unexpectedly.
CSMS connection lost during session end. Charger ended the session locally but couldn’t notify the CSMS. Lock-release logic may depend on getting confirmation; if the logic is too strict, the lock stays.
Software bug. Race condition or state-machine error in the firmware leaves the lock state inconsistent.
Power glitch. Brief power blip mid-release leaves the lock partially-released or in an unknown state.
Mechanical issue. Lock motor failed; the cable is physically stuck.
Charger faulted. A fault during session end may pause the release sequence.
Session never properly ended. User pulled away without ending the session; charger thinks session is still in progress.
In the first 4-5 cases, UnlockConnector usually resolves the issue. In the last (mechanical), a technician visit is needed. Several of these — CSMS connection lost, charger faulted, session never ended cleanly — overlap with the failure modes covered in Common OCPP Errors Explained (coming soon).
The OCPP message
OCPP 1.6 UnlockConnector:
{ "connectorId": 1 }Response:
{ "status": "Unlocked" }Statuses:
- Unlocked — lock released successfully.
- UnlockFailed — the charger tried but couldn’t release.
- NotSupported — the charger doesn’t implement UnlockConnector.
OCPP 2.0.1 UnlockConnectorRequest is similar:
{ "evseId": 1, "connectorId": 1 }Response includes status (Unlocked, UnlockFailed, OngoingAuthorizedTransaction, UnknownConnector).
When to send UnlockConnector
A few legitimate triggers.
User calls support stuck at charger. Support agent verifies the charger thinks the session is over, confirms current isn’t flowing, sends UnlockConnector.
Self-service in app. Some networks expose a “release cable” button in their app, with safety guards. The user triggers UnlockConnector themselves.
Automated recovery. Operations sees a connector stuck in Finishing state for an extended period and triggers UnlockConnector automatically. This relies on accurate connector status — see StatusNotification deep dive (coming soon) for how Finishing is reported.
Maintenance access. Tech needs to remove a cable for replacement. UnlockConnector before physical work.
Safety considerations
UnlockConnector should only be sent when it’s safe.
Verify current is zero before unlocking. A properly-implemented charger does this internally — it rejects UnlockConnector if it detects current flow. Some implementations don’t check; trust your charger but verify.
Never unlock during an active session. Pulling a cable while connected and charging risks arc damage and user injury. The charger should refuse; the CSMS shouldn’t even try.
Confirm intent for self-service. A user accidentally tapping “release cable” mid-session is bad UX. Confirmation dialogs help.
Audit unlock events. Every UnlockConnector should be logged with who, when, why. Useful for support analysis and abuse prevention.
Where to put the button (or not)
A UX decision: should users have direct access to UnlockConnector?
Arguments for:
- Self-service is faster than support call.
- Most issues are simple enough for users to handle.
- Empowers users.
Arguments against:
- Users may use it inappropriately (mid-session out of impatience).
- Support context (confirmed end-of-session) is hard to verify in the app.
- Risk of abuse / misuse.
A compromise: expose the option with appropriate warnings (“Only use if your session has ended and the cable is stuck”). Audit usage.
Many networks — ChargePoint, EVgo, Electrify America, and Flo in North America, alongside European operators — have moved toward direct user access over the years as user education has improved.
Operational patterns
A few patterns for handling stuck cables operationally.
Automated detection. Monitor connectors in Finishing state. If duration exceeds 5 minutes (or whatever threshold), alert or auto-unlock.
Tiered response:
- Auto-unlock first (try UnlockConnector).
- If UnlockFailed, alert operations.
- If still stuck, dispatch a technician.
User self-service via app: as above, with safety guards.
Support team capability: support agents should be able to trigger UnlockConnector quickly when a user reports an issue.
What chargers should do
For firmware engineers.
Implement UnlockConnector reliably. It’s a critical safety feature. Should work even when many other things are broken.
Verify safety before unlocking. Don’t unlock if current is flowing. Don’t unlock if a session is genuinely active.
Handle motor failures gracefully. If the lock motor fails physically, return UnlockFailed; don’t silently fail.
Report status accurately. UnlockFailed should mean the unlock genuinely failed. Don’t return Unlocked optimistically.
Test the unhappy paths. What if power glitches mid-unlock? What if the connector is partially seated? Edge cases matter.
What CSMSes should do
A few principles.
Provide an admin-facing unlock UI with audit logging.
Expose user-facing self-service with confirmation and warnings.
Monitor stuck connectors automatically.
Handle UnlockFailed gracefully. Tell the user what to do next (call support, etc.).
Audit log every unlock. Useful for analysis.
A note on connector design
The need for UnlockConnector partly reflects the limits of connector lock design. Modern locks are mostly reliable. Older charger hardware had higher rates of stuck cables.
If your fleet has a high rate of UnlockConnector usage on a specific charger model, that’s a signal — the hardware may be aging or have a design weakness.
Track unlock frequency per charger as a maintenance indicator.
The honest summary
UnlockConnector is the safety valve for stuck cables. Use it sparingly and only when safe. Build self-service into your app with appropriate guards. Monitor unlock frequency as a hardware health signal. Most charging sessions never need UnlockConnector; for the ones that do, having it work cleanly resolves user frustration before it becomes a support escalation.
If you are building out your OCPP knowledge, What is OCPP? and the OCPP version comparison (coming soon) put this message in the wider protocol context.