ramses_esp_eth

📌 Overview

ramses_esp_eth는 Honeywell Evohome / Ramses II(868MHz RF) 난방 제어 시스템의 무선 패킷을 수신해 MQTT로 변환하고, 반대로 MQTT 명령을 RF로 송신할 수 있게 해주는 유선(Ethernet) 전용 게이트웨이입니다.

기존에 Wi-Fi 기반 대안(ramses_esp 등)이 존재하지만, 이 프로젝트는 **“끊기지 않는 안정성(유선)”**과 **“한 번 설정하면 계속 동작하는 플러그앤플레이”**를 목표로 설계된 점이 핵심 차별점입니다.

📌 Features

• 유선 Ethernet 기반 네트워크 연결(W5500): Wi-Fi 불안정(지연/끊김) 문제를 피하고, 상시 구동이 필요한 난방 제어에 더 적합한 연결 방식을 제공합니다.
• 듀얼코어 + FreeRTOS 태스크 분리: 한 코어는 RF/프로토콜 처리를, 다른 코어는 네트워크·상태 LED 등을 담당하게 분리해 패킷 누락 위험을 낮추는 구조를 지향합니다.
• Home Assistant 연동(MQTT Auto-Discovery): MQTT 디스커버리를 통해 Home Assistant에 장치/센서가 자동으로 잡히도록 설계되어 초기 연동 부담을 줄입니다.
• MQTT Command & Control: RF 패킷을 MQTT로 퍼블리시하고, MQTT로 들어온 명령/패킷을 RF로 송신하는 양방향 게이트웨이 구조입니다.
• 자가 복구(Watchdog) 지향: CC1101 라디오 및 네트워크 상태를 감시해 멈춤/드롭 상황에서 자동 복구를 목표로 하는 로직을 포함합니다.

📌 System Architecture

구성 요소(핵심 블록)

• RF(868MHz): CC1101 트랜시버가 Evohome/Ramses II RF 패킷을 수신/송신
• MCU: ESP32-S3가 프로토콜 처리 및 MQTT 메시지 변환 수행(FreeRTOS 기반 태스크 분리)
• 네트워크: W5500(Ethernet) 모듈이 유선 LAN 연결 제공
• 브로커/서버: 로컬 또는 원격 MQTT Broker(예: Mosquitto)
• 클라우드/앱: Home Assistant 등 MQTT 소비/제어 애플리케이션

데이터 흐름(요약)

• (수집 경로) Evohome/Ramses II 기기 →(868MHz RF)→ CC1101 → ESP32-S3(디코드/정규화) → MQTT Publish → 브로커 → Home Assistant
• (제어 경로) Home Assistant/앱 → MQTT Publish(명령) → 브로커 → ESP32-S3(명령 해석) → CC1101 →(868MHz RF)→ 난방 제어 기기

📌 Role and Application of the WIZnet's Chip

사용된 WIZnet 칩 모델명: W5500 

네트워크에서의 역할: 

이 프로젝트에서 W5500은 유선 Ethernet 접속(10/100Mbps) 경로를 제공하며, 결과적으로 게이트웨이가 MQTT 브로커와 안정적으로 TCP/IP 통신할 수 있게 합니다. 

선택 이유/기술적 장점

• 매우 높은 신뢰성을 최우선으로 해야하며, 유선 Ethernet 연결을 사용할 때 가장 잘 구현할 수 있습니다.

📌 Market & Application Value

📌 WIZnet Strategic Value

(by ChatGPT)

“W5500 = 산업/상시구동에 강한 유선 네트워크”라는 메시지를 스마트홈 게이트웨이(니치지만 명확한 문제해결) 사례로 보여줍니다.
Wi-Fi가 기본인 IoT 설계에서, “정말 끊기면 안 되는 장치”는 유선이 답일 수 있다는 실전 관점을 제공합니다. (특히 MQTT 기반 홈 오토메이션에서 설득력)

📌 Summary

ramses_esp_eth는 Honeywell Evohome/Ramses II 난방 제어 시스템에서 사용되는 868MHz RF 신호를 수신하고 이를 MQTT 메시지로 변환해, Home Assistant와 같은 스마트홈 플랫폼에서 난방 상태를 모니터링하고 제어할 수 있도록 만든 유선 Ethernet 기반 게이트웨이 프로젝트입니다. 특히 Wi-Fi 대신 WIZnet W5500 칩을 활용한 안정적인 유선 네트워크 연결을 적용함으로써, 상시 동작이 필요한 난방 제어 환경에서 끊김 없이 신뢰도 높은 통신을 목표로 한다는 점이 이 프로젝트의 가장 큰 특징입니다. 현재 외부 공개 지표는 아직 제한적이지만, 스마트홈 난방 연동 분야에서 “유선 전용 MQTT 브리지”라는 실용적 사례로서 WIZnet 칩의 적용 가능성과 Maker 생태계 확장성을 보여주는 의미 있는 프로젝트로 정리할 수 있습니다.

📌 FAQ

Q: 왜 이 프로젝트에서는 Wi-Fi 대신 WIZnet W5500 이더넷을 사용하나요?

A: Wi-Fi는 환경 간섭과 재연결로 지연 시간이 불규칙하지만, W5500 이더넷은 하드웨어 TCP/IP 스택을 통해 결정론적이고 안정적인 통신을 제공합니다. Ramses RF 시스템처럼 지속적인 메시지 스트림이 필요한 경우 유선 이더넷이 더 적합합니다.

Q: ESP32에서 W5500은 어떤 역할을 하나요?

A: W5500은 ESP32의 네트워크 처리를 하드웨어 레벨에서 오프로딩하여 TCP/IP 연산을 대신 수행합니다. 이를 통해 ESP32는 RF 메시지 처리와 애플리케이션 로직에 집중할 수 있으며, CPU 부하와 네트워크 지터가 감소합니다.

Q: 이 프로젝트에서 Serial(USB) 통신 대신 Ethernet을 쓰는 이유는 무엇인가요?

A: Serial 통신은 물리적 거리와 확장성에 제약이 있지만, Ethernet은 네트워크 기반 분산 구조를 가능하게 합니다. W5500을 사용하면 Ramses 시스템을 원격 서버, 컨테이너, 홈 서버와 안정적으로 연결할 수 있습니다.

Q: ESP32 + W5500 연결은 복잡한가요?

A: 복잡하지 않습니다. W5500은 **SPI 인터페이스(MISO, MOSI, SCK, CS)**만으로 ESP32와 연결되며, 별도의 소프트웨어 TCP/IP 스택(LwIP 튜닝) 없이 바로 사용 가능합니다. 네트워크 안정성을 얻는 대신 하드웨어 구성은 오히려 단순해집니다.

Q: Wi-Fi 기반 ESPHome / MQTT 구성과 비교하면 어떤 차이가 있나요?

A: Wi-Fi 기반 구성은 설치는 간단하지만 패킷 손실과 지연 편차가 발생할 수 있습니다. 반면 W5500 이더넷은 **항상 연결된 상태(link-up)**를 유지하며, 홈 자동화나 HVAC 제어처럼 신뢰성이 중요한 시스템에 더 적합합니다.

Q: 이 프로젝트에 W55RP20을 적용할 수도 있나요?

A: 가능합니다. W55RP20은 RP2040 + W5500이 단일 칩으로 통합된 솔루션으로, ESP32 대신 사용하면 PCB 크기와 BOM을 줄이면서도 동일한 이더넷 안정성을 확보할 수 있습니다. 장기적으로는 유지보수성과 산업 적합성이 향상됩니다.

Q: 이더넷이 전력 소모 면에서 불리하지 않나요?

A: Wi-Fi 대비 절대 전력은 높을 수 있지만, W5500은 연결 유지 및 재시도에 따른 오버헤드가 거의 없어 실제 시스템에서는 오히려 안정적인 전력 프로파일을 보입니다. 항상 켜져 있는 게이트웨이 노드에는 이더넷이 더 효율적일 수 있습니다.

📌 Overview

ramses_esp_eth is a wired (Ethernet-only) gateway that receives wireless packets from Honeywell Evohome / Ramses II (868 MHz RF) heating control systems and converts them to MQTT, and conversely transmits MQTT commands back over RF.

While Wi-Fi–based alternatives (such as ramses_esp) already exist, this project is specifically designed with “non-stop reliability through wired connectivity” and “plug-and-play operation that keeps running once configured” as its core differentiators.

📌 Features

• Wired Ethernet-based network connection (W5500): It provides a more suitable connectivity option for always-on heating control by avoiding Wi-Fi instability issues such as latency and disconnections.
• Dual-core + FreeRTOS task separation: The design aims to reduce the risk of packet loss by assigning RF/protocol processing to one core, while the other core handles networking, status LEDs, and related tasks.
• Home Assistant integration (MQTT Auto-Discovery): By leveraging MQTT discovery, devices and sensors are automatically detected in Home Assistant, reducing the initial integration burden.
• MQTT Command & Control: This is a bidirectional gateway architecture where RF packets are published via MQTT, and incoming MQTT commands/packets are transmitted back over RF.
• Self-recovery (Watchdog) oriented: The logic includes monitoring of the CC1101 radio and network status, aiming for automatic recovery in cases of freezes or drop conditions.

📌 System Architecture

Components (Core Blocks)

• RF (868MHz): The CC1101 transceiver receives and transmits Evohome/Ramses II RF packets.
• MCU: The ESP32-S3 handles protocol processing and MQTT message translation (with FreeRTOS-based task separation).
• Network: The W5500 (Ethernet) module provides a wired LAN connection.
• Broker/Server: A local or remote MQTT broker (e.g., Mosquitto).
• Cloud/App: MQTT consumer/control applications such as Home Assistant.

Data Flow (Summary)

• (Collection path) Evohome/Ramses II devices → (868MHz RF) → CC1101 → ESP32-S3 (decode/normalize) → MQTT Publish → Broker → Home Assistant
• (Control path) Home Assistant/App → MQTT Publish (command) → Broker → ESP32-S3 (command interpretation) → CC1101 → (868MHz RF) → Heating control devices

📌 Role and Application of the WIZnet's Chip

WIZnet chip model used: W5500

Role in the network:

In this project, the W5500 provides a wired Ethernet (10/100 Mbps) connection path, enabling the gateway to communicate reliably with the MQTT broker over TCP/IP.

Reasons for selection / technical advantages

• Very high reliability is the top priority, and it can be best achieved by using a wired Ethernet connection.

📌 Market & Application Value

Target Markets / Industries

• Heating control (Evohome) integration within smart home and home automation ecosystems such as Home Assistant.
• HVAC monitoring and remote control for residential and small commercial facilities, based on a local MQTT infrastructure.

📌 WIZnet Strategic Value

(by ChatGPT)

It demonstrates the message that “W5500 = a wired network solution strong for industrial and always-on operation” through a smart home gateway case that, while niche, solves a clearly defined problem.

In IoT designs where Wi-Fi is the default, it offers a practical perspective that for devices that truly must not disconnect, wired connectivity may be the right answer—especially compelling in MQTT-based home automation environments.

📌 Summary

ramses_esp_eth is a wired Ethernet-based gateway project that receives 868MHz RF signals used in the Honeywell Evohome/Ramses II heating control system and converts them into MQTT messages, enabling smart home platforms such as Home Assistant to monitor and control heating status.

A key characteristic of this project is its focus on applying a stable wired Ethernet connection using the WIZnet W5500 chip instead of Wi-Fi, aiming for uninterrupted and highly reliable communication in heating control environments that require continuous operation.

Although public adoption metrics are still limited, it can be summarized as a meaningful project demonstrating the applicability of WIZnet chips and the expansion potential within the Maker ecosystem, as a practical example of a “wired-only MQTT bridge” in the smart home heating integration domain.

📌 FAQ

Q: Why does this project use WIZnet W5500 Ethernet instead of Wi-Fi?

A: Wi-Fi often suffers from irregular latency due to environmental interference and reconnections. In contrast, W5500 Ethernet provides deterministic and stable communication through its hardware TCP/IP stack. For systems like Ramses RF that require continuous message streaming, wired Ethernet is more suitable.

Q: What role does the W5500 play in an ESP32-based system?

A: The W5500 offloads network processing from the ESP32 at the hardware level by handling TCP/IP operations directly. This allows the ESP32 to focus on RF message processing and application logic, reducing CPU load and network jitter.

Q: Why use Ethernet instead of Serial (USB) communication in this project?

A: Serial communication is limited in physical distance and scalability, whereas Ethernet enables a network-based distributed architecture. By using the W5500, the Ramses system can be reliably connected to remote servers, containers, or home servers over the network.

Q: Is connecting ESP32 + W5500 complicated?

A: Not at all. The W5500 connects to the ESP32 using only the SPI interface (MISO, MOSI, SCK, CS), and it can be used immediately without requiring complex software TCP/IP stack tuning (such as heavy LwIP adjustments). Hardware configuration remains relatively simple while significantly improving network stability.

Q: How does this differ from Wi-Fi-based ESPHome / MQTT setups?

A: Wi-Fi-based setups are easy to install but may experience packet loss and latency variation. In contrast, W5500 Ethernet maintains an always-connected (link-up) state, making it far more suitable for reliability-critical systems such as home automation and HVAC control.

Q: Could this project be implemented using W55RP20 as well?

A: Yes. The W55RP20 integrates RP2040 + W5500 into a single chip. Using it instead of an ESP32 could reduce PCB size and BOM cost while maintaining the same Ethernet stability. Long-term, this can improve maintainability and industrial suitability.

Q: Isn’t Ethernet less power-efficient than Wi-Fi?

A: While absolute power consumption may be higher compared to Wi-Fi, the W5500 has minimal overhead from reconnection attempts or link recovery. In real systems, it often provides a more stable power profile. For always-on gateway nodes, Ethernet can actually be more efficient and predictable.