Wiznet makers

📌 Overview

AstroWeatherStation은 천문대에 설치되어 관측 환경을 실시간으로 판단하고, 악천후로부터 망원경과 돔을 보호하기 위한 기상·안전 관측 시스템입니다.

단순한 날씨 기록이 아니라, 강우·풍속·하늘 밝기(SQM) 등 관측 장비 손상과 직결되는 지표를 실시간 수집하고,  이더넷 기반으로 외부 시스템에 상태 정보와 측정 데이터를 전달하는 것을 목표로 합니다.

ESP32를 중심으로 센서·전원·네트워크·릴레이 제어가 하나의 보드에 통합된 구조이며, 12V 및 PoE 환경 모두를 고려해 설계되었습니다.

📌 Developer

출처: https://www.linkedin.com/in/franck-lesage-2a4a834/

AstroWeatherStation 프로젝트는 천문 관측소를 위한 태양광 기반 기상 스테이션이라는 개인 취미 프로젝트에서 출발했습니다.
이후 실제 관측소 운영자와 공공 프로젝트로 부터 요구가 늘어나, 다음과 같은 맞춤형 디바이스 설계 및 제작 요청으로 확장되고 있습니다.

• Sky Quality Meter(SQM)를 포함한 기상 스테이션
• 모로코 Oukaïmeden 지역 망원경 팜을 위한 SafetyMonitor 및 돔 제어 기상 스테이션
• 고정형 및 이동형 GPS + Sky Quality Meter 장치
• 도시 환경 모니터링을 위한 Urban Ecology 센서 스테이션

고객에게 서비스를 제공하기 위해 LOADS.CH라는 1인 기업을 설립하였고, 아래와 같은 주요 사용자 및  고객이 있습니다.

• 모로코 Oukaïmeden 천문대(“Atlaskies”)
• 프랑스 Strasbourg 유럽도시권(EuroMétropole) – University of Strasbourg 소속 EvolVille 프로젝트

📌 Features

• 관측 안전 중심의 센서 구성: 온습도/기압/풍향풍속/강우 + 구름(하늘 온도) + 일사/조도 + SQM(하늘 밝기)까지 묶어 “관측 가능/위험” 판단에 필요한 변수를 한 번에 수집
• 강우 이벤트 기반 보호 로직: 비 감지 시 알람 전송 및 돔 제어(릴레이/상태입력) 같은 운영 기능을 포함(원격 무인 운영에 적합)
• 표준 연동(ASCOM ALPACA): 천문 자동화 소프트웨어(장비 제어/관측 스케줄러)와 연결 가능한 인터페이스 제공
• 유선 Ethernet(옵션) + PoE 구성 고려: Wi-Fi가 불안정한 옥외/원격 환경에서 유선 연결을 선택 가능(12V/PoE 변형)
• 운영 편의 기능: 설정 UI, 펌웨어 업데이트/다운로드 같은 운영 기능을 코드/문서에서 체계적으로 다룸

📌 System Architecture

센서/입력 계층

• I2C/RS485/디지털 입력으로 환경·천문 센서 및 강우/돔 상태 신호 수집

MCU 처리 계층 (ESP32)

• 센서 값을 통합해 상태(예: rain_event, sky 상태 등)를 만들고, 데이터/알람 payload를 JSON으로 구성

네트워크 계층 (Wi-Fi 또는 Ethernet)

• 환경에 따라 Wi-Fi STA/AP 또는 Ethernet로 서비스 제공

서버/클라이언트 계층

• 서버는 판단 결과와 측정 데이터를 수신·시각화하며, 관측 자동화 소프트웨어(ALPACA)가 상태를 조회·연동

📌 Role and Application of the WIZnet's Chip

사용된 WIZnet 칩: W5500

네트워크에서의 역할:

• ESP32에 유선 Ethernet 인터페이스를 제공(옵션/PoE 변형에서 사용)
• 프로젝트 동작 관점에서는 측정 데이터/알람을 서버로 보내는 경로(HTTP(S) 전송)에 안정적인 링크를 제공

기술적 장점:

• 하드웨어 TCP/IP 오프로딩: TCP/UDP 등 주요 프로토콜을 칩 내부 로직이 처리 → MCU 부하/구현 복잡도 감소
• SPI 기반 간단 결선 + 최대 80MHz SPI: 임베디드 보드에 붙이기 쉽고 처리량 확보에 유리
• 동시 8 소켓 지원: 설정 UI/ALPACA/데이터 업로드 같은 다중 통신 시나리오에 구조적으로 유리

📌 Market & Application Value

주요 적용 시장

• 원격 천문대 / 망원경 호스팅 시설
• 대학·연구기관 관측소
• 무인 환경 모니터링 스테이션

제품화 가능성

• 실제 1인 사업(LOADS.CH) 기반으로 고객 프로젝트 진행
• Strasbourg 도시 생태 프로젝트, 망원경 팜 적용 사례 존재

📌 External Indicators

Github

https://github.com/switux/AstroWeatherStation/tree/main

• GitHub 공개 지표(저장소): Star 2, Fork 2, Commits 133 (표시 기준)
• 릴리스 존재: 3.0.1 “bug fix release”가 태그/릴리스로 제공됨(유지보수/배포 흔적)
• 이슈/마일스톤 운영 흔적: 기능/버그/질문 이슈와 마일스톤(예: 3.0.0 Release) 운영이 확인됨

📌WIZnet Strategic Value

"관측소/옥외 인프라”처럼 Wi-Fi가 불리한 현장에서도, **W5500 기반 유선 Ethernet(+PoE 구성)**으로 안정적인 IoT/제어 시스템을 만들 수 있다는 실증 사례입니다.

확장 가능성:

• 관측소 안전(돔/전원/히터/제습) 제어 패키지
• 데이터 수집 → 대시보드/알림(슬랙/메일) 연동 템플릿

임베디드 기상 스테이션 자체는 흔하지만, ALPACA(천문 장비 표준) + 돔 안전 제어 + (옵션) W5500 유선/PoE 조합은 WIZnet Maker 관점에서 “현장형 자동화/안전” 사례로 차별화 포인트가 됩니다.

📌 Summary

AstroWeatherStation은 원격 천문 관측소의 안전 운영을 목표로, ESP32에 다양한 센서를 통합하고 데이터를 서버로 전송하며, ASCOM ALPACA 표준 연동까지 제공하는 프로젝트입니다. PoE/12V 변형에서 WIZnet W5500을 사용해 유선 Ethernet을 제공함으로써, 설치 환경에 따라 통신 신뢰성을 강화할 수 있는 구성이 특징입니다. 외부 지표(Star/Fork)는 크지 않지만, 릴리스/이슈/마일스톤 운영으로 실사용 기반의 개선 흐름이 확인됩니다.

📌 QnA

Q1: 왜 이 프로젝트는 Wi-Fi 대신 W5500 이더넷을 쓰나요?
A: 원격 천문대(돔) 운영용 기상 관측은 “연결이 끊기지 않는 것”이 핵심이라, 무선 간섭/전파 환경에 좌우되는 Wi-Fi보다 유선 이더넷이 유리합니다. 이 프로젝트는 관측 데이터/알람을 HTTP(S) JSON으로 전송하고(ALPACA 서버 포함), 안정적인 백홀을 전제로 설계되어 있어요. 이런 환경에서는 W5500 기반 SPI-Ethernet이 “항상 붙어있는 링크”를 만들기 좋습니다. 

Q2: ESP32에 W5500을 어떻게 연결해야 하나요? (핀/리셋 관점)
A: W5500은 SPI(MISO/MOSI/SCK/CS) 기반이라 배선이 단순합니다. 이 프로젝트 코드에서는 이더넷 초기화 루틴에서 특정 GPIO를 출력으로 두고 HIGH로 올려(리셋/전원/Enable 계열로 쓰는 전형적인 패턴) 이더넷 모듈 구동을 보장합니다. 즉, **SPI 4선 + (CS) + (RST/INT 등 보조 신호)**까지 포함해 “부팅 시 확실히 살아나게” 배선하는 게 중요합니다. 

Q3: 이 프로젝트에서 W5500은 정확히 어떤 역할을 하나요?
A: W5500은 “센서 데이터/알람을 외부로 내보내는 유선 네트워크 인터페이스” 역할을 합니다. README에 따르면 스테이션은 알람을 HTTPS 엔드포인트로 JSON 형태로 보내고, 관측 데이터도 JSON으로 전송합니다. 또한 ASCOM ALPACA 서버 기능이 포함되어 원격 천문대 운영 시스템에서 상태를 조회/제어하는 네트워크 경로가 필요합니다. 이때 W5500 이더넷은 Wi-Fi가 불안정한 설치 환경에서도 통신을 유지하는 핵심 부품이 됩니다. 

Q4: “ETH Started에서 멈춤” 같은 증상이 나오면 W5500에서 무엇부터 의심해야 하나요?
A: 이 저장소 Discussion에서 유지관리자가 직접 언급하듯, **“ETH Started에서 멈추면 W5500 배선 문제일 가능성이 크다”**가 1순위 체크 포인트입니다. 브레드보드/점퍼선 접촉 불량이 원인인 경우도 있었고, SPI 클럭을 낮춰(예: 18MHz) 임시 완화하던 걸 다시 25MHz로 올려도 “배선이 탄탄하면 잘 동작”했다고 공유되어 있어요. 결론은 **클럭 튜닝보다 배선/접촉 품질(특히 CS/RST/GND)**을 먼저 잡는 게 재현성 측면에서 더 효과적입니다. 

Q5: W5500을 쓰면 ESP-IDF/ESP32 이더넷 드라이버가 하드웨어 TCP/IP를 다 활용하나요?
A: 참고로 Espressif의 W5500 드라이버 문서에서는 **W5500이 하드웨어 TCP/IP 스택과 32KB 내부 버퍼를 갖지만, ESP 드라이버는 그 하드웨어 TCP/IP 스택을 “그대로 사용하지는 않는다”**고 명시합니다. 즉, “W5500 = 무조건 TCP/IP 오프로딩”으로 단정하기보다, ESP32 쪽 네트워킹 구조(드라이버/스택)와 프로젝트 구현 방식에 따라 이점의 형태가 달라질 수 있어요. 그래도 W5500은 SPI-Ethernet 구현을 빠르게 만들고, 배선/링크가 안정적이라 원격 설치 환경에서 운영 리스크를 줄이는 데 실질적인 가치가 있습니다.

📌 Overview

AstroWeatherStation is a weather and safety monitoring system installed at observatories to assess observing conditions in real time and protect telescopes and domes from severe weather.

Rather than simply recording weather data, it aims to collect in real time indicators that are directly related to potential damage to observational equipment—such as rainfall, wind speed, and sky brightness (SQM)—and to deliver system status and measurement data to external systems over Ethernet.

The system is built around an ESP32, with sensors, power management, networking, and relay control integrated into a single board, and is designed to support both 12 V and PoE environments.

📌 Developer

Reference : https://www.linkedin.com/in/franck-lesage-2a4a834/

The AstroWeatherStation project originated as a personal hobby project—a solar-powered weather station for astronomical observatories.
As interest and requests from actual observatory operators and public projects increased, it has since expanded into custom device design and fabrication requests such as the following.

• Weather stations including a Sky Quality Meter (SQM)
• SafetyMonitor and dome control weather stations for telescope farms in the Oukaïmeden region of Morocco
• Fixed and mobile GPS + Sky Quality Meter devices
• Urban ecology sensor stations for urban environment monitoring

To provide services to customers, a sole proprietorship called LOADS.CH was established, and it has the following key users and customers.

• Oukaïmeden Observatory (“Atlaskies”)
• Strasbourg Eurometropolis (EuroMétropole), France – EvolVille project of the University of Strasbourg

📌 Features

• Observation-safety-focused sensor configuration:
  Collect all variables required to determine “observable / hazardous” conditions in a single system, including temperature/humidity/pressure/wind direction & speed/rainfall, cloud cover (sky temperature), solar irradiance/illuminance, and SQM (sky brightness).
• Rain-event–based protection logic: Includes operational functions such as sending alarms when rain is detected and controlling the dome (relay/status inputs), making it suitable for remote unmanned operation.
• Standard integration (ASCOM ALPACA): Provides an interface that can connect with astronomical automation software (equipment control and observation schedulers).
• Wired Ethernet (optional) + PoE configuration considered: Allows selection of wired connectivity in outdoor or remote environments where Wi-Fi is unstable (12 V / PoE variants).
• Operational convenience features: Operational functions such as a configuration UI and firmware update/download are systematically addressed in the code and documentation.

📌 System Architecture

Sensor / input layer

• Collects environmental and astronomical sensor data, as well as rain and dome status signals, via I2C, RS485, and digital inputs.

MCU processing layer (ESP32)

• Integrates sensor values to generate states (e.g., rain_event, sky status) and constructs data and alarm payloads in JSON format.

Network layer (Wi-Fi or Ethernet)

• Provides services via Wi-Fi STA/AP or Ethernet depending on the environment.

Server / client layer

• The server receives and visualizes decision results and measurement data, while astronomical automation software (ALPACA) queries and integrates system status.

📌 Role and Application of the WIZnet's Chip

WIZnet chip used: W5500

Role in the network:

• Provides a wired Ethernet interface to the ESP32 (used in optional / PoE variants).
• From a project operation perspective, it provides a stable link for sending measurement data and alarms to a server (via HTTP(S) transmission).

Technical advantages:

• Hardware TCP/IP offloading: Major protocols such as TCP/UDP are handled by internal chip logic → reduced MCU load and implementation complexity.
• Simple SPI-based connection + up to 80 MHz SPI: Easy to integrate into embedded boards and advantageous for achieving sufficient throughput.
• Support for up to 8 simultaneous sockets: Structurally well suited for multi-communication scenarios such as configuration UI, ALPACA integration, and data uploads.

📌 Market & Application Value

Key target markets

• Remote observatories / telescope hosting facilities
• University and research institute observatories
• Unmanned environmental monitoring stations

Productization potential

• Customer projects carried out based on a real sole proprietorship (LOADS.CH)
• Existing application cases in the Strasbourg urban ecology project and telescope farm deployments

📌 External Indicators

Github

https://github.com/switux/AstroWeatherStation/tree/main

• GitHub public metrics (repository): Stars 2, Forks 2, Commits 133 (as displayed)
• Releases available: Version 3.0.1 “bug fix release” provided as a tagged release (evidence of maintenance and distribution)
• Issue / milestone management activity: Operation of feature, bug, and question issues, as well as milestones (e.g., 3.0.0 Release), is confirmed

📌WIZnet Strategic Value

This is a demonstrated case showing that a stable IoT and control system can be built using W5500-based wired Ethernet (+ PoE configuration) even in field environments such as observatories and outdoor infrastructure where Wi-Fi is disadvantageous.

Expandability:

• Observatory safety control packages (dome / power / heater / dehumidifier control)
• Data collection → dashboard / alert (Slack / email) integration templates

While embedded weather stations themselves are common, the combination of ALPACA (astronomical equipment standard) + dome safety control + (optional) W5500 wired Ethernet/PoE becomes a differentiating point from a WIZnet Maker perspective as a “field-deployed automation and safety” use case.

📌 Summary

AstroWeatherStation is a project aimed at the safe operation of remote astronomical observatories, integrating various sensors on an ESP32, transmitting data to a server, and providing interoperability with the ASCOM ALPACA standard. By using the WIZnet W5500 to provide wired Ethernet in PoE/12V variants, it features a configuration that enhances communication reliability depending on the installation environment. Although external indicators (Stars/Forks) are modest, a practical, real-world–driven improvement cycle is evident through the operation of releases, issues, and milestones.

📌 QnA

Q1: Why does this project use W5500 Ethernet instead of Wi-Fi?
A: For weather monitoring used in remote observatory (dome) operations, the key requirement is “never losing the connection.” Compared to Wi-Fi, which is affected by wireless interference and RF conditions, wired Ethernet is more advantageous. This project transmits observation data and alarms as HTTP(S) JSON (including an ALPACA server) and is designed with a stable backhaul in mind. In such environments, W5500-based SPI Ethernet is well suited for creating an “always-connected link.”

Q2: How should the W5500 be connected to the ESP32? (pin / reset perspective)
A: The W5500 uses an SPI interface (MISO/MOSI/SCK/CS), so wiring is simple. In this project’s code, during the Ethernet initialization routine, a specific GPIO is configured as an output and driven HIGH (a typical pattern used for reset/power/enable control) to ensure that the Ethernet module starts correctly. In other words, it is important to wire it so that it “definitely comes up at boot,” including the 4 SPI lines + CS + auxiliary signals such as RST/INT.

Q3: What exactly is the role of the W5500 in this project?
A: The W5500 serves as the wired network interface that sends sensor data and alarms to external systems. According to the README, the station sends alarms to HTTPS endpoints in JSON format and also transmits observation data as JSON. In addition, since ASCOM ALPACA server functionality is included, a network path is required for remote observatory management systems to query and control status. In this context, W5500 Ethernet becomes a core component that maintains communication even in installation environments where Wi-Fi is unstable.

Q4: If symptoms like “stuck at ETH Started” appear, what should be checked first on the W5500?
A: As directly mentioned by the maintainer in the repository’s Discussions, “if it stops at ETH Started, a W5500 wiring issue is the most likely cause” is the first checkpoint. In some cases, poor contact on breadboards or jumper wires was the cause. It was also shared that after temporarily lowering the SPI clock (e.g., to 18 MHz), raising it back to 25 MHz worked fine once the wiring was solid. The conclusion is that fixing wiring and contact quality (especially CS/RST/GND) is more effective for reproducibility than tuning the clock.

Q5: When using the W5500, does the ESP-IDF / ESP32 Ethernet driver fully utilize hardware TCP/IP offloading?
A: For reference, Espressif’s W5500 driver documentation explicitly states that although the W5500 has a hardware TCP/IP stack and 32 KB internal buffer, the ESP driver does not use that hardware TCP/IP stack directly. In other words, it should not be assumed that “W5500 = automatic TCP/IP offloading”; the actual benefits depend on the ESP32 networking architecture (driver/stack) and the project’s implementation. That said, the W5500 still provides real value by enabling quick SPI-Ethernet integration and offering stable wiring and links, which reduce operational risk in remote installation environments.