Amazon のクラウドとESP8266 を接続することを目標に､ AWS IoT のお勉強を始めようと思います｡ これらは私の試行錯誤の記録です｡
私は WEB屋さんではないので､あまりクラウド側は得意ではないのですが､そうも言っていられない時代なので､少しづつですが勉強していこうと思います｡
ESP8266 をインターネットに繋ぐ
まず ESP8266 は Wi-Fi機能を内蔵しているので､インターネットに接続することは問題なく可能です｡ しかし､インターネット側から ESP8266 を宛先にして通信する為には変化しない宛先が無ければいつでも満足に通信することが出来ません｡ 宛先とはIPアドレスとか WEBページのURLのことです｡
Google home や Amazon Alexa から 壁コンを操作できるようにしてみた
の記事では ルーターによってコレを肩代わりする形で実現しています｡
家中に ESP8266 をばら撒くとして､その全てにIPアドレスやURLを割り振るのは効率が悪いため､代表者を1つ用意して､代表者が 其々の ESP8266 に配信する方法を取ります｡ 代表者を家庭内ネットワークに置く場合は固定されたIPアドレスやURLが必要になりますが､この代表者を Amazon に任せよう というのが AWS IoT の利用目的となります｡
なお､代表者から ESP8266 への配信は同じ事になるのですが､ ESP8266 から代表者に接続させることでコレを回避します｡
ここで言う 代表者や配信プロトコルに MQTT という仕組みを使用します｡
MQTTについて簡単に
- MQTT とは Message Queuing Telemetry Transport プロトコル 事で､ IoT に適した軽量なプロトコルとされています｡
- この MQTT 自体には暗号化は必須では無いですが､ TLSを使った暗号化通信も可能です｡
- メッセージのやり取りは先の代表者として､ ブローカー と呼ばれる役割の端末が仲介します｡
- メッセージを贈りたい人は パブリッシャー､ 受け取りたい人はサブスクライバー と呼びます｡
- パブリッシャー､サブスクライバー は 1つの ESP8266 の中に同時に持つ事ができます｡
- メッセージはトピックというカテゴリ分けをすることが出来ます｡
- サブスクライバーはトピックを指定してブローカーに受信契約を申し込みます｡
- パブリッシャーはトピックを指定してブローカーにメッセージを配信します｡
- サブスクライバーが申し込んでいない､自分に関係のないトピックは配信されません｡
- パブリッシャーに配信状況は通知されません｡
- なお､トピックの指定にワイルドカードが使用できます｡
- QoSが設定できます｡
今回ブローカーには AWS IoT を使用します｡
AWS IoT を使用する上での制限もあります
- 通信はTLS1.2の暗号化が必要となります｡
- QoS 0 でサブスクライブするとメッセージは0回以上配信されます｡
この場合､異なるパケットIDで送信される事があります｡ - QoS 2 はサポートされていません｡
- メッセージの保持はサポートされていません｡
- 同じクライアントIDを使用することは出来ません｡
- 永続セッションはサポートされていません｡
- MQTT over WebSocket をサポートしています｡
これらに対応していく必要があります｡
Direct MQTT と MQTT over WebSocket
このあたりは自身が無いので補足説明とか指摘をしてもらえると嬉しいのですが､
AWS IoT に MQTT で接続する場合に､ 直接 MQTTプロトコル で接続する方法と､ WebSocket を使って MQTTプロトコルを通す方法があります｡
まず､WEBアプリケーションから MQTT を使いたい場合は JavaScriptで書かれたライブラリがあるので､ WebSocket を使う必要があるようです｡
他には Direct MQTT の場合､(暗号化されていない場合) 1883ポートや (暗号化された場合)8883ポート を使用するが､ファイアーウォールの設定が変えられない場合､ WebSocket を使用することで回避できる｡ ( WebSocket で使う HTTP(s) ポートは閉じられていないだろう )
※これはブローカー側の話しで AWS IoT を使うならクライアントは関係ない?
デメリットとして､ WebSocket を使うと 効率は悪化する｡ オーバーヘッドが増える｡
AWS IoT のサポートプロトコルとして､ Direct MQTTではクライアント証明書を使用するが､ MQTT over WebSocket では SigV4 で認証が必要となる｡
WeSocket で HTTP(s)ポートを使うと書いたが､ WebSocket のハンドシェイクをHTTP通信によって行うだけで､通信自体は HTTP を使うわけではない｡ (そうだとしたら､せっかくMQTTが軽量プロトコルなのが台無しになってしまう)
WebSocket は双方向通信を円滑に行うための仕組み｡TCPコネクションは張りっぱなしとなる｡
Direct MQTT だとしても クライアントはNAT超えは可能だと思うが､実際どんなデメリットがあるだろう??
その辺ちょっとよくわからないです｡
