Reset a charger

OCPP functional block B — Provisioning.

Rebooting a station remotely is the blunt instrument that fixes a surprising proportion of field problems — a wedged session, a setting that needed a restart, firmware in a state nobody can explain.

curl -X POST https://api.flowion.io/v1/chargers/$CHARGER/commands/reset \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"type": "soft"}'

Soft and hard#

Type	What restarts
`soft`	The station's OCPP software, gracefully
`hard`	The station's hardware — a power cycle

Prefer soft. It stops running transactions properly, so they are reported rather than lost, and it comes back faster.

Use hard when soft has not worked, or when the station is unresponsive enough that its software cannot be trusted to shut down cleanly. A hard reset can leave a transaction unfinished, which shows up later as a session with no end.

These are not the same axis as OCPP 2.x's reset types. 2.x asks when a reset happens (Immediate or OnIdle); 1.6 asks how much restarts (Soft or Hard). Soft is not OnIdle — a soft reset stops transactions straight away rather than waiting for the station to be idle — and Hard is not Immediate. The two axes are independent, so neither maps onto the other, and this API keeps 1.6's. See How Flowion maps onto OCPP.

For a 2.x station you may also pass evse_id to restart one EVSE rather than the whole station. Omit it for the whole thing.

The three answers#

Status	Meaning
`accepted`	Rebooting
`rejected`	The station will not
`scheduled`	Accepted, deferred until it can

scheduled can only come from a station whose OCPP version has a notion of deferral — a 1.6 station can never report it. If you are running a 1.6 fleet and handling this case, you are handling something that cannot happen.

What happens next#

The station goes away and comes back:

Its socket drops, so status becomes offline.
It reboots.
It reconnects and sends BootNotification — a genuine one, because it genuinely restarted.
You answer, and it resumes.

That boot is your confirmation the reset worked. Watch last_boot_at, and compare it against when you issued the command.

A station that never comes back is a station that could not restart, and no further command will reach it.

Do not reset to fix these#

A setting that will not take effect. If a configuration change returned RebootRequired then yes, reset. Otherwise a reset will not persuade a station to accept a setting it rejected.

An inoperative connector. Availability survives reboots by design. Set it back to operative instead — see Take a charger in and out of service.

A rejected charger. A charger whose registration_status is Rejected stops responding entirely, so the reset command cannot reach it either. Fix the registration status and wait for its retry.

A stuck cable. Try unlocking first. A hard reset may release the lock as a side effect, but it will also drop any other session on that station.

Timeouts mean "unknown"#

A 504 on a reset is genuinely ambiguous: the station may have accepted the command and rebooted before it could answer — the reboot being precisely what prevented the answer.

Do not retry immediately. Wait for the station to reconnect and check last_boot_at. If it moved, the reset happened.

Endpoints#

Commands · ChargingStations · Command History