Wiznet makers

Summary

This ESP32 project monitors DS18B20 temperature sensors across two OneWire buses and sends readings to an external server through a WIZnet W5500 Ethernet interface. The W5500 replaces the earlier Wi-Fi transport and provides the wired TCP/IP path used for HTTP POST telemetry, local web monitoring, configuration, and bus diagnostics.

What the Project Does

The project is a multi-point temperature monitor built around an ESP32, DS18B20 digital temperature sensors, and a W5500 Ethernet module. The current v2 design reads DS18B20 sensors on two OneWire buses, maps Bus 1 to GPIO 25 and Bus 2 to GPIO 26, and publishes readings as JSON through HTTP POST. The firmware also provides an embedded web server on port 80 with REST endpoints for live status, diagnostics, configuration, and sensor rescanning.

The DS18B20 is a digital temperature sensor, not an analog thermistor. It measures temperature internally, converts the result to a digital value, and communicates that value over a 1-Wire bus. The part supports 9-bit to 12-bit Celsius temperature measurements, has a -55°C to +125°C measurement range, and stores a unique 64-bit serial code in each device, which is why multiple sensors can share the same bus while still being individually addressed.

OneWire in this project refers to the Arduino OneWire software layer used to talk to Maxim/Analog Devices 1-Wire sensors. Electrically, 1-Wire is a serial bus that uses one data line plus ground for communication between one master and one or more slave devices. In this design, the ESP32 is the bus master, and the DS18B20 probes are slave devices distributed along each cable run.

The sensor data flow is direct: the ESP32 scans both OneWire buses, stores each discovered DS18B20 address, requests temperature conversion, reads the temperature from each address, builds a JSON document, and sends it through the W5500 Ethernet path. This separation is clean: OneWire handles local sensor discovery and measurement, while W5500 Ethernet handles network transport.

Where WIZnet Fits

The WIZnet product used here is the W5500 Ethernet controller. In this architecture, it is the ESP32’s wired network transport: the ESP32 handles OneWire scanning, DS18B20 temperature reads, JSON construction, EEPROM-backed configuration, and web UI logic, while the W5500 provides the SPI-connected Ethernet interface used by EthernetClient and EthernetServer.

This is a practical fit because the project targets continuous temperature monitoring, where missed readings and unstable network links are more important than wireless convenience. The W5500 provides a hardwired TCP/IP stack, SPI integration, 10/100 Ethernet PHY, 8 independent sockets, and internal 32 KB memory for packet buffers. For a fixed cold-chain node, the wired link is easier to inspect and stabilize than Wi-Fi in metal, refrigerated, or electrically noisy environments.

The W5500 does not replace the ESP32 application logic. Its role is narrower and useful: it gives the firmware a deterministic Ethernet interface for HTTP POST telemetry and local HTTP service while the ESP32 remains focused on DS18B20 polling, bus diagnostics, and configuration handling.

Implementation Notes

The repository contains real W5500 and OneWire implementation code in ds18b20_ESP32_eth/.

#define ONE_WIRE_BUS_1 25
#define ONE_WIRE_BUS_2 26

OneWire ow1(ONE_WIRE_BUS_1);
OneWire ow2(ONE_WIRE_BUS_2);

DallasTemperature bus1(&ow1);
DallasTemperature bus2(&ow2);

DeviceAddress addrBus1[16];
DeviceAddress addrBus2[16];

pinMode(ETH_RST, OUTPUT);
digitalWrite(ETH_RST, LOW);
delay(100);
digitalWrite(ETH_RST, HIGH);
delay(200);

Ethernet.init(ETH_CS);

if (Ethernet.begin(cfg.mac) == 0) {
  IPAddress fallback(192, 168, 3, 220);
  IPAddress gateway(192, 168, 3, 1);
  IPAddress subnet(255, 255, 255, 0);
  Ethernet.begin(cfg.mac, fallback, gateway, gateway, subnet);
}

Practical Tips / Pitfalls

• Keep the OneWire bus wiring stable before tuning software. Long cables, weak pull-ups, and noisy environments can make DS18B20 sensors appear intermittently disconnected even when the firmware is correct.
• Use the project’s bus diagnostic endpoint during installation. The repository describes /api/diag as reporting the percentage of responding sensors per bus, which is useful when adjusting pull-up behavior and cable quality. 
• Keep DS18B20 addressing in mind. Because each sensor has a unique 64-bit serial code, replacing a physical probe may change the address reported in JSON even if it is installed in the same location. 
• Keep W5500 SPI wiring short and consistent: MOSI GPIO 23, MISO GPIO 19, SCLK GPIO 18, CS GPIO 5, reset GPIO 33, and optional interrupt GPIO 4 are the mappings used by this project. 
• Change the fallback IP before deployment. The sample fallback address is 192.168.3.220, which may not match the target network. 
• Avoid oversized JSON documents on the ESP32. The firmware uses fixed JSON buffers and reports free heap in the outgoing payload, so adding more sensors or metadata should be checked against available memory. 

FAQ

Q: Why use W5500 for this ESP32 temperature monitor?
A: The W5500 gives the ESP32 a wired Ethernet path with hardware TCP/IP offload, internal packet buffering, and socket-based networking. For refrigerated-room or cold-chain monitoring, this is usually more predictable than Wi-Fi because the node is fixed in place and can use a cabled link instead of a radio link.

Q: How does the W5500 connect to the ESP32 in this project?
A: It connects over SPI. The repository maps MOSI to GPIO 23, MISO to GPIO 19, SCLK to GPIO 18, CS to GPIO 5, reset to GPIO 33, and optional interrupt to GPIO 4. The firmware then calls Ethernet.init(ETH_CS) before starting DHCP.

Q: What role does the W5500 play in this project specifically?
A: It is the network transport for both directions of communication. Outbound readings are sent through EthernetClient as HTTP POST JSON, while the local dashboard and REST endpoints are served through EthernetServer on port 80.

Q: Can beginners follow this project?
A: Yes, but it is not a first Arduino sketch. A beginner should already understand ESP32 GPIO pin mapping, SPI wiring, OneWire pull-ups, IP addressing, and installing Arduino libraries such as Ethernet, OneWire, DallasTemperature, and ArduinoJson.

Q: How does W5500 Ethernet compare with the earlier Wi-Fi + MQTT version?
A: The earlier version used Wi-Fi and MQTT, while v2 uses W5500 Ethernet and HTTP POST. Wi-Fi + MQTT can be convenient where cabling is unavailable, but W5500 Ethernet is better aligned with fixed cold-chain monitoring because link quality can be physically controlled, DHCP/link status can be checked locally, and the ESP32 can use a simple HTTP POST path for periodic readings.