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

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

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

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

6. Data Upload Path (2 Channels)

TX Data Flow

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

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:

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. 시스템 아키텍처

3. 제어 및 업로드 흐름

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

4. 성능 특성

처리량: 문제 없음

지연: 네트워크 의존적

안정성: 매우 높음

5. 흔한 오류

RX 포인터 미갱신

소켓 재초기화 누락

6. 핵심 메시지

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

태그

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