Background

Commercial differential solar controllers are typically designed for relatively simple applications. Their primary responsibility is to compare collector and storage temperatures and activate a circulation pump when enough thermal energy is available. While this approach works for basic solar hot water systems, real installations often involve significantly more complex operating conditions.

The project presented here was developed for a large residential solar thermal installation with approximately 600 gallons of thermal storage. Instead of managing a single circulation loop, the controller coordinates multiple heating subsystems operating simultaneously.

These include:

• Solar collector circulation
• Domestic hot water (DHW)
• Radiant floor heating
• Auxiliary boiler integration
• Pipe freeze protection
• Water recirculation

Each subsystem has its own operating conditions, priorities, and safety requirements. At any given moment the controller must determine whether solar energy is sufficient, whether domestic hot water has priority over space heating, whether the storage tank can continue supplying heat, and whether the auxiliary boiler should be enabled.

Unlike many demonstration projects that simply display sensor readings, this controller makes continuous control decisions based on dozens of real-world operating conditions.

Engineering Challenge

Building this type of controller requires solving several engineering problems simultaneously.

First, the controller must acquire data from a large number of sensors without introducing excessive latency into the control loop.

Second, pump control cannot rely on simple temperature thresholds. Differential temperature control with hysteresis is required to prevent pumps from rapidly cycling on cloudy days when collector temperatures fluctuate around the switching point.

Third, external heating requests from both the furnace and domestic hot water system must be integrated into the same decision process.

Finally, operators need continuous visibility into system operation without interfering with the real-time control firmware.

These requirements transform what initially appears to be a simple temperature controller into a complete embedded automation system.

System Overview

The hardware platform is centered around an ESP32-S3 DevKitC-1 N8R8 that acts as the main control processor.

Sensor inputs include thirteen DS18B20 digital temperature sensors distributed throughout the solar heating system, together with a PT1000 resistance temperature detector connected through a MAX31865 interface for higher-accuracy measurement at elevated temperatures.

Flow monitoring is performed using four interrupt-driven flow meters that continuously measure circulation rates throughout the heating loops.

External digital inputs monitor both furnace heating requests and domestic hot water demand, allowing the controller to coordinate solar heating with conventional heating equipment.

Relay outputs drive every major actuator within the system.

These include:

• Solar lead pump
• Solar lag pump
• Domestic hot water pump
• Space heating pump
• Boiler circulator
• Heat tape
• Circulation pump
• Recirculation valve

The overall architecture can be summarized as follows.

DS18B20 Temperature Sensors (13)
            │
            │
PT1000 + MAX31865
            │
            │
Flow Meters (4)
            │
            │
Heating Call Inputs
            │
            ▼
     ESP32-S3 Controller
     PumpControl() Logic
            │
            ▼
      Relay Outputs (8)
            │
            ▼
   Pumps / Valves / Boiler
            │
            │
     SPI Interface
            ▼
     WIZnet W5500
            │
            ▼
     Ethernet Network
            │
            ▼
 Browser-based Dashboard

The firmware continuously collects sensor values before passing them into the main control algorithm. PumpControl() evaluates differential temperatures, heating requests, storage tank conditions, and safety limits before determining which relay outputs should be energized.

Unlike traditional industrial PLC systems where monitoring and control are separated, both functions share the same embedded platform. The ESP32 executes the control algorithm while simultaneously serving a browser-based dashboard over Ethernet.

The web interface displays live temperatures, flow rates, pump status, and operating modes while also allowing maintenance personnel to manually override relay outputs whenever commissioning or troubleshooting is required.

Why Wired Ethernet Matters

Many embedded monitoring projects default to Wi-Fi because it is readily available on modern development boards. However, heating equipment is rarely installed in ideal wireless environments.

Mechanical rooms are often located in basements, utility closets, or equipment rooms surrounded by reinforced concrete walls, steel piping, electrical motors, and large contactors. These conditions significantly reduce wireless signal quality and can introduce intermittent connectivity precisely when operators need reliable system access.

For a monitoring-only application, occasional Wi-Fi interruptions may be acceptable.

For equipment responsible for operating circulation pumps, controlling heating loops, and coordinating boiler operation, communication reliability becomes considerably more important.

A wired Ethernet connection eliminates RF interference entirely while providing predictable network availability throughout the lifetime of the installation.

This design decision makes the W5500 much more than a network accessory—it becomes an integral part of a controller intended for continuous field operation.

Firmware Design

Although the hardware consists of numerous sensors and relay outputs, the software architecture remains relatively straightforward.

The firmware can be divided into four major functional blocks:

1. Ethernet initialization
2. Sensor acquisition
3. Control algorithm
4. Embedded web server

Rather than implementing complicated multitasking between these components, each block contributes to a continuous control cycle that updates both the physical system and the browser interface.

Initializing the W5500 Ethernet Interface

The project uses the WebServer_ESP32_SC_W5500 library to register the W5500 as the Ethernet interface for the ESP32-S3.

Initialization begins by configuring Ethernet event handling before starting the SPI-connected W5500.

ESP32_W5500_onEvent();

ETH.begin(
    W5500_MISO,
    W5500_MOSI,
    W5500_SCK,
    W5500_SS,
    4,
    SPI_CLOCK_MHZ,
    ETH_SPI_HOST
);

ESP32_W5500_waitForConnect();

The initialization sequence performs three essential tasks.

First, it configures the SPI interface used to communicate with the W5500.

Second, it initializes the Ethernet hardware and PHY.

Finally, it waits until a valid network connection has been established before allowing the application to start its web services.

From the application's perspective, Ethernet becomes available through the same Arduino networking interface normally used for Wi-Fi.

This abstraction allows the firmware to use familiar server classes while the W5500 transparently manages TCP/IP communication in hardware.
 

Engineering Highlights

Several engineering decisions make this project stand out from a typical ESP32 monitoring application.

Differential Temperature Control

Instead of activating the solar pumps at a fixed temperature, the controller compares collector and storage temperatures using asymmetric hysteresis. Pumps start only when sufficient thermal energy is available and continue running until the temperature difference drops significantly. This minimizes relay chatter and improves pump longevity.

Hardware Interrupt Flow Measurement

The four flow meters use interrupt-driven pulse counting rather than continuous polling. This approach reduces CPU overhead while maintaining accurate flow monitoring during normal operation.

Active-Low Relay Design

All relay outputs are active-low, matching the behavior of many industrial relay modules. This provides a safer default state during system startup because relays remain de-energized until the firmware explicitly enables them.

PT1000 for High-Temperature Measurement

Most DIY solar projects rely exclusively on DS18B20 sensors. This design supplements them with a PT1000 RTD connected through a MAX31865 interface, improving measurement accuracy in high-temperature sections of the heating system where digital sensors may become less suitable.

Things to Consider

Although the project is technically well designed, several improvements would make it easier to maintain and extend.

• The firmware is implemented as a single file containing nearly 3,000 lines, making modular maintenance difficult.
• Shared global variables are accessed by both the control loop and web interface without explicit synchronization, which could become a concern if additional FreeRTOS tasks are introduced.
• Flow meter rate calculations appear partially disabled, meaning displayed flow values may not always represent real-time measurements.
• Separating sensor management, control logic, and web services into independent modules would improve long-term maintainability.

These limitations do not reduce the value of the project but highlight opportunities for future refinement.

Practical Tips

• Verify Ethernet link status before enabling the web server.
• Use static IP addressing for permanently installed heating systems whenever possible.
• Keep the W5500 SPI bus isolated from other high-frequency peripherals.
• Test manual relay override before enabling automatic control.
• Use shielded wiring for temperature sensors installed near pumps and motors.

Frequently Asked Questions

Why use the W5500 instead of the ESP32-S3's built-in Wi-Fi?

Heating controllers are often installed in mechanical rooms where wireless coverage is inconsistent. The W5500 provides a stable wired Ethernet connection while offloading TCP/IP processing, allowing the ESP32-S3 to focus on sensor acquisition and control logic.

How is the W5500 connected to the ESP32-S3?

The W5500 communicates through an SPI interface using dedicated MOSI, MISO, SCK, and CS pins. Once initialized through the WebServer_ESP32_SC_W5500 library, it operates as the Ethernet interface for the application.

What role does the W5500 play in this project?

The W5500 hosts the embedded HTTP dashboard, enabling real-time monitoring and manual relay control over a wired Ethernet connection without relying on Wi-Fi.

Can beginners reproduce this project?

Basic knowledge of ESP32 development, SPI peripherals, and relay wiring is recommended. Reproducing the complete heating controller also requires configuring temperature sensor addresses and adapting control thresholds to the specific installation.

How does this compare with a Wi-Fi-based controller?

Both approaches can provide remote monitoring, but Ethernet offers more predictable communication in electrically noisy environments such as boiler rooms. For systems expected to operate continuously, wired networking generally provides greater long-term reliability.

Related WIZnet Maker Projects

If you're interested in similar Ethernet-based embedded control systems, these WIZnet Maker projects are worth exploring:

• ESP32 + W5500 Industrial HVAC Monitor – Demonstrates wired Ethernet monitoring for HVAC equipment with real-time environmental sensing.
• Raspberry Pi Pico + W5500 Greenhouse Controller – Shows how the W5500 can provide reliable Ethernet connectivity for environmental monitoring and actuator control.
• ESP32 + W5100S Boiler Monitoring System – Focuses on embedded web monitoring for residential heating equipment using WIZnet Ethernet controllers.

These projects illustrate how hardware TCP/IP offloading can be applied across different industrial and building automation applications.

Conclusion

This project demonstrates that the W5500 is more than a networking accessory—it is an integral part of a reliable embedded control system. By combining deterministic Ethernet communication with the ESP32-S3, the controller can simultaneously monitor multiple sensors, execute complex heating logic, and provide a browser-based management interface without relying on wireless connectivity.

Rather than serving as a simple temperature monitoring example, the project presents a practical architecture for deploying Ethernet-enabled embedded controllers in real mechanical environments where long-term stability is a primary design requirement.

Source

Original Project: GitHub Repository (Solar Heating Controller for ESP32-S3 + W5500)

License: Refer to the original repository for licensing information.

Tags

#W5500 #ESP32S3 #Ethernet #SolarHeating #BuildingAutomation #IndustrialIoT #EmbeddedSystems #HTTPServer #TemperatureMonitoring