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 した内容は見えない。

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

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

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

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

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

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

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

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

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