myThingsとIDCFチャンネルの使い方を理解してみる(MQTTで繋いでみる編)

今回は、実際にMeshbluに繋いでみて、挙動を確認してみたいと思います。

myThingsとIDCFチャンネルの使い方を理解してみる(前編)

の続きなので、Meshbluについては上の記事をご参照ください。

MQTT環境の準備

messageの送受信について確認…の前に、いくつか準備が必要です。

mosquittoのインストール

subscribeの挙動をみるにあたって、HTTP(S)ではなく、MQTTというプロトコルで先に確認したいと思います。このMQTTのクライアントをインストールした環境が必要です。

OSX上のpythonから…という手もあるようですが、手っ取り早く行きたいので、ここは一つ、IDCFクラウドで確認用のサーバを立てちゃうのが楽ちんです(こういう使い方ができるのがIDCFクラウドのいいところ＼(^o^)／)。で、そのサーバの上にMQTTのクライアントであるmosquittoをインストールします。

サーバの作成の仕方については、ここでは割愛します。ちょっと動きも変わってきてるから改めてそのうち書くと思います。

どのOSイメージで作成するかですが、debianだとapt-get一発でインストールできるMQTTクライアントのパッケージが準備されているようなのでこれも楽ちん。

私は、CentOSのほうがなんとなく使い慣れているのでこっちを使いたい気持ちでいっぱいなのですが、標準のリポジトリにはMQTTクライアントであるmosquittoのパッケージが含まれていません(´・ω・｀)

ですが、

Qiita

MosquittoをCentOSにインストールする手順 - Qiita MosquittoをCentOSにインストールする際、毎回makeとかをしていて面倒だな、と思ってたのですが、Mosquittoのページを見てみると簡単にインストールする手順が乗っていたの...

によれば、リポジトリを追加してやればヨサゲなのでこの手で行くことにしました。2分で終了！らっくちん！

接続先の確認

接続先の情報もここで確認しておきます。

IDCFクラウドを使ってMeshblu環境を最速で準備する

の接続先を例にして説明を進めますので、適宜ご自身の環境に読み替えてください。

接続先ホスト：210.129.19.218

接続先ポート：1883

デバイス情報

[table id=4 /]

Mosquittoで繋いでみる

ではMosquittoで繋いでみます。

action-1でsubscribeする

まずは、acction-1として接続します。

IDCFクラウドを使ってMeshblu環境を最速で準備する

でも書いたように、Publisher として接続するか、Subscriberとして接続するかの選択肢があるのですが、ここではまず、Subscriberとして繋いでみます。

【Subscribeするときのコマンド】

mosquitto_sub \
 -h 接続先ホスト \
 -p 接続先ポート \
 -t SUBSCRIBEするトピック \  ← これ超重要！！！
 -u 自分のuuid \
 -P 自分のtoken

いくつかハマりどころを書いておきます。

他の説明を見ると、-t オプションの引数は、(ここでの例で言えば)action-1のuuidという表現をされている事が多く、また、現実的にはそれで正しいのですが、mosquitto的にはここは「トピック」です。そしてこのことは後からの理解で重要な意味を持っていると思います。

あと、わかりにくいですが、-p オプションはポートで、-P オプションがtokenです。

なお、ここで接続のための情報としてuuidとtokenを渡していることから、ここで名乗るデバイスとしてMeshbluにつなぐのだ、ということがイメージできるかと思います。

てことで、前置きが長くなりましたが、

• action-1というデバイス名を名乗り
• なぜかaction-1のuuidと同名のトピックをsubscribe

してみます。

念のためですが、このコマンドを入力するのは、Meshbluをインストールしたサーバではなく、mosquittoをインストールした方です。

【Action-1としてsubscribe】

mosquitto_sub \
-h 210.129.19.218 \
-p 1883 \
-t 57263fa4-d64b-433b-9bd8-3fb85ab24a03 \
-u 57263fa4-d64b-433b-9bd8-3fb85ab24a03 \
-P 4e41dc51

多分、何もおきないと思います。というか、ローカルのプロンプトさえ出ないと思います。

この状態が、「トピックをsubscribeしている状態」です。

実行した画面としてはこんな感じになっているはずです。

trigger-1でpublishする

さて、ただsubscribeして待っててもつまらないので、今度は、trigger-1としてpublishします。先ほど起動したsshクライアントはsubscribeして待ってますので、もう一つSSHクライアントを立ち上げてsshしておきます。

【publishするときのコマンド】

mosquitto_pub \
 -h 接続先ホスト \
 -p 接続先ポート \
 -t message \
 -m '{"devices": ["送信相手のuuid"], "payload": {"メッセージのタイトル":"メッセージの中身"}}' \
 -u 自分のuuid \
 -P 自分のtoken

いやちょっと待て待て待て待てっ！と5回位ツッコみたくなるのではないかと思います。

Action-1がsubscribeして待ってるトピックは、何故かAction-1のuuidと同名のトピック。なのに、Trigger-1がpublishするトピックはmessageてなんじゃそりゃ！

でも、物は試し。publishする側(Trigger-1)のSSHクライアントから下記のコマンドを投入してみます。

【Trigger-1としてPublish】

mosquitto_pub \
-h 210.129.19.218 \
-p 1883 \
-t message \
-m '{"devices": ["57263fa4-d64b-433b-9bd8-3fb85ab24a03"],"payload": {"メッセージのタイトル":"メッセージの中身"} }' \
-u dfaf1f04-ce98-416b-990b-8c1dd90372ee \
-P 9fa4d90c

【Action-1としてSubscribeしている方の画面】

{"topic":"message","data":{"devices":["57263fa4-d64b-433b-9bd8-3fb85ab24a03"],"payload":{"メッセージのタイトル":"メッセージの中身"},"fromUuid":"dfaf1f04-ce98-416b-990b-8c1dd90372ee"}}
{"topic":"message","data":{"devices":["57263fa4-d64b-433b-9bd8-3fb85ab24a03"],"payload":{"メッセージのタイトル":"メッセージの中身"},"fromUuid":"dfaf1f04-ce98-416b-990b-8c1dd90372ee"}}

subscribeしている方にはこんな感じで見えます！(しかも何故か2つ…この謎は今もとけてません)

Action-1でPublish、Trigger-1でSubscribeしてみる

何か今一つ腑に落ちないのですが、んじゃ今度は逆にしてみます。Action-1がPublish、Trigger-1がSubscribeというパターンです。

まず、先にTrigger-1デバイスでSubscribeします。

Subscribeするときは

mosquitto_sub \
 -h 接続先ホスト \
 -p 接続先ポート \
 -t SUBSCRIBEするトピック \
 -u 自分のuuid \
 -P 自分のtoken

なので、以下のようになります。

【Trigger-1としてSubscribe】

mosquitto_sub \
 -h 210.129.19.218 \
 -p 1883 \
 -t dfaf1f04-ce98-416b-990b-8c1dd90372ee \
 -u dfaf1f04-ce98-416b-990b-8c1dd90372ee \
 -P 9fa4d90c

Subscribeするトピックは、自分自身のuuidと同一になります。

次に、Action-1でPublishします。

Publishするときは

mosquitto_pub \
 -h 接続先ホスト \
 -p 接続先ポート \
 -t message \
 -m '{"devices": ["送信相手のuuid"], "payload": {"メッセージのタイトル":"メッセージの中身"}}' \
 -u 自分のuuid \
 -P 自分のtoken

ですから、以下のようになります。

【Action-1としてPublish】

mosquitto_pub \
 -h 210.129.19.218 \
 -p 1883 \
 -t message \
 -m '{"devices": ["dfaf1f04-ce98-416b-990b-8c1dd90372ee"], "payload": {"メッセージのタイトル":"メッセージの中身"}}' \
 -u 57263fa4-d64b-433b-9bd8-3fb85ab24a03 \
 -P 4e41dc51

【Trigger-1としてSubscribeしている方の画面】

# mosquitto_sub \
> -h 210.129.19.218 \
> -p 1883 \
> -t dfaf1f04-ce98-416b-990b-8c1dd90372ee \
> -u dfaf1f04-ce98-416b-990b-8c1dd90372ee \
> -P 9fa4d90c

{"topic":"message","data":{"devices":["dfaf1f04-ce98-416b-990b-8c1dd90372ee"],"payload":{"メッセージのタイトル":"メッセージの中身"},"fromUuid":"57263fa4-d64b-433b-9bd8-3fb85ab24a03"}}

届くじゃないですか！！！

例えば、IDCFさんの説明(http://www.idcf.jp/cloud/iot/detail01.html)とかを見ると、

デフォルトでは、trigger-[1-5]から action-[1-5]へ末尾が同じ数字の組み合わせのメッセージ送信を許可しています。

という説明になっています。また、Quiitaの記事でも

末尾の番号が同じ番号の場合は、trigger-*からaction-*へメッセージが送信できるように設定されています。

とされています。

なんですが何故か、Action-1からTrigger-1へのメッセージ送信もできている…。むむー。

クリティカルな問題では無いのですが、なんか腑に落ちないです。

…ついでに他の組み合わせも試してみます。

Trigger-1でPublish、Trigger-2でSubscribe

【Trigger-2としてSubscribeする】

まず、Trigger-2としてSubscribeしておきます。

mosquitto_sub \
 -h 210.129.19.218 \
 -p 1883 \
 -t c0b29b45-20db-483b-9b20-a9953a5dcf2a \
 -u c0b29b45-20db-483b-9b20-a9953a5dcf2a \
 -P 865ba919

【Trigger-1としてPublish】

Trigger-2がSubscribeしているトピックに対してTrigger-1としてPublishします。

mosquitto_pub \
 -h 210.129.19.218 \
 -p 1883 \
 -t message \
 -m '{"devices": ["c0b29b45-20db-483b-9b20-a9953a5dcf2a"], "payload": {"From_Trigger-2":"To_Trigger-1"}}' \
 -u dfaf1f04-ce98-416b-990b-8c1dd90372ee \
 -P 9fa4d90c

【Trigger-2としてSubscribeしている画面】

# mosquitto_sub  -h 210.129.19.218  -p 1883  -t c0b29b45-20db-483b-9b20-a9953a5dcf2a  -u c0b29b45-20db-483b-9b20-a9953a5dcf2a  -P 865ba919
{"topic":"message","data":{"devices":["c0b29b45-20db-483b-9b20-a9953a5dcf2a"],"payload":{"From_Trigger-2":"To_Trigger-1"},"fromUuid":"dfaf1f04-ce98-416b-990b-8c1dd90372ee"}}

バッチリ送信されてる…

Action-2でPublish、Trigger-3でSubscribe

【Trigger-3としてSubscribeする】

まず、Trigger-3としてSubscribeしておきます。

mosquitto_sub \
 -h 210.129.19.218 \
 -p 1883 \
 -t 87371a60-f62a-4995-b89e-b35882294566 \
 -u 87371a60-f62a-4995-b89e-b35882294566 \
 -P 2e0ac6a0

【Trigger-1としてPublish】

Trigger-3がSubscribeしているトピックに対してTrigger-1としてPublishします。

mosquitto_pub \
 -h 210.129.19.218 \
 -p 1883 \
 -t message \
 -m '{"devices": ["87371a60-f62a-4995-b89e-b35882294566"], "payload": {"From_Trigger-2":"To_Trigger-1"}}' \
 -u dfaf1f04-ce98-416b-990b-8c1dd90372ee \
 -P 9fa4d90c

【Trigger-2としてSubscribeしている画面】

# mosquitto_sub \
>  -h 210.129.19.218 \
>  -p 1883 \
>  -t 87371a60-f62a-4995-b89e-b35882294566 \
>  -u 87371a60-f62a-4995-b89e-b35882294566 \
>  -P 2e0ac6a0
{"topic":"message","data":{"devices":["87371a60-f62a-4995-b89e-b35882294566"],"payload":{"From_Trigger-2":"To_Trigger-1"},"fromUuid":"dfaf1f04-ce98-416b-990b-8c1dd90372ee"}}

こっちもメッセージ来てるー。

まとめ

なんだかよくわからないのですが、ひとまず確認された事実としては、dockerのカプセルになって配布されているMeshbluに関しては、Trigger-xからAction-x、という縛りなく、全てのデバイス間でメッセージの送信ができるっぽいです。

メッセージの送信の際のトピックなどがどうなっているのかについての図は後日追加予定です。

で、次の記事では、クライアントとしてMosquittoのようなMQTTクライアントを使うのではなく、CURLをつかってHTTP経由でメッセージの送受信を試してみます。

なお、前回の記事で説明したdataのやり取りもあるので、このシリーズ、しばらく続きそうです(汗