How Does Weidmüller Weidos Actually Use the W5500's TOE? — Analyzing the Official Software Repository

TL;DR: Weidos doesn't use the W5500 as a plain Ethernet PHY/interface. Its official Ethernet.h-based library talks directly to the W5500's hardware TCP socket (TOE). On top of that, the official ModbusTCP_Master example follows an EthernetClient → W5500 hardware socket → TOE path — confirmed at the code level.

Overview

In our previous WIZnet Maker post, we confirmed that Weidmüller Weidos is an industrial DIN-rail IoT controller combining an ESP32 with a WIZnet W5500, and that product documentation and manuals show the W5500 connected to the ESP32 over SPI. At the time, however, we hadn't found the actual software that controls the W5500.

This time we went straight to Weidmüller's official Weidos ESP32 Arduino Core/BSP repository. The short version: Weidos genuinely uses the W5500's hardwired TCP/IP stack and hardware sockets — its TOE (TCP/IP Offload Engine) — at the code level. And through the official ModbusTCP_Master example, we could trace the full path showing how the industrial Modbus TCP protocol runs on top of that TOE.

What's New Compared with the Previous Post?

The previous post, built on product and hardware documentation, established:

• The W5500 is onboard
• It's connected over SPI
• The overall structure of an industrial controller
• Potential support for Modbus TCP and other IoT protocols
• LoRa / NB-IoT product variants

This time, by digging into the official software repository, we newly confirmed:

• The W5500 TOE is genuinely used — the hardware TCP/UDP socket is used directly, rather than handing TCP/IP processing off to the ESP32's lwIP stack.
• The W5500 is actually wired into the Weidos BSP — the board-specific ETHERNET_CS pin is used directly by the official Ethernet example.
• Modbus TCP runs on top of the W5500 TOE — the ModbusTCPClient → EthernetClient → W5500 Hardware Socket path is verifiable in code.
• It can scale into a multi-network industrial platform — combined with RS485, LoRa, and NB-IoT, the W5500 can serve as the foundation for a local wired industrial network.
• It's part of an open development ecosystem — the dual Arduino/PlatformIO distribution structure, an Azure IoT integration experiment, and real industrial application examples (waste processing, HTTP latency measurement) show the W5500 being reused as a common building block across multiple projects.

Key Finding: Weidos Genuinely Uses the W5500's TOE

Physically wiring a W5500 to an ESP32 doesn't automatically mean the TOE is in use. In Espressif's typical W5500 Ethernet driver approach (based on ETH.h), the ESP32's lwIP stack handles TCP/IP processing, and the W5500 acts closer to an Ethernet PHY/MAC interface.

Weidos's official Ethernet example, by contrast, is built on Ethernet.h, not ETH.h.

#include <Ethernet.h>

Ethernet.init(ETHERNET_CS);
Ethernet.begin(mac);

On this path, EthernetClient isn't an ESP32 software socket — it talks directly to the W5500's hardware TCP socket. The full stack looks like this:

Application
    ↓
EthernetClient / EthernetUDP
    ↓
W5500 Hardware Socket
    ↓
SPI
    ↓
W5500 TOE
    ↓
Ethernet

In other words, Weidos doesn't treat the W5500 as a plain Ethernet interface — it offloads TCP/UDP/IP processing to the W5500 itself.

Code-Level Evidence

The Weidos repository defines the Ethernet Chip Select as a board-specific pin (ETHERNET_CS), and the official Ethernet example uses it directly.

Weidos BSP
    ↓
ETHERNET_CS
    ↓
Ethernet Library
    ↓
SPI
    ↓
W5500

Internally, the Ethernet library detects the W5500, creates a hardware socket, and configures TCP mode. Connection state is also checked through the W5500's socket status register rather than the ESP32's lwIP. Data transfer likewise doesn't involve the ESP32 assembling or parsing raw Ethernet frames — application payloads are exchanged directly with the W5500's internal TX/RX socket buffers.

Looking purely at the software path, whether the TOE is in use is unambiguous at the code level.

Industrial Protocol: Modbus TCP

The most notable finding in this analysis is that the Weidos repository ships the ArduinoModbus library and an official Modbus TCP example (ModbusTCP_Master).

The example wires up the Ethernet transport like this:

EthernetClient ethClient;
ModbusTCPClient modbusTCPClient(ethClient);

That is, Modbus TCP's underlying transport is EthernetClient, and EthernetClient in turn uses the W5500's hardware socket. The full path:

ModbusTCPClient
       ↓
EthernetClient
       ↓
W5500 Hardware TCP Socket
       ↓
W5500 TOE
       ↓
TCP Port 502
       ↓
PLC / Modbus TCP Device

The official example goes beyond a simple TCP connection test — it actually works with real Modbus data models:

• Coil
• Discrete Input
• Holding Register
• Input Register

In short, this goes further than "the W5500 can do Ethernet." It's code-level evidence of how a Modbus TCP application on an industrial ESP32 controller actually connects to the W5500's TOE.

Why TOE Matters in an Industrial Controller

In this architecture, the roles of the ESP32 and the W5500 are cleanly separated.

       Industrial Controller
               │
      ┌───┴───┐
      │                            │
 Application          Networking
      │                            │
    ESP32                 W5500
      │                            │
Control / I/O         TCP/IP TOE
                                      │
                                 Ethernet

The ESP32 stays focused on application and control logic, while the W5500 owns the entire wired network transport stack. This division of labor shows that the W5500 TOE isn't limited to maker projects — it's a pattern that fits real industrial DIN-rail controllers, too.

Beyond Modbus TCP

Modbus TCP is the industrial protocol most clearly confirmed at the code level in this repository, but the W5500's TCP/UDP socket structure isn't tied to any single protocol. Plenty of other applications can be layered on the same Ethernet transport:

                 ┌─ Modbus TCP
                 ├─ HTTP / REST
Application ─────┼─ MQTT
                 ├─ Custom TCP
                 └─ Custom UDP
                        │
                        ▼
                    W5500 TOE

Existing Weidos product materials already mention HTTP, HTTPS, MQTT, MQTTS, and Modbus TCP as possible use cases. That said, of everything in this newly published repository, Modbus TCP is the one whose W5500 path is confirmed most clearly at the code level.

Multi-Connectivity Industrial Platform

The Weidos lineup isn't Ethernet-only — LoRa and NB-IoT variants also exist, and the repository analyzed here serves as the common Arduino Core/BSP for the entire Weidos ESP32 family.

That makes the W5500 a component responsible for local wired networking within a broader industrial connectivity platform.

                Local Industrial Network
                         │
                    Modbus TCP
                         │
                      W5500
                         │
Industrial I/O ─────── ESP32
                         │
                    LoRa / NB-IoT
                         │
                  Remote / Cloud

• W5500 → local industrial Ethernet
• LoRa / NB-IoT → remote connectivity

Public materials alone aren't enough to confirm that this kind of multi-network setup is actually used simultaneously in production. For now, it's more accurate to describe it as an expansion capability the platform provides, rather than a confirmed deployment pattern.

Weidos as an Open Industrial Development Ecosystem

What's interesting here isn't just how the W5500 is used — it's also how Weidmüller opens up and extends the Weidos lineup for developers.

Looking at the public WeidmullerSA GitHub organization, Weidos isn't a single, finished industrial controller product — it's closer to a small open development ecosystem designed to expand across multiple dev environments and applications. As of this writing, the organization has 12 public repositories, which break down roughly as follows:

Two things stand out in this list.

First, Arduino and PlatformIO are both officially supported at the same time. For the same Weidos ESP32 hardware, the Arduino Core/BSP, PlatformIO platform, PlatformIO package, and PlatformIO example project are each maintained as separate repositories, and registered with the Arduino Boards Manager through Weidos-index's index.json. The MKR1010 line repeats the exact same four-repository pattern (Core/BSP, platform, package, example), suggesting this is Weidmüller's standard distribution model rather than a one-off.

Second, the published projects lean toward "experiments/measurements" rather than polished example apps. WeidosESP32-EnergyManagement-AzureSDK-pruebas has "tests" baked right into its Spanish name, hinting the Azure IoT SDK integration was still experimental. P00010-WeidosMKR1010-S-SF2I is, as its name suggests, a project that measures Ethernet HTTP latency between a Weidos MKR1010-A1 and a local server — circumstantial evidence that the W5500 TOE-based hardware socket structure we confirmed in this analysis has actually been performance-tested enough to be worth measuring.

Roughly diagrammed, Weidos's distribution model looks like this:

Industrial Hardware
        ↓
Open BSP / Core (Arduino + PlatformIO)
        ↓
Libraries & Example Projects
        ↓
Modbus TCP / RS485 / LoRa / NB-IoT
        ↓
Cloud Integration Experiments / Industrial Application Trials

The advantage of this structure is that users aren't locked into a single firmware. Weidmüller publishes the hardware platform and a base software stack (Core/BSP, PlatformIO package, example project), and leaves it open for users to build the industrial application they actually need on top of it. Each repository structurally accepts GitHub Issues and Pull Requests, so bug reports and community contributions are possible in principle. That said, as of this writing most repositories still sit at zero stars, forks, and issues — external contribution doesn't appear to be particularly active yet.

Within this ecosystem, it's more accurate to think of the W5500 not as one project's Ethernet feature, but as a wired networking building block shared across the entire Weidos ecosystem. Modbus TCP uses this path:

Industrial Application
        ↓
ArduinoModbus
        ↓
EthernetClient
        ↓
W5500 TOE

But on the same ESP32 platform, developers can also build a waste-processing industrial application like P00014-WeidosESP32-SA-WPT, or bolt on other connectivity options like LoRa or NB-IoT.

Put together, Weidos isn't just "an industrial controller with a W5500 in it." It's more accurate to describe it as:

A platform that connects industrial hardware to an open Arduino/PlatformIO software ecosystem, extensible with Modbus TCP and a range of other protocols and connectivity options.

That framing also broadens what the W5500 means here. It's not tied to a single Modbus TCP application — within this open development ecosystem, it's an Ethernet TOE component that gets reused across different industrial applications, from energy management to waste processing to latency measurement.

Conclusion

Our earlier post confirmed that Weidos is an industrial ESP32 controller using a W5500 — but nothing more. This time, by analyzing the official software repository, we were able to confirm exactly how the W5500 is used at the code level.

Weidos doesn't treat the W5500 as a plain Ethernet interface. It genuinely uses the hardware TCP/IP socket and TOE, with an official Modbus TCP example wired directly on top.

The whole picture, summarized in one line:

Industrial I/O
      ↓
ESP32 Application
      ↓
Modbus TCP
      ↓
W5500 TOE
      ↓
Industrial Ethernet

Factor in that RS485, LoRa, and NB-IoT can all be added to the mix, and the W5500 stops looking like a plain RJ45 interface — it becomes the TCP/IP offload engine responsible for local wired networking in a multi-connectivity industrial controller. This is a solid software-architecture example of what the W5500 TOE can do inside a real industrial ESP32-based controller.

https://www.weidmuller.ca/en/products/connectivity/connectors/single_pair_ethernet.jsp

FAQ

Q. How do you tell whether Weidos is using the W5500's hardware socket versus the ESP32's lwIP? A. The library tells you. ETH.h-based code is the typical Ethernet PHY approach, where lwIP handles TCP/IP. Weidos's Ethernet.h + EthernetClient approach is the TOE path, talking directly to the W5500's hardware TCP socket.

Q. Do other protocols work the same way besides Modbus TCP? A. Modbus TCP is the only one confirmed at the code level in this repository, but anything built on EthernetClient/EthernetUDP — HTTP, MQTT, and other TCP/UDP-based protocols — can run over the same TOE path structurally.

Q. Is an official RS485 (Modbus RTU) ↔ Modbus TCP gateway provided? A. The repository includes both ArduinoRS485 and ArduinoModbus, so the building blocks are there. But there's no evidence of a complete, officially provided gateway example application.

Q. Does the same W5500 TOE structure apply to the LoRa/NB-IoT variants? A. Since this repository is a common BSP for the whole Weidos ESP32 family, the Ethernet path itself is likely the same. Whether the W5500 is used simultaneously alongside LoRa/NB-IoT on those variants, though, can't be confirmed from public materials alone.

Q. Is this an active, community-driven open-source project? A. The repositories are structurally open (Issues, Pull Requests), but as of this writing most sit at zero stars, forks, and issues. It reads more as an open distribution model than an actively contributed-to community project — at least for now.

Related WIZnet Maker Projects

• How Does Weidmüller Weidos Use W5500 Ethernet for Open-Source Industrial IoT? — The prequel to this analysis, covering Weidos's hardware setup and what product documentation alone could confirm.
• Which Industrial Protocols Can a W5500 and ESP32-S3 Detect on an OT Network? — Same W5500 + ESP32 pairing, opposite purpose: an OT security project that bypasses the TOE and watches Layer 2 traffic in promiscuous mode.
• PicoArtnet2DMX — Uses the W5500's hardware socket for real-time UDP (Art-Net) traffic — a useful reference point for TOE-based low-latency application design.
• LamePod — A design that runs media, control, and maintenance traffic over a single W5500 wired interface — worth comparing against Weidos's multi-service Ethernet structure.