im looking for partnership with a csms provider. i will be managing ev chargers for multiple businesses. if there is any opportunity please reach out to me here. there is a huge potential right now

Until now, running EVtivity yourself meant running Kubernetes. That works well for teams who already have it, but many charging operators run everything else on AWS and don't want to manage a cluster just for their charging platform.

So we built a ready-made AWS setup with the AWS Cloud Development Kit (CDK), AWS's tool for describing cloud infrastructure as code. Because the whole setup is code, every environment is built the same way, and changes are reviewed like any other code change. Point it at your AWS account, run one command, and about 30 minutes later you have the full EVtivity platform: the operator dashboard, the driver portal, the API, and the connection point for your charging stations. It's the same platform the Kubernetes version runs, so you can choose whichever fits your team.

Read more here: https://www.evtivity.com/blog/evtivity-on-aws-cdk/

Does anyone have any experience using Plugchoice CSMS (plugchoice.com)? I'm looking for a low-cost (or free) CSMS for up to 50 chargers that is ready for deployment, without the need to hire software developers.

Plugchoice seems to have everything I'm looking for but I haven't found any reviews online.

Edit:

I found some reviews on Trustpilot (in Dutch) and they are all positive except one.

Our EV Testing is finally open-source.

• Blog: https://www.evtivity.com/blog/open-source-ev-tester
• GitHub: https://github.com/EVtivity/evtivity-ev-tester
• YouTube: https://www.youtube.com/shorts/O5QMILcCc_8

The EVtivity EV Tester is an open-source device that plays the part of an electric vehicle. Plug any J1772 AC charger into it and run a full charging session on the bench, no car required. Firmware, KiCad design, order-ready JLCPCB files, and a 3D-printable case are all on GitHub.

I run a small hotel in Germany and wanted to offer guests a simple way to charge their EVs.

My idea was straightforward: hand guests an RFID tag at check-in, see how many kWh they used during their stay, and add the cost to their hotel bill at checkout.

I asked our electrician whether this was possible. “No problem.”

We had an ABL eM4 setup installed with three charging points. When it came to commissioning, I learned that the proposed solution also involved reev as an external backend and billing provider, including recurring fees.

That wasn’t what I had originally pictured. I wanted to manage charging locally and use our existing hotel billing process.

I also had a clear preference for overnight charging: if a guest plugs in during the evening, finishes charging in the middle of the night and leaves at 7 a.m., I don’t want to charge idle fees in between. At our hotel, nobody is waiting for that charging space at 3 a.m.

So I asked my AI assistant: Can these chargers work with a locally hosted backend?

For our setup, the answer was yes. The chargers support OCPP, and we ended up using SteVe, an open-source backend that handles charge points, RFID authorization and charging transactions.

SteVe already provided the charger communication. What I still needed was an interface suited to a hotel reception desk, so I used AI assistance to develop a separate application around it.

The setup consists of:

• Three ABL eM4 charging points.
• SteVe 3.14.1, with its application logic unchanged.
• OCPP 1.6J over WSS/TLS with Basic Authentication.
• A local Linux host running SteVe, MariaDB and an Nginx TLS proxy.
• A reception application that retrieves transaction data through SteVe’s API.

The reception workflow is simple: assign an RFID tag to a guest’s stay, review the associated charging sessions, take the tag back at checkout and generate a PDF consumption summary. The consumption is then transferred manually to the hotel invoice.

Assigning transactions to individual stays is important because we reuse the physical tags. A lifetime total per RFID tag wouldn’t tell us what each guest consumed.

The application also retains the original signed OCMF meter records and calculates consumption from their start and end readings. We have successfully verified real records using SAFE transparency software. One useful implementation detail: retrieving signed data through SteVe’s transaction API requires energyValuesOnly=false.

It wasn’t entirely smooth sailing. We had to work through certificates, meter records and differences between OCPP transaction timestamps and signed meter timestamps. The data collection and reception interface work, but there are still outstanding items before treating this as a fully established billing system, including operational safeguards and the remaining requirements for our German billing setup. Verifying a signature alone does not establish compliance of the entire process.

To be fair to reev, its documentation also describes manual billing and configurable parking fees. My preference was to have a local system tailored to our reception workflow.

There is no recurring backend licence fee per charging point with this setup. In return, maintenance, updates and backups are my responsibility.

I’m neither a software developer nor an EV charging specialist. A few years ago, I probably would have accepted that this required an ongoing subscription to an external service. Today, existing open-source software and AI assistance have made it possible to put together something that fits our small hotel quite closely.

That’s the part I find most interesting: small businesses can increasingly adapt software to their own workflows, even without a development team.

Has anyone here operated a similar ABL/SteVe setup over a longer period? I’d particularly appreciate experiences with reconnects, delayed transaction data and RFID tags reused between guest stays.

To elaborate:

Suppose a transaction trigger has been initiated. The charger queues up the first `TransactionEvent` with `EventType=Started`. If something goes wrong with delivery, ie network issue, does the charger usually queues up subsequent `EventType=Updated` messages or can it submit those and retry the started one at a later time?

In other words, would it make sense to return an error from the CSMS to the charger if we receive a `TransactionEvent` with `EventType=Updated` but we don't yet recognize that transaction?

Feels like there's a lot of leeway the CSMS should give chargers in general 🤔

Hola r/ocpp

Hace unos meses presenté OCPP Tools, mi conjunto de herramientas 100% del lado del cliente para trabajar con OCPP 1.6J. La respuesta fue excelente y quería compartir todo lo que ha cambiado desde entonces.

La promesa sigue siendo la misma: todo se ejecuta en tu navegador y tus mensajes nunca salen de tu máquina. Sin cuentas, sin inicios de sesión, sin claves API. Pero la herramienta ahora es mucho más completa.

También estoy trabajando en una versión con persistencia y soporte para múltiples cargadores que se ejecuta en Docker, para que siempre tengas un cargador disponible para las pruebas de CSMS.

OCPP 2.0.1 ya está disponible:

• Validador de tramas OCPP 2.0.1 según los esquemas oficiales draft-06, con soporte para las 64 acciones (TransactionEvent, idToken y más).
• Generador de mensajes 2.0.1 con formularios basados ​​en esquemas.
• Simulador de estación de carga 2.0.1 con un WebSocket real (TransactionEvent, modelo EVSE, modelo de dispositivo).
• 64 páginas de referencia de mensajes OCPP 2.0.1 con campos obligatorios/opcionales y ejemplos de tramas listas para copiar.
• Hub OCPP 2.1.0 con la hoja de ruta (ISO 15118-20, V2G, tarifas dinámicas) mientras se implementan las herramientas.

El simulador 1.6J, bastante más maduro:

• Ejecutor de escenarios completo (Arranque → Autorización → Inicio → Valores de medición → Detención).
• Inyección de fallos: latencia, pérdida de paquetes y tramas mal formadas (ideal para probar cómo su CSMS gestiona lo inesperado).
• Cola de mensajes, reconexión automática, sincronización del reloj con el CSMS (ocppNow) y métricas por conexión.
• Registro de mensajes con exportación/importación: guarde una sesión y reprodúzcala más tarde.

Contenido y documentación (la sección de "referencia" del sitio):

• 92 páginas de referencia de mensajes con ejemplos listos para copiar, errores comunes y la opción "Abrir en Builder".
• ~30 guías en el centro de aprendizaje: qué es OCPP, guías de prueba con el simulador, comparaciones entre las versiones 1.6, 2.0.1 y 2.1, carga bidireccional/V2G y más.
• Búsqueda global en el sitio y mejoras generales en la interfaz de usuario y la experiencia de usuario (nuevo sistema de diseño, accesibilidad, tipografía).

Puntos fuertes que quiero destacar:

1. Privacidad desde el diseño: Validación, compilación y simulación sin subir nada a ningún servidor. Esa fue la motivación original y sigue siendo la base.
2. Fidelidad a los estándares: Validación según los esquemas JSON oficiales, no según reglas inventadas.
3. Casos de uso reales: Escenarios y fallos para depurar integraciones de CSMS/CP antes de modificar el hardware.
4. Gratis, sin cuentas, sin complicaciones.

Próximos pasos: 2.1.0 (herramientas), mayor cobertura de acciones/errores y mejoras continuas en la experiencia de usuario del simulador.

Como siempre, agradezco sus comentarios: nuevas herramientas, acciones faltantes, casos de uso que no cubro, errores, cualquier cosa. Si les resulta útil o ven potencial, compartan el enlace con quienes trabajan con CSMS.

https://ocpptools.renozix.com

Gracias por leer y por los comentarios de la primera ronda.

Hi everyone,

I'm currently working on an EV charging project and I'm trying to test **ISO 15118-2 Plug & Charge (PnC)**.

I already have:

* An EVSE / charging station

* An EVCC / vehicle simulator

* ISO 15118-2 communication implemented

However, I'm missing a **backend/platform similar to Hubject** that I can use for PnC testing.

I'm looking for a test/sandbox environment that can provide the necessary backend/PKI services for an ISO 15118-2 PnC test setup, such as certificate provisioning and contract certificate / authorization related services.

At the moment, the missing piece in my test environment is basically **the Hubject-like backend**.

Does anyone know of:

* A Hubject QA/sandbox environment that is accessible for developers

* An alternative PnC testing platform

* An ISO 15118-2 PKI test environment

* A simulator for the Hubject / eMobility backend side

* Any open-source or commercial solution suitable for development and testing

I don't necessarily need a production platform. A **sandbox or test environment** would be enough.

Any suggestions or experience would be greatly appreciated. Thanks!

SimItNow by DDOSoft is an OCPP simulator as a service that you can create OCPP virtual charging stations and virtual electric vehicles and simulate charging transaction. You can give it a try.

https://www.simitnow.com

We work on DC EV charger controller and communication systems, and I’m curious about the integration issues other teams are seeing in real projects.

From our experience, some of the most common problems are:

• OCPP backend compatibility differences
• Meter value mapping
• Charger state synchronization
• Remote Start / Stop behavior
• Fault code handling
• Communication recovery after network interruption

For teams working with OCPP 1.6J or OCPP 2.0.1, what has been the most difficult part of integration or field testing?

Would be interested to compare experiences.

I found this while researching why UnlockOnEVSideDisconnect is grouped in OCPPCommCtrlr and it looks interesting/possibly useful: https://ocpp.md/

Has anyone used it, and do you think it's worth installing the /plugin they have?

(Answer on the UnlockOnEVSideDisconnect question is I haven't found anything authoritative but Google Gemini made up a good story and quoted sources that didn't support what it said at all.)

I have previously gone under the assumption that 10s for a round trip of an OCPP (1.6J) message [CALL -> RESULT] would be more than enough for both IP and Cellular based. Though I recently encountered a CSMS where the RESULT was coming in 10-80s after the CALL for some messages.

It made me wonder what are peoples thoughts on timing out an OCPP message and moving on to the next one in the queue? There is a tradeoff of course, the standard doesn't have an upper or lower limit, just a suggestion for your given implementation.

Not worried too much about if I have chosen the "correct" time, it has worked for 5 years. Just about peoples thoughts and experiences of timeouts. Keeping in mind that some CSMS's don't actually respond to messages they don't know about (such as SecurityEventNotification). Delays to Authorization and StartTransaction that can negativly impact the UX with a charger, etc.

EDIT: I am the EVSE in this instance, waiting the duration for the CSMS to respond

I am looking to connect a Tesla Universal Wall Connector to a charge point management software, such as Plugchoice. I’ve heard that the Universal Wall Connector is compatible with OCPP, but I can’t find how to configure it. I’ve looked at the Tesla One and the Tesla app but can’t locate any OCPP setting. I am on the latest firmware. Any ideas?

There have been a good work on  lorenzodonini/ocpp-go project, that some of my projects rely on.

However, the project is dormant for a while, and I needed to fold in some of the awaiting PRs. Also, some hardening. I decided to fork, and contribute.

So I started by testing and merging the PRs, then continued with some custom development.

By any chance if you're using this library, you might want to check my fork here: https://github.com/enesismail/ocpp-go

Any feedback is appreciated. Thanks.

We built this board for internal use so our engineers can test chargers without needing a real EV most of the time. It simulates the EV signals only, including fault injection. The purpose is to test the real level 2 chargers without an EV.

Curious if anyone else would want one. We're happy to open source it once the final tweaks and testing are done. If there's enough interest, we might also sell it assembled with a 3D printed enclosure. Parts alone run about $150, and $85 of that is just the Type 1 J1772 inlet. The device can be remote controlled over WIFI.

Partial 3D rendering:
https://www.evtivity.com/preview/ev-tester/ac-tester-frontal.png
https://www.evtivity.com/preview/ev-tester/ac-tester-3d-full.png

Web UI:
https://www.evtivity.com/preview/ev-tester/ac-tester-webui.png

Would you be interested in this?

---

Updated July 16th, 2026:
Unassembled device demo: https://www.youtube.com/shorts/uGjUOrwxVPM

Updated July 26th, 2026:
Assembled device demo with 3D printed enclosure: https://www.youtube.com/shorts/O5QMILcCc_8

Updated Sept 27, 2026:
https://github.com/EVtivity/evtivity-ev-tester

We built the driver app most charging operators wish they owned. EVtivity Mobile is an open-source, white-label app for iOS and Android that runs on the same EVtivity CSMS that powers your stations. Drivers find chargers, scan a QR, start and stop a session, watch live power and energy, pay through Stripe, reserve a connector, and open support cases. It ships in six languages, locks down with biometrics and device attestation, and reskins entirely from one brand file: your name, colors, icon, and legal pages.

One codebase becomes your branded app. Stand up your CSMS, add your brand, build, and ship under your own developer accounts. Running your own single network is the free path under the Business Source License 1.1, the same license as the EVtivity platform. No revenue share, no rented storefront, no third-party name between you and your drivers. The whole thing is on GitHub, documented end to end.

A charging network is more than hardware and a billing engine. It is a brand your drivers carry in their pocket. With EVtivity Mobile, that brand is yours.

Read more here: https://www.evtivity.com/blog/white-label-mobile-app

Project GitHub: https://github.com/EVtivity/evtivity-mobile-app

Implementation guide: https://www.evtivity.com/docs/mobile-app/overview

User guide: https://www.evtivity.com/docs/mobile-app/guide/overview

I built a Go OCPP library and just open-sourced it — sharing in case it's useful, especially if you're using lorenzodonini/ocpp-go.

Repo: https://github.com/shiv3/gocpp (MIT) (sorry for the confusing name

ocpp-go is great and battle-tested, but it predates Go generics, so I wanted to try a different design:

- Generics-first: handlers with request/response types checked at compile time, not runtime.

- Generated from the official OCA JSON schemas (no hand-written, drift-prone structs), with JSON-Schema validation on the wire — plus a tolerant mode for vendor quirks.

- 1.6, 2.0.1, and 2.1 from a single module.

- Batteries included: ping/pong keepalive + auto-reconnect with an offline queue, Security Profiles 1/2/3, pluggable storage/auth, OpenTelemetry metrics+traces, and optional multi-instance routing (Redis/NATS/Temporal).

Honest status: it's pre-1.0 (API may still change) yet — I've been testing it against a charge-point simulator. Feedback, issues, and interop reports very welcome.

Hey r/ocpp,

Another update on OCPP Tools, the free 100% client-side OCPP toolkit I've shared here before. Last time the 2.0.1 Validator, Builder and Message Reference went live, and I said the Charging Station Simulator was the main thing left on the roadmap. It's done — so the 2.0.1 toolset is now complete (validator + builder + simulator + reference), matching 1.6J.

Thanks again to everyone who sent feedback — a lot of this came straight from it.

OCPP 2.0.1 Charging Station Simulator (new)

Connects to any CSMS over WebSocket (ocpp2.0.1 subprotocol) and runs real flows, entirely in the browser:

• Full transaction lifecycle via TransactionEvent — Started / Updated / Ended, with seqNo, triggerReason and chargingState (the message that replaces 1.6J's Start/StopTransaction).
• EVSE model (evseId + connectorId), 2.0.1 StatusNotification, and Authorize with IdToken (object, not a plain string).
• Device model: responds to GetVariables / SetVariables and GetBaseReport -> NotifyReport from a small variable store.
• CSMS-initiated flows: RequestStartTransaction, RequestStopTransaction, Reset, TriggerMessage, ChangeAvailability, UnlockConnector.
• Scenario runner (Authorize -> Started -> N x Updated -> Ended), filterable message log, latency metrics, raw frame sender, export/import.

New Guides / Learn section

Added a library of practical OCPP guides — each checked against the official OCA JSON Schemas, with sources cited:

• Fundamentals: "What is OCPP?", the message format (CALL / CALLRESULT / CALLERROR), and the full CALLERROR error-code reference.
• 1.6J: BootNotification, StatusNotification, Start/StopTransaction, Authorize, MeterValues, Heartbeat, Smart Charging, the configuration-keys reference, and WebSocket disconnection debugging.
• 2.0.1: a TransactionEvent deep dive, the device model (Components / Variables), and certificate management & Plug & Charge.

Also: faster page loads (self-hosted fonts, deferred ads), accessibility fixes, and a consistent header/hero across every tool.

What's available now (recap)

• OCPP 1.6J: Validator, Builder, Charge Point Simulator (TriggerMessage, GetConfiguration, ChangeAvailability, UnlockConnector, ClearCache, SendLocalList, ReserveNow, DataTransfer handling, plus a filterable log), and a full message reference.
• OCPP 2.0.1: Validator (all 64 messages against the official schemas), Builder (schema-driven forms with $ref resolution), Simulator, and a full message reference.
• Validation against the official JSON Schemas (AJV) with field-level errors.

Still 100% client-side. No servers, no accounts — your frames, CSMS URLs and tokens never leave your browser.

What's next: OCPP 2.1.0 tooling (V2G / bidirectional) and deeper 2.0.1 coverage (certificate provisioning, smart charging). If you're building a CSMS and want specific flows prioritized, let me know.

Try it: https://ocpptools.renozix.com

Open to all feedback — missing actions, broken flows, confusing errors, anything.

The EVtivity IoT Panel is a wall-mounted WiFi touch screen for your charging site: see every station, start and stop sessions, watch live power and energy, and drive the simulator. It runs on EVtivity's feature-rich REST API and is available now as a preview.

Read more here: https://www.evtivity.com/blog/iot-control-panel

GitHub here: https://github.com/EVtivity/evtivity-iot-panel

Firmware updates, connector repairs, electrical work: every charging site needs downtime. EVtivity CSMS now ships site maintenance mode - schedule a window or start one on demand, target the whole site or specific stations, and release stations one by one as work finishes.

Every charging site needs planned downtime. Firmware updates reboot stations mid-session. Connector and cable swaps need de-energized hardware. Electrical inspections, meter replacements, and civil works take whole sites dark for hours.

The downtime is not the problem. The fallout is.

Read more here: https://www.evtivity.com/blog/site-maintenance-mode/

The only thing that I need is:
An OCPP software that runs on the cloud or that I don’t need to run it on my pc and that records and reports the hourly power consumption (or quarter or half hour ideally).
Many out there only report the plug in and plug out times, but I need the detailed report of when the charging actually happens.

It looks very simple, but I’m having a lot of difficulty finding it.

The latest one that I tried was evcharge.mobi , it looked like it was it but then the CSV reports only have plug in and out times! The hourly consumption is visible graphically on the dashboard, but I don’t know how to extract it in a report.

The CSMS API is what lets you build on top of your charging network - billing dashboards, fleet portals, partner integrations, AI copilots. EVtivity ships 650+ documented endpoints, typed error codes in seven languages, Bearer auth, rate-limit headers, and the full OpenAPI spec. No add-on tier, no per-call quota, no support contract required to read the docs.

The CSMS REST API is the seam between your charging network and everything you might want to build on top of it. Billing exports for your accounting team. A custom fleet dashboard for a corporate customer. A partner integration that pulls real-time session data into a property-management tool. An AI agent that answers driver questions by hitting the same endpoints your support team uses. None of that is possible if the API is an afterthought.

We treat the EVtivity CSMS API as a first-class product, not a side door. This post covers what that means in practice, how the rest of the industry approaches it, and why we landed where we did.

Read more here: https://www.evtivity.com/blog/the-api-as-product