zhi-an-cloud-shield

COMPONENTS

PROJECT DESCRIPTION

Zhi'an Cloud Shield (智安云盾) — A Cloud-Edge-Device Smart Home Safety System

#W5500 #TOE #ModbusTCP #STM32F103 #SmartHome #JetsonOrinNano #YOLOv8 #DigitalTwin #ThreeJS #FastAPI

📚 University innovation & entrepreneurship project — Guizhou Vocational College of Electronic Science & Technology (贵州电子科技职业学院) Self-reported pilot in 10–20 households of the Gui'an community; lab-claimed AI accuracy > 95%.

01 — What is this project?

Zhi'an Cloud Shield is a four-layer home safety system built around three jobs: detect gas leaks and smoke with chemical sensors, detect human falls with a camera, and report both to a 24/7 monitoring dashboard. When something dangerous happens — gas concentration over threshold, a person on the floor — the system sounds an alarm, cuts the gas valve via relay, and pushes an alert to the family and the property management.

The architecture stacks four layers: an STM32F103 sensor node at the bottom, a Jetson Orin Nano edge gateway running YOLOv8 in the middle, a Python FastAPI cloud server with MySQL, and a Three.js 3D dashboard at the top. The STM32 talks to the Jetson over W5500 wired Ethernet using Modbus TCP on port 502. The Jetson forwards to the cloud over MQTT/HTTP.

According to the README, the system is designed to keep functioning even when external network connectivity is lost: the edge can make its own decisions in under 1 second, and 16–64 GB of local storage buffers data until the connection returns. The project is developed by a student team from Guizhou Vocational College of Electronic Science & Technology and is entered in the Guizhou Provincial Vocational Skills Competition and the Guiyang Entrepreneurship Competition.

02 — Why this architecture?

🔷 Reason 1 — Edge can act without the cloud

The most concrete design choice is putting the alarm logic at the edge, not in the cloud. The STM32 reads its sensors and runs the threshold check locally. The Jetson runs YOLOv8 locally. When the external network is down, neither device needs to wait for a round trip to the cloud — they make the call themselves, and the cloud only gets involved when it's reachable again.

Per the README: edge response is sub-1-second, and a local 16–64 GB buffer holds whatever data couldn't be uploaded so it can sync after recovery. The author summarizes this in one phrase: "断网可用" — usable when the network is down.

🔷 Reason 2 — Modbus TCP between the field node and the gateway

Most DIY home-IoT projects use MQTT over Wi-Fi between the MCU and the gateway because the toolchain is easier. This project goes with Modbus TCP over Ethernet instead. That choice carries the system into the same protocol family used in factory automation and building management, which means the same node could later plug into a SCADA-style operations center without changing the wire format. For a student project aiming at a property-management business model, that's a sensible bet.

🔷 Reason 3 — Spatial dashboard

The frontend is a Three.js 3D model of the home with sensors and alarm states overlaid in real time. For a single house, it's overkill. For a property management center watching many households at once, a spatial view is faster to scan than a wall of text rows.

03 — System architecture

┌──────────────────────────────────────────────────────────────────────┐
│  🖥️  APPLICATION LAYER                                                │
│  Three.js 3D dashboard · ECharts · Glassmorphism UI · Port 8002      │
└─────────────────────────────────▲────────────────────────────────────┘
                                  │ WebSocket / REST
                                  ▼
┌──────────────────────────────────────────────────────────────────────┐
│  🧠  CLOUD LAYER                                                      │
│  Python FastAPI + Uvicorn · MySQL · WebSocket broadcast              │
│  Multi-channel notification: APP / SMS / phone call                  │
└─────────────────────────────────▲────────────────────────────────────┘
                                  │ MQTT / HTTP
                                  │ (external network — medium unspecified by author)
                                  ▼
┌──────────────────────────────────────────────────────────────────────┐
│  ⚡  EDGE LAYER                                                       │
│  Jetson Orin Nano · YOLOv8 fall detection · OpenCV                   │
│  Modbus TCP master · Local 16–64 GB buffer · Sub-1s edge decision    │
└─────────────────────────────────▲────────────────────────────────────┘
                                  │ Modbus TCP over wired Ethernet
                                  │ Function 0x03 (read) / 0x06 (write)
                                  ▼
┌──────────────────────────────────────────────────────────────────────┐
│  🛰️  PERCEPTION LAYER  —  STM32F103C8T6 + W5500                       │
│                                                                      │
│   ┌─────────────┐   SPI    ┌──────────┐   Ethernet → Gateway         │
│   │ STM32F103   │ ───────► │  W5500   │ ──────────►                  │
│   │ Cortex-M3   │          │  TOE TCP │   Port 502                   │
│   │ 72 MHz      │ ◄─────── │ Sn_MR_TCP│ ◄──────────                  │
│   └─────────────┘          └──────────┘                              │
│        │                                                             │
│        ├── ADC ─► MQ-2 (smoke/CH4) · MQ-7 (CO) · MQ-135 (air quality)│
│        ├── GPIO ► DHT11 (temp/humidity)                              │
│        ├── GPIO ► Relay (gas valve / power cutoff)                   │
│        ├── GPIO ► Buzzer + alarm LED                                 │
│        └── I2C ─► OLED status display                                │
└──────────────────────────────────────────────────────────────────────┘

04 — Why W5500?

🔷 The constraint

The field node is an STM32F103C8T6: a 72 MHz Cortex-M3 with 20 KB RAM and 64 KB flash. In a single super-loop, it has to:

Sample three MQ sensors via ADC with median filtering
Bit-bang DHT11 with interrupts disabled during the timing-critical read
Drive an OLED over I2C and scan debounced keys
Run the relay and alarm state machine
Act as a Modbus TCP server on port 502 to the Jetson

A software TCP/IP stack like LwIP would consume a meaningful share of the F103's RAM, add unpredictable latency to the alarm logic, and require careful interrupt prioritization to avoid breaking the DHT11 read timing.

🔷 W5500 usage mode: TOE TCP server (`Sn_MR_TCP`)

The project uses the W5500 in TOE TCP server mode, confirmed in main.c:

void TCP_Server_Poll(void) {     uint8_t s = getSn_SR(0);     if(s == SOCK_CLOSED) {         socket(0, Sn_MR_TCP, TCP_SERVER_PORT, 0);  // Port 502 — Modbus TCP         listen(0);     }     if(s == SOCK_ESTABLISHED) {         recv_len = recv(0, g_rx_buffer, RX_BUF_SIZE);         // Modbus TCP function code 0x03 (Read Holding Registers)         if(recv_len >= 12 && g_rx_buffer[7] == 0x03) { ... }         // Modbus TCP function code 0x06 (Write Single Register)         else if(recv_len >= 12 && g_rx_buffer[7] == 0x06) { ... }     } }

The entire TCP/IP stack — IP, TCP, ARP, ICMP, retransmission, flow control — runs inside the W5500 silicon. The STM32 just reads finished application-layer bytes from the receive buffer and writes responses. No competing ISR in the main loop. No stack overhead eating the F103's 20 KB of RAM.

🔷 Why hardware TCP, not a software stack

Approach	What it costs on the F103
LwIP / software TCP/IP	Large RAM and flash footprint; tuning complexity; interrupt latency risk on the DHT11 timing-critical path
ENC28J60 (MAC only)	Still needs a software TCP stack on the MCU — same drawbacks as LwIP
W5500 (chosen)	SPI calls + ~2 KB of driver code; TCP/IP is in silicon; MCU stays free for the sensor super-loop

🔷 What's verified in the code ✅

W5500 hardware presence checked at boot via VERSIONR == 0x04 (W5500_ReadVersion())
3-attempt initialization retry loop with OLED status feedback
Modbus TCP function codes 0x03 / 0x06 implemented
Standard WIZnet ioLibrary structure (socket.c, w5500.c, wizchip_conf.c)
Complete Keil MDK + CubeMX project — buildable as-is

⚠️ What's claimed but not independently verified

10–20 household pilot deployment in the Gui'an community (no photos or video in the README)
AI accuracy > 95% (lab self-test, no public test set referenced)
Sub-1-second edge response (a design target stated in the README)

05 — Key components

🌐 WIZnet W5500 — TOE TCP server, port 502 Modbus TCP slave

Hardware TCP/IP stack lets the F103 host a Modbus TCP server without burdening the MCU. SPI interface to STM32, wired Ethernet to the Jetson gateway.

🧠 STM32F103C8T6

The field-node MCU. ADC sampling, DHT11 bit-bang, relay/alarm control, OLED refresh, and Modbus TCP request handling — all in one super-loop scheduler.

🤖 NVIDIA Jetson Orin Nano

The edge gateway. Runs YOLOv8 person/fall detection in OpenCV, acts as the Modbus TCP master against W5500 nodes, and bridges to the cloud over MQTT/HTTP.

🧪 Sensor set

MQ-2 (combustible gas / smoke), MQ-7 (carbon monoxide), MQ-135 (air quality), DHT11 (temperature & humidity).

🐍 Python / FastAPI cloud

FastAPI on port 8002 with MySQL persistence and WebSocket fan-out. Multi-channel notification (APP / SMS / phone).

🎨 Three.js 3D dashboard

A 1,729-line single-file Three.js + ECharts dashboard with glassmorphism UI, intended for a 24/7 property management call center.

06 — Application scenarios

01. Gas leak / fire

MQ-2 or MQ-7 over threshold → buzzer + LED alarm + automatic gas-valve cutoff via relay, with a Modbus TCP event to the gateway. Edge action completes locally.

02. Fall detection

Jetson runs YOLOv8 on a camera feed. On a confirmed fall, the gateway escalates through the cloud to property management, with APP/SMS/voice fallback.

03. Electrical safety

Voltage/current monitoring feeds the same Modbus TCP register map. Overload or leakage events use the same alarm path.

04. Property management aggregation

Because the wire protocol is standard Modbus TCP, a property management company can aggregate dozens or hundreds of households into a single operations center.

Conclusion

Zhi'an Cloud Shield is a well-integrated student project that uses the W5500 the way it was designed to be used: hand the whole TCP/IP stack to the chip, run a clean Modbus TCP server on a small Cortex-M3, and keep the MCU focused on its sensor work.

What this project demonstrates well:

✅ W5500 + ioLibrary + Modbus TCP — a complete, working reference implementation
✅ Clean separation of edge and cloud responsibilities
✅ Full-stack integration: MCU + edge AI + backend + 3D frontend

What is claimed but would benefit from independent confirmation:

⚠️ Pilot deployment in 10–20 households (no media evidence in the repo)
⚠️ >95% AI accuracy (lab-internal claim)

Q&A

Q. Why TCP server on the STM32 instead of TCP client? A. The Jetson gateway acts as the Modbus TCP master, polling each field node. A server-mode W5500 means the STM32 doesn't manage connection retries to a moving target — that's the gateway's job. This matches the standard Modbus TCP industrial pattern.

Q. Why not just use UDP on the W5500 for telemetry? A. Two reasons. (1) Modbus TCP is the standard, and the project's stated value lies in matching the industrial protocol. (2) Alarm events benefit from TCP's guaranteed delivery and ordering. The W5500's hardware TCP stack makes the choice essentially free for the MCU.

Q. Could this scale to multiple W5500 nodes? A. Yes — the W5500 supports up to 8 independent hardware sockets. One chip could host the Modbus TCP server, an HTTP firmware-update endpoint, and an MQTT client to a backup broker at the same time.

[한글 버전]

智安云盾 (Zhi'an Cloud Shield) — Cloud-Edge-Device 스마트 홈 안전 시스템

#W5500 #TOE #ModbusTCP #STM32F103 #스마트홈 #JetsonOrinNano #YOLOv8 #디지털트윈 #ThreeJS #FastAPI

📚 대학 창업 프로젝트 — 귀주전자과기직업학원(贵州电子科技职业学院) 저자 주장 기준 귀안 사회구 10~20가구 시범 운영, 실험실 AI 정확도 95% 초과

01 — 이 프로젝트는 무엇인가?

智安云盾은 세 가지 일을 하는 4계층 가정 안전 시스템이다. 화학 센서로 가스 누출과 연기를 감지하고, 카메라로 사람의 낙상을 감지하며, 두 가지 모두를 24시간 모니터링 대시보드로 보고한다. 위험 상황 — 가스 농도 임계값 초과, 사람이 바닥에 쓰러진 상황 — 이 발생하면 경보를 울리고, 릴레이로 가스 밸브를 차단하며, 가족과 부동산 관리실에 알림을 보낸다.

아키텍처는 4계층으로 구성된다. 아래에서부터 STM32F103 센서 노드, YOLOv8을 돌리는 Jetson Orin Nano 엣지 게이트웨이, MySQL을 사용하는 Python FastAPI 클라우드 서버, 그리고 Three.js 3D 대시보드다. STM32는 **W5500 유선 이더넷과 Modbus TCP(포트 502)**로 Jetson과 통신한다. Jetson은 MQTT/HTTP로 클라우드에 전달한다.

README에 따르면 이 시스템은 외부 네트워크 연결이 끊겨도 동작하도록 설계됐다. 엣지가 1초 이내에 자체 결정을 내릴 수 있고, 16~64GB의 로컬 저장 공간이 연결이 복구될 때까지 데이터를 버퍼링한다. 귀주전자과기직업학원 학생 팀이 개발했고, 귀주성 직업원교 기능 대회와 귀양 창업 대회에 출전 중이다.

02 — 왜 이런 구조인가?

🔷 이유 1 — 엣지가 클라우드 없이 동작할 수 있다

가장 구체적인 설계 결정은 경보 로직을 클라우드가 아닌 엣지에 두었다는 점이다. STM32가 센서를 읽고 임계값 체크를 로컬에서 수행한다. Jetson이 YOLOv8을 로컬에서 돌린다. 외부 네트워크가 끊겨도 두 장치는 클라우드 왕복을 기다릴 필요가 없다 — 스스로 판단하고, 클라우드는 연결이 복구된 뒤에 합류한다.

README의 표현 그대로: 엣지 응답은 1초 이내이며, 16~64GB의 로컬 버퍼가 업로드되지 못한 데이터를 모아두었다가 복구 후 동기화한다. 저자는 이걸 한 단어로 요약한다 — "断网可用" (네트워크 끊겨도 사용 가능).

🔷 이유 2 — 현장 노드와 게이트웨이 사이의 Modbus TCP

대부분의 DIY 홈 IoT 프로젝트는 툴체인이 쉽다는 이유로 MCU와 게이트웨이 사이에 Wi-Fi 기반 MQTT를 쓴다. 이 프로젝트는 대신 이더넷 위의 Modbus TCP를 선택했다. 이 선택은 시스템을 공장 자동화와 빌딩 관리에서 사용하는 프로토콜 패밀리 안으로 들여놓는다. 즉, 같은 노드가 와이어 포맷을 바꾸지 않고도 나중에 SCADA 스타일 운영 센터에 연결될 수 있다. 부동산 관리 비즈니스 모델을 노리는 학생 프로젝트로서는 합리적인 베팅이다.

🔷 이유 3 — 공간 기반 대시보드

프런트엔드는 가정의 Three.js 3D 모델 위에 센서와 경보 상태를 실시간으로 오버레이한 형태다. 단독 가정 한 채에는 과한 구성이지만, 여러 가정을 동시에 감시하는 부동산 관리 센터에서는 텍스트 행 나열보다 공간 뷰가 훨씬 빠르게 스캔된다.

03 — 시스템 아키텍처

┌──────────────────────────────────────────────────────────────────────┐
│  🖥️  애플리케이션 계층                                                │
│  Three.js 3D 대시보드 · ECharts · Glassmorphism UI · 포트 8002       │
└─────────────────────────────────▲────────────────────────────────────┘
                                  │ WebSocket / REST
                                  ▼
┌──────────────────────────────────────────────────────────────────────┐
│  🧠  클라우드 계층                                                    │
│  Python FastAPI + Uvicorn · MySQL · WebSocket 브로드캐스트           │
│  다채널 알림: APP / SMS / 전화                                       │
└─────────────────────────────────▲────────────────────────────────────┘
                                  │ MQTT / HTTP
                                  │ (외부 네트워크 — 매체는 저자 미명시)
                                  ▼
┌──────────────────────────────────────────────────────────────────────┐
│  ⚡  엣지 계층                                                        │
│  Jetson Orin Nano · YOLOv8 낙상 감지 · OpenCV                        │
│  Modbus TCP 마스터 · 로컬 16~64GB 버퍼 · 1초 이내 엣지 결정          │
└─────────────────────────────────▲────────────────────────────────────┘
                                  │ Modbus TCP / 유선 이더넷
                                  │ Function 0x03 (read) / 0x06 (write)
                                  ▼
┌──────────────────────────────────────────────────────────────────────┐
│  🛰️  감지 계층  —  STM32F103C8T6 + W5500                              │
│                                                                      │
│   ┌─────────────┐   SPI    ┌──────────┐   Ethernet → 게이트웨이      │
│   │ STM32F103   │ ───────► │  W5500   │ ──────────►                  │
│   │ Cortex-M3   │          │ TOE TCP  │  포트 502                    │
│   │ 72 MHz      │ ◄─────── │ Sn_MR_TCP│ ◄──────────                  │
│   └─────────────┘          └──────────┘                              │
│        │                                                             │
│        ├── ADC ─► MQ-2 (연기/CH4) · MQ-7 (CO) · MQ-135 (공기질)      │
│        ├── GPIO ► DHT11 (온/습도)                                    │
│        ├── GPIO ► 릴레이 (가스 밸브 / 전원 차단)                     │
│        ├── GPIO ► 부저 + 경보 LED                                    │
│        └── I2C ─► OLED 상태 디스플레이                               │
└──────────────────────────────────────────────────────────────────────┘

04 — 왜 W5500인가?

🔷 제약 조건

현장 노드는 STM32F103C8T6 — 72MHz Cortex-M3, RAM 20KB, 플래시 64KB이다. 단일 슈퍼루프 안에서 다음을 모두 처리해야 한다:

3채널 MQ 센서 ADC 샘플링 (미디언 필터링 적용)
인터럽트 비활성화 상태에서의 DHT11 비트뱅 (타이밍 크리티컬)
I2C OLED 갱신과 디바운스 키 스캔
릴레이와 경보 상태 머신
Jetson에 대한 포트 502 Modbus TCP 서버 역할

LwIP 같은 소프트웨어 TCP/IP 스택은 F103의 RAM을 의미 있는 비율로 소모하고, 경보 로직에 예측 불가능한 지연을 추가하며, DHT11 타이밍을 깨뜨리지 않도록 정교한 인터럽트 우선순위 관리를 요구한다.

🔷 W5500 사용 모드: TOE TCP 서버 (`Sn_MR_TCP`)

이 프로젝트는 W5500을 TOE TCP 서버 모드로 사용한다. main.c에서 직접 확인된다:

void TCP_Server_Poll(void) {     uint8_t s = getSn_SR(0);     if(s == SOCK_CLOSED) {         socket(0, Sn_MR_TCP, TCP_SERVER_PORT, 0);  // 포트 502 — Modbus TCP         listen(0);     }     if(s == SOCK_ESTABLISHED) {         recv_len = recv(0, g_rx_buffer, RX_BUF_SIZE);         // Modbus TCP 함수 코드 0x03 (Read Holding Registers)         if(recv_len >= 12 && g_rx_buffer[7] == 0x03) { ... }         // Modbus TCP 함수 코드 0x06 (Write Single Register)         else if(recv_len >= 12 && g_rx_buffer[7] == 0x06) { ... }     } }

전체 TCP/IP 스택 — IP, TCP, ARP, ICMP, 재전송, 흐름 제어 — 이 W5500 실리콘 내부에서 실행된다. STM32는 수신 버퍼에서 완성된 애플리케이션 계층 바이트를 읽고 응답을 쓸 뿐이다. 메인 루프에서 경합하는 인터럽트 서비스 루틴이 없고, 20KB RAM을 갉아먹는 스택 오버헤드도 없다.

🔷 왜 하드웨어 TCP인가, 소프트웨어 스택이 아니라

접근 방식	F103에서의 비용
LwIP / 소프트웨어 TCP/IP	큰 RAM·플래시 footprint, 튜닝 복잡성, DHT11 타이밍 크리티컬 경로에 대한 인터럽트 지연 위험
ENC28J60 (MAC만)	MCU에 여전히 소프트웨어 TCP 스택 필요 — LwIP와 동일한 단점
W5500 (선택됨)	SPI 호출 + 약 2KB 드라이버 코드, TCP/IP는 실리콘 안, MCU는 센서 슈퍼루프에 집중 가능

🔷 코드에서 검증되는 것 ✅

부팅 시 VERSIONR == 0x04 체크로 W5500 하드웨어 존재 확인 (W5500_ReadVersion())
3회 재시도 초기화 루프 + OLED 상태 피드백
Modbus TCP 함수 코드 0x03 / 0x06 구현
표준 WIZnet ioLibrary 구조 (socket.c, w5500.c, wizchip_conf.c)
완전한 Keil MDK + CubeMX 프로젝트 — 그대로 빌드 가능

⚠️ 주장되었으나 독립적으로 검증되지 않은 것

귀안 사회구 10~20가구 시범 운영 (README에 사진·영상 없음)
AI 정확도 95% 초과 (실험실 자체 테스트, 공개 데이터셋 미참조)
1초 이내 엣지 응답 (README에 명시된 설계 목표)

05 — 핵심 컴포넌트

🌐 WIZnet W5500 — TOE TCP 서버, 포트 502 Modbus TCP 슬레이브

하드웨어 TCP/IP 스택 덕분에 F103이 MCU 부담 없이 Modbus TCP 서버를 호스팅할 수 있다. STM32와는 SPI, Jetson 게이트웨이와는 유선 이더넷으로 연결된다.

🧠 STM32F103C8T6

현장 노드 MCU. ADC 샘플링, DHT11 비트뱅, 릴레이/경보 제어, OLED 갱신, Modbus TCP 요청 처리 — 모두 단일 슈퍼루프 스케줄러 안에서 수행한다.

🤖 NVIDIA Jetson Orin Nano

엣지 게이트웨이. OpenCV 위에서 YOLOv8 인체/낙상 감지를 실행하고, W5500 노드들에 대한 Modbus TCP 마스터 역할을 하며, MQTT/HTTP로 클라우드와 연결한다.

🧪 센서 세트

MQ-2 (가연성 가스/연기), MQ-7 (일산화탄소), MQ-135 (공기질), DHT11 (온/습도).

🐍 Python / FastAPI 클라우드

포트 8002의 FastAPI, MySQL 영속화, WebSocket 팬아웃. 다채널 알림 (APP / SMS / 전화).

🎨 Three.js 3D 대시보드

글래스모피즘 UI를 가진 1,729줄 단일 파일 Three.js + ECharts 대시보드. 24시간 부동산 관리 콜센터를 위한 구성.

06 — 응용 시나리오

01. 가스 누출 / 화재

MQ-2 또는 MQ-7이 임계값 초과 → 부저 + LED 경보 + 릴레이를 통한 자동 가스 밸브 차단, 그리고 게이트웨이로 Modbus TCP 이벤트 보고. 엣지 동작은 로컬에서 완결된다.

02. 낙상 감지

Jetson이 카메라 피드에서 YOLOv8을 실행한다. 낙상이 확정되면 게이트웨이가 클라우드를 통해 부동산 관리로 에스컬레이션하고, APP/SMS/음성 폴백이 동작한다.

03. 전기 안전

전압/전류 모니터링이 같은 Modbus TCP 레지스터 맵으로 들어온다. 과부하나 누전 이벤트는 동일한 경보 경로를 사용한다.

04. 부동산 관리 통합

와이어 프로토콜이 표준 Modbus TCP이기 때문에, 부동산 관리 회사는 수십에서 수백 가정을 단일 운영 센터로 집계할 수 있다.

결론

智安云盾은 W5500을 설계 의도대로 사용하는, 잘 통합된 학생 프로젝트다 — TCP/IP 스택 전체를 칩에 위임하고, 작은 Cortex-M3 위에서 깔끔한 Modbus TCP 서버를 돌리며, MCU가 본업인 센서 처리에 집중하게 한다.

이 프로젝트가 잘 보여주는 것:

✅ W5500 + ioLibrary + Modbus TCP — 완전하고 동작하는 레퍼런스 구현
✅ 엣지와 클라우드 책임의 깔끔한 분리
✅ 풀스택 통합: MCU + 엣지 AI + 백엔드 + 3D 프런트엔드

주장되었으나 독립 확인이 필요한 것:

⚠️ 10~20가구 시범 운영 (저장소에 미디어 증거 없음)
⚠️ AI 정확도 95% 초과 (실험실 자체 주장)

Q&A

Q. 왜 STM32에서 TCP 클라이언트가 아닌 TCP 서버로 동작시키는가? A. Jetson 게이트웨이가 Modbus TCP 마스터 역할을 하며 각 현장 노드를 폴링한다. W5500을 서버 모드로 두면 STM32가 움직이는 타겟에 대한 연결 재시도를 관리할 필요가 없다 — 그건 게이트웨이의 책임이다. 이는 표준 Modbus TCP 산업 패턴과 일치한다.

Q. 텔레메트리에는 W5500 UDP 모드를 써도 되지 않나? A. 두 가지 이유. (1) Modbus TCP가 표준이고, 이 프로젝트가 내세우는 가치 자체가 산업 프로토콜과의 정합이다. (2) 경보 이벤트는 TCP의 보장된 전달과 순서 보존의 혜택을 받는다. W5500의 하드웨어 TCP 스택 덕분에 이 선택이 MCU에게 사실상 무료다.

Q. 여러 W5500 노드로 확장 가능한가? A. 가능하다 — W5500은 최대 8개의 독립 하드웨어 소켓을 지원한다. 단일 칩이 Modbus TCP 서버, HTTP 펌웨어 업데이트 엔드포인트, 백업 브로커에 대

Documents

Comments Write

zhi-an-cloud-shield

Zhi'an Cloud Shield (智安云盾) — A Cloud-Edge-Device Smart Home Safety System

01 — What is this project?

02 — Why this architecture?

🔷 Reason 1 — Edge can act without the cloud

🔷 Reason 2 — Modbus TCP between the field node and the gateway

🔷 Reason 3 — Spatial dashboard

03 — System architecture

04 — Why W5500?

🔷 The constraint

🔷 W5500 usage mode: TOE TCP server (Sn_MR_TCP)

🔷 Why hardware TCP, not a software stack

🔷 What's verified in the code ✅

⚠️ What's claimed but not independently verified

05 — Key components

🌐 WIZnet W5500 — TOE TCP server, port 502 Modbus TCP slave

🧠 STM32F103C8T6

🤖 NVIDIA Jetson Orin Nano

🧪 Sensor set

🐍 Python / FastAPI cloud

🎨 Three.js 3D dashboard

06 — Application scenarios

01. Gas leak / fire

02. Fall detection

03. Electrical safety

04. Property management aggregation

Conclusion

Q&A

[한글 버전]

智安云盾 (Zhi'an Cloud Shield) — Cloud-Edge-Device 스마트 홈 안전 시스템

01 — 이 프로젝트는 무엇인가?

02 — 왜 이런 구조인가?

🔷 이유 1 — 엣지가 클라우드 없이 동작할 수 있다

🔷 이유 2 — 현장 노드와 게이트웨이 사이의 Modbus TCP

🔷 이유 3 — 공간 기반 대시보드

03 — 시스템 아키텍처

04 — 왜 W5500인가?

🔷 제약 조건

🔷 W5500 사용 모드: TOE TCP 서버 (Sn_MR_TCP)

🔷 왜 하드웨어 TCP인가, 소프트웨어 스택이 아니라

🔷 코드에서 검증되는 것 ✅

⚠️ 주장되었으나 독립적으로 검증되지 않은 것

05 — 핵심 컴포넌트

🌐 WIZnet W5500 — TOE TCP 서버, 포트 502 Modbus TCP 슬레이브

🧠 STM32F103C8T6

🤖 NVIDIA Jetson Orin Nano

🧪 센서 세트

🐍 Python / FastAPI 클라우드

🎨 Three.js 3D 대시보드

06 — 응용 시나리오

01. 가스 누출 / 화재

02. 낙상 감지

03. 전기 안전

04. 부동산 관리 통합

결론

Q&A

🔷 W5500 usage mode: TOE TCP server (`Sn_MR_TCP`)

🔷 W5500 사용 모드: TOE TCP 서버 (`Sn_MR_TCP`)