Alfen OCPP Testing
Test Alfen charger workflows against your CPMS with virtual sessions, status changes, and backend-driven commands. Validate how your CPMS handles Alfen hardware including the Eve Single Pro-line, Eve Double Pro-line, and the NG9xx platform before you roll out to the field.
What is Alfen OCPP testing?
Alfen OCPP testing validates how your CPMS handles Alfen chargers across BootNotification, Authorize, StartTransaction, MeterValues, StatusNotification, and remote commands. Alfen units such as the Eve Single Pro-line and Eve Double Pro-line commonly speak OCPP 1.6J and rely on Active Load Balancing and smart-charging configuration that your backend must read and set correctly. Teams use this testing to catch compatibility gaps before a backend release or a fleet rollout reaches production.
Why this matters
- A backend that passes a generic OCPP check can still mishandle Alfen smart-charging keys and Active Load Balancing limits once real sessions run.
- Rolling out Eve Pro-line or NG9xx units across sites is safer with repeatable regression tests than with one-off manual checks.
- Virtual Alfen chargers let engineering, product, and support reproduce the same session behavior on every release without booking a hardware lab.
What to validate
- BootNotification, Authorize, StartTransaction or TransactionEvent, MeterValues, and session completion flows.
- Status transitions, reconnect handling, and backend resilience under repeated session cycles.
- Remote commands such as start, stop, reset, and operational control validation.
- OCPP 1.6 and OCPP 2.0.1 workflow checks where mixed-version support matters.
Example Alfen OCPP validation flow
A practical Alfen 1.6J regression test covers BootNotification with the Alfen vendor identity, authorization, an active session with meter values, a smart-charging limit, and a remote stop before the session ends.
Charge point -> CPMS: BootNotification(chargePointVendor "Alfen BV", chargePointModel "Eve Single Pro-line")
CPMS -> Charge point: Accepted
Charge point -> CPMS: Authorize(idTag)
CPMS -> Charge point: Accepted
Charge point -> CPMS: StartTransaction
CPMS -> Charge point: Accepted
Charge point -> CPMS: MeterValues (Energy.Active.Import.Register)
CPMS -> Charge point: Accepted
CPMS -> Charge point: SetChargingProfile (Active Load Balancing limit)
Charge point -> CPMS: Accepted
CPMS -> Charge point: RemoteStopTransaction
Charge point -> CPMS: StopTransactionAlfen compatibility proof points
Alfen testing reduces regression risk across the charger lifecycle, from BootNotification identity through smart-charging limits, before a backend release or a site rollout.
| Area | Coverage | Typical validation |
|---|---|---|
| Registration and identity | BootNotification and early-session setup | Confirm your CPMS accepts the Alfen BV vendor identity and applies the right configuration keys to Eve Pro-line and NG9xx units. |
| Session execution | Authorize, MeterValues, and StopTransaction | Validate the Authorize, MeterValues, and StopTransaction path that drives billing and support cases. |
| Smart charging and commands | SetChargingProfile, Reset, and reconnect handling | Exercise SetChargingProfile limits, Reset, and reconnects where Alfen Active Load Balancing assumptions often break. |
Common scenarios
Pre-release validation
Check Alfen charger behavior before shipping backend changes to sessions, statuses, or smart-charging limits across your Eve Pro-line fleet.
Mixed-fleet compatibility
Run Alfen 1.6J flows next to other vendors so your CPMS handles Active Load Balancing and configuration differences cleanly.
Operational bug reproduction
Replay reported Alfen session or load-balancing issues in a controlled setup instead of waiting on hardware-lab access.
Validate Alfen OCPP workflows before release
Run repeatable virtual tests for Eve Pro-line and NG9xx onboarding, sessions, smart-charging limits, and reconnect behavior before they reach production.