Wiznet makers

About Author

Project Intro

SensorsIot/OCPP-ESP32-Server is an ESP32 firmware project that implements an OCPP 1.6J “Central System” (i.e., the server side) to communicate with EV chargers (“wallboxes”) over WebSocket/OCPP, then bridge data and control into an MQTT-based energy management system.

The repository’s architecture targets a practical “edge gateway” deployment:

• A wallbox talks OCPP to the ESP32 over Ethernet (WebSocket).
• The ESP32 can boot into a Wi-Fi AP captive portal for configuration, then operate in a “normal” mode for day-to-day uptime.
• It’s designed to grow into advanced site features like smart charging policies and phase switching (roadmapped in phases).

Why W5500 is used here (and when it’s the right choice)

This repo explicitly supports two Ethernet paths:

1. WT32-ETH01 (LAN8720 RMII) as the recommended “integrated Ethernet” board
2. ESP32 + W5500 (SPI Ethernet) as an external module option

So the “why W5500” story is mostly about deployment flexibility + wired reliability:

1) OCPP stability is a networking problem first

OCPP-J 1.6 defines the Central System as a WebSocket server with the charger connecting as a WebSocket client. That means long-lived TCP connections, keep-alives/heartbeats, and clean reconnection behavior matter in the real world. 
Wired Ethernet is often the simplest way to avoid Wi-Fi congestion, roaming weirdness, and RF dead zones in garages, basements, or parking structures.

2) SPI Ethernet lets you add RJ45 to “any ESP32 board”

If you’re not using an ESP32 module with native RMII PHY (like WT32-ETH01), W5500 is a common way to add 10/100 Ethernet over SPI with minimal PCB complexity (SPI + INT + CS + power). The W5500 itself supports up to 80 MHz SPI and exposes 8 hardware sockets with on-chip buffering.

3) Important nuance (ESP-IDF driver behavior)

Espressif’s W5500 Ethernet driver documents that the W5500’s “hardwired TCP/IP stack” is not used in the ESP driver (ESP-IDF typically uses its own TCP/IP stack). In practice, W5500 is often used as a reliable SPI-Ethernet interface while ESP-IDF handles TCP/WebSocket above it. 
That’s still valuable here: the project gets wired link robustness and predictable network behavior for OCPP sessions, without requiring a specialized OCPP stack rewrite.

Technical Analysis (what’s actually in the repo)

From the repository README, the firmware is organized into clear “system blocks” that match typical production gateways:

• Network bring-up & configuration
  • ethernet_manager/ is explicitly labeled for W5500 SPI Ethernet
  • wifi_manager/ + captive_portal/ + dns_server/ provide the “AP config mode” experience (captive portal + DNS redirect) 
    This pattern is common in devices that must be installable by field technicians without serial cables.
• Protocol layer
  • ocpp_server/ is the OCPP 1.6J WebSocket server component (Central System role). 
    The project status table indicates BootNotification and Heartbeat are already implemented (a meaningful milestone because they validate core connectivity + keep-alive flow).
• System integration
  • mqtt_manager/ is the bridge to an “energy manager” upstream (planned to be Wi-Fi STA in the future architecture).
  • ota_manager/ is planned for OTA updates; the repo already frames a web-based firmware upload approach with rollback as a feature target.
• EVSE-specific control
  • phase_control/ + GPIO components exist for phase switching and safety interlocks (the README explicitly notes never switching relays under load).

In short: this is not “just OCPP.” It’s structured like a deployable edge appliance: OCPP session handling on wired Ethernet, local captive portal provisioning, and an MQTT bridge to integrate with site power logic.

Architecture Explanation (focused on W5500 path)

Because OCPP is WebSocket-based and benefits from stable links, the W5500 option fits the project’s intended “professional gateway” role:

Data path (runtime):

1. Wallbox → (Ethernet) → ESP32
   1. Wallbox opens a WebSocket connection to the ESP32 (Central System).
2. ESP32 parses OCPP messages
   1. BootNotification and Heartbeat are already in the completed phase list.
3. ESP32 → MQTT → Energy Manager
   1. Site automation can consume status, meter values, and apply policies (smart charging / phase switching are on the roadmap).
4. Why W5500 helps this flow:
   1. It provides a widely available SPI Ethernet hardware path when an RMII PHY board isn’t an option.
   2. It aligns with ESP-IDF’s Ethernet framework (external SPI-Ethernet modules are a first-class supported category).
   3. It improves “installer reality”: RJ45 + fixed wiring beats troubleshooting Wi-Fi SSIDs on-site.

Related video

FAQ

1) Why use W5500 in an ESP32 OCPP gateway?

For OCPP 1.6J, you’re maintaining a WebSocket session where jittery Wi-Fi or captive-network quirks can look like protocol failures. W5500 gives you a straightforward wired Ethernet option over SPI (up to 80 MHz), and the chip supports multiple hardware sockets with on-chip buffering. Even when ESP-IDF doesn’t use W5500’s built-in TCP/IP stack, it still delivers a robust RJ45 link for long-lived sessions.

2) How does W5500 connect to ESP32 in this project?

The repo lists a dedicated ethernet_manager/ component for W5500 SPI Ethernet, meaning the intended interface is SPI (SCLK/MOSI/MISO/CS plus interrupt and power). ESP-IDF supports external SPI-Ethernet modules through a consistent Ethernet API layer, so the application can treat W5500 as a network interface while keeping OCPP/MQTT logic unchanged above it.

3) What role does W5500 play specifically in OCPP-ESP32-Server?

W5500 is one of the supported “wired front-ends” for the gateway. In the documented architecture, the wallbox connects to the ESP32 over Ethernet using WebSocket/OCPP, with the ESP32 acting as the Central System server. W5500 enables that Ethernet link on boards that don’t have an RMII PHY, helping keep OCPP connectivity stable while the firmware focuses on protocol handling, captive-portal provisioning, and MQTT bridging.

4) Can beginners follow this project if they’re new to W5500?

Yes—but it’s best approached as two layers. First, bring up Ethernet (WT32-ETH01 or ESP32+W5500) using ESP-IDF’s Ethernet framework, confirm IP connectivity, then move upward to OCPP WebSocket behavior (BootNotification/Heartbeat). The repo’s componentized layout (network managers, captive portal, OCPP server, MQTT manager) is “learnable” because each subsystem is isolated, which is ideal for incremental debugging.

5) W5500 vs LAN8720 (WT32-ETH01) vs Wi-Fi: which is better here?

WT32-ETH01 (LAN8720 RMII) is “simpler” if you can standardize on that board—fewer SPI timing/interrupt variables and typically higher raw throughput. W5500 is ideal when you must retrofit Ethernet onto an ESP32 design via SPI and still want wired reliability. Wi-Fi is convenient for provisioning, but for long-lived OCPP WebSocket sessions in noisy RF environments, wired Ethernet usually reduces operational risk.