技術

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のパッケージが含まれていません(´・ω・`)

ですが、

http://qiita.com/kimutansk/items/81b9ddddeb4d6e4e3256

によれば、リポジトリを追加してやればヨサゲなのでこの手で行くことにしました。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している状態」です。

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

1__root_blog____ssh_

 

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のやり取りもあるので、このシリーズ、しばらく続きそうです(汗

 

 

関連記事

  1. Raspberry Pi

    Raspberry Pi 2でまずはLピカそしてLチカへ

    この一連の記事は、サバフェス2016に参加した門外漢のいなばがいろいろ…

  2. 技術

    二度寝を防ぐ目覚ましアプリ「Sleep Meister」以外で起きられる気がしない

    このアプリ、各方面で紹介されているのですが、他の目覚ましアプリでも実装…

  3. ガジェット

    iPhoneやAndroidでの通話内容を録音できる!テレホンピックアップTP8がオススメ

    突然ですが、プライベートで通話内容を保存しておく必要ができてしまいまし…

  4. ガジェット

    リビング使いを前提にスマートスピーカー3機種を比較レビュー!

    我が家にスマートスピーカーが3機種揃ったので、色々比べてレビューしてみ…

  5. 技術

    IDCFクラウドにVPNでリモートアクセス ~Windows10でL2TP編~

    気がついたら3ヶ月弱ブログを放置してました。いなばです。…

  6. 技術

    IDCFクラウドにVPNでリモートアクセス ~ Pertino 編~

    先日書いた「Windows10でL2TP」は標準的なWindo…

コメント

  1. この記事へのコメントはありません。

  1. この記事へのトラックバックはありません。

最近の記事

おすすめ記事

  1. ガジェット

    LINE WAVEの誤認識について考えてみる
  2. こどもとスマートフォン

    アプリの追加をファミリー共有で制限する
  3. ガジェット

    スマートスピーカー3機種が自宅に揃ったのでレビュー (LINE WAVE・Goo…
  4. Raspberry Pi

    myThingsとIDCFチャンネルの使い方を理解してみる(前編)
  5. ガジェット

    MacBook Air 11インチ用に3Mのセキュリティ/プライバシーフィルター…
PAGE TOP