まだプログラマーですが何か?

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

タグ:mqtt

自分で作って公開しているサービスの中で使うために MQTT over WebSocket サーバーが必要になり、DockerHub の eclipse-mosquitto イメージを使って同環境を構築したので、その手順を紹介します。
2023040900



【MQTT over WebSocket とは】
「WebSocket(HTTP) プロトコルで実現する MQTT」です。MQTT ブローカーに対して Publisher や Subscriber の機能をウェブのクライアント(=ブラウザ)から使いたい場合に、ウェブクライアントから直接 MQTT を使うことはできませんが、HTTP ベースである WebSocket 経由で使うことができます(そのためのライブラリも公開されています)。このような「WebSocket 対応した MQTT 」が MQTT over Socket で、そのような MQTT ブローカー環境を構築するための手順を以下で紹介しています。


【事前準備】
今回は MQTT ブローカーとして DockerHub から公式イメージとして公開されている eclipse-mosquitto を使い、これを MQTT over WebSocket 対応させます。 というわけで eclipse-mosquitto イメージが対応した docker 環境(linux/386, linux/amd64, linux/arm/v6, linux/arm64/v8, linux/ppc64le, linux/s390x)を事前にご用意ください。


また以下のような mosquitto.conf ファイルが必要です。これは mosquitto の動作設定用ファイルなのですが、これとは別の設定が必要な場合は、それらの設定の最後にこの4行の内容を追加して mosquitto.conf ファイルを用意してください(ここでは /tmp/mosquitto.conf というファイルパスで作成したものとします):
listener 1883
allow_anonymous true
listener 11883
protocol websockets

※ちなみにこの4行が意味する設定内容は以下の通りです。この設定を変える場合は(数値などを)適宜変更してください:

  • 1883 番ポートで MQTT を送受信する(変更せずこのまま)
  • 11883 番ポートで MQTT over WebSocket を送受信する(使っていないポート番号なら任意)
  • 認証無し

docker コンテナの起動だけであれば以上の準備でいいのですが、後述の動作確認までを行う場合は Node.js の実行環境が必要になります。必要な場合は Node.js のインストールまで済ませておいてください。



【起動】
ここまでの準備ができていれば起動は簡単です:
$ docker run -d -p 1883:1883 -p 9001:9001 -p 11883:11883 -v /tmp/mosquitto.conf:/mosquitto/config/mosquitto.conf --name mosquitto eclipse-mosquitto

外部に公開するポートとして 1883, 9001, 11883 を指定し、用意した mosquitto.conf ファイルを使って eclipse-mosquitto イメージを実行しています。


【動作確認】
以下のサンプルソースコードを使って動作確認します:
https://github.com/dotnsf/MoWS

このアプリケーションそのものは「簡易 SNS」です。タイトルとメッセージを編集&送信すると、その内容を一覧画面で確認できます。一覧画面をリロードするとその時点までに送信されたメッセージの一覧が表示されますが、一覧表示後に新しいメッセージが送信された場合、通常のアプリであればリロードするまでは新しいメッセージは表示されないのですが、このサンプルアプリでは MQTT over WebSocket を併用することで新しいメッセージが自動的に画面最上部に追加されるようになっています。


実際に動かしてみましょう。"git clone" 等でソースコードをダウンロードします。そしてルートフォルダ直下にある .env ファイルをテキストエディタで開き、以下の内容に書き換えて保存します:
MOWS_URL=ws://xxx.xxx.xxx.xxx:11883
MQTT_URL=mqtt://xxx.xxx.xxx.xxx
MQTT_PORT=1883
MQTT_TOPIC=yellowmix/mytest/topic

この内容の、"xxx.xxx.xxx.xxx" 部分は上で起動した MQTT ブローカーコンテナの IP アドレス、11883 は同ブローカーで MQTT over WebSocket が待ち受けるポート番号、1883 は MQTT が待ち受けるポート番号です。また MQTT_TOPIC には適当なトピック文字列を指定してください(よくわからなければこの例の内容そのままでも構いません)。

※なおデフォルト状態の MOWS_URL は "wss://test.mosquitto.org:8081" と設定されているので、プロトコル部分も "wss" から "ws" に変更する必要がある点に留意してください。

そして動作確認用アプリケーションを起動します:
$ npm install
$ node app

アプリケーションは 8080 番ポートで起動します。ウェブブラウザを2つ(同じブラウザの別ウィンドウでも可)を開いて、1つは一覧画面である "http://localhost:8080/" にアクセスします:
2023040901


そしてもう1つは編集画面である "http://localhost:8080/edit" にアクセスします:
2023040902


編集画面内の「タイトル」欄と「本文」欄に適当な文字列を入力します。最後に「送信」ボタンをクリックします:
2023040903


全て正しく動作していると、一覧画面をリロードしていなくても、編集画面で入力されたメッセージが一覧画面に表示されているはずです。編集画面に入力された値はバックエンド側で MQTT パブリッシュされ、MQTT over WebSocket でサブスクライブしていた一覧画面に内容とともに通知され、リロードしていなくてもその内容が表示できています:
2023040904


同様にして編集画面から送信するたびに一覧画面が更新されていく様子が確認できます:
2023040905


ちなみに送信されたメッセージはアプリケーションが起動している間はメモリ内に保存されているので、一覧画面をリロードするとそれまでに送信されたメッセージが新しい順に並ぶ様子も確認できます(データを適当な DB に永続保存して、そこから読み出すように改良すれば一応の SNS っぽくなると思います)。MQTT over WebSocket を使って一覧が自動更新される簡易 SNS が実現できている様子を確認できているはずです。


【まとめ】
趣味アプリの1つとして SNS っぽいものを作っているのですが、その中で要件としてでてきた「一覧の自動更新」機能を実現するための手段として MQTT over WebSocket を使う例を紹介しました。ウェブブラウザの JavaScript で実装された MQTT over WebSocket ライブラリを使って MQTT サブスクライブを実装することで比較的簡単に実現できることがわかりました。


IBM Cloud から提供されている IoT サービスである IBM Watson IoT Platform (の QuickStart)にメッセージをパブリッシュする Node.js のサンプルアプリケーション(とソースコード)を作って公開しました:
https://github.com/dotnsf/mqtt_pub_ibmiot

2018051501


主要なソースコードは app.js だけですが、内部的に MQTT.js ライブラリを使っています:
2018051500


主な挙動としては settings.js で指定された内容に併せて、1秒(デフォルト)ごとに0から1つずつ増えるカウンタ値、タイムスタンプ値、実行したマシンの CPU 稼働率、12回周期のサイン値およびコサイン値、そしてランダムな値が JSON で IBM Watson IoT Platform の QuickStart に送られます。その際のデバイス ID 値は settings.js 内で指定されていればその値が、されていなければ動的に生成されるようにしました。


IBM Cloud 環境で Node-RED ランタイムを作ると動作を確認しやすく、またそのためカスタマイズの勘所が分かりやすいと思っています。以下、この環境での動作確認方法を紹介します。

まずはこのサンプルを動かす前提として Node.js がインストールされたマシンが必要です。Windows/MacOS/Linux/Raspberry Pi などなど、Node.js をインストール可能なマシンで導入を済ませていると仮定して以下を続けます。

次に上記リポジトリから git clone またはダウンロード&展開して、アプリケーションのソースコードを手元に用意します:
$ git clone https://github.com/dotnsf/mqtt_pub_ibmiot
$ cd mqtt_pub_ibmiot

必要に応じてテキストエディタで settings.js の中身を編集します。とはいえ、変える必要がありそうなのは exports.interval の値(メッセージデータを送信する時間間隔(ミリ秒)。デフォルト値は 1000 なので1秒ごとにメッセージを送信する)と、exports.deviceId の値(後で指定するデバイス ID。デフォルトは空文字列なので、後で自動生成された値になります)くらいです。なお、settings.js の値は変えなくても動きます。


※もし exports.deviceId の値を編集する場合は、("test" のような簡単な単語ではなく)他の人が使わないようなユニークな値になるよう指定してください。exports.deviceId の値をデフォルトのから文字列のままにする場合は、実行時ごとにデバイス ID を生成するので、この値は実行ごとに変わることに留意してください。


ではアプリケーションの動作に必要なライブラリをインストールします:
$ npm install

そして実行します:
$ node app

実行が成功して IBM Watson IoT Platform に接続すると、"client#connect: " という文字列に続いてデバイス ID が画面に表示されます(以下の例では 5d7436e992d0)。この値は settings.js で指定した場合はその値が、指定しなかった場合は自動生成された値が表示されます。この後で使うのでメモしておきます:
2018051502


※なお、メッセージを送信しているアプリケーションの終了方法は特に用意していないので、終了する場合は Ctrl+C で強制終了してください。


これでサンプルアプリケーションが IBM Watson IoT Platform に接続し、exports.interval で指定した値の間隔でメッセージデータを送信し続けている状態になりました。

最後にこの送信データを Node-RED で確認してみます。IBM Cloud で Node-RED ランタイムを作成し、IBM IoT のインプットノード(右側にジョイントのあるノード)と、debug アウトプットノードをキャンバスに配置して接続します:
2018051503


↑IBM Watson IoT Platform サーバーにメッセージが送られてきたらその payload の内容をデバッグタブに表示する、というシンプルなフローです。


IBM IoT インプットノードをダブルクリックし、Authentication が Quickstart になっていることを確認した上で、Device Id 欄に先程確認した実行中アプリケーションのデバイス ID を指定します。そして「完了」してから、このアプリケーションを「デプロイ」します:
2018051504


すると、Node-RED 画面右のデバッグタブに(デフォルトであれば)1秒おきにメッセージが追加されていく様子が確認できるはずです:
2018051505


メッセージの1つを選んで展開してみると、元のアプリケーションから送信されたカウント値(count)、タイムスタンプ値(timestamp)、CPU稼働率(cpu)、サイン値(sin)、コサイン値(cos)、そして乱数値(random)が確認できます。つまり Node.js を使って動かしたアプリケーションから MQTT 経由で実際にデータが送信されていて、その内容を Node-RED と IBM IoT インプットノードを使って取り出して確認できたことになります:
2018051506


送信データをカスタマイズしたり、別の値を送信したい場合は app.js をカスタマイズして、publish 時に送信する data 変数の中身を変える(必要な値を取得して、この中に JSON で入れる)ということになります。こちらはシンプルなのでなんとなく理解できるんじゃないかな・・・と期待しています。


また Node-RED の場合であれば node-red-dashboard と組み合わせることで、ここで取得した値を簡単にチャート化することもできます。例えば Gauge ノードと Chart ノードを使って CPU 負荷とサインカーブをこんな感じで・・・
2018051600


IBM Watson IoT Platform の Quickstart にデータを送信するサンプルとして使ってくださいませ。

※(注)最初にお断りしておきます。マジメぶって書いてますが馬鹿エントリです。


全てのきっかけは最近たまにみかけるこういった記事でした:

人工知能やコグニティブエンジンと呼ばれる技術の発達により、これまで人間の脳でないと判断できなかったようなことをコンピュータができるようになり、人間の仕事がより低コストな人工知能やそれらを搭載したロボットによって奪われてしまう時代がくる、という啓発記事です。

個人的にはそこまでそんな時代が身近に迫ってきているとは思っていません。ただし、その一方で企業間の競争が働いたこともあり、ここ数年における人工知能分野の発展はすさまじいものがあります。静止画像や個人の機械認識率はぐんと上がり、各社が API を公開している背景も手伝って、人工知能に触れる機会がより身近な世界になりつつあるのも事実だと思っています。以下は個人的見解ですが、クリエイティブな仕事(例えば小説を書く、など)を学習させるのはまだ難しいにせよ、脳を使わない単純作業や、ルーチン化された業務などは意外と早い段階で人間の効率を追い抜く日がやってくるかもしれない(そうなると作業コストで勝てるわけがないので、本当に仕事を失う日がやってくるかもしれない)、と思っています。

例えばお客様とお話ししていて、ただ頷いて聞いているだけ。お客様が話し終わったらすかさず相槌を打つ、そんなフローチャートのような業務では近い将来に職を奪われてしまうかもしれないのです!
(注 実在する誰かのことではありません)
2015022305


さて話は変わって、先日秋葉原でこのような部品を買ってしまいました:

2015022300



この SEN02281P はいわゆる「音センサー」です。画像左上にある大きな丸い部分がマイクになっていて、ここで音を拾って、その情報を電気回路を通じて外部に知らせることができる、というものです。買った後で知ったのですが、Arduino に接続したり、Raspberry PiGrovePi という拡張モジュールを取り付けて簡単に使う方法がネットなどで紹介されていました。

・・・ん、もしかすると、この SEN02281P と(例えばラズベリーパイとかの)演算機能を使えば、上記のような簡単なデータフローが実現できてしまうんじゃないだろうか? つまり「誰かが喋っている時は頷き、喋り終わったら相槌を入れる、という仕組みは、このセンサーとアルゴリズムを実装するプログラムだけで実現できてしまうんじゃないだろうか?」ということに気付いてしまったのです! というわけで、よく調べずにとりあえず買ってしまいました。


自分は「ラズベリーパイならメジャーだからまあ繋がるだろう、その方法もネットで見つかるだろう」とタカを括っていたのですが、これが意外と苦戦しました。結論からいうと GrovePi を使わない方法(ラズベリーパイの GPIO に直接繋げる方法)を見つけることができませんでした。えーマジで!?自分で調べるしかないの??電子回路は苦手なんだよなあ。。まあ挑戦してみました。以下、やってみたことのおさらいの意味で書いてます。当方こっち方面はド素人なので、間違いを見つけたり、こうするともっといいよ、という方法があればウェルカム、というか教えてください。

・・・改めてパーツを眺めてみました。接続端子はこの↓画面上部の白い四角の中に生えた4つの突起部分です:
Loudness_101020063_01

これを裏返すとこんな感じ(上図とは左右が逆になった状態):
2015022301


拡大するとこんな感じ。ちょっと見難いのですが、この画面の左から順に(反対から見た場合は右から順に) SIG / NC / VCC / GND と書かれています:
2015022302


GND はアース(Ground)、VCC は電圧、これは(他の部品とほぼ共通なので)分かる。上記の商品ページを見ると、このパーツの動作電圧は 5V(3.5~10V) と書かれているので、とりあえず 5V の電圧ピンにジャンパケーブルを繋いであればいいかな。そして SIG はシグナル、つまりここを GPIO27 とかに繋げて音の信号を受け取るんだろうな・・・ で、NC ?なんだこれ、見たことないぞ・・・

で、ここだけ調べて分かったのは NC = Not Connected 、つまり「どことも繋がない」という端子らしい。そうなんだ。。じゃ、なんで存在してるんだろ?? うーん・・・まあ、いいやw

というわけで、ジャンパケーブルを使ってこんな感じで自分のラズベリーパイの GPIO に接続しました:
2015022303

これで 5V の電源を供給し、アースも備え、SEN02281P が感知した音を取り込む仕組みが動くはずです。実際の写真はこんな感じです(メス-メスのジャンパーケーブルがあればもっと綺麗に接続できたのに・・・):
2016022400


そして、ラズベリーパイ側にはこのような Python プログラムを導入しました:
#!/usr/bin/env python
# -*- coding: utf-8 -*-
# SEN02281P ----- RaspberryPi GPIO
# =SIG ---------- 13
# =NC
# =VCC ---------- 2
# =GND ---------- 20

import paho.mqtt.client as mqtt
import time
import RPi.GPIO as GPIO

def on_connect(client,userdata,flags,rc):
	print( "Connection with result code " + str(rc) )
	client.subscribe( "sen02281p" )

def on_message(client,userdata,msg):
	print( msg.topic + " " + str(msg.payload) )

def reading(sensor):
	sum = -1 
	if sensor == 0:
		sum = 0
		for i in range(0,20):
			time.sleep(0.1)
			a = GPIO.input(SIG)
			sum += a
	else:
		print "Incorrect function."

	return sum

GPIO.setwarnings(False)
GPIO.setmode(GPIO.BOARD)
SIG = 13
GPIO.setup(SIG,GPIO.IN)

client = mqtt.Client()
client.on_connect = on_connect
client.on_message = on_message

client.connect( "iot.eclipse.org", 1883 )
while client.loop() == 0:
	msg = reading(0);
	client.publish( "sen02281p", msg, 0, True )
	pass

GPIO.cleanup()
※事前に pip install paho-mqtt をして、Paho の Python ライブラリを導入済みです。

ちなみに上記ソースファイル(sen02281p.py)はこちらからダウンロードできます:
https://raw.githubusercontent.com/dotnsf/sen02281p/master/sen02281p.py


GPIO の(SEN02281P の SIG 端子とつながっている)13番ピンからのインプット情報を 0.1 秒ごとに20回(つまり2秒間)取得し、その20回中音が確認できた回数を MQTT ブローカー(iot.eclipse.org)に投げる、というものです。つまり MQTT ブローカーに対しては2秒おきにどれくらい音が識別できたかを 0 から 20 の整数値でパブリッシュする、というものです。トピックは上記例では "sen02281p" と指定していますが、皆さんがもしこのソースを使う場合は少し変えていただけると嬉しいです。

次に Bluemix 上の NodeRED 環境を使って、このパブリッシュされたメッセージを取り出す仕組みを用意します。MQTT インプットノードを用意し、ホスト名に上記の MQTT ブローカーホスト(iot.eclipse.org:1883)、トピックに "sen02281p" を指定しています。このノードからは2秒に1回、ラズベリーパイの接続された SEN02281P のマイクから拾った音の頻度が渡されてくる、という仕組みとなります。また、その取り出した結果を /ws/unzk_sensor というパスの WebSocket に出力しています:
2015022304


後はこの /ws/unzk_sensor からリアルタイムにデータを取り出して動く WebSocket アプリケーションを用意してあげればマイクで拾った音の頻度をリアルタイムに可視化するようなアプリケーションを作ることができる、ということになります。そのサンプルアプリ(やその中で使う画像)も合わせてこちらで公開しておきます:
https://github.com/dotnsf/sen02281p


このアプリを上記の NodeRED 環境にデプロイしてアプリケーション(hoho.html)を開くと、このような画面になります:
2016022401


ひたすら「頷いている」画面になっています。何もデータが送られていないとただ頷いているだけですが、一応この画面が出ればデプロイには成功していることになります。

ではラズベリーパイ側のアプリも起動します。ネットに接続されたラズベリーパイ上で先程の MQTT パブリッシャーアプリを実行します:
# python sen02281p.py

そして先程の頷き画面をリロードすると・・・ ラズベリーパイに接続されたマイクが音を拾っている間は頷き、音が途切れたと判断した時に「ほほー」と相槌を売ってくれるようになります!
2016022402


この「音を拾っているか」「音が途切れたか」の判断がまだ少し甘いところがあるかもしれませんが、一応それっぽく動いていることが確認できました。これで忙しい営業さんに変わってお客様のお話しを上手に引き出してくれるロボットができました(笑)。


実際に動いている動画を Ustream に上げておきます:

Live streaming video by Ustream




最近は多くのクラウド業者が IoTMQTT との連携をアピールしています。IBM を含めて各社が「いかに簡単に IoT データを扱う/応用することができるか」を競っている感じです。

この点で IBM の強みの1つが Node-RED フローエディタだと思っています。Bluemix に統合されたこの GUI エディタは MQTT サーバー(ブローカー)との接続を簡単に行い、データを集め、保存する仕組みを簡単に提供することができます。MQTT ブローカー/クライアントの Mosquitto といい、この Node-RED といい、IoT にもオープンソース製品が多くの場面で使われるようになってきて、更なる広まりを見せているように感じます:
2015082602


IBM の場合、この Node-RED をうまく Bluemix に合わせてカスタマイズして提供しており、Bluemix 内ではすぐに使えるようになっており、また Bluemix の各サービスと簡単に組み合わせて使えるような形で提供されています。


ただ Node-RED そのものはオープンソースで提供されているものです。他のクラウドインスタンスやオンプレミスサーバー環境でも(Bluemix 用の拡張がされていない素のエディションを)動かすことが可能です。つまり IBM 以外の業者のクラウド環境内で Node-RED を使った IoT アプリ開発環境を構築することだってできるわけです。


というわけで、今回のブログエントリでは SoftLayer や AWS、IDCF、オンプレミスなどの(クラウド)サーバー環境内で Node-RED を使って IoT アプリ開発環境を構築する手順を紹介します。


まず最初に Bluemix と IBM IoT Foundation を使った場合の IoT アプリ開発環境のシステムトポロジーを確認しておきます。必要になるサーバーとしては各種センサーデバイスからの情報を集約する MQTT ブローカーと、Node-RED が稼働する Node.js アプリケーションサーバーです。Bluemix 環境の場合、前者は IBM IoT Foundation が提供する quickstart サーバーを無料で使うことができます(つまり構築不要です)。後者は Bluemix のボイラープレートを使うことで Node-RED が動く状態まで含めて簡単に構築できてしまいます。なお収集したデータを保存しようとすると別途データベースサーバーを用意する必要がありますが、Bluemix であればデータベースも簡単に追加してバインドすることが可能です(今回はデータベースを使わない環境を前提とします):
2015082601


これと同じ環境を Bluemix を使わずに構築することを考えると、(物理的には1台のマシンでも構いませんが)上記の MQTT ブローカーと Node.js の2サーバーを手動で用意することになります:
2015082602


具体的には MQTT と Node-RED それぞれの環境を用意する必要があります。1台または2台のサーバーを用意し、それぞれのサーバーインスタンスに MQTT ブローカーおよび Node-RED 環境を構築します。それぞれの手順は(CentOS サーバーの場合であれば)以下の記事を参照ください:
ラズベリーパイにオープンソース MQTT の Mosquitto をインストールする (←ラズベリーパイだけでなく CentOS の場合のインストール方法も記載しています)
CentOS に Node-RED をインストールする


まずは MQTT ブローカーを起動しておく必要があります。MQTT ブローカー(Mosquitto サーバー)を導入したマシン上で以下のコマンドを実行するなどして Mosquitto サービスを動かしておきます:
# service mosquitto start

次に Node-RED を導入したサーバーで Node-RED を起動します:
2015082603


起動した Node-RED にブラウザでアクセスします。Node-RED はデフォルトでは 1880 番ポートで起動するので、 http://(Node-RED サーバー):1880/ でアクセスするとフローエディタの画面が開きます:
2015082604


そして下図のような、MQTT インプットと Debug アウトプットを繋げただけのシンプルなフローを記述します:
2015082608


MQTT インプットの属性は以下のようにします。Broker には Mosquitto を導入したサーバーの 1883 番ポートを指定します。Topic はなんでもいいのですが、ここでは "top/001" と指定しています(後で実行するコマンドで指定することになる文字列です)。準備ができたらデプロイして実行状態にします:
2015082605


これで環境は出来上がりました。では正しく動いているかどうかを確認してみましょう。
別途 Mosquitto クライアントを導入したマシン(これも同一マシンでもかまいません)から以下のコマンドを実行して、MQTT ブローカーにメッセージをパブリッシュします:
$ mosquitto_pub -h (MQTT ブローカーサーバー) -t "top/001(上記 Node-RED で指定した Topic 属性と同じ文字列)" -m "Hello."

2015082606


すると、Node-RED 画面の debug タブには -m オプションで指定された文字列が表示されるはずです。つまり MQTT ブローカーの top/001 トピックに送信されたメッセージを、Node-RED から正しく取得することができたことになります:
20150824_nodered



ちゃんと動きました。Node-RED は Bluemix や IBM IoT Foundation がなくても、普通の(?) MQTT 環境の中でも動くことが確認できました。


・・・とはいえ、Bluemix + IBM IoT Foundation 環境で Node-RED を使ったことのある者として言わせていただくと、ここまでの環境を整えないと使えないわけです。また現実的には取得したデータをデータベースに格納しようとすると、Bluemix 環境のように簡単にはいきません。動くか動かないかでいうと動きますが、その準備のためのハードルはまだまだ高いように感じています。

IoT アプリ開発環境を検討する上で IBM Bluemix + IBM IoT Foundation + Node-RED がいかに簡単で便利なのか、を改めて再確認するような実験になったとも感じました。




 

以前のブログエントリでオープンソース MQTT 環境である Mosquitto の導入方法を紹介しました。このブログエントリではラズベリーパイ用と CentOS 用の紹介をしていますが、Mosquitto 自体には Windows などのバイナリも用意されていて、多くの環境で使えます:
ラズベリーパイにオープンソース MQTT の Mosquitto をインストールする


この Mosquitto を使って、IBM IoTF(IoT Foundations) 環境に用意されている QuickStart と呼ばれる MQTT ブローカーに任意のメッセージデータを送る方法を紹介します。センサーシミュレータなどを使って QuickStart に送られたデータを集めて取り出して加工して・・・という作業は Node-RED 環境があれば簡単ですが、その前段になるデバイスから QuickStart にデータを送るにはどうするか?という手段の紹介です。今回は MQTT クライアント(パブリッシャー)を使った例を紹介します。


準備として、まずは上記のリンク先の情報から、Mosquitto のパブリッシャー(mosquitto_pub)をインストールする所までは済ませておいてください。今回は mosquitto_pub を使って IoTF QuickStart にデータを送信します。

次に、IoTF QuickStart に送られてきたメッセージデータを確認するための環境を整えておく必要があります。IBM Bluemix の IoT Foundations Starter ボイラープレートや Node-RED Starter ボイラープレートを使って、Node-RED 環境を用意してください。この辺りの詳しい手順がよく分からない場合はこちらを参照してください:


Node-RED 環境ができたら、次のような IBM IoT ノードと Debug ノードをつなげただけの、シンプルなフローを作成してください:
2015072701


IBM IoT ノードをダブルクリックし、このような属性値に設定します。Authentication を "QuickStart" に、Input Type を "Device Event" に、そして Device Id には任意のユニークな文字列(下の例では "91a19d112233" にしていますが、同じものを使わないでください。実際にはネットに接続された機器の MAC アドレスを想定しています)を入力します。最後に Name に適当な名前を入力して OK をクリックします:
2015072702


Debug ノードの属性は以下のようにします。Output はデフォルトの payload のままでも実用的にはいいのですが、今回は送られてくるメッセージ全体を確認したいので "complete msg object" に変更して OK をクリックします。最後に "Deploy" をクリックして、デプロイまで済ませておきます:
2015072703


これで Device Id が(今回の例であれば) "91a19d112233" に設定されたデバイスから QuickStart に送られてくるデータを取得してデバッグタブに表示する、というアプリが動いている状態になりました。

では Mosquitto を使って、そのようなデータを QuickStart にパブリッシュしてみます。Mosquitto を導入した環境にログインし、ターミナルのプロンプトから以下のようなコマンドを実行します:
$ mosquitto_pub -h quickstart.messaging.internetofthings.ibmcloud.com -t "iot-2/evt/myeventtype/fmt/json" -m '{"d":{"name1":"stringValue","name2":10}}' -i d:quickstart:MyDevice:91a19d112233

このコマンドは、
 (1) quickstart.messaging.internetofthings.ibmcloud.com という MQTT ブローカーに対して、
 (2) "iot-2/evt/myeventtype/fmt/json" というトピックを指定し、
 (3) '{ "d": { "name1":"stringValue", "name2": 10 } }' という JSON 形式のメッセージを、
 (4) d:quickstart:MyDevice:91a19d112233 というクライアント ID で
パブリッシュする、という処理内容のコマンドです。

※ちなみに IoTF では送信メッセージは '{ "d": { (ここが実際の送信内容) } }' という JSON 形式で送付することを推奨しています。

2015072704


このコマンドを実行した直後、Node-RED アプリのデバッグタブにメッセージが表示されるはずです! 実行したパブリッシュコマンドのメッセージが届いた証拠です:
2015072705


ここで届いたメッセージはこのような内容になっているはずです:
{
 "topic": "iot-2/type/MyDevice/id/91a19d112233/evt/myeventtype/fmt/json",
 "payload": {
  "d": {
   "name1": "stringValue",
   "name2": 10
  }
 },
 "deviceId": "91a19d112233",
 "deviceType": "MyDevice",
 "eventType": "myeventtype",
 "format": "json",
 "_msgid": "6e152038.91eae" 
}

(3) で指定したメッセージは、"payload" の中身として届けられています。また (2) で指定したトピックは "topic" と、"eventType" の値として表示されています。また (4) で指定したクライアント ID は "deviceId""deviceType" として届いていることもわかります。"deviceType" と "eventType" はパブリッシュする側で任意に設定できる、デバイスとイベントの分類用文字列です。


ということは、上記の mosquitto_pub コマンドで実行した MQTT パブリッシュ処理に相当するコマンドを quickstart.messaging.internetofthings.ibmcloud.com に対して実行することで QuickStart にメッセージを送ることができる、ということが分かりました。QuickStart にメッセージを送ることができれば、後は Node-RED を使って便利に処理できます。

このコマンドをプログラミング言語から実行するにはどのようにすればよいのか、それは別途紹介させていただくつもりです。
 

このページのトップヘ