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

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

タグ:iot

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 にデータを送信するサンプルとして使ってくださいませ。

MQTT は IoT の仕組みの中で使われることの多いプロトコルですが、以前からそれだけに使うのは勿体ないなあと思っていました。MQTT のリアルタイム性はチャットなどのメッセージングアプリケーションにも向いていると思っており、実際に Facebook Messenger の仕組みとしても使われているとの情報もあります。というわけで、MQTT を使ったチャットアプリの開発に挑戦してみました。

加えて、IoT といえば IBM Bluemix からも提供されている Node-RED が有名です。今回は IBM Bluemix 環境上の Node-REDIBM IoT Platform サービスの quickstart エディションを使ってチャットを作ってみることに挑戦しました。

何はともあれ、まずは Node-RED 環境を用意します。IBM Bluemix にログインし、ボイラープレートから Node-RED Starter を選択して、Node-RED が使えるアプリケーションサーバーインスタンスを用意します:
2017040301


IBM Bluemix の Node-RED を使わずに、自前等で Node-RED 環境を用意する場合は npm などで node-red-contrib-scx-ibmiotapp ノードをインストールして有効にしておく必要があります:
2017040302

(↑この ibmiot ノードが使える状態にしてください)


では Node-RED でチャットアプリを作ります、といっても実はかなりシンプルです。1つ1つノードを配置してもいいのですが、まずはインポートして中身を確認し、必要に応じて説明を加えることにします。画面右上のハンバーガーメニューを開き、 読み込み→クリックボード を選択します:
2017040303

 
「フローの読み込み」画面になったら、ここの内容をそっくりそのままコピー&ペーストして「読み込み」ボタンをクリックし、フロー定義を作成します:
2017040304


正しく読み込みが完了すると以下のような3本のデータフローが再現されるはずです。上から1つ目は GET /chat 実行時のチャット画面(HTML)の定義、2つ目はチャットメッセージを POST(POST /post) した時の処理、そして3つ目は IBM IoT サービスを使って MQTT 経由でチャット参加メンバーのメッセージを取り出す処理を定義しています。いずれもシンプルな処理で実現できていることが確認できます:
2017040305


画面内に2つの IBM IoT ノードが含まれています(青いノード、INPUT/OUTPUT が1つずつ)。それぞれダブルクリックすると、どちらにも Device Id を入力する項目があり、いずれも初期状態では空になっているはずです。この Device Id にはユニークな値を指定する必要があります。以下の例では "dotnsf.mqtt.chat.001" という値を設定していますが、ここには自分の名前や日付を含めるなどして、誰とも被らないユニークな値を設定します(2つのノード両方の Device Id に同じ値を指定します)。指定後「完了」ボタンをクリックします:
2017040306


また、2つ目のフローの中にある function ノードの中身を確認します。ここはチャット参加者が自分のメッセージを投稿した時に実行されるフローで、HTTP リクエストの本文(msg.req.body)の値を取り出して、その値を IoT の Payload に変換している部分です。これも非常にシンプルな処理内容が記述されていることが確認できます:
2017040307


改めて3つそれぞれのフローの中でどのような処理が定義されているのかを確認してみましょう。1つ目のフローはウェブブラウザから(サーバー名)/chat という URL に(GET リクエストで)アクセスした時に返される HTML の定義です。実際の HTML や CSS/JavaScript 定義そのものは「チャット画面」というテンプレートノードの中で定義されています(後述します):
2017040301


2つ目のフローはチャット画面の中で利用者が自分のメッセージをチャットに流した時に実行される処理です。チャットにメッセージを流すと(サーバー名)/post という URL に名前やメッセージ内容が HTTP POST され、その内容を(上記のように)取り出して MQTT の Payload に変換し、IBM IoT に転送(MQTT の処理でいうと「パブリッシュ」)しています。転送時にユニークな Device Id を指定していることで、同じテンプレートを使っても異なるアプリケーションであるとみなし、他の人が作ったチャットと混線しないようにしています。なお、緑色のノードはデバッグノードで、POST されたメッセージの内容をこの画面内からも確認できるようにしているだけで、実際の処理には無関係です(無くても動きます):
2017040302


そして3つ目のフローは上記2つ目のフローで処理されたメッセージを取り出すフローになります。自分だけでなく、同じチャット画面を見ている他のユーザーがメッセージを流した場合もこの処理が実行され、IBM IoT 経由で送られたメッセージが(サーバー名)/ws/chat という URL の WebSocket に送信されるよう記述されています。実際には1つ目の HTML の中で /ws/chat を監視しており、ここにメッセージが送られてきた場合の処理が記述されています:
2017040303


この状態でデプロイ(画面右上のボタン)をクリックすることで実際にチャットアプリケーションを使うことができるようになります。デプロイ後、PCやスマホのウェブブラウザで https://(Node-RED の動いているホスト名)/chat にアクセスしてみてください。Node-RED の一番上のフローが呼ばれ、テンプレートノードの中で定義された内容の HTML が表示されます。初期状態では↓のように名前の入力を求められます:
2017040301


適当な名前を入力して「入室」ボタンをクリックします(入室のタイミングで IoT と接続します):
2017040302


入室すると画面が切り替わり、自分の名前とメッセージ入力フィールドが画面下に表示されます。画面の大半はチャット履歴が表示される画面ですが、まだ何もメッセージがないので何も表示されていません:
2017040303


では試しに何かメッセージを入力してみます。入力を確定するには PC からであれば Enter キーを、スマホであれば「開く」などでメッセージを確定させてください:
2017040304


入力したメッセージがチャット履歴に表示されます。これは自分のメッセージなので右側に吹き出しがついて、緑色で表示されるようにしています:
2017040305


もう1つメッセージを送ると、メッセージが下に追加されます:
2017040306


試しに別のブラウザや別のスマホなどから同じ URL にアクセスして、別の名前で入室してメッセージを送信してみます。このユーザーから見ると入室前のメッセージは見れないので、自分のメッセージが一番最初に表示されます:
2017040307


が、元のユーザーからは別のユーザーが入室してきてメッセージを送信したことになります。その場合は白背景で、左側に吹き出しがある状態でチャット履歴に記録されます(この UI 見たことありますよね。意識して CSS を作ってます(笑)):
2017040308


同様にして別のユーザーが入室してくると、そのユーザーのメッセージも白背景で左に吹き出しが付く形で表示されていく、というものです。最低限のグループチャットの機能は実現できていると思ってます:
2017040309


さて、ではこのチャット画面の HTML はどうなっているのかを説明します。具体的な内容は PC ブラウザからアクセスして HTML ソース(と埋め込まれた CSS など)を直接参照していただきたいのですが、肝心な部分の JavaScript はこのようになっています(赤字はコメント):
  :

var socket; var wsUrl = 'wss://' + location.hostname + '/ws/chat'; //. WebSocket監視先URL function connect(){ //. 「入室」時に呼ばれる処理 console.log( "connect()" ); socket = new WebSocket(wsUrl); //. WebSocket 接続 socket.onmessage = function(e) { //. WebSocket にメッセージが来たら、以下を実行 var msg = JSON.parse(e.data); //. 送信データ(POST されたデータ)を JSON で取り出し //console.log( msg ); if( msg.id != deviceid ){ //. 自分のメッセージなのか、他人のメッセージなのかを判別 //. 自分以外の発言 var box = "<div class='question_box'><p class='notmymessage'>" + msg.name + "</p><div id='arrow_question'>" + msg.message + "</div></div>"; $('#contents').append( box ); }else{ //. 自分の発言 var box = "<div class='answer_box'><p class='mymessage'>" + msg.name + "</p><div id='arrow_answer'>" + msg.message + "</div></div>" $('#contents').append( box ); } } }

:

2つ目のフローで投稿したメッセージの内容が IBM IoT ノードに(MQTT で)送られていました。自分だけでなく同じチャットルームに入室している全ての人のメッセージがこのように MQTT データとして送信されます。 そしてその内容を3つ目のフローで取得し、/ws/chat というパスに WebSocket データとして送信していました。つまりチャットで誰かがメッセージを送ると、/ws/chat に WebSocket でデータが送られるということになります。そのデータを監視して、自分のメッセージか他人のメッセージかを判別して Dynamic HTML でチャット履歴に追加する、という部分の処理が上記になります。


そしてこれだけでチャットが実現できているということは、(気付いている人もいるかもしれませんが)少なくともここまでの処理に関してはデータベースを一切使わずに実現できていることを意味しています。確かにリアルタイムデータ処理なのでデータを保存する必要はないのですが、実際に保存せずに実現できるというのはなかなか興味深いのではないかと思っています。


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


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

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

個人的にはそこまでそんな時代が身近に迫ってきているとは思っていません。ただし、その一方で企業間の競争が働いたこともあり、ここ数年における人工知能分野の発展はすさまじいものがあります。静止画像や個人の機械認識率はぐんと上がり、各社が 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




IBM BluemixNode-RED および IBM IoT Foundation 環境を使って集めたデータをリレーショナルデータベース(dashDB)に格納する、という手順を紹介します。

まず準備段階として、「何の」データを集めるか、という問題があります。技術的な要素としては IBM IoT Foundation QuickStart 環境に MQTT パブリッシュが可能なアプリケーションやデバイスであれば何でもいいのですが、後のデータ解析のことを考え、シミュレーターではなく実機のデータを集めることにします。今回は IBM developerWorks Recipes から提供されているサンプルの1つでもあるラズベリーパイを使うことにします:
Connect a Raspberry Pi to Internet of Things Foundation

上記ページの Recipe を参照してラズベリーパイにアプリケーション("iot" という名前のサービス)を導入すると、ラズベリーパイから1秒ごとに CPU 負荷率(%)、CPU 温度(℃)、そしてサインカーブを描くような -1 から 1 までの間の値、の3つの値が1秒おきに IBM IoT Foundation(MQTT ブローカー)に送られるようになります。今回はそのデータを集めてみます。

iot サービスは MAC アドレスを deviceId として IoT Foundation QuickStart にメッセージを MQTT パブリッシュする仕様になっています。そこで iot サービス導入済みのラズベリーパイにログインし、ifconfig コマンドでイーサネットポート(或いはワイアレスポート)の MAC アドレスを調べておきます(下図では b827ebb9ddc0 ):
2015121502

ちなみにこの MAC アドレスは本物なので、もしラズベリーパイのデータを集めたいのであれば同じアドレスを指定いただければ、僕の自宅のラズパイデータを収集することができますw


そして Bluemix 上に作成した Node-RED 環境に ibmiot インプットノードと、debug アウトプットノードを配置して、線を結びます:
2015121501


また ibmiot インプットノードをダブルクリックして開き、deviceId 欄に先程調べた MAC アドレスを入力して OK をクリックします:
2015121503


また debug アウトプットノードもダブルクリックして開き、Output 欄を "complete msg object" に変更します(実体である payload 以外のデータも出力するようにします):
2015121506


最後に Node-RED 画面右上の Deploy ボタンをクリックすると、このノードアプリケーションが動き出します。指定した deviceId のデータを IBM IoT Foundation QuickStart(MQTT ブローカー)を通じて取得し、画面内の debug タブに出力されます:
2015121504


この個々のデータをよく見るとこのようなデータが送られてきていることが確認できます:
2015121505

{
"topic": "iot-2/type/iotsample-raspberrypi/id/b827ebb9ddc0/evt/status/fmt/json",
"payload": { "d":{ "myName": "myPi", "cputemp": 40.08, CPU温度(℃) "cpuload": 0,   CPU負荷(%) "sine": 0.53    サインカーブの値 }
},
"deviceId": "b827ebb9ddc0",
"deviceType": "iotsample-raspberrypi",
"eventType": "status",
"format": "json",
"_msgid": "8ebe5e09.7141a" 一意のメッセージID }

上記の赤字で書かれたデータは個々のメッセージ毎に変わるデータなので、このデータを集めることにします。先程作ったパレットから線を削除し、function ノードを間に追加して線を繋ぎ直します:
2015121507


function ノードをダブルクリックして、ここで JSON データの変換を行うよう指定します。以下のに内容に書き換えて OK をクリックしてください:
2015121508

return { payload:{
 ID: msg._msgid,
 CPUTEMP: msg.payload.d.cputemp,
 CPULOAD: msg.payload.d.cpuload,
 SINE: msg.payload.d.sine
}};

これで送られてくるメッセージから、ID, CPUTEMP, CPULOAD, SINE の4つの値だけをフラットに取り出すことができるようになりました。この状態で再度 Deploy すると debug タブにはこのようなデータが流れてくるはずです:
2015121509


この payload 部分を dashDB に格納します。改めて Bluemix のプロジェクトに dashDB サービスを追加します:
2015121501


実際にデータを追加(insert)するには、その前にテーブルを定義しておく必要があります。テーブルを定義するために dashDB サービスをクリックし、"LAUNCH" ボタンをクリックしてウェブコンソール画面へ移動します:
2015121502


dashDB のウェブコンソール画面が表示されたら、左メニューから "Tables" を選択します:
2015121503


テーブル一覧画面で "Add Table" ボタンをクリックします:
2015121504


"Create a table" ダイアログボックスが表示されます。ここで CREATE TABLE の SQL を指定して、テーブルを作成します:
2015121505


集めたデータを格納できるよう、以下の内容で RPDATA テーブルのスキーマを指定し、最後に "Run DDL" ボタンをクリックします:
CREATE TABLE "RPDATA"
(
  "ID" VARCHAR(20),
  "CPUTEMP" DOUBLE,
  "CPULOAD" DOUBLE,
  "SINE"  DOUBLE
);

"DDL ran successfully" というメッセージが表示されれば成功です:
2015121506


改めて先ほどの画面に戻るとテーブル一覧の中に "RPDATA" テーブルが追加されています。"RPDATA" テーブルを選択すると RPDATA テーブルの設計要素が表示されます。これで集めたデータを格納するためのテーブルが定義できました:
2015121507


改めて Node-RED 画面に戻り、dashDB ノード(左側だけに接続パーツが付いているもの)をパレットに追加し、function ノードから紐付けます:
2015121508


dashDB ノードをダブルクリックして、Service には Bluemix 上のサービス名称(おそらく選択肢は1つだけなのでそれを選択)、Table にはこのデータを格納する RPDATA テーブル(上記で定義したテーブル)を指定し、OK ボタンをクリックします:
2015121509


この状態で改めて Deploy します。成功しても Node-RED 上の画面では特に変化はありませんが、ラズベリーパイから送られてくるデータは dashDB の RPDATA テーブルに格納され続けているはずです:
2015121510


しばらく待ってから dashDB のウェブコンソール画面に移動し、テーブル一覧で RPDATA テーブルを選択して Browse Data タブを選ぶと、その時点までに溜まったデータが表示されます:
2015121511


これでラズベリーパイのデータを IBM IoT Foundation QuickStart 経由で dashDB に格納する、という処理が実現できました。


(追記 このエントリの続編はこちらです)
 

このエントリの続きです:
IBM IoT Foundation サービスへのデバイス登録方法

IBM IoT Foundation サービスを使うために、同サービスにデバイスを登録する方法を上記で紹介しました。では IBM IoT Foundation サービスに登録したデバイスのセンサーデータを Node-RED で集めるための方法を紹介します。


まずは上記手順の完了した IBM IoT Foundation サービスの環境変数を参照し、apiKey と apiToken の値を確認しておきます。これらの値は後に利用します:
2015112600


次に Node-RED のフローエディタを開き、IBMIoT インプットノードを1つ用意します:
2015112601


同ノードをダブルクリックして、属性を編集する画面に切り替えます:
2015112602


IBM IoT Foundation サービスを使う場合、Authentication は QuickStart ではなく、API Key にする必要があります。また API Key は "Mine" を選択、その他は以下のようにチェックボックスを付けます(名前も IBM IoTF に変更しています):
2015112603


API Key の横にある鉛筆マークをクリックしてノードの属性を確認します。ここではデバイスを追加した IBM IoT Foundation サービスの API Key と API Token(上記で確認したもの)が入っていることを確認してください(入っていなかったら入力してください):
2015112604


最後にこのノードにデバッグ output ノードを足して&繋いで、送られてきたデータが参照できるようにしておきます。この状態でデプロイしておきましょう:
2015112605


次に IoT Foundation サービスにに登録したデバイスから実際に MQTT メッセージをパブリッシュして、Node-RED のフローに送られたデータが表示されることを確認してみましょう。今回想定している環境ではこのようなデバイスを IoT Foundation サービスに登録していました:
属性属性値
組織IDttb8bh
デバイスタイプMyDevice
デバイスID(MACアドレス)112233445566
認証トークン(自分で指定する接続パスワード)K.Kimura777


このデバイスの場合、MQTT パブリッシャーとしては以下のような条件で IBM IoT Foundation サーバーにメッセージをパブリッシュすることになります:
設定項目設定値
MQTT ブローカーホストttb8bh.messaging.internetofthings.ibmcloud.com
(組織ID).messaging.internetofthings.ibmcloud.com
MQTT ブローカーポート1883
(固定値)
クライアントIDd:ttb8bh:MyDevice:112233445566
d:(組織ID):(デバイスタイプ):(デバイスID)
認証ユーザーIDuse-token-auth
(固定値)
認証パスワードK.Kimura777
(認証トークン)
トピックiot-2/evt/event_id/fmt/json
(固定値)
メッセージ{"d":{"a":"x","b":"y","c":"z"}}
(任意のJSONテキスト)


実際に動くデバイスがあれば、この内容でパブリッシュするようなコードを記述することでメッセージを送信することができます。ここでは MQTTLens を使って同じ動きをエミュレートして、動作を確認してみることにします。

まずコネクション画面では以下の様な内容でホスト名、クライアントID、ユーザー名、パスワードを指定して接続してください:
iotf08


実際にパブリッシュする際には、上記の Topic と JSON メッセージを指定してパブリッシュします:
iotf09


メッセージが正しく送信されれば、Node-RED 側の Debug タブに送信した JSON が表示されるはずです:
2015112601


期待通りに動きました。これで QuickStart を使わずに IBM IoT Foundation サーバーを使う方法が分かりました。QuickStart でなければ QOS = 1 の制約もなく、より自由度の高い MQTT ブローカー利用が可能になりますね。


(参考資料)
https://docs.internetofthings.ibmcloud.com/ja/messaging/mqtt.html
https://docs.internetofthings.ibmcloud.com/ja/messaging/devices.html


 

このページのトップヘ