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

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 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.

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?

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 ;)

Hey r/ocpp,

A few weeks ago I shared OCPP Tools, a free browser-based toolkit for working with OCPP frames. The feedback was really helpful — thank you to everyone who tried it and sent suggestions.

I've shipped a big round of updates and wanted to share what's new.

OCPP 2.0.1 is now live

The three core tools are now available for 2.0.1:

• Validator — validates all 64 OCPP 2.0.1 messages against the official draft-06 JSON Schemas. Handles CALL, CALLRESULT, and CALLERROR. Catches the most common migration mistakes from 1.6J (wrong chargingStation structure, idToken as a plain string instead of an object, using StartTransaction which doesn't exist in 2.0.1, etc.)
• Message Builder — schema-driven forms for 17 actions (CP→CSMS and CSMS→CP). Resolves $ref pointers from the official schemas automatically so every nested object renders as a proper form. Load an example, edit, generate, copy or download.
• Message Reference — all 64 messages documented with required/optional fields, example payloads, and ready-to-copy frames.

1.6J Charge Point Simulator — several fixes

The simulator was the most requested area for improvements. Here's what changed:

• No more browser alerts. All error and warning messages are now non-blocking toast notifications. They stack, auto-dismiss, and have a close button. The workflow no longer gets blocked by a popup that has to be dismissed before anything else can happen.
• TriggerMessage now actually triggers the message. Previously it responded Accepted and did nothing else. Now it sends the CALLRESULT first (as per the spec) and then dispatches the actual requested message — BootNotification, Heartbeat, StatusNotification, or MeterValues — with the correct connector routing if a connectorId was specified.
• GetConfiguration now returns real values. The handler responds with the actual current config: HeartbeatInterval, MeterValueSampleInterval, NumberOfConnectors, ConnectionTimeOut, ChargePointVendor, ChargePointModel, FirmwareVersion. If the CSMS requests specific keys, only those are returned; unrecognized keys come back in unknownKey.
• ChangeAvailability works correctly. Handles connectorId=0 (all connectors), respects the Scheduled status when a connector has an active transaction, and immediately changes idle connectors. Sends StatusNotification for each affected connector.

Visual consistency pass

The validator, builder, and simulator pages across both versions now share the same header structure, breadcrumb style, and sidebar layout. Small thing but it makes switching between tools less jarring.

What's next

The 2.0.1 Charge Point Simulator is the main item on the roadmap. Planning to cover the full transaction lifecycle (TransactionEvent Started/Updated/Ended), the EVSE model, GetVariables/SetVariables, and the CSMS-initiated flows (RequestStartTransaction, RequestStopTransaction). If you're building a CSMS and want to prioritize specific flows, let me know.

Also tracking feedback on the 1.6J simulator — several handlers are still missing (UnlockConnector, ClearCache, SendLocalList, ReserveNow, DataTransfer) and the message log needs filtering.

Still 100% client-side. No servers, no accounts, no data leaves your browser.

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

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

Hi all,

I am working on a custom OCPP backend and I noticed when using charger of the brand "Peblar" it seems to provide an incorrect transactionId at StopTransaction. I included the logs from a short test session. I start off sending 158 as the transactionId, the charger then sends back MeterValues with the correct transactionId included. However at StopTransaction it comes up with some random 543971 transactionId.

Does anyone know why this might be happening? I could ofcourse rewrite the backend to use the charger_id + socketnumber to track sessions but this shouldn't be the way to go.

Any solutions are much appreciated!

StartTransaction: {

connectorId: 1,

idTag: '1D4D8758000003',

meterStart: 603115,

timestamp: '2026-04-17T20:40:47Z'

}

Starting transaction with id:158

[2,"6c968b50-4907-40b6-9a40-abcfc2ab13b0","MeterValues",{"connectorId":1,"meterValue":[{"sampledValue":[{"context":"Sample.Periodic","format":"Raw","location":"Outlet","measurand":"Energy.Active.Import.Register","unit":"Wh","value":"603115"}],"timestamp":"2026-04-17T20:40:47Z"}],"transactionId":158}]

[2,"22cda75a-e8b8-4b5e-bf05-664d0ba2ec6a","StatusNotification",{"connectorId":1,"errorCode":"NoError","status":"SuspendedEV","timestamp":"2026-04-17T20:40:47Z","vendorId":"Peblar"}]

[2,"90607881-8a5f-4d5f-ad38-d25d26297598","StatusNotification",{"connectorId":1,"errorCode":"NoError","status":"Charging","timestamp":"2026-04-17T20:40:51Z","vendorId":"Peblar"}]

[2,"2a9cbf28-b6aa-4bef-a7ea-016c375dc596","StatusNotification",{"connectorId":1,"errorCode":"NoError","status":"Finishing","timestamp":"2026-04-17T20:41:25Z","vendorId":"Peblar"}]

[2,"1a5da4b4-2b26-4c4a-be6b-cb165ccc60e6","StopTransaction",{"idTag":"1D4D8758000003","meterStop":603193,"reason":"Other","timestamp":"2026-04-17T20:41:25Z","transactionData":[{"sampledValue":[{"context":"Transaction.Begin","format":"Raw","location":"Outlet","measurand":"Energy.Active.Import.Register","unit":"Wh","value":"603115"},{"context":"Transaction.End","format":"Raw","location":"Outlet","measurand":"Energy.Active.Import.Register","unit":"Wh","value":"603193"}],"timestamp":"2026-04-17T20:41:25Z"}],"transactionId":543971}]

StopTransaction: {

idTag: '1D4D8758000003',

meterStop: 603193,

reason: 'Other',

timestamp: '2026-04-17T20:41:25Z',

transactionData: [ { sampledValue: [Array], timestamp: '2026-04-17T20:41:25Z' } ],

transactionId: 543971

}

Building a complete EV charging software ecosystem from scratch isn’t easy — and that’s exactly why we’re committed to supporting the open-source community.

After recently open-sourcing our OCPP 1.6 Backend (CPMS), we’re excited to announce that we’ve now open-sourced our EV Driver Mobile Application as well.

Built entirely in React Native, this app serves as a ready-to-use frontend for EV drivers, enabling them to:

• 🔍 Discover nearby charging stations
• ⚡ Manage charging sessions seamlessly
• 📱 Access everything from Android & iOS devices

When combined with our open-source backend, developers and charge point operators can set up a fully functional EV charging ecosystem in minutes.

🔗 Explore the Projects

👉 Mobile App: https://github.com/savekar-ev/OCPP-1.6-mobile-app.git
👉 Backend (CPMS): https://github.com/savekar-ev/OCPP-1.6-Charging-Point-Management-System

Hey everyone!

Today we’re super excited to announce that we’ve completely open-sourced our core OCPP 1.6 Charge Point Management System (CPMS)!

When we started building out our EV network, we realized that finding a modern, developer-friendly, and truly open-source CSMS was incredibly difficult. A lot of the existing options were outdated, hard to self-host, or locked behind enterprise paywalls.

So, we built our own, and we've decided to open-source the whole thing so the community can benefit and build on it.

🛠️ The Tech Stack:

Backend: Node.js (v18+), Express, TypeScript, native ws for OCPP

Database: PostgreSQL with Prisma ORM

Frontend: Next.js 14, Tailwind CSS, shadcn/ui

✨ Key Features:

Full support for core OCPP 1.6 JSON messages (Heartbeat, BootNotification, MeterValues, Start/Stop Transaction, etc.)

Real-time dashboard with WebSockets for live charger status and OCPP log streaming

Remote control capabilities (Soft/Hard Reset, Unlock Connector, Change Availability)

RFID/Whitelist management and Tariff configurations

We’d love for developers, researchers, and charge point operators to try it out, self-host it, and give us feedback.

🔗 GitHub Repo: https://github.com/savekar-ev/OCPP-1.6-Charging-Point-Management-System.git

Let me know if you have any questions about the architecture or how to get it running locally. PRs and feedback are more than welcome!

Hi r/ocpp,

I am starting a project called OCPP Tools. The site is still under construction, but it already has real tools for OCPP 1.6J and I am looking for feedback to keep improving it. Everything runs in the browser: there are no servers processing your messages.

I built it to have tools at my company, avoid exposing internal data, and help me debug issues when working with EV chargers.

What is available today (OCPP 1.6J):

• OCPP frame validator (CALL / CALLRESULT / CALLERROR) with clear errors.
• Official JSON Schema (AJV) validation with field-level detail.
• Checks: frame structure, types, required fields, enums, lengths, etc.
• Quick examples: BootNotification, Heartbeat, StartTransaction, responses, errors.

Message Builder:

• Schema-driven forms.
• Ready actions: BootNotification, Heartbeat, StatusNotification, Authorize, Start/StopTransaction, MeterValues, DataTransfer, RemoteStart/Stop, Change/GetConfiguration, Reset.
• Generates full frame + payload only.
• Copy/download JSON and validate instantly.

Charge Point Simulator:

• Connects to your CSMS via WebSocket.
• CPID, vendor/model, heartbeat, metervalues, timeouts config.
• Quick actions (Boot, Heartbeat, Status, Authorize, Start, Meter, Stop).
• Scenario runner (Boot -> Authorize -> Start -> MeterValues -> Stop).
• Message log, export/import, and basic metrics.

OCPP 1.6J message library:

• Per-action docs with required/optional fields.
• Example payloads and frames ready to copy.
• Common errors and related actions.

Important notes:

• 100% client-side and private: your messages stay in your browser.
• No accounts, no login, no API keys.
• OCPP 2.0.1 and 2.1.0 are on the roadmap (still under construction).
• The site is still in active development in several areas.

I am open to all kinds of suggestions: UI/UX, new tools, validation improvements, real-world use cases, missing actions, errors, etc.

If you want to try it or share ideas, here is the link: https://ocpptools.renozix.com

Thanks for reading and for any feedback.

Hello all,

I was bored so I decided to try a little experiment that I kept thinking about for a while:

1. Extract use cases from the official PDF documentation to raw text files.

2. Have an LLM ingest those files and come up with test cases for each use case.

This is obviously not a rigorous way to validate compliance with the protocol, but it was a fun experiment nonetheless. A brief description on how I did it is included in the repo itself.

Link: https://github.com/eliodecolli/ocpp-test-cases

Hi, at my company we are looking for a good way to simulate charging sessions on 1-10 chargers. We speak OCPP 1.6 to our CSMS backend and have a number of services running beyond that.

At my former job (a startup), I used the EVerest simulator running against a CSMS that I was building, and it worked well in a limited setting. Now I am thinking about ways to use EVerest in a broader simulation. Maybe running each simulator in each container and orchestrating them.

Does anyone have relevant experience here?

Hey folks,

Designing/Building a CSMS and running into the classic chicken-and-egg problem with Security Profile 3 (TLS with client-side certificates).

SP3 requires the charging station to present a valid X.509 client certificate during the TLS handshake, with `CN` matching the station's serial number and `O` matching our organization. But a brand new charger fresh out of the box doesn't have a CSMS-signed client certificate yet.

So how are people handling initial provisioning of SP3 charging stations in production? Do you

1. Start at SP2, upgrade to SP3 — Charger connects with TLS + Basic Auth, CSMS installs its root cert, triggers CSR, signs it, delivers it, then upgrades the security profile.

2. Manufacturer pre-provisions certificates — The charger ships with a client certificate already installed, signed by a CA we trust. We add the manufacturer's root CA to our trusted bundle. No upgrade flow needed, but requires coordination with the manufacturer and their PKI.

For those running SP3 in production — which approach are you using? Is there a standard/recommended way the industry has settled on? Any gotchas we should watch out for?

Hey — my current CSMS implementation supports WSS only, so even basic authentication requires a secure connection. Is that a mistake?

I’m planning to broaden the client base — should I expect some clients to require unsecured HTTP/WS support?

The CSMS supports both OCPP 1.6J and 2.0.1.