How to Build an IR Remote Gateway with W55MH32 for Industrial IoT and Ethernet-Based Remote Control?
This project uses the WIZnet W55MH32 as the main controller for an Ethernet-connected infrared gateway that can receive cloud commands,
How to Build an IR Remote Gateway with W55MH32 for Industrial IoT and Ethernet-Based Remote Control?
Summary
This project uses the WIZnet W55MH32 as the main controller for an Ethernet-connected infrared gateway that can receive cloud commands, decode them into appliance control actions, and transmit IR signals to legacy devices such as air conditioners. In this design, W55MH32 is not just the network interface. It is the MCU, the Ethernet endpoint, and the protocol execution layer for MQTT-based remote control, which makes the architecture compact and appropriate for Industrial IoT gateways, commercial controllers, and maker-grade retrofit devices.
What the Project Does
The source project is an IR remote gateway built around W55MH32, an IR transmit and learning path, local flash storage with W25Q64, and a cloud control path through a mobile mini-program and the OneNET platform. The stated goal is to retrofit traditional IR-controlled appliances that do not have built-in networking, so they can be switched and adjusted remotely over Ethernet rather than Wi-Fi.
Architecturally, the flow is straightforward. A client application sends device-property updates through OneNET’s HTTP interface, the cloud platform forwards them to the device through MQTT topics, the gateway parses the incoming JSON payload, converts the requested state into IR command data using the IRext library, and then emits the corresponding IR waveform. For codes that are not already present in the library, the author plans local storage using W25Q64 and FatFs so the gateway can persist learned IR codes on the device side.
For Industrial IoT and commercial use, the interesting part is not the IR transmitter itself. It is the fact that a non-networked field device can be represented upstream as a managed cloud endpoint, with a deterministic wired backhaul and a simple message bridge between cloud properties and local actuation. For maker use, the same structure is attractive because the design avoids a split-MCU-plus-Ethernet-module software architecture.
Where WIZnet Fits
The exact WIZnet product here is the W55MH32. In this project it plays three roles at once: application MCU, Ethernet controller, and TCP/IP offload engine. WIZnet’s documentation describes W55MH32 as a Cortex-M3 MCU running up to 216 MHz with 1024 KB Flash, 96 KB SRAM, integrated 10/100 Ethernet MAC and PHY, a hardwired TCP/IP stack, and 8 independent sockets with 32 KB internal Tx/Rx memory.
That matters for protocol handling. The project does not build its connectivity around a general-purpose software IP stack running on the application core. Instead, it uses the W55MH32 networking subsystem as the transport foundation beneath MQTT, with DHCP and DNS support referenced by the official example materials. This is a good fit for an IR gateway because the application logic is already doing timing-sensitive work on the local side, such as IR waveform generation, state tracking, and flash-backed code management. Offloading the network path reduces software complexity and leaves the application focused on command translation rather than packet plumbing.
From a performance and deployment perspective, the practical advantage is less about raw throughput and more about system shape. A gateway like this does not need high application-layer bandwidth, but it does benefit from predictable Ethernet connectivity, integrated MAC/PHY, reduced external BOM, and a clear socket-oriented programming model. Those are all relevant in industrial retrofit controllers, commercial building control nodes, and maker products that need to remain understandable and maintainable.
Implementation Notes
The source is a technical article rather than a complete repository with verified file paths, so exact project file paths cannot be cited. However, the article includes real code excerpts that show how the protocol path is structured on W55MH32, and those excerpts line up with WIZnet’s official MQTT example flow for OneNET.
One important excerpt is the MQTT state machine:
{
case CONN:
ret = MQTTConnect(&c, &data);
...
run_status = (ret != SUCCESSS) ? ERR : SUB;
break;
case SUB:
ret = MQTTSubscribe(&c, mqtt_params.subtopic,
mqtt_params.subQoS, message_Arrived);
...
run_status = (ret != SUCCESSS) ? ERR : KEEPALIVE;
break;
case KEEPALIVE:
if (MQTTYield(&c, 30) != SUCCESSS)
run_status = ERR;
This code, shown in the article, matters because it makes the network behavior explicit: connect to the broker, subscribe to the control topic, then stay alive in a maintenance loop that services MQTT traffic. For an Industrial IoT gateway, that is the real protocol spine of the product. The IR subsystem is local output; the MQTT state machine is the remote-control contract.
A second useful excerpt is the message callback path:
{
...
if (strcmp(topicname, mqtt_params.subtopic) == 0)
{
mqtt_recv_flag = 1;
memcpy(mqtt_recv_msg, msg, strlen(msg));
}
}
This is the handoff point from transport to application logic. The subscribed MQTT topic is treated as the command ingress, and the payload is staged for later JSON decoding instead of being acted on directly inside the callback. That is a sensible architectural choice for a gateway product because it keeps broker-facing code separate from appliance-control logic and makes error handling easier.
The JSON parsing step is also central to the design. The article’s json_decode() function extracts fields such as id and params, then uses that data to interpret the requested air-conditioner state and generate an acknowledgement on the reply topic. Combined with the IRext library and the planned flash-backed IR code storage, this creates a complete application chain from cloud property write to physical IR emission.
Practical Tips / Pitfalls
- Keep the MQTT transport and IR execution decoupled. The article already stages received MQTT payloads through a flag and buffer before JSON decoding, which is safer than doing heavy processing directly in the message callback.
- Treat topic design as part of the product architecture. This project subscribes to OneNET property-set topics and replies on the corresponding reply topic, so command semantics are tied directly to the cloud device model.
- Use Ethernet deliberately. The author explicitly chose Ethernet because Wi-Fi is easier to disturb and has relatively higher communication power cost in this use case. That reasoning is especially relevant for fixed gateways in plant rooms, equipment racks, or commercial installations.
- Do not assume the IR library solves the whole product. The article notes that IRext currently covers core functions such as power, fan speed, temperature, and swing, but the IR learning path is still incomplete and requires additional workflow design.
- Plan storage early. The project intends to store learned IR codes locally in W25Q64 through FatFs, which is important if you need field-added device support without constant cloud dependency.
- Watch timing interactions. IR generation, MQTT keepalive handling, and JSON processing all share the same embedded system. Even with hardwired TCP/IP underneath, poor task structure can still cause dropped keepalives or sluggish response to control events. This is an application-level scheduling issue, not a socket-limit issue.
FAQ
Q: Why use W55MH32 for this project instead of a separate MCU plus Ethernet chip?
A: Because this gateway needs both application control and reliable Ethernet messaging, and W55MH32 combines the MCU, integrated MAC/PHY, and hardwired TCP/IP stack in one device. That reduces external design complexity while keeping a socket-based programming model for the cloud path.
Q: How does W55MH32 connect into the platform architecture?
A: In this project it sits at the center of the device-side architecture. It handles the Ethernet link to OneNET, runs the MQTT client flow, receives JSON control messages, and then drives the IR control logic and local storage flow on the embedded side.
Q: What role does W55MH32 play in this specific project?
A: It is the protocol bridge between cloud-side device properties and local IR actuation. The mini-program writes device properties through OneNET, MQTT delivers those commands to the gateway, and W55MH32 parses and turns them into IR actions for the target appliance.
Q: Can beginners follow this project?
A: Maker-level developers can follow the broad structure, but it is not a beginner-only example. To reproduce it cleanly, you need working knowledge of MQTT topics, JSON parsing, IR protocol basics, and embedded task flow, especially if you want to finish the IR learning and local persistence path.
Q: How does this compare with Wi-Fi for the same gateway idea?
A: The source explicitly chooses Ethernet because Wi-Fi is more easily affected and has relatively higher communication power cost for this application. For industrial and commercial gateways, wired Ethernet also tends to simplify installation predictability and network stability, especially when the node is fixed in place and does not need wireless mobility.
Source
Original source: CSDN article “W55MH32-红外遥控网关” by love__yoona, published March 26, 2026, under CC BY-SA 4.0.
Supporting references: WIZnet W55MH32 product documentation, datasheet, and official OneNET MQTT example materials.
Tags
#W55MH32 #WIZnet #IndustrialIoT #EthernetGateway #MQTT #IRGateway #OneNET #EmbeddedEthernet #ProtocolHandling #CommercialIoT #MakerProject
W55MH32로 산업용 IoT 및 이더넷 기반 원격 제어용 IR 게이트웨이를 어떻게 구축할 수 있을까?
Summary
이 프로젝트는 WIZnet W55MH32를 메인 컨트롤러로 사용해, 클라우드 명령을 수신하고 이를 가전 제어 동작으로 해석한 뒤, 에어컨 같은 기존 적외선(IR) 기반 장치로 신호를 송신하는 Ethernet 기반 IR 게이트웨이를 구현합니다. 이 설계에서 W55MH32는 단순한 네트워크 인터페이스가 아니라 MCU, Ethernet endpoint, 그리고 MQTT 기반 원격 제어를 처리하는 프로토콜 실행 계층까지 맡습니다. 그 결과 아키텍처가 단순해지고, Industrial IoT 게이트웨이, 상업용 제어기, 메이커용 레트로핏 장치에 모두 적합한 구성이 됩니다.
What the Project Does
이 소스 프로젝트는 W55MH32를 중심으로, 적외선 송신 및 학습 경로, W25Q64 기반 로컬 플래시 저장, 그리고 미니프로그램과 OneNET 플랫폼을 통한 클라우드 제어 경로를 결합한 IR 리모컨 게이트웨이입니다. 목적은 네트워크 기능이 없는 기존 IR 제어 가전기기를 Wi-Fi가 아닌 Ethernet을 통해 원격 제어 가능하게 만드는 것입니다.
아키텍처 흐름은 비교적 명확합니다. 클라이언트 애플리케이션이 OneNET의 HTTP 인터페이스를 통해 장치 속성 업데이트를 보내면, 클라우드 플랫폼은 이를 MQTT 토픽을 통해 디바이스로 전달합니다. 게이트웨이는 수신한 JSON payload를 파싱하고, 요청된 상태를 IRext 라이브러리를 이용해 적외선 명령 데이터로 변환한 뒤, 대응하는 IR 파형을 송신합니다. 라이브러리에 없는 코드에 대해서는, 작성자가 W25Q64와 FatFs를 사용해 학습된 IR 코드를 로컬에 저장하는 구조도 계획하고 있습니다.
Industrial IoT와 상업용 관점에서 흥미로운 점은 IR 송신기 그 자체보다, 네트워크 기능이 없던 현장 장치를 상위 시스템에서는 관리 가능한 클라우드 endpoint로 표현할 수 있다는 데 있습니다. 유선 백홀을 바탕으로, 클라우드 속성과 로컬 구동 사이를 단순한 메시지 브리지로 연결하는 구조입니다. 메이커 관점에서도 MCU와 Ethernet 모듈을 따로 분리해 소프트웨어를 구성하지 않아도 된다는 점이 장점입니다.
Where WIZnet Fits
이 프로젝트에서 사용된 정확한 WIZnet 제품은 W55MH32입니다. 여기서 W55MH32는 세 가지 역할을 동시에 수행합니다. 애플리케이션 MCU, Ethernet controller, 그리고 TCP/IP offload engine입니다. WIZnet 문서에 따르면 W55MH32는 최대 216 MHz 동작의 Cortex-M3 MCU, 1024 KB Flash, 96 KB SRAM, 통합 10/100 Ethernet MAC/PHY, hardwired TCP/IP stack, 그리고 8개의 독립 소켓과 32 KB 내부 Tx/Rx 메모리를 갖습니다.
이 점은 프로토콜 처리 측면에서 중요합니다. 이 프로젝트는 범용 소프트웨어 IP 스택을 애플리케이션 코어에서 직접 돌리는 구조가 아니라, W55MH32의 네트워킹 서브시스템을 MQTT 하부 전송 계층으로 사용합니다. 공식 예제 자료에서도 DHCP와 DNS 지원이 언급됩니다. 이는 IR 게이트웨이 같은 장치에 잘 맞습니다. 애플리케이션 쪽은 이미 IR 파형 생성, 상태 관리, 플래시 기반 코드 저장 같은 타이밍 민감 작업을 수행하고 있기 때문입니다. 네트워크 경로를 오프로드하면 소프트웨어 복잡도를 줄이고, 애플리케이션은 패킷 처리보다 명령 해석에 집중할 수 있습니다.
성능과 배포 관점에서의 실질적 이점은 순수 처리량보다는 시스템 구조에 있습니다. 이런 게이트웨이는 높은 애플리케이션 계층 대역폭이 필요한 장치는 아니지만, 예측 가능한 Ethernet 연결, 통합 MAC/PHY, 줄어든 외부 BOM, 그리고 명확한 socket-oriented programming model의 이점을 얻습니다. 이런 특성은 산업용 레트로핏 컨트롤러, 상업용 빌딩 제어 노드, 유지보수가 쉬운 메이커 제품에서 모두 의미가 있습니다.
Implementation Notes
이 소스는 완전한 repository가 아니라 기술 블로그 형태이므로, 정확한 프로젝트 파일 경로를 검증해 인용할 수는 없습니다. 다만 글에는 W55MH32 위에서 프로토콜 경로가 어떻게 구성되는지 보여주는 실제 코드 발췌가 포함되어 있고, 이 내용은 WIZnet의 공식 OneNET MQTT 예제 흐름과도 맞아떨어집니다.
첫 번째로 중요한 부분은 MQTT 상태 머신입니다.
{
case CONN:
ret = MQTTConnect(&c, &data);
...
run_status = (ret != SUCCESSS) ? ERR : SUB;
break;
case SUB:
ret = MQTTSubscribe(&c, mqtt_params.subtopic,
mqtt_params.subQoS, message_Arrived);
...
run_status = (ret != SUCCESSS) ? ERR : KEEPALIVE;
break;
case KEEPALIVE:
if (MQTTYield(&c, 30) != SUCCESSS)
run_status = ERR;
이 코드는 네트워크 동작을 명확하게 보여줍니다. 브로커에 연결하고, 제어 토픽을 구독하고, 이후 유지 루프에서 MQTT 트래픽을 서비스합니다. Industrial IoT 게이트웨이 관점에서 이것이 제품의 실제 프로토콜 중심축입니다. IR 서브시스템은 로컬 출력부이고, MQTT 상태 머신이 원격 제어 계약을 담당합니다.
두 번째로 중요한 부분은 메시지 콜백 처리입니다.
{
...
if (strcmp(topicname, mqtt_params.subtopic) == 0)
{
mqtt_recv_flag = 1;
memcpy(mqtt_recv_msg, msg, strlen(msg));
}
}
이 부분은 transport와 application logic 사이의 handoff 지점입니다. 구독한 MQTT 토픽이 명령 유입 경로로 사용되고, payload는 콜백 안에서 바로 실행되지 않고 이후 JSON decoding을 위해 버퍼에 저장됩니다. 이는 게이트웨이 제품 구조로서 타당한 선택입니다. 브로커 처리 코드와 가전 제어 로직을 분리할 수 있고, 오류 처리도 단순해집니다.
JSON parsing 단계 역시 핵심입니다. 글의 json_decode() 함수는 id와 params 같은 필드를 추출하고, 그 데이터를 이용해 에어컨 상태 요청을 해석한 뒤 reply topic으로 응답을 생성합니다. 여기에 IRext 라이브러리와 향후 플래시 기반 IR 코드 저장을 결합하면, 클라우드 속성 쓰기부터 실제 IR 송신까지 이어지는 완전한 애플리케이션 체인이 형성됩니다.
Practical Tips / Pitfalls
- MQTT transport와 IR 실행 로직은 분리해 두는 것이 좋습니다. 이 글처럼 수신한 MQTT payload를 flag와 buffer에 먼저 적재한 뒤 JSON decoding을 하는 구조가, 메시지 콜백 안에서 바로 무거운 처리를 하는 것보다 안전합니다.
- topic 설계 자체를 제품 아키텍처의 일부로 봐야 합니다. 이 프로젝트는 OneNET의 property-set topic을 구독하고 대응 reply topic으로 응답하기 때문에, 명령 의미론이 클라우드 device model과 직접 연결됩니다.
- Ethernet 사용은 의도적으로 선택해야 합니다. 작성자는 Wi-Fi가 간섭에 더 취약하고, 이 용도에서는 통신 전력 소모도 상대적으로 크다고 판단해 Ethernet을 택했습니다. 이런 판단은 설비실, 제어반, 상업용 설치 환경처럼 고정형 게이트웨이에 특히 적합합니다.
- IR 라이브러리가 제품 전체를 해결해준다고 보면 안 됩니다. 글에서도 IRext가 전원, 풍속, 온도, 스윙 같은 핵심 기능은 다루지만, IR 학습 경로는 아직 미완성이고 추가적인 설계가 필요하다고 밝힙니다.
- 저장 구조는 초기에 설계하는 것이 좋습니다. 이 프로젝트는 학습한 IR 코드를 W25Q64에 FatFs로 저장하려고 하며, 이는 현장에서 새로운 기기를 추가 지원해야 할 때 클라우드 의존도를 낮추는 데 중요합니다.
- 타이밍 상호작용을 주의해야 합니다. IR 생성, MQTT keepalive 처리, JSON parsing은 모두 같은 임베디드 시스템 안에서 동작합니다. 하부 TCP/IP가 하드웨어 오프로드되어 있어도, 태스크 구조가 나쁘면 keepalive 누락이나 제어 응답 지연이 발생할 수 있습니다. 이는 소켓 수의 문제가 아니라 애플리케이션 스케줄링 문제입니다.
FAQ
Q: 별도의 MCU와 Ethernet 칩 조합 대신 왜 W55MH32를 쓰나요?
A: 이 게이트웨이는 애플리케이션 제어와 안정적인 Ethernet 메시징을 동시에 요구하는데, W55MH32는 MCU, 통합 MAC/PHY, hardwired TCP/IP stack을 한 칩에 결합합니다. 덕분에 외부 설계 복잡도를 줄이면서도 클라우드 경로는 socket 기반 프로그래밍 모델로 유지할 수 있습니다.
Q: W55MH32는 이 플랫폼 아키텍처에서 어떻게 연결되나요?
A: 이 프로젝트에서는 디바이스 측 아키텍처의 중심에 위치합니다. OneNET과의 Ethernet 링크를 처리하고, MQTT client 흐름을 실행하며, JSON 제어 메시지를 받아 적외선 제어 로직과 로컬 저장 흐름으로 넘깁니다.
Q: 이 프로젝트에서 W55MH32는 구체적으로 어떤 역할을 하나요?
A: W55MH32는 클라우드 측 device property와 로컬 IR 동작 사이의 protocol bridge입니다. 미니프로그램이 OneNET을 통해 device property를 쓰면, MQTT가 그 명령을 게이트웨이로 전달하고, W55MH32가 이를 파싱해 대상 가전의 IR 동작으로 변환합니다.
Q: 초보자도 따라갈 수 있나요?
A: 메이커 수준 개발자라면 전체 구조는 따라갈 수 있지만, 완전 초보용 예제는 아닙니다. 제대로 재현하려면 MQTT topic 구조, JSON parsing, IR 프로토콜 기초, 그리고 임베디드 task 흐름에 대한 이해가 필요합니다. 특히 IR 학습과 로컬 저장 경로까지 완성하려면 더 그렇습니다.
Q: 같은 게이트웨이 아이디어를 Wi-Fi로 구현하는 것과 비교하면 어떤가요?
A: 원문은 Wi-Fi가 더 쉽게 영향을 받고, 이 용도에서는 통신 전력 소모도 상대적으로 크다고 보고 Ethernet을 선택합니다. 산업용과 상업용 게이트웨이에서는 노드가 고정 설치되는 경우가 많기 때문에, 유선 Ethernet이 설치 예측성과 네트워크 안정성 측면에서 더 유리한 경우가 많습니다.
Source
Original source: CSDN article “W55MH32-红外遥控网关” by love__yoona, published March 26, 2026.
License: CC BY-SA 4.0
Supporting references: WIZnet W55MH32 product documentation, datasheet, and official OneNET MQTT example materials.
Tags
#W55MH32 #WIZnet #IndustrialIoT #EthernetGateway #MQTT #IRGateway #OneNET #EmbeddedEthernet #ProtocolHandling #CommercialIoT #MakerProject