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




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



主な挙動としては settings.js で指定された内容に併せて、１秒（デフォルト）ごとに０から１つずつ増えるカウンタ値、タイムスタンプ値、実行したマシンの 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 なので１秒ごとにメッセージを送信する）と、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 で指定した場合はその値が、指定しなかった場合は自動生成された値が表示されます。この後で使うのでメモしておきます：



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


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

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



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


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



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



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



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


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



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

タグ ：

ibm

cloud

watson

iot

platform

nodejs

javascript

mqtt

mqtt.js

quickstart

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

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

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



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


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


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


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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



さて、ではこのチャット画面の 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 );
    }
  }
}

  :

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


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

タグ ：

bluemix

ibm

watson

iot

platform

mqtt

chat

node-red

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


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

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

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

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



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





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

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


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

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


これを裏返すとこんな感じ（上図とは左右が逆になった状態）：



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



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

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

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


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



そして、ラズベリーパイ側にはこのような 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回（つまり２秒間）取得し、その20回中音が確認できた回数を MQTT ブローカー（iot.eclipse.org）に投げる、というものです。つまり MQTT ブローカーに対しては２秒おきにどれくらい音が識別できたかを 0 から 20 の整数値でパブリッシュする、というものです。トピックは上記例では "sen02281p" と指定していますが、皆さんがもしこのソースを使う場合は少し変えていただけると嬉しいです。

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



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


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



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

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

# python sen02281p.py

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



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


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

Live streaming video by Ustream

タグ ：

python

paho

nodered

mqtt

iot

sen02281p