Wiznet makers

Higenis HG-ESP32-S3-RLY4-PRO + W5500: an ESP32-S3 industrial controller that drives real relays over UDP via SPI Ethernet.

Higenis developed the HG-ESP32-S3-RLY4-PRO, an industrial control board based on the ESP32-S3. In a blog post published on 15 August 2026, the author (chandong83) demonstrated remote relay control over Ethernet by connecting a WIZnet W5500 module to that board over SPI.

This is more than a standard ESP32 development board. It integrates four high-current relay channels, two RS485 interfaces, CAN, USB-C, OLED connectivity, external GPIO, a WS2812 status LED, Wi-Fi, and Bluetooth into a single control platform, running from a single 12 V supply.

The board is intended for applications such as smart farming, pump control, lighting control, heaters, industrial equipment, and remote power control.

The architecture of the Ethernet demo can be simplified as follows.

PC / Controller
        │
        │ UDP over Ethernet
        ▼
      W5500
        │
        │ SPI
        ▼
    ESP32-S3
        │
        ├─ Relay 1
        ├─ Relay 2
        ├─ Relay 3
        └─ Relay 4

W5500       → Wired Ethernet / TCP/IP communication
ESP32-S3    → Application logic / Relay control
Relay Board → Physical load switching

Why Add W5500 to an ESP32-S3 That Already Has Wi-Fi?

This is one of the most interesting aspects of the project.

The ESP32-S3 already includes Wi-Fi. Even so, Higenis added a separate wired Ethernet path using the W5500.

A basic ESP32-S3 industrial controller might look like this.

ESP32-S3
    │
    ├─ Wi-Fi
    ├─ Bluetooth
    ├─ RS485
    ├─ CAN
    └─ Relay

The Higenis demo adds one more network path.

ESP32-S3
    │
    ├─ Wi-Fi
    ├─ Bluetooth
    │
    └─ SPI
         │
       W5500
         │
      Ethernet

The important point is not that Ethernet replaces Wi-Fi. Instead, this project shows that an MCU with built-in Wi-Fi may still benefit from a dedicated wired network interface.

For fixed industrial equipment, wired Ethernet can be useful when a device is installed in a cabinet, machine room, production line, or other location where network cabling is already available. Wi-Fi may still be convenient for configuration, maintenance, or temporary access.

The two interfaces therefore do not have to compete with each other.

The Higenis UDP Relay Demo

The Higenis example is built with Arduino IDE. The environment published with the demo is as follows.

The data flow is straightforward.

Network Command
      ↓
UDP Packet
      ↓
W5500
      ↓
SPI
      ↓
ESP32-S3
      ↓
Relay Control

This simplicity is useful. The project demonstrates the basic process of adding wired Ethernet to an existing ESP32-S3 control platform without requiring a cloud platform or complicated backend infrastructure.

The command set, read from the published source

The archive published with the post (Relay_4_pro_demo.zip) contains a small text protocol in src/W5500Network.cpp. The device listens on UDP port 5000 and answers every command it receives.

Two details are worth noting, because they are easy to assume incorrectly.

Every command is answered. processUdpPacket() follows a receive → normalise → execute → reply sequence, and the reply carries the action that was performed.

STATUS is a real readback, not a cached value. The reply is built from relayIsOn(), which reads the pin itself:

bool relayIsOn(uint8_t relay_number)
{
  return digitalRead(relay_gpio_pins[relay_index]) == HIGH;
}

So a controller can write a relay, read the reply, and then confirm the physical output with a separate STATUS query — the same three steps a Modbus TCP master would use.

Where Can This Architecture Be Used?

The hardware combination can be expanded well beyond a simple relay demo.

1. Remote Relay I/O

The most direct use case is remote output control.

Control PC / PLC
        │
     Ethernet
        │
      W5500
        │
    ESP32-S3
        │
    Relay x4

This can be used for pumps, lighting, heaters, valves, or general industrial equipment. The current demo uses UDP, but the same hardware could later support HTTP, MQTT, or Modbus TCP.

2. Modbus TCP Remote I/O

The four relays can also be mapped directly to Modbus coils. Using the conventional Modbus documentation numbering, where coils start at 00001 and the wire carries a zero-based address:

Coil 00001 (address 0) → Relay 1
Coil 00002 (address 1) → Relay 2
Coil 00003 (address 2) → Relay 3
Coil 00004 (address 3) → Relay 4

The resulting architecture would be:

PLC / SCADA
      │
 Modbus TCP
      │
    W5500
      │
  ESP32-S3
      │
 Modbus Coil
      │
   Relay x4

This is a natural path from a simple UDP demo to a practical industrial Remote I/O device.

3. Modbus TCP to RTU Gateway

The HG-ESP32-S3-RLY4-PRO includes two RS485 channels. This makes it possible to build a gateway between Ethernet and serial field devices.

PLC / SCADA
      │
 Modbus TCP
      │
    W5500
      │
  ESP32-S3
      │
    RS485
      │
 Modbus RTU
      │
Inverter / Sensor / Meter

At this point, the board becomes more than a relay controller. It becomes a small industrial protocol gateway.

4. Ethernet to CAN Gateway

The board also includes a CAN transceiver.

PC / Server
     │
 Ethernet
     │
   W5500
     │
 ESP32-S3
     │
    CAN
     │
CAN Device

Potential applications include vehicle testing, motor controllers, CAN diagnostics, and data acquisition.

What UDP Still Does Not Give You

Because the demo already answers every command and can report the physical output state, the usual first criticism of a UDP control demo does not apply here. What remains is narrower, and worth stating precisely.

A lost datagram is detectable but not recovered. If the sender transmits

R1 ON

and no reply arrives, the sender knows something went wrong — but UDP will not retransmit. Any retry policy has to be written by the sender.

The reply can be the part that is lost. The relay may have switched while the acknowledgement disappeared, so a missing reply does not mean the command failed. A blind retry can therefore repeat an action that already happened.

There is no sequence number. Duplicated or reordered datagrams cannot be distinguished from new commands, which matters once a retry policy exists.

There is no authentication. Anything that can reach the device's address on port 5000 can switch a relay.

This is where a protocol such as Modbus TCP differs. It runs over TCP, so delivery and ordering are handled below the application, every request carries a transaction identifier, and a refusal arrives as a response rather than as silence:

Write Coil
    ↓
Response
    ↓
Read Coil
    ↓
State Confirmation

The Higenis demo already implements the shape of that exchange over UDP. Moving to Modbus TCP would mostly be a matter of letting the transport carry the guarantees the application currently has to arrange for itself — and of speaking a protocol that a PLC or SCADA package already knows.

Connecting This Project to WIZnet's ESP32-S3 Platform

This Higenis project connects naturally to WIZnet's current ESP32-S3 development direction. The Higenis implementation can be summarized as:

Existing ESP32-S3 Controller
          │
          │ Ethernet required
          ▼
External W5500 Module
          │
          ▼
Arduino Ethernet Library
          │
          ▼
UDP Application

WIZnet is generalizing the same hardware pattern through its ESP32-S3 platform and the wsm_driver ESP-IDF component, which supports the ESP32-S3 with both the W5500 and the W6300. The W5500 uses standard SPI; the W6300 uses QSPI in either single 1-bit or quad 4-bit mode.

The board targets currently selectable in wsm_driver are:

Selecting a board sets both the chip and its pins, because choosing the chip alone cannot express the wiring — a Dev-kit and a SoM can carry the same chip on different GPIOs. For wiring that no listed board covers, the Custom option makes the pin fields editable.

The direction is to move from:

ESP32-S3 + external Ethernet module

toward:

ESP32-S3
   +
W5500 / W6300
   +
Reusable driver
   +
Reusable applications

What wsm_driver Adds

The Higenis demo uses the Arduino Ethernet library. That approach is convenient for rapidly adding W5500 Ethernet to a sketch.

Larger applications become more complex when Wi-Fi and Ethernet must be used together, because in Arduino-style development the two paths use different classes:

Wi-Fi           → WiFiUDP
W5500 Ethernet  → EthernetUDP

The names look similar, but they are different types. An application that must serve on both paths ends up with two copies of its networking code.

wsm_driver takes a different approach in ESP-IDF.

        Application
             │
      BSD socket API
             │
         wsm_driver
      ┌──────┴──────┐
      │             │
     TOE      esp_eth MACRAW
      │             │
 chip runs      ESP32-S3 LwIP
 the stack      runs the stack
      │             │
  W5500/W6300   W5500/W6300

The driver handles the common low-level work:

• W5500 / W6300 initialization
• SPI or QSPI transport configuration
• RESET pin control
• PHY link checking
• ioLibrary callback registration
• network backend selection

Choosing Between Hardware TCP/IP and LwIP

wsm_driver supports two networking backends, and both work with either chip.

TOE mode — the chip runs the stack

ESP32-S3
    │
 Application
    │
 BSD socket (with --wrap) or ioLibrary API
    │
W5500 / W6300
    │
Hardware TCP/IP

esp_eth MACRAW + LwIP mode — the ESP32-S3 runs the stack

ESP32-S3
    │
   LwIP
    │
 MACRAW (hardware socket 0)
    │
W5500 / W6300
    │
 Ethernet

The two are not simply fast and slow versions of each other. They differ in what the socket API can do:

For a relay controller that answers a handful of commands, TOE mode is a comfortable fit. For an application that needs TLS, many simultaneous connections, or select()-driven event loops, the LwIP backend is the one to choose. The application architecture stays the same either way.

Wi-Fi and Ethernet Can Coexist

Adding a W5500 or W6300 does not require removing Wi-Fi.

      ESP32-S3
          │
    ┌─────┴─────┐
    │           │
  Wi-Fi   W5500 / W6300
                │
             Ethernet

This enables dual-network application designs, for example:

Wi-Fi
→ Configuration
→ Web UI
→ Maintenance

Ethernet
→ Control
→ Modbus TCP
→ PLC / SCADA

How the two paths stay separate in one application

There is a detail here that is easy to miss. If the --wrap option is enabled, plain BSD socket calls are redirected to the WIZnet chip — so how does the same firmware still reach the Wi-Fi stack?

wsm_driver answers this with a small socket vtable published in include/net_sock_ops.h:

extern const net_sock_ops_t net_eth_ops;   /* redirected to the WIZnet hardware sockets */
extern const net_sock_ops_t net_wifi_ops;  /* bypasses the wrap, reaches the real LwIP */

An application receives one of these two vtables and calls ops->socket(), ops->bind(), ops->recv() and so on. The server logic above it does not change. The component's examples/modbus_tcp uses exactly this: one Modbus TCP server implementation, started twice, once with net_eth_ops and once with net_wifi_ops, serving on both interfaces at the same time.

This is the practical difference from the Arduino WiFiUDP / EthernetUDP split. The transport changes; the application does not.

What This Higenis Project Shows

If this project is viewed only as a “W5500 UDP relay demo,” it looks small. The broader architecture is more interesting.

Higenis already had an industrial controller based on the ESP32-S3 with Wi-Fi, RS485, CAN, and high-current relays. The W5500 was then added to give that controller a wired Ethernet path. The resulting pattern is:

Field Device
     │
Relay / RS485 / CAN
     │
  ESP32-S3
     │
   W5500
     │
 Ethernet
     │
PLC / PC / Server

This pattern aligns with the direction of WIZnet's ESP32-S3 platform.

User implementation          WIZnet platform

ESP32-S3 controller          ESP32-S3
       +                        +
External W5500               W5500 / W6300
       +                        +
UDP application              wsm_driver
                                +
                             Reusable applications

Higenis demonstrates how wired Ethernet can be added to an actual control product. WIZnet can generalize that pattern into a reusable development platform.

Possible Next Applications

The current UDP relay demo can be extended step by step.

Because the Higenis board already includes relays, RS485, and CAN, it is a suitable hardware platform for exploring many of these industrial networking applications.

Engineering Value and Source Limits

Three things are worth stating plainly, so that the demo is read for what it is.

The Ethernet module is connected with jumper wires. The demo uses a separate W5500 module and F/F jumper cables rather than an Ethernet controller placed on the board. That is fine for a demonstration and says nothing about the board itself, but it is not the same as a wired-Ethernet product.

The demo is Ethernet-only. The ESP32-S3-WROOM-1 module carries Wi-Fi and Bluetooth, but the published source does not use either. This is a single-path design, not a dual-network one, which is worth knowing before reading the hybrid section below as something the demo already does.

There is no authentication and no defined link-loss behaviour. Anything that can reach the device on UDP port 5000 can switch a relay, and the source does not define what the relays do if the network path disappears. For a board whose relays are rated by the manufacturer at up to 40 A contacts — with Higenis itself recommending 20 A or less per channel, depending on wiring, terminals, load type and environment — both points matter before this leaves a bench.

None of this is a criticism of the demo. It is published as a starting point, and as a starting point it is a good one: the command handling is clean, every command is answered, and the state readback reads the actual pin.

WIZnet User Curation Perspective

The most important part of this case is not simply that the W5500 was used.

An external developer built an industrial ESP32-S3 controller, kept the built-in Wi-Fi capability, and still added W5500 Ethernet for a real relay control demo. That leads to a useful question:

Why would an ESP32-S3 controller with built-in Wi-Fi add W5500 Ethernet?

There is no single answer. Some installations benefit from wired networking. Wi-Fi may still be useful for configuration or maintenance. The two interfaces may also be assigned different roles, or used together in a hybrid network design.

This is where the Higenis project connects to WIZnet's ESP32-S3 + W5500 / W6300 platform and wsm_driver. Higenis demonstrates the need at the application level. WIZnet can turn that repeated need into a reusable platform.

FAQ

Q1. Does the W5500 directly control the relays?

No. The W5500 handles Ethernet communication. The ESP32-S3 receives the command and controls the relay GPIOs.

Q2. Why use a W5500 if the ESP32-S3 already has Wi-Fi?

Wi-Fi and Ethernet suit different installation conditions. Ethernet can be useful for fixed industrial systems, while Wi-Fi may be convenient for installation, configuration, or maintenance. They do not have to be mutually exclusive.

Q3. Is UDP suitable for industrial relay control?

It can be, with work at the application level, and this demo does more of that work than most. It answers every command and provides a STATUS query that reads the relay pins directly. What UDP still does not provide is retransmission, sequence numbers to detect duplicates, or any authentication. For critical control, add those, or move to a protocol such as Modbus TCP where the transport handles delivery and ordering and a PLC already knows how to speak to the device.

Q4. What changes when using wsm_driver?

The component handles the common W5500 / W6300 integration work — SPI or QSPI transport, reset, PHY link state, ioLibrary callbacks, and backend selection — and lets the application use BSD socket-style networking. It supports both chips and lets the developer choose between hardware TCP/IP and LwIP. In TOE mode, BSD sockets are enabled through the --wrap option in menuconfig; without it the application calls the ioLibrary API directly.

Q5. Can Wi-Fi and Ethernet run at the same time?

Yes. The component publishes two socket vtables, net_eth_ops and net_wifi_ops, so one application can serve on both interfaces without duplicating its networking code. Automatic failover, however, is a separate application-level feature and should not be assumed simply because both interfaces exist.

Q6. Which network backend does the Higenis demo use?

The hardware TCP/IP path. The Arduino Ethernet library drives the W5500's own hardware sockets, so the chip runs the stack and the ESP32-S3's LwIP is not part of the data path. That is the same arrangement as wsm_driver's TOE backend, reached through a different API.

Q7. Does the demo use Wi-Fi and Ethernet together?

No. The published source contains no Wi-Fi, Bluetooth or LwIP code at all. The board is capable of it, but this demo is Ethernet-only. Dual-network operation is the next step described in this article, not something the demo already does.

Q8. Does TOE mode support TLS or select()?

No. TOE mode is IPv4 TCP and UDP only, limited to the chip's eight hardware sockets, and does not provide select() or poll(). Applications that need those should use the esp_eth MACRAW backend, where the ESP32-S3's LwIP owns the stack.

Reference and Demo Links

Higenis published a video showing the HG-ESP32-S3-RLY4-PRO connected to a WIZnet W5500 Ethernet module and controlling the relays over UDP.

• Original blog post (demo, 15 Aug 2026) — blog.naver.com/chandong83/224379489585
• Higenis product introduction post — blog.naver.com/chandong83/224304947738
• YouTube demo — youtube.com/watch?v=jNvdy1bNmhg
• Arduino source code — Relay_4_pro_demo.zip, attached to the blog post above
• Product page — HG-ESP32-S3-RLY4-PRO, smartstore.naver.com/higenis/products/13621797932
• WIZnet wsm_driver — github.com/Wiznet/wsm_driver