---
title: "How to Build a Rack-Management Controller on ESP32-S3 with W5500 Ethernet in TianShanOS?"
url: "https://maker.wiznet.io/viktor/projects/how-to-build-a-rack-management-controller-on-esp32-s3-with-w5500-ethernet-in-tianshanos/"
markdown_url: "https://maker.wiznet.io/viktor/projects/how-to-build-a-rack-management-controller-on-esp32-s3-with-w5500-ethernet-in-tianshanos/md"
type: "UCC: User Created Content"
author: "Thomas Hiddenpeak"
author_url: "https://github.com/thomas-hiddenpeak/TianshanOS"
editor: "WIZnet"
editor_url: "https://maker.wiznet.io/"
original_author: "Thomas Hiddenpeak"
original_url: "https://github.com/thomas-hiddenpeak/TianshanOS"
published: "2026-01-16"
language: "en"
hardware: ["WIZnet W5500"]
likes: 0
views: 841
comments: 0
source: "WIZnet Makers (https://maker.wiznet.io/)"
---

# How to Build a Rack-Management Controller on ESP32-S3 with W5500 Ethernet in TianShanOS?

> TianShanOS is an ESP-IDF v5.5+ framework that turns an ESP32-S3 into a rack-management controller.

Original author: Thomas Hiddenpeak (source: https://github.com/thomas-hiddenpeak/TianshanOS)

## Components

- **WIZnet W5500** x 1 ([docs](https://docs.wiznet.io/Product/Chip/Ethernet/W5500))

WIZnet parts: W5500 ([Datasheet](https://docs.wiznet.io/Product/Chip/Ethernet/W5500/datasheet?utm_source=maker&utm_medium=project&utm_campaign=w5500), [product hub](https://maker.wiznet.io/products/w5500/))

## Article

## Project introduction: what TianshanOS actually implements

**TianShanOS** is presented as a **configuration-oriented (not code-oriented)** embedded OS framework for **server cabinet / rack management**, built on **ESP-IDF v5.5+** and explicitly targeting **NVIDIA Jetson AGX carrier-board rack management** scenarios.

The README describes:

- A modular, component-based layout (core framework, HAL, console, API, LED subsystem, networking, security, WebUI, storage, drivers).

- **JSON configuration** to define hardware pins and behavior, with runtime flexibility for loading pin/service configuration.

- A layered architecture and an “8-stage” style service startup concept (“服务管理层 (8阶段启动)”).

- A security-first feature set: **HTTPS/mTLS**, SSH public-key auth, **AES-GCM**, and permission levels.

- Networking includes **Wi-Fi + Ethernet (W5500) + HTTP/HTTPS server**, and WebUI provides **REST API + WebSocket broadcast**.

This is essentially a “microcontroller BMC-like controller”: not a full server BMC stack, but a practical embedded control plane for rack/carrier-board power, fans, sensors, and remote UI.

## What “rack management” means (and where TianShanOS fits)

Rack management is the operational layer that keeps systems safe and serviceable: controlling **power sequencing**, **fan curves**, monitoring **voltages/currents/temperatures**, and exposing a remote interface (web/CLI/API) so an operator can check health and apply changes without physical access.

Traditional datacenter BMC stacks (e.g., **OpenBMC**) run on dedicated BMC silicon and provide a broad ecosystem for enterprise/HPC/cloud environments.
TianShanOS, by contrast, targets a lighter footprint: it’s designed around an ESP32-class MCU with modular services and a web console, making it attractive when you need “enough remote management” on custom hardware—without taking on a full Linux distribution.

## Why ESP32-S3 + WIZnet W5500 is a strong platform choice

### Wired-first reliability for control planes

For rack control, the network link isn’t a convenience—it’s the control plane. Wired Ethernet eliminates common Wi-Fi failure modes (RF congestion, roaming surprises, power-save jitter), which is especially important if your controller must remain reachable during incidents.

### W5500 simplifies Ethernet integration over SPI

The **WIZnet W5500** integrates 10/100 Ethernet MAC+PHY and is designed to connect to hosts over **SPI (up to 80 MHz)**, with **32 KB internal buffer memory** and support for multiple sockets/features typical of embedded Ethernet controllers.
In ESP-IDF ecosystems, there are established driver paths for W5500-class SPI Ethernet, which reduces “custom PHY bring-up” complexity.

### Practical alternative comparisons

- **Wi-Fi-only ESP32**: simplest BOM, but less deterministic for 24/7 rack access.

- **RMII PHY (e.g., LAN8720-style designs)**: great performance, but increases board-level clocking/layout constraints versus SPI wiring.

- **Linux BMC/OpenBMC**: maximum ecosystem and standards coverage, but far heavier (hardware + software) than an ESP32-S3 class controller.

### Upgrade paths in the WIZnet family

If you want a compact wired controller without ESP32 Wi-Fi, a SiP like **W55RP20 (RP2040 + W5500 integrated)** is a natural direction for “Ethernet-first appliance controllers.”

## Architecture explanation (repo-based + clearly marked conceptual details)

The repo’s README documents a layered architecture and modular component breakdown that maps cleanly to a rack controller:

**(1) Configuration-driven boot**

- Pins/services are described via JSON (“面向配置”), enabling a board profile under `boards/` and keeping the core logic generic.

**(2) Staged service startup**

- An event/message bus plus service manager brings up subsystems in order: storage → config → networking → API/WebUI → drivers (fans/power/AGX control).

**(3) Networking + UI**

- `ts_net` is the networking component (Wi-Fi + Ethernet + HTTP/HTTPS), while `ts_webui` provides REST + WebSocket. The current status table explicitly lists **“Ethernet W5500”** support.

**Conceptual (because I could not reliably open code files in this environment): W5500 bring-up sequence**

- Initialize SPI bus and W5500 reset GPIO

- Install an Ethernet driver instance, bind it to an ESP-IDF netif, and start link + DHCP

- Start HTTPS/mTLS endpoints and WebSocket broadcasting after network is ready

Important nuance: the W5500 has a “hardwired TCP/IP stack,” but Espressif’s W5500 driver documentation notes that the ESP driver path treats W5500 primarily as MAC/PHY while the TCP/IP stack is typically provided by the host (lwIP).

## FAQ

### 1) Why use W5500 for rack management instead of Wi-Fi?

Rack management is a control-plane workload: you care about reachability during stressful conditions (RF noise, AP failures, interference). W5500 gives you a wired Ethernet path over SPI (up to 80 MHz) with internal buffering, and TianShanOS explicitly lists W5500 Ethernet as part of its networking feature set. Wired-first management reduces “it’s online except when I need it most.”

### 2) How do you connect ESP32-S3 to W5500 in an ESP-IDF project like TianShanOS?

Electrically, W5500 connects over **SPI + a reset line** (and optionally an interrupt). On the software side, ESP-IDF uses an Ethernet driver model: you bind the SPI Ethernet driver to a network interface, then your HTTP/HTTPS/WebSocket services sit on top. TianShanOS’s structure (`ts_net` for network + HTTP/HTTPS) fits that model well.

### 3) What role does W5500 play inside TianShanOS specifically?

Based on the repo’s status table, W5500 is the **Ethernet option** inside the networking module: “WiFi, Ethernet W5500, HTTP/HTTPS server.” That implies W5500 provides the stable wired interface used by the WebUI (REST + WebSocket) and any API-driven rack control operations—exactly where you want deterministic connectivity.

### 4) Can beginners deploy a W5500-based rack controller with this project?

If you’re comfortable with ESP-IDF workflows (`idf.py set-target`, `menuconfig`, `build`, `flash monitor`), you’re most of the way there. The bigger learning curve is usually **hardware definition** (pin/service JSON) and verifying your rack IO (fans/power monitors) matches the board profile. Ethernet via W5500 is often simpler to validate than Wi-Fi because link state and cabling are concrete.

### 5) W5500 vs RMII PHY (LAN8720-style) vs “real BMC/OpenBMC”: which is best?

W5500 shines when you want **simple, reliable wired Ethernet** on an MCU board without tight RMII clock/layout constraints. RMII PHY designs can be excellent for throughput and integration, but board design is less forgiving. OpenBMC is the right answer when you need full datacenter-grade BMC capabilities and a Linux ecosystem—but it’s far heavier than an ESP32-S3 class design.

---

Source: https://maker.wiznet.io/viktor/projects/how-to-build-a-rack-management-controller-on-esp32-s3-with-w5500-ethernet-in-tianshanos/