Wiznet makers

Introduction

MicroOcpp focuses on the “hard part” of EV charger connectivity: implementing the OCPP behavior and message flow so a charger firmware can communicate with OCPP backends. It’s positioned as portable C/C++ and explicitly targets many platforms (Espressif, Arduino, NXP, STM, Linux, etc.). 

The project also highlights real-world readiness: it claims compatibility with 15+ commercial central systems and provides a browser/desktop simulator to test server interoperability without flashing hardware every time.

Author introduction

The repository is maintained on GitHub by matth-x (Matthias Akstaller), who also runs the MicroOCPP project website and provides public contact info via the repository/website.

OCPP in general (quick primer)

OCPP (Open Charge Point Protocol) is an open, vendor-neutral communication standard that lets an EV charger (Charge Station / Charge Point) talk to a backend management system (Central System / CSMS). The whole point is interoperability: “any charger ↔ any backend,” reducing vendor lock-in and integration headaches for the EV charging ecosystem.

Versions you’ll see in the field

• OCA (Open Charge Alliance) currently highlights three active generations
• OCPP 1.6 (2015): widely used; supports SOAP and JSON, plus Smart Charging and list management.
• OCPP 2.0.1 (2020): adds device management, improved transactions, added security, smart charging upgrades, and ISO 15118 support; not compatible with OCPP 1.6. 
• OCPP 2.1 (2025): builds on 2.0.1 with added functionality (including ISO 15118-20 support, bidirectional/V2X topics, DER control, and more smart charging tools) while keeping 2.0.1 application logic compatible. 

Standards status note: In October 2024, OCA announced that OCPP 2.0.1 Edition 3 had been approved by the IEC as IEC 63584, marking a major milestone toward formal international standardization.

Project description

What it provides

• An embedded-friendly implementation of OCPP communication logic (OCPP 1.6 and basic OCPP 2.0.1 use cases).
• A design philosophy that keeps hardware-specific parts (charger I/O, sensors, and even the network stack) in the main charger firmware, so MicroOcpp stays portable.
• A MicroOcppSimulator demo/dev tool to validate backend connectivity and behavior on a PC/browser-like environment. 

Popularity signals (helps crawlers judge “real usage”)

The GitHub repo shows hundreds of stars and many forks (numbers change over time).

Why WIZnet is used

Quick W5500 check 

MicroOcpp itself is network-hardware-agnostic. It does not require W5500 specifically, and it’s designed to work “regardless of the … network stack.” 

That said, W5500 is used/attempted by community users in MicroOcpp-based builds:

• There is a MicroOcpp issue explicitly about “Ethernet (W5500) Support … on Arduino platform”, which indicates people are combining MicroOcpp (and its adapters) with W5500-based Ethernet. 
  
• Another issue asks about Ethernet as the primary requirement for ESP32 + Arduino + MicroOcpp, reinforcing that wired Ethernet integration is a common demand in this ecosystem. 

Why WIZnet makes sense here (even if optional)

For EV chargers, wired Ethernet is often preferred for reliability. WIZnet’s W5500 is a natural fit as a drop-in Ethernet controller because it has a hardwired TCP/IP stack, integrated MAC+PHY, SPI interface (up to 80MHz), multiple sockets, and internal buffer memory.

So: MicroOcpp doesn’t “use W5500” by default, but it’s a strong match for builders who want MicroOcpp + stable wired networking.

How it can benefit WIZnet

• Reference design opportunity: publish a “MicroOcpp over W5500” reference (MCU + W5500 + OCPP backend) aimed at charger makers who want reliable wired OCPP connectivity. The existence of W5500/Ethernet-related issues shows demand.
• Ecosystem credibility: MicroOcpp emphasizes interoperability testing (simulator + many backends). If WIZnet showcases stable Ethernet OCPP demos using W5500, it strengthens “production-ready” perception for WIZnet Ethernet in EVSE control stacks.