--- title: "Reliable Remote Management of REPACSS Cluster (Telemetry v1)" url: "https://maker.wiznet.io/matthew/projects/reliable-remote-management-of-repacss-cluster-telemetry-v1/" markdown_url: "https://maker.wiznet.io/matthew/projects/reliable-remote-management-of-repacss-cluster-telemetry-v1/md" type: "UCC: User Created Content" author: "TalkingJupiter" author_url: "https://github.com/TalkingJupiter/ReliableManagementRPCS" editor: "WIZnet" editor_url: "https://maker.wiznet.io/" original_author: "TalkingJupiter" original_url: "https://github.com/TalkingJupiter/ReliableManagementRPCS" published: "2026-02-04" language: "en" likes: 0 views: 416 comments: 0 source: "WIZnet Makers (https://maker.wiznet.io/)" --- # Reliable Remote Management of REPACSS Cluster (Telemetry v1) > Dual-ESP32 rack telemetry node with heartbeat failover. Sends UDP/JSON over WIZnet W5500 Ethernet to a Radxa backend designed for PostgreSQL/Grafana. Original author: TalkingJupiter (source: https://github.com/TalkingJupiter/ReliableManagementRPCS) ## Article Thumbnail image: AI-generated image ## Reliable Rack Telemetry with Active/Standby ESP32 Nodes over WIZnet W5500 (UDP/JSON → Radxa) ## Introduction **Reliable_Remote_Management_REPACSS (Telemetry v1)** defines a rack-level telemetry subsystem designed to keep reporting even when a controller fails. The design uses **two ESP32 controllers per rack**—an active **Controller A (Primary)** and a standby **Controller B (Standby)**—and sends telemetry to a **Radxa cluster** as **UDP JSON over wired Ethernet using a WIZnet W5500 module**. ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) ## Telemetry, in plain English ![](https://maker.wiznet.io/upload/ckeditor5/1045114563%5F1770626770%2Ejpg) AI-generated image “Telemetry” is simply the **automatic collection and transmission of measurements and status** from remote devices to a central system so operators can **monitor health, spot failures, and analyze trends**. IBM summarizes telemetry as automated data collection and transmission from distributed/remote sources to a central system for monitoring and analysis. ([IBM](https://www.ibm.com/think/topics/telemetry)) In this project’s context, telemetry is the rack’s “health report”: liveness (heartbeat), sensor readings (e.g., temperature/humidity), and operational events (failover/network changes). ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) ## What this project is ![](https://maker.wiznet.io/upload/ckeditor5/1045114563%5F1770626843%2Ejpg) AI-generated image - **High-availability rack telemetry pattern:** two ESP32s per rack with **automatic failover** based on heartbeat timeouts. ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) - **Deterministic transport choice:Ethernet-only** in this version, explicitly framed as a reliability decision, using **W5500** and **UDP** to a single Radxa IP. ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) - **Operational back end scope:** the Radxa cluster is specified as the **central ingestion, identification, storage, and alerting authority**, with a SQL database and Grafana-friendly access patterns. ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) - **Repository structure:** the repo shows an `ESP32-Firmware/` directory and a connection guide markdown file, in addition to the README spec. ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) ## Author & Community Published as a public GitHub repository by **TalkingJupiter**. At the time of review, the repository shows **1 star** and **8 issues**, which suggests it’s early-stage but actively being iterated. ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) ![](https://maker.wiznet.io/upload/ckeditor5/1045114563%5F1770626167%2Epng) Source: --- ## How it works ![](https://maker.wiznet.io/upload/ckeditor5/1045114563%5F1770626856%2Ejpg) AI-generated image ### 1) Heartbeat-based failover (the core reliability mechanism) The failover logic is specified in concrete timing terms: - Controller A emits a heartbeat every **500 ms**. - Controller B monitors that heartbeat continuously. - If B receives no heartbeat for **2000 ms**, it declares A unhealthy and takes over telemetry transmission automatically. - Failover state is included in the telemetry payload so the back end can record and alert on it. ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) A “critical rule” prevents double-reporting: **B must remain silent while A is healthy**, only transmitting after A fails, and stopping again when A recovers. This is a small rule with big operational value—one rack should look like one reporting source unless a switchover occurs. ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) ### 2) Network path: WIZnet W5500 as the wired telemetry interface Telemetry v1 explicitly chooses **Ethernet-only** transport for “deterministic, reliable” delivery, and it explicitly mandates a **W5500 Ethernet module**. Messages are sent as **UDP** to a **single Radxa IP**, and each message includes a unique **MAC address** for device identity. ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) From a WIZnet perspective, this is a clean match for W5500’s lane: W5500 is a hardwired Internet controller with an integrated TCP/IP stack and support for **UDP**, with **8 sockets** and **32KB internal memory**, intended to simplify Ethernet application development over SPI. ([WIZnet](https://wiznet.io/products/ethernet-chips/w5500)) In this design, the W5500’s job is straightforward: provide a stable wired link so the ESP32 can focus on **state machine + sensor + failover logic**, while the back end receives a consistent stream of small UDP “health report” packets. ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) ### 3) Payload model: one structured “rack health report” message The README defines a minimal schema and shows an example structure. Each telemetry message includes: - `message_type` (telemetry) - `device.mac` - a device timestamp - an `items[]` list that combines **heartbeat**, **sensor readings**, and **failover/event data** ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) This “single structured message” approach is practical for ingestion: the Radxa side can validate the envelope, then route/store sensor samples and events without coupling tightly to a single firmware build. ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) ### 4) Scaling operations: central MAC→rack mapping and “unknown device” handling Instead of hardcoding rack IDs into firmware, the design makes the Radxa cluster the **source of truth** for mapping **MAC → rack_id**. Unknown MACs are **not dropped**—they’re stored and labeled as unassigned/unknown, and the alert policy is intentionally rate-limited to a **daily summary** when unknown devices are observed. ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) This is a subtle but important ops detail: it supports scaling deployments by updating only the back end mapping, while still capturing data from newly installed nodes. ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) ### 5) Radxa ingestion + storage + dashboards (designed like an ops system) The Radxa cluster is described as the central authority for: - ingestion and message timestamping - identity resolution (MAC → rack) - long-term storage and alerting ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) Storage requirements are spelled out in operational terms: - **PostgreSQL** is required, with **TimescaleDB recommended** for time-series optimization. - Data must remain **Grafana SQL datasource compatible**. - Environmental telemetry is specified at **5-second resolution** with **minimum 1-year retention**. - The system anticipates scale by provisioning **~1 TB** persistent storage for multi-year retention and growth. ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) This reads less like a toy demo and more like an “ops spec” that can be implemented incrementally. ### 6) Novelty and roadmap baked into the requirements Even though Telemetry v1 excludes relay control and sensor-bus switching, the repo specifies forward-looking architecture requirements: - **Redundant sensor buses** (front/back) sharing ESP32 GPIO pins, selected via **analog SPDT switches** for electrical isolation and avoidance of bus contention, with coordinated behavior during failover. ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) - **Network failover concept** from Ethernet (primary) to Wi-Fi (secondary) with bounded switchover time and event reporting. ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) - That’s a meaningful design signal: the project is not only collecting telemetry, but planning for **fault domains** (controller, sensor bus, and network path) as separate layers. --- ## Why it matters ![](https://maker.wiznet.io/upload/ckeditor5/1045114563%5F1770626869%2Ejpg) AI-generated image This repository is useful as a reference not because it claims novel silicon tricks, but because it documents a practical, repeatable pattern: - **A reliability-first edge telemetry node design** (active/standby with explicit timings and a “no double-reporting” rule). ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) - **A deployable operational model** (MAC-based identity, unknown device registry, daily warning summary, fail-safe ingestion). ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) - **A familiar monitoring marketplace stack** (PostgreSQL + optional TimescaleDB + Grafana compatibility) that makes it easy to plug into existing dashboards/alerting workflows. ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) - **WIZnet fit:** W5500 is used exactly where it shines—stable wired UDP telemetry—while leaving the MCU to run the failover state machine and sensor logic. ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) **Reason:** (mass-production potential) the “rack telemetry node” pattern scales cleanly with central MAC→rack mapping and long-term storage assumptions. (niche market) homelabs, edge clusters, and small rack deployments that value wired reliability and simple ingestion. ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) --- ## Quick notes (reproducibility, missing artifacts, and access) - The README provides unusually detailed requirement-style documentation (heartbeat timing, schema, storage, retention, and alerting). ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) - The repo shows an `ESP32-Firmware/` directory and a connection guide file, but **GitHub pages for those files did not load** in this browsing session (GitHub returned an error message), so this curation cannot verify the exact firmware implementation details (e.g., the specific W5500 driver/library usage, link-status detection, or UDP send loop). ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS/tree/main/ESP32-Firmware)) - No schematic/BOM or demo video is visible from the accessible README sections. If the goal is fast replication by others, adding (1) a wiring diagram or module BOM, and (2) a short “failover demo” clip showing A→B takeover in Grafana, would materially improve reproducibility and reviewer confidence. ([GitHub](https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS)) --- #### Q: What is the REPACSS Telemetry v1 project? A: REPACSS (Reliable Remote Management) is a high-availability rack telemetry system designed to monitor server rack health. It uses a dual-controller architecture (two ESP32 nodes) to ensure data reporting continues even if the primary controller fails. The system transmits data over wired Ethernet using WIZnet W5500 modules to a central Radxa cluster. #### Q: Who created the REPACSS telemetry project? A: The project is published as an open-source repository on GitHub by TalkingJupiter. It is currently in an active iteration phase, focusing on reliable edge telemetry patterns. #### Q: What is the main purpose of this telemetry system? A: Its primary purpose is to act as a "health report" for server racks. It continuously collects and transmits: Liveness: Heartbeat signals to prove the rack is online. Sensor Readings: Environmental data like temperature and humidity. Operational Events: Critical alerts such as network changes or failover events (switching from Primary to Standby). ## References ```plaintext https://github.com/TalkingJupiter/Reliable_Remote_Management_REPACSS https://wiznet.io/products/ethernet-chips/w5500 https://www.ibm.com/think/topics/telemetry ``` --- Source: https://maker.wiznet.io/matthew/projects/reliable-remote-management-of-repacss-cluster-telemetry-v1/