ThingsBoard(Community Edition) と IoTデバイス を MQTT 通信させる

ThingsBoard の MQTT 通信は独特な仕様のため、初見で困ることがあったのでメモを残す。

デバイスの認証方法

いくつか用意されているが、わかりやすい AccessToken による認証を選択した。
ThingsBoardをブローカーとした MQTT 通信の場合、IoT デバイスは ユーザー名に AccressTokenを指定するだけでよい（クライアントIDは自由。パスワードは空欄）

IoTデバイスからみた publish 先の Topic の違い

Topic: v1/devices/me/telemetry
　測定データなどを UPLINK　する場合に利用。
　時系列の履歴データとして記録される。

Topic: v1/devices/me/attributes
　IoTデバイスの状態、情報などを UPLINK　する場合に利用。
　既存のクラインと属性を上書き更新する。

属性って何？

サーバーのコンテキスト上に保持される変数のようなもの。
サーバー属性、共通属性、クライアント属性の３種がある。

サーバー属性
　サーバー内部で完結する属性情報
　IoTデバイスとのやり取りには向かない。

クライアント属性
　IoT デバイスからサーバーに UPLINK できる
　IoT デバイスからリクエストを publishして サーバーから DOWNLINK できる
　サーバー側からは操作しない。

共通属性
　IoT デバイスからサーバーに UPLINK できる
　IoT デバイスからリクエストを publishして サーバーから DOWNLINK できる
　サーバー側からも操作できる。　

トピックのスコープ

ここは普通のMQTTブローカーと異なる。
異なるデバイスで接続しても AccessToken がことなれば、他のクライアントが Publish した内容は見えない。

DOWNLINK（サーバー主導）

ここも普通のMQTTブローカーと異なる。
Topic: v1/devices/me/attributes を subscribe

共通属性を追加、更新すると、IoTデバイスと TCP接続が有効な時にのみMQTTパケットを送信する。
それ以外は破棄される。

つまり常時接続状態でないと、取りこぼすことになる。

IoTデバイス主導で属性情報を DOWNLINK する方法（共有属性、クライアント属性のみ）

同一の TCPセッションにて、以下の手順で MQTT通信を行う。

1. Topic: v1/devices/me/attributes/response/+ を subscribe
2. Topic: v1/devices/me/attributes/request/1 に取得したい属性名のリスト（カンマ区切り）を publish

TCPセッションがことなるとリクエストとした属性情報は受信できない。

mosquitteクライアントなどで個別の端末でサブスクライブしつつパブリッシュしても受信できない。
（サンプル例がPythonで記述されているのは、同一セッションで通信させるため）

リクエスト用の MQTTメッセージは以下のようなJSON形式になる。
{"clientKeys":"<属性名>,<属性名>,....","sharedKeys": "<属性名>,<属性名>,...."}

{"clientKeys":"<属性名>"}や、{"sharedKeys": "<属性名>"} といった形式でも良い。

ここまで理解できれば ThingsBoardもそれなりに使えるようになると思われる。

以上