Mosquitto 설치

MQTT 브로커인 Mosquitto 를 설치한다.

모스키토 다운로드 페이지

Mosquitto 설치시
Mosquitto 설치 디렉토리에 다음 파일을 복사에 주어야 한다.

OpenSSL dll 파일들(ssleay32.dll, libeay32.dll)과 pthreadVC2.dll
파일들
최근 버전의 OpenSSL 에는 ssleay32.dll과 libeay32.dll 파일들이 없으므로
Win32OpenSSL_Light-1_0_2h 이전 버전을 다운받아야 한다.

Win32OpenSSL 다운로드 페이지
pthreadVC2.dll 다운로드 페이지

설치후 실행중 에러 조치사항

컴퓨터에 MSVCR100.dll이(가) 없어 프로그램을 시작할 수 없습니다.
프로그램을 다시 설치하여 이 문제를 해결하십시오
시스템 오류 팝업이 뜨는 경우

Visual C++ 재배포 가능 패키지 다운로드
운영체제가 32비트인 경우 vredist_x86.exe
운영체제가 64비트인 경우 vredist_x64.exe와 vredist_x86.exe 둘다 다운로드

커맨드 창에서 unknown 에러가 뜨는 경우

Mosquitto Broker 서비스가 잘못 실행되는 경우가 있다. 컴퓨터를 재시작하고
[제어판][관리도구][서비스] 에서
Mosquitto Broker 서비스를 수동 혹은 자동으로 변경해준다.

[참고 페이지]
http://midnightcow.tistory.com/entry/MQTT-Sever-Mosquitto
http://deneb21.tistory.com/416
http://dalkomit.com/119
http://programmerchoo.tistory.com/132

[LoRa]Device Classes – Not All Nodes Are Created Equal

End-devices는 다양한 애플리케이션을 제공하고 다른 요구사항들을 갖는다. 다양한 end 애플리케이션 프로파일을 최적화하기 위해 LoRaWAN 은 각각 다른 device classes를 사용한다. 장치 class들은 네트워크 다운로드 통신 대기 시간(반응 시간)에 대해 배터리 수명의 균형을 맞춘다.제어 또는 구동 타입의 애플리케이션에서 다운로드 통신 반응시간은 중요한 요소이다.

양 방향의 end-devices(Class A):Class A의 End-device들은 양방향 통신을 위해 각
end-device의 상방향 전송 이후에 두개의 짧은 하방향 수신 윈도우가 따라온다. end-device에 의해 스케줄되는 전송 슬롯은 랜덤 시간 기반(ALOHA-type의 프로토콜)에 약간의 변형을 가하여 자신의 통신 필요에 기초를 둔다. 이 Class A 작업은 end-device가 상방향 전송을 보낸 후에 서버로부터 짧은 하방향 통신을 필요로 하는 가장 적은 전력을 소비하는 애플리케이션을 위한 end-device 시스템이다. 다른 시간의 서버로부터 하방향 통신은 다음 스케줄된 상방향 통신 때까지 기다려야 할 것이다.

스케줄된 수신 슬롯을 가진 양 방향의 end-devices(Class B): Class A 의 랜덤 수신
윈도우와 더불어, Class B 장치는 예정된 시간에 추가적인 수신 윈도우를 연다. end-device가 예정된 시간에 수신 윈도우를 열기 위해 게이트웨이로부터 시간 동기화된 신호를 받는다. 이는 서버가 end-device가 언제 귀기울이고 있는지를 알게 해준다.

최대 수신 슬롯을 가진 양방향 en-devices(Class C):Class C의 end-device는
전송시에만 닫아놓고 거의 계속해서 수신 윈도우를 열어놓는다.

[퍼온글]AI 스피커를 가진 자, IoT 지배한다

[아이티투데이 이경탁 기자] 최근 인공지능(AI) 기술이 음성인식 기반의 스피커 형태로 구체화되고 있다. 아마존, 구글, 애플, 페이스북 등의 글로벌 기업이 이미 제품을 출시하거나 준비할 뿐 아니라 국내 대표 ICT 기업인 삼성전자, 네이버도 한창 개발 중인 것으로 알려졌다. SKT 또한 지난달 31일 음성인식 기반 인공지능 서비스 ‘누구‘와 전용기기를 공개했다. 이처럼 각 분야에서 내노라 하는 AI 스피커 제품을 개발하는 이유는 향후 사물인터넷(IoT), 특히 스마트홈이라 불리는 홈 IoT 시장을 선점할 수 있기 때문이다. 스마트홈은 집안의 가전제품, 수도, 전기, 보안기기 등 모든 것을 통신망으로 연결해 모니터링과 제어할 수 있는 기술이 구현된 집을 뜻한다. IoT 구현에는 빅데이터 서비스가 핵심기술로 사용. 예를 들면 우리 집 냉장고가 나의 퇴근 시간 패턴을 빅데이터로 분석한 뒤 퇴근 시간에 맞춰 저녁 메뉴를 추천해주는 상황이 가능해지는 것이다. 경제협력개발기구(OECD) 조사에 따르면 현재 가정당 인터넷에 연결된 기기는 10개 수준이며 오는 2022년에는 가정당 인터넷에 연결된 기기가 50개에 이를 것으로 예상된다. x ▲ 최근 AI 기술이 음성인식 기반의 스피터 형태로 구체화되고 있다 (사진=위키피디아) 하지만 안 그래도 수 많은 앱이 깔려 복잡한 스마트폰에서 홈IoT까지 구현하기에는 사용자들의 피로성을 증가시킬 수 있다는 지적이다. 이에 기업들이 집안의 기기들을 목소리만으로 간편하게 컨트롤할 수 있는 AI 스피커 제품을 개발하는 것이다. AI 스피커는 딥러닝(사람처럼 학습하는 인공신경망) 기술을 활용한 인공지능 알고리즘이 제품 속에 탑재된 사용자와 음성으로 커뮤니케이션을 할 수 있는 기기다. 예를 들어 사용자가 음성으로 “신나는 음악을 틀어줘”, “날씨가 더운데 에어컨을 틀어줘”같은 명령어를 내리면 수행하게 된다. 아마존이 지난 2014년 선보인 에코 같은 경우는 음성인식과 블루투스 기능을 갖췄다. ‘알렉사’라고 불러 음악 재생을 요청하거나 인터넷에 연결된 조명을 켜고 끌 수 있다. 이외에도 길이나 위치에 대해 물어보거나 스포츠 경기는 언제 하는지 물어보고 전자책을 읽어 달라할 수 있다. 아마존에서 에코의 제품 평점은 5점 만점에 4.4점 사용자들의 평가도 후한 편이다. 아마존은 지속적인 기술 개발을 통해 같은 가격 또한 대폭 낮춘다는 계획이다. ▲ 아마존 AI 알렉사가 탑재된 스피커 '에코' (사진=플리커) 구글 또한 지난 5월 구글개발자회의에서 ‘구글 어시스턴트’를 탑재한 구글홈을 선보였다. 현재 구글의 지주회사 알파벳의 홈 기술 기업 네스트의 엔지니어들이 구글에 투입되어 기술 개발에 더욱 박차를 가하고 있다. SKT의 누구는 음악 스트리밍 서비스, 조명, 제습기, 플러그, TV 등 가전기기를 제어하고 음악추천 및 자동 재생, 날씨·일정 등 정보 안내, 스마트폰 위치 찾기 등의 기능이 가능하다. 박일환 SK텔레콤 디바이스 지원단장은 “과거 키보드에서 마우스로, 이후 터치로 입력방식이 진화하며 우리의 일상이 크게 변해 왔다”며 “누구를 시작으로 음성인식과 인공지능이 생활 전반을 획기적으로 바뀌는 AI 대중화 시대를 열어갈 것”이라고 밝혔다. 한편, 삼성전자도 마찬가지로 스피커 형태 인공지능 홈 비서 ‘스쿱’을 준비 중인 것으로 알려졌다. 네이버는 연내 출시를 목표로 홈 비서인 ‘라온’을 개발 중에 있지만 타사와 같이 스피커 제품 형태로 내놓을지는 미정이다.

[퍼온글]Amazon Web Service(AWS) IOT

AWS IoT 디바이스 SDK

AWS IoT에서는 하드웨어 디바이스 또는 모바일 애플리케이션을 쉽고 빠르게 연결할 수 있도록 SDK를 제공합니다. AWS IoT 디바이스 SDK를 사용하면 디바이스에서 MQTT, HTTP 또는 WebSockets 프로토콜을 사용하여 AWS IoT와 연결하고, 인증하고, 메시지를 교환할 수 있습니다. 디바이스 SDK는 C, JavaScript 및 Arduino를 지원하며, 클라이언트 라이브러리, 개발자 안내서 및 제조업체용 포팅 안내서를 포함합니다. 또한, 이를 대체하는 오픈 소스를 사용하거나 자체 SDK를 작성할 수 도 있습니다.
자세한 내용은 AWS IoT 디바이스 SDK 설명서를 참조하거나 SDK를 다운로드하여 시작하십시오.

 디바이스 게이트웨이

AWS IoT 디바이스 게이트웨이를 사용하면 디바이스가 AWS IoT와 안전하고 효율적으로 통신할 수 있습니다. 디바이스 게이트웨이는 게시/구독 모델을 사용하여 메시지를 교환할 수 있으며, 이러한 모델은 1대1 및 1대 다수 통신을 가능하게 합니다. AWS IoT는 이러한 1대 다수 통신 패턴을 통해 연결된 디바이스가 데이터를 해당 주제의 여러 구독자에게 브로드캐스트할 수 있게 해줍니다. 디바이스 게이트웨이는 MQTT, WebSockets 및 HTTP 1.1 프로토콜을 지원하며, 고유 또는 레거시 프로토콜을 지원하도록 손쉽게 구현할 수 있습니다. 디바이스 게이트웨이는 인프라 프로비저닝 없이 수십억 개의 디바이스를 지원하도록 자동으로 확장됩니다.
자세한 내용은 AWS IoT 사용 설명서의 프로토콜을 참조하십시오.

인증 및 권한 부여 
AWS IoT는 모든 연결 지점에서 상호 인증 및 암호화를 제공하므로 디바이스와 AWS IoT 간에 입증된 자격 증명 없이는 데이터가 교환되지 않습니다. AWS IoT는 AWS의 인증 방법(‘SigV4’라고 부름)뿐 아니라X.509 인증서 기반 인증을 지원합니다. HTTP를 사용하여 연결하면 이러한 메서드 중 하나를 사용할 수 있고, MQTT를 사용하여 연결하면 인증 기반 인증서를 사용할 수 있으며, WebSockets를 사용하여 연결하면 SigV4를 사용할 수 있습니다. AWS IoT에서는 AWS IoT에서 생성한 인증서뿐만 아니라 선호하는 인증 기관(CA)에서 서명한 인증서도 사용할 수 있습니다. 원하는 역할 및/또는 정책을 각 인증서에 매핑하여 디바이스 또는 애플리케이션에 액세스 권한을 부여하거나, 마음이 바뀐 경우 디바이스를 직접 조작하지 않고도 액세스 권한을 모두 취소할 수 있습니다.
콘솔이나 API를 사용해 디바이스에 대한 인증서와 정책을 생성, 배포 및 관리할 수 있습니다. 이러한 디바이스 인증서는 AWS IAM를 사용해 구성된 관련 정책으로 프로비저닝 및 활성화하고 해당 정책과 연결할 수 있습니다. 이를 통해 원하는 경우, 개별 디바이스에 대한 액세스를 즉시 취소할 수 있습니다. 또한, AWS IoT는 앱 사용자에 대한 고유 식별자를 생성하고 제한적인 임시 AWS 자격 증명을 가져오는 데 필요한 모든 단계를 처리하는 Amazon Cognito를 사용하여 사용자의 모바일 앱으로부터의 연결도 지원합니다.
자세한 내용은 AWS IoT 사용 설명서의 보안 및 인증 섹션을 참조하십시오.

레지스트리 
레지스트리는 디바이스에 대한 자격 증명을 설정하고 디바이스의 속성 및 기능 같은 메타데이터를 추적합니다. 레지스트리는 디바이스 유형이나 연결 방식과 관계없이 지속적으로 형식이 지정되는 각 디바이스에 고유 자격 증명을 지정합니다. 또한, 예를 들어 센서가 온도를 보고하는지 그리고 데이터가 화씨인지 섭씨인지와 같은 디바이스의 기능을 설명하는 메타데이터를 지원합니다.
레지스트리를 사용하면 추가 비용 없이 디바이스에 관한 메터데이터를 저장할 수 있으며, 최소 7일에 한 번 이상 레지스트리 항목을 액세스 또는 업데이트하기만 하면 레지스트리에 저장된 메터데이터가 계속 유지됩니다.
자세한 내용은 AWS IoT 사용 설명서의 레지스트리 섹션을 참조하십시오.

디바이스 섀도 
AWS IoT에서는 디바이스의 최신 상태가 포함된 각 디바이스의 영구, 가상 버전 또는 "섀도"를 생성하여 애플리케이션이나 다른 디바이스가 메시지를 읽고 해당 디바이스와 상호 작용할 수 있습니다. 디바이스 섀도는 디바이스가 오프라인이더라도 각 디바이스의 최종 보고된 상태와 원하는 이후 상태를 유지합니다. API 또는 규칙 엔진을 사용하여 디바이스의 최종 보고된 상태를 가져오거나 원하는 이후 상태를 설정할 수 있습니다.
디바이스 섀도에서는 언제나 사용 가능한 REST API를 제공함으로써 디바이스와 상호 작용하는 애플리케이션을 손쉽게 구축할 수 있게 해줍니다. 또한, 애플리케이션은 디바이스의 현재 상태를 확인하지 않고도 디바이스의 원하는 이후 상태를 설정할 수 있습니다. AWS IoT는 원하는 상태와 최종 보고된 상태의 차이를 비교하여 디바이스에게 차이를 없애도록 명령합니다.
AWS IoT 디바이스 SDK를 사용하면 디바이스에서 손쉽게 섀도와 상태를 동기화하고, 섀도에서 설정한 원하는 이후 상태를 처리할 수 있습니다.
디바이스 섀도에서는 최대 1년까지 무료로 디바이스 상태를 저장할 수 있습니다. 디바이스 섀도는 최소 1년에 한 번 이상 업데이트하면 영구적으로 유지되며 그렇지 않은 경우 종료됩니다.
자세한 내용은 AWS IoT 사용 설명서의 디바이스 섀도 섹션을 참조하십시오.

규칙 엔진 
규칙 엔진을 사용하면 인프라를 관리할 필요 없이 글로벌 규모로 연결된 디바이스에서 생성된 데이터를 수집, 처리, 분석하고 이를 기반으로 조치를 취할 수 있습니다. 규칙 엔진은 AWS IoT에 게시된 수신 메시지를 평가하고, 정의한 비즈니스 규칙에 따라 다른 디바이스나 클라우드 서비스로 이를 변환 및 전송합니다.규칙은 하나 이상의 디바이스의 데이터에 적용할 수 있으며 하나 이상의 작업을 동시에 수행할 수 있습니다.
또한, 규칙 엔진은 AWS Lambda, Amazon Kinesis, Amazon S3, Amazon Machine Learning, Amazon DynamoDB, Amazon CloudWatch, Kibana와 기본적으로 통합되어 있는 Amazon Elasticsearch Service 등과 같은 AWS 엔드포인트로 메시지를 라우팅할 수 있습니다. 외부 엔드포인트에는 AWS Lambda, Amazon Kinesis 및 Amazon Simple Notification Service(SNS)를 사용해 전달할 수 있습니다.
관리 콘솔에서 규칙을 작성하거나 유사 SQL 구문을 사용하여 규칙을 작성할 수 있습니다. 규칙은 메시지의 콘텐츠에 따라 다르게 동작하도록 작성할 수 있습니다. 예를 들어, 온도 값이 특정 임계치를 초과하는 경우 AWS Lambda로 데이터를 전송하도록 규칙을 트리거할 수 있습니다. 또한, 규칙은 다른 서비스의 데이터와 같이 클라우드의 다른 데이터를 고려하도록 작성할 수 있습니다. 예를 들어, 온도가 5개의 다른 디바이스 평균보다 15% 이상 높으면 조치를 취하도록 할 수 있습니다.
규칙 엔진은 데이터 변환에 사용할 수 있는 수십 개의 함수를 제공하고, AWS Lambda를 사용해 원하는 만큼 추가로 함수를 생성할 수 있습니다. 예를 들어, 다양한 값을 처리해야 하는 경우 수신되는 숫자의 평균을 사용할 수 있습니다. 또한, 규칙은 AWS Lambda에서 Java, Node.js 또는 Python 코드가 실행되도록 트리거할 수 있으므로 디바이스 데이터 처리를 위한 최고의 유연성 및 기능을 제공합니다.

[출처] Amazon Web Service(AWS) IOT|작성자 동시사랑