개발 가이드

IoT Portal 서비스 개발에 필요한 개발 가이드 입니다.

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 접속에 대한 설정을 하기 위해 표시된 ‘톱니바퀴 모양’ 버튼을 클릭합니다.

MQTT 접속 설정

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

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’ 탭을 클릭합니다.

MQTT User Credentials 규칙

‘User Credentials’ 탭에 입력해야 하는 정보는 다음과 같습니다

개발가이드 설명
옵션 내용
User Name ThingPlug 계정
Password ThingPlug 계정 사용자 인증키(User Key)

SSL/TLS를 사용하지 않는 일반 MQTT 접속을 위해서는 SSL/TLS 설정을 변경할 필요가 없습니다.

SSL/TLS 를 사용하지 않는 일반 MQTT 접속 설정

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

SSL/TLS 를 사용하는 MQTTS 접속 설정

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

설정한 MQTT 브로커에 접속

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

MQTT 접속 확인

MQTT 발행/구독토픽 규칙

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

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’ 와 같은 형태로 접근해야 합니다.

ThingPlug Resource API 구조

그림에서 확인할 수 있는 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 구조와 비교하여 설명 드리도록 하겠습니다.

ThingPlug Resource API 구조와 MQTT 기반 최신 데이터 조회 Request message 비교

만약, LoRa 디바이스 정보가 다음과 같을 때,

개발가이드 설명
내용
AppEUI 0000000000000004
LTID 00000004d02544fffef03b47

최신 데이터인 ContentInstance에 접근하기 위해서는 Request message 내부 <to> 속성에 다음과 같이 작성 해야 합니다.

개발가이드 설명
Request message 내부 <to> 속성
<to>/0000000000000004/v1_0/remoteCSE-00000004d02544fffef03b47/Container-LoRa</to>

top