EVBox OCPP Testing
Test EVBox charge point workflows against your CPMS with repeatable virtual validation for OCPP 1.6J and OCPP 2.0.1 transactions, StatusNotification states, remote commands, and release QA across Elvi, Liviqo, and Troniq models.
What is EVBox OCPP testing?
EVBox OCPP testing validates how your CPMS handles EVBox chargers, including Elvi and Liviqo AC units and Troniq Modular and Troniq High Power DC units, across core OCPP workflows. Teams check BootNotification onboarding, StatusNotification changes, Authorize, charging sessions, MeterValues, and backend-initiated commands such as RemoteStopTransaction and Reset before a release reaches production.
Why this matters
- EVBox spans AC units like Elvi and Liviqo and DC units like Troniq Modular and Troniq High Power, so connector count, power levels, and StatusNotification timing differ across the lineup.
- Most installed EVBox chargers speak OCPP 1.6J, while newer EVBox platforms add OCPP 2.0.1, so your CPMS must handle both message sets from the same vendor.
- A repeatable virtual setup lets engineering and QA replay the same EVBox session patterns on every release without booking field hardware.
What to validate
- BootNotification, StatusNotification, Heartbeat, Authorize, MeterValues, and transaction coverage.
- Remote start, stop, reset, and operational command validation from the CPMS side.
- Status transitions such as available, preparing, charging, suspended, finishing, unavailable, and faulted.
- Regression testing across connectivity interruptions and reconnection behavior.
Example EVBox OCPP validation flow
A strong EVBox compatibility test checks the full operational path for an Elvi or Troniq unit: BootNotification registration, Authorize, a charging session with MeterValues, a CPMS-issued command, and session closure.
EVBox -> CPMS: BootNotification (chargePointVendor "EVBox", chargePointModel "Elvi")
CPMS -> EVBox: Accepted
EVBox -> CPMS: StatusNotification (status Preparing)
CPMS -> EVBox: Accepted
EVBox -> CPMS: Authorize (idTag)
CPMS -> EVBox: Accepted
EVBox -> CPMS: StartTransaction
CPMS -> EVBox: Accepted (transactionId)
EVBox -> CPMS: MeterValues (Energy.Active.Import.Register)
CPMS -> EVBox: Accepted
CPMS -> EVBox: RemoteStopTransaction
EVBox -> CPMS: StopTransaction
EVBox -> CPMS: StatusNotification (status Finishing)EVBox compatibility proof points
EVBox testing proves your CPMS handles session state, charger status, and backend commands consistently across the Elvi, Liviqo, and Troniq lineup before production rollout.
| Area | Coverage | Typical validation |
|---|---|---|
| Registration and availability | BootNotification (chargePointVendor EVBox), StatusNotification, and Heartbeat | Confirm the CPMS registers Elvi, Liviqo, and Troniq units and reflects connector readiness. |
| Charging-session flow | Authorize, StartTransaction, MeterValues, and StopTransaction | Validate the path that drives billing and support cases, including Energy.Active.Import.Register meter samples. |
| Control operations | RemoteStartTransaction, RemoteStopTransaction, Reset, and UnlockConnector | Confirm CPMS-issued commands behave predictably on multi-connector Troniq DC units during active sessions. |
Common scenarios
Release validation
Check EVBox charger sessions before shipping CPMS changes that affect StatusNotification handling, billing, or session control.
Support and bug reproduction
Recreate reported Elvi or Troniq behavior in a virtual environment instead of waiting for field logs and hardware availability.
Scalable QA
Run many virtual EVBox chargers at once to validate CPMS stability under realistic concurrency and regression volume.
Validate EVBox OCPP workflows before rollout
Reproduce Elvi, Liviqo, and Troniq sessions, remote commands, and charger state transitions with virtual charge points instead of depending on lab hardware timing.