MQTT Client로 개발하기
MQTT API 시작하기
App/Web 서버가 ThingPlug에서 제공하는 기능을 사용하려면 ThingPlug Resource API를 사용해야 합니다. 이 문서에서는 ThingPlug의 Resource API를 간단히 테스트 해보기 위하여 MQTT.fx라는 툴을 사용합니다. MQTT.fx를 이용하여 ThingPlug로 최신 데이터, 제어 명령(Downlink) 등과 같은 Resource API를 요청하고, ThingPlug로 부터 이에 대한 응답을 받아보도록 하겠습니다. MQTT 설치의 경우, http://mqttfx.jensd.de/index.php/download에 접속하여 PC의 환경에 맞게 최신 버전을 다운로드하고 설치 합니다. (본 문서의 경우, MQTT.fx Version 1.5.0-windows-x64를 설치 하였습니다.)
ThingPlug 접속하기
실행 후, MQTT 접속에 대한 설정을 하기 위해 표시된 ‘톱니바퀴 모양’ 버튼을 클릭합니다.

좌측 하단의 ‘+’ 버튼을 클릭 하여 새로운 프로필을 생성 합니다.

ThingPlug에 MQTT 프로토콜을 통해 접속하려면 정해진 규칙을 따라야 하며 규칙은 다음 표와 같습니다.
옵션 | 내용 |
---|---|
Profile Name | 해당 프로필을 나타내는 이름으로 작성 Ex) MQTT_ThingPlug_TEST |
Broker Address | mqtt.sktiot.com |
Broker Port | 1883(MQTT), 8883(MQTTS) |
Client ID | ThingPlug 계정_Random Value Ex) ThingPlug계정 ID: TPMQTT Client ID: TPMQTT_01 |
위와 같이 ThingPlug 규칙을 따라서 MQTT 프로필 정보를 입력한 후, ‘User Credentials’ 탭을 클릭합니다.

‘User Credentials’ 탭에 입력해야 하는 정보는 다음과 같습니다
옵션 | 내용 |
---|---|
User Name | ThingPlug 계정 |
Password | ThingPlug 계정 사용자 인증키(User Key) |
SSL/TLS를 사용하지 않는 일반 MQTT 접속을 위해서는 SSL/TLS 설정을 변경할 필요가 없습니다.

그러나, MQTTS 접속을 위해서는 Broker Port를 8883으로 변경 후, ‘SSL/TLS’ 탭을 클릭하여 다음과 같이 설정 합니다.

설정을 모두 완료 하였다면 ‘Apply’ – ‘Cancel’ 버튼을 차례로 클릭합니다. 설정한 프로필을 선택한 후, ‘Connect’버튼을 클릭합니다.

접속 되면 다음과 같이 우측 상단이 초록색 불이 켜지는 것을 확인 할 수 있습니다.

MQTT 발행/구독토픽 규칙
MQTT 프로토콜의 기본적으로 발행/구독 기반 통신이며, 송신자는 브로커에게 특정 토픽으로 메시지를 발행하고 수신자가 브로커에게 같은 토픽에 대해 구독을 요청하게 되면 브로커는 송신자가 발행한 메시지를 수신자에게 전달합니다. ThingPlug에서는 이와 같은 MQTT 프로토콜을 지원하며 다음은 대표적으로 ThingPlug와 App/Web 서버간의 MQTT 프로토콜을 이용한 통신을 나타내는 그림입니다.

App/Web 서버가 MQTT 프로토콜을 사용하여 ThingPlug와 통신할 때, 발행 및 구독을 수행하려면 다음과 같은 토픽 규칙을 따라야 합니다.
발행 Topic | 구분 | ThingPlug Resource API 요청을 하기 위한 Topic |
---|---|---|
사용 예 | /oneM2M/req/[Client ID]/[LTID] | |
구독 Topic | 구분 | Subscription에 대한 Push 데이터를 받기 위한 Topic |
사용 예 | /oneM2M/req/+/[clientID] | |
구분 | 요청에 대한 응답을 받기 위한 Topic | |
사용 예 | /oneM2M/resp/[clientID] |
ThingPlug Resource API 구조
ThingPlug Resource API를 사용하기 위해 ThingPlug Resource API 구조를 알아보도록 하겠습니다. ThingPlug의 Resource API 구조는 다음과 같이 계층 구조입니다.
예를 들어 ContectInstance에 접근하려면 ‘CSEBase/SCV Version/remoteCSE/Container/ContectInstance’ 와 같은 형태로 접근해야 합니다.

그림에서 확인할 수 있는 Resource API에 대한 설명은 다음과 같습니다.
생성순서 | Resource API Type | 설명 |
---|---|---|
1 | Node | LoRa 디바이스의 물리적 정보를 저장하는 Resource API |
2 | remoteCSE | LoRa 디바이스의 Uplink 데이터와 같은 논리적 정보를 저장하는 Root Resource API |
3 | Container | LoRa 디바이스의 Uplink 데이터가 저장되는 저장소 Resource API |
4 | ContentInstance | 실제 Uplink 데이터가 저장되는 Resource API |
5 | mgmtCmd | LoRa 디바이스 제어 Resource API |
MQTT 프로토콜을 이용하여 최신 데이터 요청을 위해 발행할 경우, Request message 내부 <to> 속성에 요청하는 리소스 위치가 들어가야 합니다. 이와 같이 최신 데이터를 요청할 때는 <to> 속성에 최신 데이터를 의미하는 ContentInstance의 위치가 들어가야 하며, 이 때, 최신 데이터에 해당하는 ContentInstance 리소스 위치와 실제 ThingPlug Resource API 구조와 비교하여 설명 드리도록 하겠습니다.

만약, LoRa 디바이스 정보가 다음과 같을 때,
값 | 내용 |
---|---|
AppEUI | 0000000000000004 |
LTID | 00000004d02544fffef03b47 |
최신 데이터인 ContentInstance에 접근하기 위해서는 Request message 내부 <to> 속성에 다음과 같이 작성 해야 합니다.
Request message 내부 <to> 속성 |
---|
<to>/0000000000000004/v1_0/remoteCSE-00000004d02544fffef03b47/Container-LoRa</to> |