IoTDataHub
https://www.arduinolibraries.info/libraries/io-t-data-hub
W5500 이더넷 + MQTT로 만드는 "Blynk 스타일" IoT 대시보드 연동 드롭인 라이브러리 (IoTDataHub)
WiFi·이더넷·셀룰러를 가리지 않고 동일한 코드로 클라우드 대시보드에 붙이고 싶지만, 매번 연결·재접속·토픽 관리 코드를 다시 짜는 것이 IoT 펌웨어의 반복 비용이다. IoTDataHub는 이 "전송 계층 보일러플레이트"를 라이브러리로 흡수하고, 개발자는 가상핀 핸들러(IoTDATAHUB_WRITE/READ)와 begin()/run()만 작성하도록 단순화한 Arduino용 MQTT 클라이언트 라이브러리다 — 그리고 그 전송 옵션 중 하나가 WIZnet W5100/W5500 이더넷이다.
COMPONENTS
Hardware components
- WIZnet W5500 / W5100 기반 이더넷 (Arduino Ethernet Shield 호환, 표준
Ethernet.h경로) — 본 글의 WIZnet 적용 지점 - 대안 전송용 MCU/모듈: ESP32, ESP8266, Raspberry Pi Pico W(RP2040), Arduino MKR WiFi 1010, Nano 33 IoT, ENC28J60, TinyGSM(SIM800/SIM900/SIM7600), MKR GSM 1400, MKR NB 1500, STM32 + ESP8266 AT 쉴드
- 네트워크: DHCP 가능한 이더넷/인터넷 회선, MQTT 브로커
Software & Tools
- IoTDataHub 라이브러리 v1.1.0 / v1.1.1 (2026-06-17 릴리스, MIT)
- PubSubClient ≥ 2.8 (필수 의존성, MQTT 클라이언트)
- Arduino IDE / Arduino Library Manager
- IoTDataHub 대시보드(디바이스 ID·토큰 발급처) [확인 필요 — 플랫폼 공개 운영 여부 미확인]
출처 안내 원문 출처: Arduino Library List 등재 페이지(https://www.arduinolibraries.info/libraries/io-t-data-hub) 및 공식 저장소 README(https://github.com/iotpioneers/iotdatahub-library). 원 작성자: Emmanuel SHYIRAMBERE / IoTPioneers Ltd. 재구성 관점: 단순 번역이 아니라, 라이브러리 소스 코드(
IoTDataHub.cpp,IoTDataHubSimpleEthernet.h)를 직접 확인해 W5500 이더넷을 MQTT 전송 계층으로 쓰는 구조와 가상핀·LWT 동작 원리를 WIZnet Maker 독자 관점에서 재서술했다. 본문의 기술적 사실은 모두 공개 저장소에서 확인 가능한 범위로 한정했고, 미확인 항목은 [확인 필요]로 표기했다.
작성자 / 출처 신뢰도
재구성자(본 글 게시자)
- WIZnet Maker 에디토리얼 관점에서 재작성. 기술 검증은 공식 저장소 소스 대조로 수행.
원 프로젝트 작성자: Emmanuel SHYIRAMBERE (GitHub: iotpioneers)
- 공개 활동(확인됨)
- GitHub Org
iotpioneers: 단일 공개 저장소iotdatahub-library, 팔로워 2명, 저장소 Star 0 / Fork 0 (게시 시점 기준). 초기 단계 프로젝트. - 릴리스: v1.1.0 "Initial Arduino Library Manager release" (2026-06-17). 커밋 약 62건.
- Arduino 공식 Library Manager 등재(Contributed 타입), MIT 라이선스.
- GitHub Org
- 배경 정보(제3자 집계 기반, [확인 필요])
- 인물 데이터 집계 서비스(ZoomInfo) 기준, 르완다 키갈리 소재 풀스택 개발자이며 과거 IoT Pioneers의 Software Development Lead로 표기됨. University of Rwanda 학사, Cisco Networking Academy CCNA(ITN) 이수로 기록됨.
- 위 인물 정보는 동명이인 가능성·집계 오류 여지가 있어 1차 출처로 단정하지 않는다. 다만 "Emmanuel SHYIRAMBERE + IoT Pioneers" 조합의 일치도는 높은 편이다.
- 미확인 항목: 소속사 매출, SNS 활동량, IoTDataHub 클라우드 플랫폼의 상용 운영 규모 등은 공개 출처가 없어 기재하지 않는다. [확인 필요]
신뢰도 요약: 코드·라이선스·등재는 공개 출처로 명확히 확인되나, 커뮤니티 채택도(별·포크·이슈)는 아직 낮고 플랫폼 운영 실체는 미확인이다. 학습/참조용 레퍼런스로서는 가치가 있으나, 양산 펌웨어에 그대로 채택하기 전엔 검증이 필요하다.
신규 콘텐츠 요약
- 무엇인가: 전송 계층(WiFi/이더넷/셀룰러)과 MQTT 연결·재접속·토픽 관리를 라이브러리로 추상화하고, 개발자는 가상핀 핸들러만 작성하게 하는 Blynk 스타일의 드롭인 IoT 클라이언트 라이브러리.
- 사용 칩(WIZnet 관점): W5100 / W5500 (표준 Arduino
Ethernet.h경유). 그 외 ESP32/ESP8266/RP2040/SAMD/STM32 등 다양한 MCU. - 프로토콜: MQTT(PubSubClient 기반), 디바이스 상태에 LWT(Last Will & Testament) 적용, QoS 1, retained 메시지.
- 플랫폼: IoTDataHub 대시보드(디바이스 ID·토큰 발급) [확인 필요].
- 핵심 가치: "전송 수단이 달라도 애플리케이션 코드는 그대로." 특히 WIZnet 사용자에겐 WiFi 없이 W5500 유선 이더넷으로 동일한 대시보드 연동을 얻는 경로가 의미 있다.
유사한 기존 콘텐츠 (WIZnet Projects)
단순 키워드가 아니라 칩(W5x00 이더넷) · 프로토콜(MQTT) · 플랫폼(Blynk/클라우드) · 가상핀 중 2개 이상이 겹치는 것을 우선 선별했다.
1) IRIV IO Controller Series: RS-485(Modbus) → Ethernet → Cloud (Blynk / ThingSpeak / MQTT)
- 링크: https://maker.wiznet.io/irina/projects/iriv-io-controller-series-rs-485-modbus--ethernet--cloud-blynk-thingspeak-mqtt-agricult/
- 유사한 이유: W5x00 이더넷 + MQTT + Blynk 가상핀 + 멀티 클라우드 추상화라는 4개 축이 모두 겹친다. "하나의 코드 골격으로 여러 클라우드 경로에 보낸다"는 발상이 IoTDataHub의 추상화 철학과 사실상 동일.
- 다른 점: 이 글은 CircuitPython 기반 튜토리얼이며 코드 스켈레톤 제공 방식. IoTDataHub는 Arduino C++ 패키지 라이브러리이고 GSM/NB-IoT 전송까지 포함.
- 연결 포인트: "왜 가상핀 추상화가 필요한가"를 설명할 때 이 글을 멀티플랫폼 사례로, IoTDataHub를 패키지화 사례로 대비시키면 좋다.
2) IRIV IO Controller IoT Gateway : Blynk
- 링크: https://maker.wiznet.io/irina/projects/iriv-io-controller-iot-gateway--blynk/
- 유사한 이유: W5x00 이더넷으로 Blynk 가상핀(V0/V1)에 값 전송. IoTDataHub의
virtualWrite(Vx, value)모델과 1:1로 매핑되는 개념(원 튜토리얼: Cytron, Hussien Jawhar Sathik). - 다른 점: 단일 플랫폼(Blynk)·CircuitPython이며 MQTT/LWT 추상화나 재접속 루프 같은 라이브러리 내부 메커니즘은 다루지 않음.
- 연결 포인트: "가상핀이란 무엇인가"의 입문 레퍼런스로 링크하고, IoTDataHub는 그 개념을 라이브러리 매크로로 박제한 버전으로 소개.
3) IoT Lighting and Curtain Control System (Arduino 101 + WIZ750SR + Blynk)
- 링크: https://maker.wiznet.io/Hannah/projects/iot-lighting-and-curtain-control-system-built-with-arduino-101-wiz750sr-and-blynk/
- 유사한 이유: WIZnet 네트워킹 + Blynk 대시보드로 액추에이터(조명/커튼) 양방향 제어. 대시보드 → 디바이스 명령 흐름이 IoTDataHub의
IoTDATAHUB_WRITE(Vx)콜백과 동일한 패턴. - 다른 점: WIZ750SR(시리얼-이더넷 게이트웨이)을 쓰는 반면 IoTDataHub는 W5500을 **SPI 네이티브
Ethernet.h**로 직접 구동. 또한 라이브러리가 아니라 완성형 프로젝트. - 연결 포인트: "장치 제어(쓰기)" 섹션의 실사용 예시로 인용 가능.
차이점과 확장 가치
기존 콘텐츠와의 차이
- 기존 WIZnet 사례 다수는 특정 보드 + 특정 플랫폼(주로 Blynk/CircuitPython) 에 묶인 완성형 프로젝트다. IoTDataHub는 그 패턴을 전송 비종속(transport-agnostic) C++ 라이브러리로 일반화했고, W5500 이더넷을 WiFi/GSM과 동급의 교체 가능한 백엔드로 취급한다.
- MQTT 내부 동작(상태 LWT, retained, QoS 1, 자동 재접속)을 사용자에게 숨기고 매크로 API만 노출 → 학습 곡선이 낮다.
확장 가치 / 연결 아이디어
- 유선 결정성 강조 포지셔닝: WiFi 예제가 많은 생태계에서, "공장·빌딩처럼 무선이 불안정한 환경에선 W5500 유선으로 동일 대시보드를 쓴다"는 각도로 확장하면 차별화된다.
- WIZnet 보드 포팅 갭 메우기: 현재 이더넷 경로는 범용
Ethernet.h에 의존한다. W5500-EVB-Pico2 / W6300 계열용 전용 예제를 추가 기고하면 기존 IRIV·WIZ750SR 사례와 라이브러리 사이의 빈칸을 채울 수 있다. - 보안 계층 결합: 아래 "개선 여지"의 TLS 부재 이슈를, WIZnet 보안 모듈/시큐어 엘리먼트 기반 mTLS 적용 후속 글로 연결할 수 있다.
PROJECT DESCRIPTION
문제 제기: 똑같은 센서·액추에이터 로직인데, 전송 수단이 WiFi에서 이더넷으로, 다시 셀룰러로 바뀔 때마다 연결·재접속·토픽·콜백 코드를 처음부터 다시 짜야 한다면, 정작 "장치가 무엇을 하는가"라는 핵심 코드는 어디에 두어야 할까?
이 프로젝트의 답은, 전송 계층과 MQTT 세션 관리를 라이브러리 내부로 밀어 넣고, 사용자 스케치에는 가상핀 핸들러와 begin()/run() 두 줄짜리 생애주기만 남기는 것이다. 전송이 W5500 이더넷이든 ESP32 WiFi든, 위쪽 애플리케이션 코드는 단 한 글자도 바뀌지 않는다.
0. 핵심 기술 / 부품 설명 — W5500과 "전송 비종속" 구조
핵심은 코어 클래스(IoTDataHubClass)가 Client 인터페이스 하나에만 의존한다는 점이다. 보드별 헤더가 알맞은 클라이언트 객체를 만들어 코어에 주입한다.
이더넷 경로(IoTDataHubSimpleEthernet.h)는 표준 Arduino Ethernet.h의 EthernetClient를 그대로 코어에 넘긴다. 즉 W5100/W5500은 별도 드라이버 없이 기존 Arduino 이더넷 스택 위에서 MQTT 전송 매체가 된다.
// IoTDataHubSimpleEthernet.h (요지) #include <Ethernet.h> #include <PubSubClient.h> #include "IoTDataHub.h" static EthernetClient _iotdh_net; // W5100/W5500 소켓 IoTDataHubClass IoTDataHub(_iotdh_net); // 코어에 주입W5500은 하드웨어 TCP/IP 오프로드를 제공하므로, MCU는 소켓 상태머신 대신 애플리케이션 로직에 집중할 수 있다. 이 라이브러리의 추상화 철학과 W5500의 "연결을 칩에 위임" 철학이 자연스럽게 맞물린다.
1. 개발 도구 / 플랫폼 설명
설치는 라이브러리 폴더 배치 + PubSubClient(≥2.8) 설치가 전부다. 보드별 헤더를 하나 선택해 include 하면 그 전송용 전역 IoTDataHub 인스턴스가 만들어진다. 디바이스 ID/토큰은 대시보드에서 발급받아 #define 또는 begin() 인자로 주입한다. (대시보드 플랫폼의 공개 운영 여부는 [확인 필요].)
2. 동작 원리
흐름은 연결 → 구독 → 콜백 디스패치 → 가상핀 핸들러 실행의 단방향 루프다. run()이 loop()에서 호출되며 재접속과 수신 처리를 모두 담당한다.
토픽 스킴(소스 확인):
- 상태:
devices/{deviceId}/status - 명령 구독:
devices/{deviceId}/cmd/# - 가상 읽기 요청: 토픽에
/vr/포함
3. 장치 A 구현 — 센서값 업로드(쓰기→대시보드)
장치가 값을 올릴 땐 virtualWrite(Vx, value) 한 줄이면 된다. 내부적으로 해당 가상핀 토픽으로 publish 된다. 연결/재접속은 사용자가 신경 쓰지 않는다.
4. 장치 B 구현 — 명령 수신(대시보드→장치)
대시보드에서 가상핀에 값을 쓰면, 구독 중인 cmd/# 토픽으로 메시지가 도착하고 해당 핀의 IoTDATAHUB_WRITE(Vx) 핸들러가 호출된다. 릴레이/LED 제어가 전형적 예시다.
IoTDATAHUB_WRITE(V3) { // 대시보드가 V3에 쓰면 호출 digitalWrite(LED_PIN, param.asInt() ? HIGH : LOW); IoTDataHub.virtualWrite(V2, param.asInt()); // 상태 회신 }5. 핵심 통신 / 보안 / 제어 로직 — LWT와 디스패치
가장 눈여겨볼 부분은 연결 시점에 LWT를 등록한다는 점이다. 브로커는 장치가 비정상 종료해도 상태 토픽을 자동으로 OFFLINE(QoS 1, retained)으로 바꿔준다. 정상 연결 시엔 ONLINE을 retained로 publish 하므로, 대시보드는 항상 최신 접속 상태를 알 수 있다.
// _connectMQTT() 요지 bool ok = _mqtt.connect(_deviceId, _token, "", _topicStatus, 1, true, "OFFLINE"); // ← LWT if (ok) { _mqtt.publish(_topicStatus, "ONLINE", true); // retained _mqtt.subscribe(_topicCmdAll, 1); // QoS 1 }콜백 디스패치는 토픽 마지막 경로 세그먼트를 핀 번호로 파싱하고, /vr/ 포함 여부로 읽기/쓰기를 가른다. 페이로드는 {"value": ...} 형태를 가정한 경량 파서로 값만 추출한다(키가 없으면 원문 그대로 사용).
6. 검증 / 예외 처리
라이브러리가 방어하는 지점과 한계가 명확하다.
- 핀 범위 검사:
0 ≤ pin < IOTDH_MAX_VPINS밖이면 무시. - 핸들러 미등록 핀: 콜백에서 그냥 반환(무동작).
- 페이로드 버퍼: 256바이트 고정. 초과분은 잘림.
- 재접속: 실패 시 3초 후 재시도하는 블로킹 루프(
while(!connected)).
7. 서버 & 결과
결과적으로 사용자 스케치는 전송 선택 헤더 1줄 + 가상핀 핸들러 + begin()/run() 으로 줄어든다. W5500 이더넷을 쓰면 WiFi 없이도 동일한 대시보드 모니터링/제어가 동작한다. 다만 본 라이브러리는 신규(릴리스 직후) 단계라 실사용 채택 사례·장기 안정성 데이터는 아직 공개되지 않았다. [확인 필요]
Takeaways
- 추상화의 핵심은
Client인터페이스 의존이다. 코어가 전송 구현을 모르도록 설계하면 W5500/WiFi/GSM이 교체 가능한 부품이 된다 — 재사용 가능한 IoT 펌웨어 설계의 정석. - LWT + retained 상태 토픽은 적은 코드로 "장치 생존 여부"를 신뢰성 있게 노출하는 모범 패턴이다.
- WIZnet 입장에선, 이 라이브러리가 W5500을 WiFi의 단순 대안이 아니라 "동일 API, 다른 물리계층" 으로 위치시킨다는 점이 의미 있다.
개선 여지
- TLS 부재(이더넷 경로): 예제는 평문
EthernetClient+ 토큰 인증. 공개망 배포 시 mTLS/시큐어 엘리먼트 결합이 필요. - 블로킹 재접속 루프:
while(!connected) delay(3000)은loop()를 멈춘다. 결정성이 중요한 산업 제어에는 논블로킹 재접속 옵션이 바람직. - 수제 JSON 파서:
"value"키만 처리하는 문자열 탐색 방식은 중첩/배열 페이로드에 취약. ArduinoJson 등 정식 파서가 더 견고. - 고정 256B 버퍼·
toInt()핀 파싱: 긴 페이로드 잘림, 비숫자 토픽이 핀 0으로 오라우팅될 여지. - 성숙도: Star/Fork 0, 이슈 트래킹 사실상 부재 — 양산 채택 전 직접 검증 권장.
신규 설계 시 참고
- 전송 비종속 라이브러리를 직접 만들 땐 코어를
Client(또는 그에 준하는 추상 인터페이스)에만 의존시키고, 보드별 어댑터 헤더로 분리하라. - 상태 가시성은 연결 시 LWT 등록 + retained 'ONLINE' 조합으로 저비용 구현하라.
- WIZnet 환경 특화 기고를 노린다면, 범용
Ethernet.h대신 W5500-EVB-Pico2 / W6300 전용 예제와 유선 결정성·보안 메시지를 결합하면 기존 Maker 콘텐츠 대비 빈칸을 채울 수 있다.
Documents
- Arduino Library 등재 페이지: https://www.arduinolibraries.info/libraries/io-t-data-hub
- 공식 저장소(README/소스/예제): https://github.com/iotpioneers/iotdatahub-library
- 의존성 PubSubClient: https://github.com/knolleary/pubsubclient
- 관련 WIZnet 사례
- IRIV IO Controller Series (Blynk/ThingSpeak/MQTT): https://maker.wiznet.io/irina/projects/iriv-io-controller-series-rs-485-modbus--ethernet--cloud-blynk-thingspeak-mqtt-agricult/
- IRIV IO Controller IoT Gateway : Blynk: https://maker.wiznet.io/irina/projects/iriv-io-controller-iot-gateway--blynk/
- IoT Lighting & Curtain Control (WIZ750SR + Blynk): https://maker.wiznet.io/Hannah/projects/iot-lighting-and-curtain-control-system-built-with-arduino-101-wiz750sr-and-blynk/
본 콘텐츠는 공개 출처로 확인 가능한 사실에 기반해 재구성되었으며, [확인 필요] 표기 항목은 1차 출처 확보 전까지 단정하지 않았다. 라이브러리는 게시 시점 기준 초기 단계로, 인용 수치(별·포크·릴리스일 등)는 변동될 수 있다.
