Wiznet makers

[Project Spotlight] An Ethernet Sensor Node for a 3,000+ Unit Seniors Village — A Real-World W5500 Deployment

Overview

This project isn't a demo or a learning exercise — it's a real embedded system being built for long-term deployment across a 3,000+ unit seniors village. The developer is building it as part of a contract engagement with a company that provides solutions for senior living facilities, and has implemented the entire firmware in C using ESP-IDF, running on an ESP32-S3 with a W5500 SPI Ethernet controller, complete with remote management, sensor telemetry, and OTA firmware updates.

Why This Qualifies as a "Real Solution" Case Study

Unlike a typical IoT demo, this project was designed from the ground up around real operational constraints:

• Unattended, long-term operation: nodes installed across a facility of thousands of units must be manageable without physical access
• Network reliability: wired Ethernet (W5500) was chosen over Wi-Fi to guarantee stable connectivity at facility scale
• Remote maintainability: status checks, reboots, and firmware updates all need to happen without a site visit
• Persistent node identity: each node must retain its configuration (static IP, etc.) across power loss and reboots

What makes this more than a tutorial project is that these constraints are visibly baked into the firmware architecture itself. Rather than buying an off-the-shelf product, the developer designed both the firmware and the hardware from scratch around one specific deployment's requirements.

Network Architecture — W5500 SPI Ethernet

The current firmware runs on an ESP32-S3 dev board with a W5500 SPI Ethernet controller, integrated with ESP-IDF's Ethernet/TCP-IP stack. The boot sequence is structured as follows:

1. Load persistent node identity and static IP configuration from NVS
2. Initialize the SPI bus and install the W5500 Ethernet driver
3. Attach the netif to the TCP/IP stack and wait for link/IP acquisition
4. Initialize sensor-facing peripherals: I2C, ADC, GPIO, timers
5. Spawn tasks for sensor measurement, heartbeat, UDP streaming, and the TCP console

On top of the network layer, two communication paths run concurrently:

• UDP telemetry: temperature, humidity, air quality, and motion detection values, along with chip/firmware version and IP, are packaged into JSON and periodically sent to the backend
• TCP node console (port 4000): commands like reboot, stream on/off, ota status, and ota flash let operators inspect and control a node without visiting the site

Sensor Integration

This isn't just placeholder telemetry fields — it includes actual working sensor drivers.

• AHT20 (I2C): temperature and humidity measurement
• MQ135 (ADC): analog air-quality readings via an ADC oneshot + calibration path
• HC-SR505 (GPIO/GPIO expander): motion detection, with interrupt-driven immediate detection support

OTA Updates for Unattended Operation

To update firmware on facility-installed nodes without a physical visit, the project implements an HTTPS-based OTA flow:

1. Fetch the manifest file over HTTPS (certificate-pinned TLS)
2. Compare firmware versions and download/flash a newer version if available
3. Reboot, validate the new image, and roll back on failure

Notably, the rollback validation logic is there specifically to prevent a node from being bricked by a bad firmware push in an unattended environment.

Hardware Roadmap — From SPI to RMII

While the current dev board + W5500 (SPI) combination is being used to validate the firmware, the custom PCB (Rev 1) is planned to move to an ESP32-WROOM-32E with the ESP32's internal Ethernet MAC and an external LAN8720A (RMII) PHY. This frees up the SPI bus for other sensors/peripherals instead of dedicating it to Ethernet. The Rev 1 PCB is currently in pre-layout schematic review.

Comparison with Commercial ESP32 Ethernet Products

Comparing this project against commercial ESP32-based industrial Ethernet controllers on the market highlights a clear difference in character.

All of these commercial products target the general-purpose industrial automation/gateway market. This repo, by contrast, was purpose-designed around a specific deployment site (a 3,000+ unit seniors village) — its sensor set and communication protocol were built for that use case from the start — and rather than buying a commercial gateway, the developer is building custom firmware and a custom PCB from scratch. That's what sets it apart.