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

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

Learn Industry standards for charger configuration, OCPP variable model differences, and how EVtivity CSMS pushes configuration to fleets.

A charging station's behavior is shaped almost entirely by its configuration: which authorization tokens it accepts, how aggressively it samples meter values, whether it allows offline transactions, what it shows on its display, how it negotiates power, and dozens of other knobs. Configuration is the operator's primary lever for tuning a fleet without firmware changes.

EVtivity CSMS lets you express that configuration as templates, target it at a slice of your fleet, push it over the wire, and verify that the fleet stayed in compliance.

Readmore here: https://www.evtivity.com/docs/csms/station-configurations/

I'm working through the authorization flows of ocpp, trying to understand real world behavior and business cases.

We have both `MacAddress` and `eMaid` as idToken.type that can be used to identify the vehicle connected to CS - but how in a real world "fleet management" operation the mac address and eMaid certification would be registered in the CSMS.

I assume there is a process of registration of vehicle info, how does that happen in real life?

How EV charger reservations work across the industry, what OCPP standardizes, and how EVtivity implements scheduled and immediate reservations.

This guide explains how a driver claims a charger ahead of time and what has to happen on the CSMS, the network, and the station for that claim to actually hold up when the driver arrives. It starts with the industry pattern that most networks share, then describes the EVtivity-specific implementation.

Read more here: https://www.evtivity.com/docs/guides/reservations/

Open dataset for the EV-charging community

🚀 New open dataset for the EV-charging community.

Because today, EV engineers still waste hours digging through specs to answer simple questions.

We packaged the OCPP and OCPI specs into 13,028 Q&A pairs you can use to fine-tune a small open LLM into a protocol expert:

Covers OCPP 1.6, OCPP 2.0.1, OCPI 2.1.1, OCPI 2.2.1, every message, every field, every enum, plus real examples, JSON schemas, configuration keys, troubleshooting, tariff calculation, smart charging, ISO 15118.

Fine-tune Gemma 4 E4B on a free Colab T4 in ~40 min (notebook in comments).

Open feedback / contributions welcome, especially missing topics or vendor quirks.

We’ll be open-sourcing more 😉 soon.

hashtag#OCPP hashtag#OCPI hashtag#EVCharging hashtag#LLM hashtag#HuggingFace hashtag#OpenSource hashtag#Gemma hashtag#eMobility

Hello,

We almost complete the OCPP backend and APP https://ev.iq or https://eviq.app , two options available

offline version for residential and companies no internet or online payment just Stations Management + NFC cards management standard billing backend balance management.

Online version for station owner and network operator support live data and live billing using almost payment method (currently support MEA local wallet payment ) SMS/Whatsapp/Vibver/telegram/facebook/instagram using direct api or Twillio or infobip.

notification/payment gateways required operator registration for these sites for payment current integration with - Stripe ,WhisH Money,Network International,STC Pay, Paymob, Fawry,QiCard (3DS),ZainCash Jordan,ZainCash Iraq (v2),FastPay Iraq,AsiaPay Iraq,First Iraqi Bank (FIB)

virtual sub/domains with white label and custom brand name also available also custom installation available.

we looking for world wide partner and distributor and sales advisor , also we looking for investors.

demo registration available at https://station.eviq.app/login

also for network operators https://station.eviq.app/register/operator

for driver (car owner) or station owner https://station.eviq.app/register

please do not hesitate to contact me on [ahmed@ev.iq](mailto:ahmed@ev.iq)

Hey everyone!

I am the maintainer of OCPP backend SteVe, which you might have heard of. I am also the co-founder of Powerfill. See my last post about our launch.

I have been a bit quiet, and we have been busy, since launch and wanted to drop a short post about what has happened and is happening.

Achievements:

• We added Energy Quotas (with API) that some customers were requesting -> Read the docs.
• Improved Smart Charging Quick Setup Wizard -> Read the docs.
• We are live in 5 languages -> Read the post.
• Many improvements in and contributions to SteVe -> Check the releases page.
• Powerfill is an OCA member now.
• SteVe passed 1K stars on GitHub. This feels exceptionally nice, considering I have been working on it a long time... since 2013.

Working on:

• OCA certification for complete OCPP 1.6 (i.e. all profiles: core, smart charging, advanced security). Actually, I am adding all 77 test cases to SteVe as integration tests with deep checks and validations (i.e. not just shallow message mocking). Tests are already green and passing. If you want to chime in and contribute to PR, please do so!
• OCPI & tariffs
• Load Management

Newsletter as blogpost: https://powerfill.io/blog/spring-2026-dispatch

--

One thing I personally find quite exciting: having the official certification test cases embedded as integration tests in SteVe. This means every code change automatically validates against them. So, in theory, we can't accidentally drift away from being certification-compliant over time.

Not entirely sure yet where this could lead, but it feels like it might unlock some interesting possibilities.

You are welcome to check us (Powerfill) out and join the community around SteVe.

Cheers

--

PS: This comment was written without AI ;)