[펌] IoT Platform Thingsboard

ThingsBoard

수많은 IoT 플랫폼들중 사용자 GUI까지 잘구성되어 있는 IoT 플랫폼이 있어서 사용해 보고 간단히 평해보려고 합니다

IoT 플랫폼을 도입하고자하는 사업장이나 개인에 도움이 되었으면 좋겠습니다

ThingsBoard (https://thingsboard.io) 는 문서화가 잘 되어 있어 문서와 동영상을 참조하면 어느 정도까지 사용에 문제가 없습니다

다만 이 글에서는 이러한 내용을 찾아보고 실행하고 익히는 과정의 이해를 가능한 줄여보고자 작성하였습니다

ThingsBoard는 일반적으로 우리가 알고 있는 클라우드 기반의 IoT 플랫폼의 구조를 따르고 있습니다

Cloud 또는 Private Cloud에 ThingsBoard를 설치하고 ThingsBoard에 센서/액츄에이터나 그밖의 디바이스를 연결하는 구조를 취하고 있습니다

기본적으로 Monolithic 아키텍쳐라 부르는 독립실행이 가능하며 또한 마이크로 서비스 아키텍쳐라고 명시되어 있는 구조를 사용하여 분산처리 기능을 제공하여 큰 규모의 서비스에도 대응하고 있습니다

일단 보편적으로 사용될 Monolithic 아키텍쳐인 독립실행으로 ThingsBoard의 기능을 알아보고자 합니다

ThingsBoard의 독립 아키텍쳐는 아래와 같습니다

위에서 설명한바와 같이 일반적인 IoT 플랫폼들의 구조와 유사한 구조를 취하고 있으며 직관적인 사용자 인터페이스를 제공한다는 점이 ThingsBoard의 가장 큰 장점이 되겠습니다

일단 ThingsBoard에서 제공하는 관리 단위에 대한 이해가 우선 필요합니다

ThingsBoard에서는 시스템 관리자(system Administrator) / 임차인 관리자(Tenant Administrator) / 고객(CUSTOMERS) / 사용자(USER) / 자산(ASSETS) / 디바이스(DEVICES) 와 같은 대표직인 키워드가 존재합니다

이러한 키워드간에는 아래와 같이 할당되는 관계성을 갖고 있습니다

ThingsBoard는 Community Edition과 Professional Edition으로 구분되며 Professional Edition은 오픈소스로 배포되는 Community Edition에서 특정 기능들이 추가되고 이에 따라 1년단위 과금이 필요한 버전입니다

설치는 기본적으로 윈도우/우분투/맥 환경 모두 지원하며 Docker를 사용하여 설치하거난 각각의 패키지를 설치하는 형태로 설치할수도 있습니다

설치 관련 문서 : https://thingsboard.io/docs/installation

설치가 완료되었다면 http://IP주소:9090 또는 http://IP주소:8080 주소로 웹브라우저를 통해 접속 할 수 있으며

시스템관리자 계정은 sysadmin@thingsboard.org / sysadmin 으로 로그인 할 수 있습니다

System 관리자로 로그인시 아래와 같은 UI를 보실수 있으며

Tenant 관리자에 대한 추가 및 삭제 관리와 시스템 세팅(접속 포트 / 보내는 이메일 서버 정보)에 대한 설정 권한을 갖고 있습니다

Tenant 관리자는 System 관리자로 부터 생성되며 고유한 로그인 계정을 갖게되며 

해당 계정으로 로그인하면 아래와 같은 UI를 보실수 있습니다

ThingsBoard의 기본 기능들인 룰체인(RULE CHAINS), 고객관리(CUSTOMER), 자산관리(ASSETS), 디바이스관리(DEVICES), 데시보드관리(DASHBOARD)를 포함하는 기능을 관리합니다

USER는 CUSTOMER가 생성하는 사용자계정으로 해당 계정으로 로그인하면 아래와 같이 제한된 UI를 볼수 있으며

Tenant 관리자가 CUSTOMER에게 할당한 ASSETS이나 DEVICES와 DASHBOARD 만 모니터링 할 수 있는 권한을 갖게 됩니다

ThingsBoard는 Tenant 관리자에서 CUSTOMERS 을 추가 할 수 있는데 이렇게 생성된 고객은 ThingsBoard의 동작에 있어 핵심이 되는 부분입니다

CUSTOMERS에서는 IoT서비스가 제공 받을 개체를 지정할수 있습니다

ASSETS과 DEVICES와 DASHBOARD는 특정 CUSTOMER에 지정 될 수 있습니다 지정의 의미는 해당 CUSTOMER가 각각의 자원의 사용 권한을 갖는다는 의미이기도 합니다

ASSETS은 특정한 정보를 담은 자산으로 DASHBOARD를 구성시 필요한 정보를 이 ASSETS에 설정한 데이터값을 참조하여 사용할수 있습니다

ASSETS는 특정 CUSTOMER에게 할당되거나 Public으로 설정하여 전역으로 사용 할 수도 있습니다

예시적으로 한개의 CUSTOMER가 여러 지역에 공장을 가지고 있다고 가정한다면 공장A 공장B가 있을 수 있고 이러한 공장이 어디에 위치하고 있는지 이 공장에서 사용될 특정한 데이터 참조 값을 지정하여 가져다 사용 할 수 있는 기능을 제공합니다

DEVICES는 임차인 관리자가 관리하는 센서나 액츄에이터 그밖에 모든 ThingsBoard와 연결가능한 장치를 나타내며 등록된 장치는 임차인 관리자가 특정 CUSTOMERS에게 할당하여 해당 DEVICES를 사용할수 있는 권한을 지정하게 됩니다

결과적으로는 현장에 대입시 다음과 같은 구조를 취할 수 있게 됩니다

기본적으로 이러한 각 항목의 이해관계를 통해 ThingsBoard의 동작이 정의됩니다

따라서 System 관리자는 Tenant 관리자를 생성하여 주고

Tenant 관리자는 CUSTOMERS를 생성한뒤

ASSETS와 DEVICES를 생성하고 DASHBOARD를 생성하여 CUSTOMER에게 할당하게 됩니다

우선은 ASSET을 다음과 같이 생성하여 봅니다

생성된 ASSET에서 CUSTOMER 할당 버튼을 클릭하여 위에서 생성한 CUSTOMER를 지정합니다

그 다음으로 ASSET에 설정의 ATTRIBUTES에 key(String형)값으로 address를 value는 주소를 입력하여 데이터를 추가하여 봅니다 

또한 latitude와 longitude의 key값을 갖는 value(Double형)에 GPS 임의 좌표값을 넣습니다 (이미지 참조)

이제 디바이스(센서/액츄에이터/그밖에)를 추가합니다

ASSET과 마찬가지로 CUSTOMER에게 할당하고 DEVICE설정에서 ATTRIBUTES에서 

xPos 0.5 / yPos 0.5 로 key와 value(Double형)를 생성합니다  이 값은 추후 DASHBOARD에서 센서위치를 표시하는데 사용합니다

그리고 생성한 DEVICE 설정에서 토큰값을 복사합니다

아래 버튼을 클릭하면 자동 클립보드에 복사됩니다

이 값은 실제 센서나 액츄에이터와 ThingsBoard에 연결시 고유한값으로 인증에 사용됩니다

물리적인 센서 디바이스를 구하기전에 ThingsBoard에서는 더미값을 발생할수 있는 소스를 제공하고 있습니다

이 코드를 사용하여 마치 온습도 센서 값이 들어오는 것으로 테스트 해볼수 있습니다

우분투 PC기준으로 다음 커맨드를 실행하여 emulator.js 를 다운받습니다 (이 프로그램을 수행하기 위해서는 node.js 실행환경이 구축되어야 합니다)

#> wget https://gist.githubusercontent.com/ashvayka/4735c78541cebd26f3ed3d340743c697/raw/1466bfbdd112937aa4d567cf4b0c939dc90321f2/emulator.js

위 명령을 수행하여 emulator.js를 다운받은뒤에

#> npm install

을 실행하여 node.js 의존 패키지를 다운받습니다

다음은 emulator.js파일을 열어 서버 주소를 수정합니다

파일 내용중 아래 변수값을 ThingsBoard가 실행된 서버 주소로 변경합니다

const thingsboardHost = “192.168.0.100”;

이제 아래와 같이 토큰값을 추가하여 실행합니다 emulator는 온습도 값을 명시된 토큰인증으로 ThingsBoard에 게시하게 됩니다

#>node emulator.js FhrBfDqANbZcjJOxQfXV 

이 과정이 정상적으로 수행되었다면 DEVICE의 설정항목의 LATEST TELEMETRY 항목에 온습도 값이 발생되는것을 확인 할 수 있습니다

위와 같이 ASSET과 DEVICE를 CUSTOMER에 할당하였다면

마지막으로 DASHBOARD를 생성한뒤 CUSTOMER에게 할당합니다

생성된 DASHBOARD로 진입하여 WIDGET생성을 클릭하여 진입하면 다음과 같은 WIDGET선택 항목을 볼 수 있습니다

우선은 Maps를 선택한뒤 LATEST VALUES의 OpenStreetMap을 선택합니다

아래와 같이 추가되는 Map Widget의 Add 설정을 볼 수 있습니다

우선 여기서는 ADD를 선택한뒤 보이는 Type에 Entity를 Parameters에 임의의 값(여기서는 factory1-map)을 입력한뒤 보이는 Create a new one을 클릭합니다

아래와 같이 Add alias 팝업이 발생되고 Type을 Filter type에 Single entity를 Type은 Asset을 Asset에는 이전에 생성되어 표시되는 ASSET을 선택합니다

이제 Attribute를 클릭하면 추가 가능한 key가 표시됩니다

맵에서 공장위치를 표시하기위해서 ASSET 생성시 속성으로 추가한 latitude와 longitude 값을 사용합니다

그 뒤 확인을 클릭하면 아래와 같이 맵과 함께 지정한 위치에 마커가 표시됩니다

다음으로는 등록한 DEVICE에서 발생되는 온습도 정보를 WIDGET을 통해 표시하여 보겠습니다

위에서와 마찬가지로 Add new widget을 선택한뒤 Charts에서 Timeseries – Flot 를 선택하여 봅니다

Parameters에 임의 parameter값을 넣어 alias를 생성합니다

alias에서는 DEVICE정보를 가져올것이기 때문에 Type에서 Device를 선택한뒤 등록된 DEVICE를 선택합니다

이제 Timeseries에 humidity와 temperature를 선택할수 있게 됩니다

한개의 Chart Widget에서 온습도를 표시할수도 있고 Chart Widget을 각각 생성하여 아래와 같이 Widget를 생성할수도 있습니다

다음으로는 센서가 설치된 위치도 도면도와 유사하게 Widget을 활용하여 표시할수 있습니다

위와 같이 Maps에서 LASTEST VALUES의 Image Map을 선택합니다

위에서 DEVICE 온습도 추가방법과 동일하게 진행후 Attributes에서 xPos와 yPos를 선택합니다

그리고 ADVANCED 탭을 선택한뒤 공장도면도를 등록합니다

저장하게 되면 아래와 같이 도면에 센서위치 마크가 표시됩니다

마지막으로 

RULE CHAINS는 IOT 디바이스에서 발생되는 데이터를 기반으로 특정 조건에 부합하면 특정 동작을 수행할수 있는 기능을 제공합니다

RULE CHAIN은 1개의 ROOT RULE CHAIN 과 다수의 RULE CHAIN 으로 구성이 됩니다

메인 룰 체인에서 받은 데이터를 온도 체크 룰 체인으로 전달하여 처리하는 형태로 구성하여 볼 수 있습니다

ROOT RULE CHAIN은 따로 생성할 필요없이 기본적으로 구성되어 있으며 아래와 같이 Post telemetry로 들어오는 데이터가 Success인 경우 다른 온도 체크 룰 체인으로 넘기도록만 추가 합니다

일단은 위와 같이 온도 체크 룰 체인을 생성합니다 

이후 메인 룰 체인으로 진입한뒤 좌측의 node 항목에서 Rule Chain항목의 node를 선택하여 아래 그림과 같이 위치합니다

rule chain node 설정시 Rule chain항목에는 자동으로 사용자가 생성한 Rule Chain 리스트가 표시되기에 위에서 생성한 온도 체크 룰을 선택하면 됩니다

참고로 이전에 등록한 DEVICE에서 들어오는 온습도 데이터값이 아래 Post telemetry를 통과하고 있습니다

이제 온도 체크 룰 체인의 내용을 아래와 같이 채워 봅니다

Input -> script -> alarm node로 구성이 됩니다

script에서는 온도 제한치에 대한 조건을 명시하고 조건에 True인 경우 Alarm을 발생하는 구조입니다

script의 filter에서는 들어온 메시지의 tempeature가 24도 이상이면 True인 조건을 작성합니다

Alarm은 아래와 같이 명시합니다 (Alarm details builder 의 코드는 저도 어떤 구조인지는 확인을 해봐야 할듯 합니다)

참고로 Debug mode도 선택합니다

이렇게 RULE CHAIN을 생성하면 DASHBOARD를 통해 Alarm을 받아 볼 수 있습니다

DASHBOARD에 Alarm Widge을 선택합니다

Alarm 설정에서 Alarm source는 Entity로 지정후 기존의 DEVICE alias를 선택합니다

등록된 Alarm Widget은 위의 RULE CHAIN에서 설정된 온도값 이상 온도값이 발생되면 다음과 같이 표시됩니다

이상 ThingsBoard를 사용하여 기본적인 설정을 추가하여 IoT환경을 구축하는 방법에 대해 알아 보았습니다

이 게시글에서 언급된 내용은 ThingsBoard의 일부기능으로 사용자의 역량에 따라 더 다양한 방법으로 사용될수 있을것이라 생각됩니다

마지막으로 구성된 DASHBOARD는 사용자 계정으로 접근하여 다음과 같은 화면으로 모니터링 할 수 있게 됩니다

이러한 ThingsBoard가 기본적으로 제공하는 기능에 대해서 REST API를 제공하고 있습니다

사용자가 프론트엔트로 ThingsBoard의 리소스를 파악하고 싶다면 다음과 같은 방법으로 RESTful API를 사용해볼 수 있습니다

 curl -X POST –header ‘Content-Type: application/json’ –header ‘Accept: application/json’ -d ‘{“username”:”tenant@thingsboard.org”, “password”:”tenant”}’ ‘http://THINGSBOARD_URL/api/auth/login’

위 명령으로 REST API를 사용하기 위한 Token을 획득 할 수 있습니다

username은 Tenant 계정을 password 값은 해당 계정의 패스워드 값으로

THINGSBOARD_URL은 자신이 thingsboard를 설치한 장치의 IP주소(예시:192.168.0.100:9090)

그렇게 curl 명령을 수행하면 아래와 같은 출력값이 발생됩니다

 {“token”:”eyJhbGciO-중략-iJIUzl8g”,”refreshToken”:”eyJhbGciz-중략-uI1xg”}

이 값중에 token에 해당하는 값을 REST API 사용시 Header에 X-Authorization에 “Bearer token값” 형태로 지정하여 사용합니다

(token 값 앞에 “Bearer “가 붙는점 유의)

ThingsBoard에서는 REST API에 대한 사용 편의를 위해서 swagger를 지원하고 있으며

http://ThingsBoard설치IP주소:9090/swagger-ui.html

위 주소로 접속하면 아래와 같은 swagger 페이지에 접속 할 수 있으며 손쉽게 API 사용해 볼 수 있습니다

사용전에는 Authorize를 클릭하여 value항목에 위에서 생성된 token값을

“Bearer Token값” 형태로 입력합니다 (Bearer는 token값과 별도로 붙여야 합니다)

Postman 프로그램사용하여 API 테스트 하고자 하실때는 다음과 같이 Header에 token값을 추가하면 인증됩니다


답글 남기기

이메일 주소는 공개되지 않습니다. 필수 항목은 *(으)로 표시합니다