Wallbox OCPP Testing
Validate how your CPMS handles Wallbox AC units like the Pulsar Plus and Commander 2 and the Supernova DC fast charger, with repeatable OCPP 1.6J tests for sessions, status changes, and remote commands.
What is Wallbox OCPP testing?
Wallbox OCPP testing checks how your CPMS handles Wallbox chargers across the OCPP 1.6J lifecycle. AC units like the Pulsar Plus, Commander 2, and Copper SB, plus the Supernova DC fast charger, send BootNotification, Authorize, StartTransaction, MeterValues, and StatusNotification. Teams verify these flows before backend changes reach production. Many Wallbox sites add the Power Boost or Power Sharing accessory for load management, so confirm your backend reads the meter values those setups report.
Why this matters
- Wallbox regressions show up in session timing and RemoteStopTransaction handling, not in simple schema checks.
- You can test a Pulsar Plus or Supernova session without booking a physical charger or a field site.
- Power Boost and Power Sharing change the MeterValues your CPMS receives, so repeatable tests catch billing and load-management bugs early.
What to validate
- BootNotification, Heartbeat, StatusNotification, Authorize, MeterValues, and transaction handling.
- Remote commands such as remote start, stop, reset, and operational control flows.
- State transitions across available, preparing, charging, suspended, finishing, and faulted conditions.
- Regression testing across reconnects, timeouts, and backend release changes.
Example Wallbox OCPP validation flow
A practical Wallbox test follows a Pulsar Plus from BootNotification through Preparing, an Authorize check, an active StartTransaction session with MeterValues, and a backend-sent RemoteStopTransaction. These are OCPP 1.6J messages, the version Wallbox chargers commonly use.
Pulsar Plus -> CPMS: BootNotification {chargePointVendor: "Wallbox", chargePointModel: "Pulsar Plus"}
CPMS -> Pulsar Plus: Accepted, heartbeatInterval 300
Pulsar Plus -> CPMS: StatusNotification {connectorId: 1, status: "Preparing"}
CPMS -> Pulsar Plus: (ack)
Pulsar Plus -> CPMS: Authorize {idTag}
CPMS -> Pulsar Plus: idTagInfo {status: "Accepted"}
Pulsar Plus -> CPMS: StartTransaction {connectorId: 1, idTag, meterStart}
CPMS -> Pulsar Plus: transactionId, idTagInfo {status: "Accepted"}
Pulsar Plus -> CPMS: MeterValues {transactionId, Energy.Active.Import.Register}
CPMS -> Pulsar Plus: RemoteStopTransaction {transactionId}
Pulsar Plus -> CPMS: StopTransaction {transactionId, meterStop, reason: "Remote"}Wallbox compatibility proof points
Wallbox QA needs confidence across the full charger lifecycle, not just one happy-path session. AC units like the Pulsar Plus and the Supernova DC fast charger both matter.
| Area | Coverage | Typical validation |
|---|---|---|
| Onboarding and status | BootNotification (chargePointVendor Wallbox), then Available and Preparing StatusNotification | Check the first messages a Pulsar Plus or Commander 2 sends after power-up or reconnect. |
| Authorization and charging | Authorize, StartTransaction, MeterValues, and StopTransaction | Confirm the billing path, including the meter readings a Power Boost or Power Sharing setup reports. |
| Operational commands | RemoteStopTransaction, Reset, and ChangeAvailability | Make sure backend commands reach the charger reliably during a live session. |
Common scenarios
Release regression testing
Replay Pulsar Plus and Supernova sessions before shipping CPMS updates that touch StartTransaction, StatusNotification, or RemoteStopTransaction handling.
Support issue reproduction
Recreate a reported Commander 2 or Copper SB fault in a controlled test instead of waiting on field access and partial logs.
Vendor-compatibility QA
Run Wallbox sessions next to other vendor profiles so mixed-fleet backend behavior stays stable, including sites that use Power Sharing.
Related resources
Validate Wallbox OCPP 1.6J behavior before rollout
Test Pulsar Plus, Commander 2, and Supernova sessions, status transitions, and RemoteStopTransaction in a repeatable virtual environment instead of waiting on a hardware lab.