EV charger bench: commissioning, factory reset and local OCPP

[HuggeK]

Bench notes for the EV chargers on the Sourceful test rig: how to get into each unit, how to point it at FTW's local OCPP server, and how to factory reset one when an installer login is in the way.

Moved here from a draft PR on srcfl/device-drivers. It is operator knowledge about hardware rather than driver source, and most of these chargers need no driver at all — FTW speaks OCPP to them directly (see #732). Discussions are disabled on that repo, so this lives here alongside the OCPP work.

The rig. Left to right: a dark Charge Amps unit, the silver RFID Charge Amps, a Zaptec, and the Easee Charge Up on the far right.

Bench inventory

Device	Rating	Local path	Driver needed?
Charge Amps Dawn	22 kW 3P 32A	OCPP 1.6J	no
Charge Amps Luna	22 kW 3P 32A	OCPP 1.6J	no
Charge Amps (silver, RFID)	—	OCPP 1.6J	no
Zaptec (Go / Go 2 / Pro)	—	OCPP 1.6J, cloud-gated	no, once unlocked
Easee Charge Up	up to 22 kW	native OCPP 1.6J, beta	no
Ambibox V2G / InterControl ambiCHARGE	AC in 400 V 3×16 A, DC out 120–500 V 30 A	MQTT	yes — ambibox_v2x

The ambiCHARGE is the only one that still needs a driver: it is DC-coupled, bidirectional, and speaks MQTT rather than OCPP.

Charge Amps (Dawn, Luna, Halo, Aura)

Charge Amps migrated from its proprietary CAPI protocol to OCPP 1.6J, so every current model can point at a third-party central system.

Dawn and Luna rating plates. Serial numbers are redacted; both are 22 kW 3P 32A.

Getting in

Halo and Aura expose a WiFi access point:

1. Power the unit.
2. Join the WiFi network named HALO_<serial> or AURA_<serial>.
3. Browse to 192.168.250.1.
4. Enter the password from the letter shipped with the charger.
5. Settings are behind the arrow in the top-right corner.

Dawn and Luna use the Charge Amps Installer app over Bluetooth (Google Play · App Store). The app authenticates with a PIN and is meant for authorised electricians.

Warning

Bluetooth is only discoverable for the first 10 minutes after power-up. If the unit has been energised longer, cut the fuse, wait, power it back on, and start the search immediately. This is the single most common reason a bench unit "will not connect".

Pointing at FTW

Set the backend URL to the FTW host. The scheme must be ws:// or wss://:

ws://<ftw-host>:8887/<charge-point-id>

• Halo / Aura: Settings → OCPP menu.
• Dawn / Luna: CPMS settings → Connect to other CPMS. The charge point ID is editable during installation.

Restart the charger after applying.

Two things to do before switching:

1. Activate RFID locks in https://my.charge.space remote control settings. Doing this after the OCPP switch does not work.
2. Accept that cloud and local are mutually exclusive. A unit on a local central system is no longer on the Charge Amps cloud, and their app loses it.

Firmware floors observed in the field: Halo ≥ 158, Dawn ≥ 1.3.5.

Factory reset

Halo and Aura reset from the local interface: System → Factory Reset.

There is no documented hardware reset button, so the reset itself sits behind the password. If the letter is missing on a second-hand or demo unit, Charge Amps support (support@charge-amps.com) has to clear it — plan for that lead time rather than hunting for a button.

If a unit hangs during start-up, break the fuse for a minute and re-energise. That is a power cycle, not a reset, and it keeps the configuration.

Known rough edges

Reported by other OCPP integrations, and worth designing around:

• Remote stop is unreliable; some units bounce straight back to on. This is why FTW models stop as a 0 A charging profile rather than RemoteStopTransaction.
• Three-phase voltage and current reporting is inconsistent per phase.
• Dual-socket Aura has connector-ID tracking problems.
• Halo occasionally drops the OCPP connection and needs a restart.

Zaptec (Go, Go 2, Pro)

Box-level OCPP 1.6J exists, but it is gated behind the Zaptec cloud portal.

Firmware floors: Go EU 2.4.2.4, Go UK 2.5.1.0, Go 2 3.2.1.0, Pro 7.5.4.0 (serial ZPR080000 and up).

Enabling it requires all of:

• the Allow OCPP 1.6J user-group permission,
• partner access granted by the installation owner via lookup key,
• the OCPP URL set in the Zaptec Portal — there is no installer-app or on-device path.

Note

Do not append the serial to the URL — Zaptec adds it in uppercase automatically. For an endpoint of ws://host:8887/ocpp/ZAP123456 you enter ws://host:8887/ocpp.

To revert: Settings → Authentication → Type, change away from OCPP 1.6J, then Circuits → Charger → Settings and disable stand-alone mode. No factory reset is documented.

Zaptec also exposes no local HTTP API — Home Assistant and evcc both go through api.zaptec.com. Worth knowing, because the existing zaptec Lua driver polls http://<host>:80/api/charger/state, an endpoint the hardware does not have. It is marked "community, untested" and its field names match Zaptec's cloud schema, so it was likely written from cloud docs and aimed at a LAN IP.

Easee Charge Up

Easee offers two OCPP modes:

• Cloud-emulated — charger talks to Easee Cloud, which proxies to your back-office. Fully supported, keeps the cloud dependency.
• Native — charger talks straight to a 1.6J server with no Easee proxy.

Native is what removes the cloud dependency at runtime. The catch is provisioning: it is switched on through Easee's cloud API, not from the app or the device.

1. POST /v1/connection-details/{serialNumber} — store the OCPP config, backend URL in websocketConnectionArgs.
2. POST /v1/connections/chargers/{serialNumber} — apply it.
3. GET /v1/connection-details/{serialNumber} — verify.

Requirements and limits:

• Easee account, and the site must have Easee selected as operator.
• Firmware ≥ 328.
• Beta — Easee recommends test environments only.
• Documented for wss:// with CA certificates; plain ws:// to a LAN host is not explicitly supported, so expect to terminate TLS.
• Revert by pairing with another operator or setting connectivityMode to OcppOff.

So the cloud dependency moves from runtime to a one-time commissioning step. A real improvement over easee_cloud, but not a cloud-free flow.

Ambibox V2G / InterControl ambiCHARGE

Ambibox-branded front, InterControl label on the side. The output line is the interesting part: 120–500 V DC, which is what makes this one bidirectional and not an OCPP candidate.

Covered by ambibox_v2x (MQTT, control enabled, v2x_charger), defaulting to sid-os.local:1883. Nothing to build unless bench testing shows the ambiCHARGE topic set differs from the Ambibox unit the driver was written against.

Manufacturer is InterControl (Turku, Finland); Ambibox is the brand.

The pattern

Easee and Zaptec need a one-time commissioning step through a vendor portal. Charge Amps needs none. After commissioning, all three dial out to FTW's local OCPP server and the cloud leaves the runtime path entirely — which is the whole argument for #732.

Open questions

• Three labels were not captured: the silver Charge Amps (Aura or Halo?), the Zaptec model (Go / Go 2 / Pro — decides the firmware floor), and the Easee Charge Up.
• Is there a Zaptec partner account with OCPP permission available? Without one, that unit stays on the read-only HTTP driver.

Sources

• Charge Amps OCPP configuration (eCarUp wiki)
• Charge Amps: migration to OCPP
• Charge Amps OCPP 1.6J field reports
• Zaptec OCPP 1.6J configuration guide
• Zaptec API usage guidelines
• Easee native OCPP introduction
• Easee OCPP commissioning for users

---

_{Photos: serial numbers on the three rating-plate shots are blacked out; model, rating and manufacturer are untouched. Hosted on the assets/charger-bench branch of the fork, since GitHub's API cannot attach files to a discussion.}