RemoteStartTransaction is accepted far more often than it succeeds, and the gap between those two things is where most driver-facing charging failures live.
The acknowledgement means the charger received a well-formed request it is willing to consider. It does not mean a session started, and treating it as confirmation is the single most common mistake in diagnosing this.
Accepted is not started
When a charger replies Accepted, it is confirming that the message was understood and the request is permitted. What follows is a sequence of conditions that must all hold before energy flows, and any of them can fail silently from the platform's point of view.
The evidence that a session actually began is a StartTransaction message, not the acceptance. If that never arrives, the remote start did not work regardless of what was acknowledged.
Conditions that must hold at the charger
The connector number is worth checking specifically. Platforms and chargers do not always agree on whether numbering starts at zero or one, and a request naming the wrong connector is a valid request for something that cannot happen.
- A cable is connected at both ends, where the charger requires it before starting.
- The vehicle is present and responding on the control pilot.
- The connector specified in the request exists and is available.
- No fault condition is active, including ones that do not surface as an obvious error.
- The charger is not already running a transaction on that connector.
- Any local authorisation requirement is satisfied or explicitly bypassed.
Authorisation is a separate question
A remote start usually carries an identifier that the charger may validate, either locally against a cached list or by asking the platform. Where the charger holds a local list and the identifier is not on it, the start can fail even though the platform considers the driver authorised.
Configuration determines which behaviour applies. Chargers configured to authorise locally will reject identifiers the platform has approved, and this looks like an inexplicable failure until you know where the decision is being made.
Vehicle-side refusals
The charger can offer energy and the vehicle can decline it. A vehicle with a departure timer, a charge limit already reached, or a scheduled charging setting will refuse to draw, and the charger reports a plugged-in state with no energy flowing.
From the platform this is indistinguishable from a charger fault. It is not one, and no amount of investigation on the charging infrastructure will resolve it.
Where the sequence usually breaks
- The command was sent to a charger that was momentarily offline and queued rather than delivered.
- The connector referenced does not match the physical connector the driver is using.
- The charger required a cable connection first and the request preceded it.
- Local authorisation rejected an identifier the platform had accepted.
- A prior transaction never closed properly, leaving the connector occupied.
- The vehicle refused for its own reasons.
The stale transaction case
A transaction that was interrupted and never formally stopped can leave a connector occupied from the charger's perspective. Every subsequent remote start is then rejected or accepted and abandoned, and the charger appears broken while behaving exactly as specified.
This is why interrupted-session handling matters more than it appears to. A fleet that does not reconcile abandoned transactions accumulates connectors that quietly stop working.
How to establish what happened
Read the message exchange in order and look for StartTransaction. If it is absent, the failure is at the charger and the conditions above are the checklist. If it is present but the session ended immediately, the failure is after start and the meter values will show whether energy ever flowed.
Both cases are resolvable from the trace. Neither is resolvable from the acknowledgement alone, which is why platforms that expose only success and failure at the command level make this class of problem expensive to own.