---
title: "How Does W5500 Communicate with OneNET Cloud Using HTTP?"
url: "https://maker.wiznet.io/mark/projects/how-does-w5500-communicate-with-onenet-cloud-using-http/"
markdown_url: "https://maker.wiznet.io/mark/projects/how-does-w5500-communicate-with-onenet-cloud-using-http/md"
type: "UCC: User Created Content"
author: "小蚂蚁2020"
author_url: "https://www.bilibili.com/video/BV13k4y1Q7Vw/?spm_id_from=333.1387.collection.video_card.click&vd_source=ab013cc5ffdecedae5ee47ae256d7306"
editor: "WIZnet"
editor_url: "https://maker.wiznet.io/"
original_author: "小蚂蚁2020"
original_url: "https://www.bilibili.com/video/BV13k4y1Q7Vw/?spm_id_from=333.1387.collection.video_card.click&vd_source=ab013cc5ffdecedae5ee47ae256d7306"
published: "2026-02-13"
language: "en"
likes: 0
views: 377
comments: 0
source: "WIZnet Makers (https://maker.wiznet.io/)"
---

# How Does W5500 Communicate with OneNET Cloud Using HTTP?

> This article analyzes an embedded system using the WIZnet W5500 Ethernet controller to communicate with the OneNET cloud platform via HTTP.

Original author: 小蚂蚁2020 (source: https://www.bilibili.com/video/BV13k4y1Q7Vw/?spm_id_from=333.1387.collection.video_card.click&vd_source=ab013cc5ffdecedae5ee47ae256d7306)

## Article

## How Does W5500 Communicate with OneNET Cloud Using HTTP?

### 4-Channel Switch Control, Data Upload, and Performance Analysis

**(W5500으로 OneNET 클라우드에서 HTTP 제어와 데이터 업로드는 어떻게 동작하는가?)**

---

### Summary (40–60 words)

This article analyzes an embedded system using the WIZnet W5500 Ethernet controller to communicate with the OneNET cloud platform via HTTP. By examining a four-channel switch control and two-channel data upload demo, it explains the end-to-end protocol workflow, throughput, and latency characteristics enabled by hardware TCP/IP offloading.

---

### 1. Why OneNET + Ethernet Is Still Relevant

OneNET is widely used in China for:

Industrial IoT gateways

Remote monitoring and control

Energy and infrastructure systems

While many OneNET devices rely on cellular or Wi-Fi, **Ethernet remains critical** for:

Fixed installations

Deterministic latency

Long-term stability

Easy debugging

Using **W5500 + HTTP** provides a clear, inspectable networking model suitable for industrial control.

---

### 2. System Architecture Overview

#### End-to-End Architecture

`4-Channel Switches / Sensors ↓ MCU Application Logic ↓ W5500 Socket Interface (SPI) ↓ W5500 Hardware TCP/IP Engine ↓ Ethernet Network ↓ OneNET Cloud HTTP API ↓ Web Dashboard / Control UI `

Key design choice:

> **All TCP/IP reliability is handled inside the W5500 hardware, not in firmware.**

---

### 3. Application Scenario: Control + Data Upload

This demo implements two main functions:

**4-channel switch control**

Cloud → device (downlink)

HTTP request triggers relay or GPIO action

**2-channel data upload**

Device → cloud (uplink)

Periodic sensor or status reporting

Both are implemented over **HTTP client connections**.

---

### 4. HTTP Communication Model on W5500

From the MCU’s perspective, HTTP is built on top of a **TCP client socket**.

#### Typical Workflow

`Network ready → TCP connect to OneNET server → HTTP request (GET / POST) → Server response → Parse payload → Close or reuse socket`

Important point:

> **W5500 does not understand HTTP. It only guarantees correct TCP transport.**

---

### 5. Socket Initialization and Lifecycle

#### TCP Client Setup (Conceptual)

Configure common network registers

Allocate TX/RX buffer sizes

Set socket mode = TCP

Configure destination IP and port

Issue CONNECT command

Wait for ESTABLISHED state

Only after this does HTTP communication begin.

---

#### Lifecycle per HTTP Transaction

`CLOSED → INIT → ESTABLISHED → DATA TX / RX → FIN_WAIT / CLOSED `

In many OneNET demos, the socket is closed after each transaction to keep logic simple.

---

### 6. Data Upload Path (2 Channels)

#### TX Data Flow

`Sensor data → Format HTTP payload → Write to TX buffer → Update TX write pointer → SEND command → W5500 transmits data`

Characteristics:

Payloads are small

Transmission time is negligible

Reliability is guaranteed by TCP hardware

Throughput requirements are very low, well within Ethernet capability.

---

### 7. Switch Control Path (4 Channels)

#### RX Data Flow

`Cloud issues control command → HTTP response arrives → Stored in W5500 RX buffer → RX size updated → MCU reads RX buffer → RX pointer updated → Parse command → Drive output channels`

Critical rule:

> **RX pointer must be advanced and RECV issued, or new commands will stop arriving.**

This is a common integration pitfall.

---

### 8. Performance, Throughput, and Latency Analysis

#### Throughput

Control commands: a few bytes

Data uploads: tens to hundreds of bytes

Ethernet bandwidth is vastly underutilized.
Throughput is not a bottleneck.

---

#### Latency

End-to-end latency includes:

`Cloud processing + Internet routing + TCP transmission + MCU parsing`

Observations:

W5500 adds negligible latency

Latency is dominated by network and cloud response

Control feels “instant” for human interaction

---

### 9. Stability and Long-Running Behavior

Hardware TCP/IP offloading provides:

No heap fragmentation

No TCP state machine bugs in firmware

Predictable socket behavior

This makes the design suitable for **24/7 industrial operation**.

---

### 10. Common Failure Modes (And Real Causes)

#### ❌ Cloud reachable, but control stops working

Cause:

RX buffer not drained

RECV command omitted

#### ❌ Data upload succeeds once, then fails

Cause:

Socket not properly closed or re-initialized

#### ❌ High latency observed

Cause:

Cloud-side throttling

Network path, not W5500

Most issues are **socket handling mistakes**, not HTTP problems.

---

### 11. Why W5500 Is a Good Match for OneNET

Deterministic Ethernet behavior

Clear register-level visibility

No dependency on large software stacks

Easy field debugging

These traits are highly valued in **industrial IoT deployments**.

---

### 12. Key Takeaway

> **In OneNET HTTP applications, W5500 turns cloud connectivity into a predictable socket and buffer management task—not a networking gamble.**

When TCP socket lifecycle and buffer handling are correct:

Control commands are reliable

Data uploads are stable

Performance remains consistent over time

---

### FAQ (Engineer-Focused)

**Q1. Does W5500 support OneNET protocol directly?**
No. It provides TCP/IP; HTTP runs on the MCU.

**Q2. Is HTTP suitable for control commands?**
Yes, for low-rate, human-scale control.

**Q3. Where does latency mainly come from?**
Cloud processing and Internet routing.

**Q4. Can sockets be kept alive?**
Yes, but requires careful RX/TX handling.

**Q5. Is this industrial-grade?**
Yes, for fixed Ethernet installations.

---

### Source

Bilibili video: **BV13k4y1Q7Vw**

WIZnet W5500 Datasheet

OneNET Cloud HTTP API documentation

---

### Tags

W5500, WIZnet, OneNET, HTTP IoT, Ethernet Control, Industrial IoT, Throughput, Latency

---

---

## 🇰🇷 한국어 번역 (1:1 Full Translation)

---

## W5500으로 OneNET 클라우드에서 HTTP 통신은 어떻게 동작하는가?

### 4채널 스위치 제어와 데이터 업로드 성능 분석

---

### 요약

본 문서는 WIZnet W5500 이더넷 컨트롤러를 사용해 OneNET 클라우드와 HTTP 통신을 수행하는 시스템을 분석한다. 4채널 스위치 제어와 2채널 데이터 업로드 데모를 통해, 엔드투엔드 프로토콜 흐름과 처리량, 지연 시간 특성을 설명한다.

---

### 1. OneNET과 이더넷의 의미

이더넷은
산업 현장에서 여전히 중요하다.

---

### 2. 시스템 아키텍처

`MCU ↓ W5500 하드웨어 TCP/IP ↓ OneNET 클라우드`

---

### 3. 제어 및 업로드 흐름

HTTP 요청/응답을 통해
제어와 데이터가 교환된다.

---

### 4. 성능 특성

처리량: 문제 없음

지연: 네트워크 의존적

안정성: 매우 높음

---

### 5. 흔한 오류

RX 포인터 미갱신

소켓 재초기화 누락

---

### 6. 핵심 메시지

> **W5500 기반 OneNET 통신은 네트워크가 아닌 소켓 관리 문제다.**

---

### 태그

W5500, OneNET, HTTP 통신, 산업용 IoT, 이더넷 제어

---

Source: https://maker.wiznet.io/mark/projects/how-does-w5500-communicate-with-onenet-cloud-using-http/