TOCOS TWE無線タグのセンサデータを MQTT Broker に送信、TWE-MQTT Gateway

●概要

リモートに設置した TOCOS TWE無線タグ・デバイスのセンサデータを MQTT Broker に送信するシステム構築例を紹介します。このシステムは TWE-Lite や TWE-Lite-2525A 等で動作する無線タグアプリ・ファームウエア(Samp_Monitor) を動作させて、これらのリモートデバイスに接続したセンサデータを MQTT Broker に送信します。

●子機の配線

リモートに設置する無線タグデバイス・子機には TWE-Lite DIP を使用しています。東京コスモス電機のホームページで公開されている TWE-Zero アプリの “無線タグアプリ(Samp_Monitor)” を書き込んで使用します。

無線タグファームウエアに設定するセンサ種別は、デフォルト設定のアナログセンサモードで使用しています。アナログ入力AI3(a2タグ) ピンには光センサを接続しています。

A/D の入力電圧が 0-2.4V なので、これを超えないようにフォトダイオードの負荷抵抗を調整してください。上記の回路では2つの5.6K の抵抗で分圧したものを AI3 に接続しています。

子機は複数同時に使用することもできます。また、ファームウエアに設定するセンサー種別を変えて、 I2C 接続の温度センサや気圧センサなどを使用することもできます。この場合には、自動的に MQTT Broker に送信する JSON フォーマットがのタグ名が対応する名前に変更されます。

●親機の配線

子機からのセンサデータを受信する親機を準備します。子機と同様に TWE-Lite DIP デバイスを使用しています。PC の USB ポートに直接接続できる スティックタイプの TWE デバイスや TWE ライタデバイスを親機として使用できます。ここでは、TWE-Lite DIP をブレッドボード上に配置して、USB シリアルアダプタ(秋月電子: AE-UM232R)経由で PC に接続しています。

子機側の TWE-Lite DIP ファームウエアの書き換えや、コンフィギュレーション設定にも上記の回路を使用します。このため、リセットボタンとプログラム書き込み用のボタンも配置しておきます。TWE-Lite DIP デバイスの電源は USB シリアルアダプタから供給される 3.3V を使用しています。

●親機の設定

最初に親機側の TWE-Lite DIP デバイスを設定します。購入直後の TWE-Lite DIP ファームウエアには “超簡単!TWEアプリ” が入っていますが、今回はこれを書き換えて “無線タグ専用の親機ファームウエア” を書き込みます。ファームウエアは東京コスモス電機の TWE-Zero アプリのページで公開されていますのでこれを使用します。詳しい書き込み方法はファームウエアのページを参照して下さい。

ここでは、ファームウエア書き込み後の親機側のコンフィギュレーション設定を説明します。親機の TWE-Lite DIP を USB シリアルアダプタに接続した状態で、シリアル端末ソフト(TeraTerm 等)で仮想 COM ポートに接続します。

“+” キーを3回連続で押してコンフィギュレーション画面に入ります。

最初に “Application ID” を設定します。この例では 0×11223344 を設定しています。この “Application ID” は接続する全ての子機側でも同じ値に設定します。

“Option Bits” に 0×00020000 フラグを既存の設定値と ”OR” した0×00020001 に設定しています。このフラグ設定によって、親機自身から出力されるカウンタ?(::ts=xxxx)データを抑止しています。リモートの無線タグ・デバイスから送信されるセンサデータ以外のデータレコードが親機自身から送信されて、シリアル出力のサイズが増えないようにしています。後で作成するMQTT ブローカに送信する部分の Lua スクリプト中で、これらの不要なデータレコードを取り除く処理を行いますので、このフラグを設定しなくても正常に動作します。

その他のフラグやコンフィギュレーション項目はデフォルトのままで大丈夫です。

●子機の設定

次に子機の TWE-Lite DIP デバイスを設定します。ファームウエアを書き換えますので、親機の設定で使用したブレッドボードから親機用のTWE-Lite DIP デバイスを抜いて、子機の TWE-Lite DIP デバイスを代わりに差し込みます。これらの作業をするときには、PC と接続している USB ケーブルを抜いた状態でデバイスの入れ替えをすると安全に操作できます。

親機と同様にメーカのホームページから”無線タグ専用の子機ファームウエア” を書き込みます。その後、子機のファームウエアを設定します。子機のコンフィギュレーション設定をするときだけは、TWE-Lite DIP の M2 ピンを GND に接続する必要があります。ブレッドボード上でジャンパケーブルを M2(26pin) と GND に接続してください。その後、シリアル端末ソフト(TeraTerm 等)でUSBシリアルアダプタに接続した後、ブレッドボード上のリセットボタンを押して子機ファームウエアのコンフィギュレーション画面に入ります。

“Application ID” には親機と同じ 0×11223344 を設定します。”Option Bits” にはOTA(無線経由での設定)を停止するためのフラグ 0×400 を有効にします。また、ここではセンサデータの送信間隔(Sleep Dur) を 300ms に設定していますが任意の値に設定しても構いません。

子機の設定が終了したら “save Configulation” で設定値を保存します。

全ての子機の設定を同様におこなったら、子機と親機の TWE-Lite DIP デバイスをそれぞれの本来の回路に戻しておきます。このとき、親機のブレッドボード上に配線した M2 <-> GND 間の配線を取り除くのを忘れないようにします。これで、無線タグデバイスのセットアップは完了しました。

●TWE-Lite タグデバイスの動作確認

MQTT broker への送信設定を行う前に、TWE 無線タグ・デバイスが動作しているかどうかを確かめてみます。

親機の USB シリアルアダプタにシリアル端末で再び接続してください。子機の無線タグの電源を入れると、下記の様なデータレコードが親機からシリアル送信されていればリモート側の無線タグは正常に動作しています。

*** Samp_Monitor (Parent) 1.05-5 ***
* App ID:11223344 Long Addr:81004152 Short Addr 0152 LID 00
::rc=80000000:lq=66:ct=0001:ed=81002A1E:id=0:ba=3310:a1=1922:a2=2467:p0=000:p1=000
::rc=80000000:lq=69:ct=0002:ed=81002A1E:id=0:ba=3280:a1=1845:a2=2467:p0=000:p1=000
::rc=80000000:lq=69:ct=0003:ed=81002A1E:id=0:ba=3400:a1=1891:a2=2467:p0=000:p1=000
::rc=80000000:lq=72:ct=0004:ed=81002A1E:id=0:ba=3440:a1=1975:a2=2467:p0=000:p1=000
::rc=80000000:lq=69:ct=0005:ed=81002A1E:id=0:ba=3400:a1=2035:a2=2467:p0=000:p1=000
::rc=80000000:lq=72:ct=0006:ed=81002A1E:id=0:ba=3440:a1=2105:a2=2467:p0=000:p1=000
::rc=80000000:lq=72:ct=0007:ed=81002A1E:id=0:ba=3440:a1=2120:a2=2467:p0=000:p1=000

もし、親機のファームエア設定で 0×00020000 フラグを設定していないときには、下記のようなシリアル出力になります。

::rc=80000000:lq=90:ct=0078:ed=81002A1E:id=0:ba=3440:a1=1435:a2=2467:p0=000:p1=000
::ts=435
::rc=80000000:lq=90:ct=0079:ed=81002A1E:id=0:ba=3460:a1=1442:a2=2467:p0=000:p1=000
::rc=80000000:lq=93:ct=007A:ed=81002A1E:id=0:ba=3470:a1=1435:a2=2467:p0=000:p1=000
::rc=80000000:lq=90:ct=007B:ed=81002A1E:id=0:ba=3440:a1=1418:a2=2467:p0=000:p1=000
::ts=436
::rc=80000000:lq=93:ct=007C:ed=81002A1E:id=0:ba=3450:a1=1418:a2=2467:p0=000:p1=000
::rc=80000000:lq=93:ct=007D:ed=81002A1E:id=0:ba=3460:a1=1440:a2=2467:p0=000:p1=000
::rc=80000000:lq=93:ct=007E:ed=81002A1E:id=0:ba=3460:a1=1430:a2=2467:p0=000:p1=000
::ts=437
::rc=80000000:lq=93:ct=007F:ed=81002A1E:id=0:ba=3440:a1=1420:a2=2467:p0=000:p1=000

これで、親機と子機の無線タグが正常に動作しているのを確認できました。複数の子機を同時に動作させることもできますので、この場合にはそれぞれのデバイスからのデータも表示されます。

動作確認が終了したら、シリアル端末のプログラムを終了させて COM ポートを開放してください。以降の設定で、親機からの出力される上記のシリアルデータを変換して MQTT Broker に JSON 文字列を送信します。

●TWE無線タグ・親機のシリアルデバイスを DeviceServer に登録

TWE無線タグ・親機から出力されるリモートセンサデータを取り込むために、DeviceServer にシリアルデバイスを登録します。”サーバー設定プログラム” を起動して、”SERIAL” タブを選択します。

親機が接続されている仮想 COM ポート(ここでは “COM10″) にデバイスタイプ “TWE”でシリアルデバイスを登録した様子です。デバイスの詳細設定は以下の様になっています。

デバイスタイプは “TWE” を選択します。シリアルデバイスのタイトル文字は適当な名前をつけて下さい。シリアルポート通信条件はファームウエアのデフォルト値 (15200baud, 8bit, 1stop-bit, no parity) に合わせます。

これで、親機からセンサデータを受信する度に、DeviceServer 側ではイベントハンドラスクリプト SERIAL_TWE.lua が実行されるようになります。

●MQTT エンドポイント作成

シリアルデバイスの作成に続いて、サーバー設定プログラムの “MQTT” タブを選択して、MQTT Broker との接続(エンドポイント)を作成します。

ここでは、2つのエンドポイントを作成しています。1つめが、TWE リモートセンサデータを MQTT Brokerに登録するための接続で、後の1つが、MQTT Broker からセンサデータを受信して、ログに出力したり LED 表示器に A/D 変換値を出力するための接続です。

今回は、構成をわかり易くするために MQTT Broker 接続のエンドポイントを2つに分けていますが、センサーデータ登録用と受信用のエンドポイントを1つで共有して運用しても構いません。

“サーバー設定プログラム”の “MQTT” タブを押してエンドポイントリストを表示した状態です。ここでは既にデータ登録用のエンドポイントとして、タイトル名 “センサーデータ登録” と データ取得用のエンドポイント、タイトル名 “センサーデータ取得” の2つのエンドポイントが登録されています。

“センサーデータ登録” のエンドポイントの詳細設定は以下の様になっています。

接続先の MQTT Broker は、IP アドレス192.168.100.14、ポート番号1883 で動作している RaspberryPi 上の mosquitto にしています。mosquitto MQTT ブローカについては、こちらの記事も参照してください。

“センサーデータ取得” のエンドポイントの詳細設定は以下の様になっています。

MQTT Broker の IP アドレスや ポート番号は同じですが、このエンドポイントでは起動時に購読するトピックを複数設定しています。

TWE 無線タグ・デバイスのセンサーデータは、下記のトピック名で送信されています。

”/twe/<TWE 子機のMACアドレスを表す16進数文字列>/Samp_Monitor”

全ての無線タグ子機から送信されるセンサーデータを購読するために、トピック名 “/twe/+/Samp_Monitor” を購読するように設定します。

”/+/+/io” や “/+/+/tdcp” のトピック購読は、リモートに設置した XBee デバイスやマイコンボード等からのセンサーデータ購読のために指定しています。今回はこれらからのトピック・データは使用していません。

これで、DeviceServer 側の親機のシリアル設定と MQTT エンドポイント設定は完了しました。サーバー設定プログラムの “次へ” ボタンを押して設定を反映させると DeviceServer が再起動してTWE 無線タグ親機へのシリアル接続と MQTT Broker へのエンドポイント接続が自動的に開始されます。

●MQTT Broker にTWE無線タグセンサ・データを JSON 形式で送信する

次に、DeviceServer 側で実行されているデフォルトのイベントハンドラスクリプトをエディタで変更して、MQTT Broker にセンサーデータを JSON 形式で送信するようにします。

TWE 無線タグ親機からセンサーデータを受信する毎に、SERIAL_TWE.lua イベントハンドラが実行されますので、この内容を変更して下記のようにします。

(ここで紹介しているイベントハンドラの内容はコメントアウトされた状態でインストールキットに含まれています。そのため、この記事の内容を試す場合にはイベントハンドラ中の該当部分のコメント指定を外して直ぐに使用できます)

file_id = "SERIAL_TWE"

--[[

******************************************************************************
* イベントハンドラスクリプト実行時間について                                 *
******************************************************************************

一つのスクリプトの実行は長くても数秒以内で必ず終了するようにしてください。
処理に時間がかかると、イベント処理の終了を待つサーバー側でタイムアウトが発生します。

また、同時実行可能なスクリプトの数に制限があるため、他のスクリプトの実行開始が
待たされる原因にもなります。

頻繁には発生しないイベントで、処理時間がかかるスクリプトを実行したい場合は
スクリプトを別に作成して、このイベントハンドラ中から script_fork_exec() を使用して
別スレッドで実行することを検討してください。

******************************************************************************

SERIAL_TWE スクリプト起動時に渡される追加パラメータ
---------------------------------------------------------------------------------
キー値			値		            									値の例
---------------------------------------------------------------------------------
COMPort			イベントを送信したシリアルデバイスの COMポート名		"COM10"

Title			イベントを送信したシリアルデバイスのタイトル名			"TWE-Lite PAN#1"
				タイトルが設定されていない場合にはこのパラメータは
				設定されません

TWE_DATA		COM ポートから入力されたアスキー形式のデータパケット全体を格納しています。

	値の例

	タイプ(1)	":01890902010A010203040405060708092F"
	タイプ(2)	"::rc=80000000:lq=84:ct=0001:ed=81002A1E:id=1:ba=3320:a1=0009:a2=0009:p0=001:p1=000"
	タイプ(3)	";116;00000000;054;001;1002ecd;3330;0007;0042;0007;0007;S;"
	タイプ(4)	"!INF TOCOS TWELITE DIP APP V1-00-2, SID=0x81000038, LID=0x78"
	タイプ(5)	"*** Samp_Monitor (Parent) 1.03-3 *** Title = TWE-Zero"

	文字列は、下記の何れかのデータで終端されたものです。
	ヌル文字(0x00),CR(0x0D),LF(0x0A),CR-LF(0x0D,0x0A)
	TWE_DATA パラメータには、終端文字を含まない文字列部分が格納されています

TWE_DATAを解析してこのスクリプト中で作成されるテーブルと文字列変数
---------------------------------------------------------------------------------
テーブルまたは文字列変数名		説明									値の例
---------------------------------------------------------------------------------
byte_arr	TWE_DATA が ":" 1文字から始まっている場合に、16進数文字列部分を
			1バイト毎に数値に変換して配列に格納したものが入る
			上記 TWE_DATA データ例タイプ(1)を参照

			byte_arr[1] = 0x01
			byte_arr[2] = 0x89
			byte_arr[3] = 0x09
			..

key_val		TWE_DATA が "::" 2文字から始まっている場合に、続く ":" 文字毎にカラムを
			分けて "<key>=<val>" で記述された部分を連想配列に格納したものが入る。
			上記 TWE_DATA データ例タイプ(2)を参照

			key_val["rc"] = "80000000"
			key_val["lq"] = "84"
			key_val["ct"] = "0001"
			key_val["ed"] = "81002A1E"
			..

tag_arr		TWE_DATA が ";" 1文字から始まっている場合に、続く ";" 文字毎にカラムを
			分けたものを文字列形式で配列に格納したものが入る。
			上記 TWE_DATA データ例タイプ(3)を参照

			tag_arr[1] = "116"
			tag_arr[2] = "00000000"
			tag_arr[3] = "054"
			tag_arr[4] = "001"
			..

comment		TWE_DATA が ":"または ";" 文字以外から始まっている場合に、
			データパケット全体の文字列を格納したものが入る
			上記 TWE_DATA データ例タイプ(4),(5)を参照

			COMMENT = "!INF TOCOS TWELITE DIP APP V1-00-2, SID=0x81000038, LID=0x78"

TWE_DATAを解析してこのスクリプト中で作成されるグローバル共有変数と共有文字列リスト
---------------------------------------------------------------------------------
グローバル共有変数名						説明
または、共有文字列リストChannel名
---------------------------------------------------------------------------------

TWE_<COMPort>_<ChildID>

			TWE_DATA が ":" 1文字から始まっていて、かつコマンド種別を示すバイト値が
			0x81(状態通知)の場合に、メッセージ内容を解析した値がカンマ区切りで
			グローバル共有変数に格納される。この変数の値は常に最後のイベント発生時
			の内容で更新されます。

			<COMPort>は、イベントを送信したシリアルデバイスの COMポート名になります
			<ChildID>は、メッセージ中の送信元論理デバイスIDを10進数にしたものになります

			変数の内容に設定されるカンマ区切りの文字列は下記のフォーマットになります。

			<LQI>,<Batt>,<DI1>,<DI2>,<DI3>,<DI4>,<AD1>,<AD2>,<AD3>,<AD4>

			<LQI> にはLQI値フィールドの値を10進数に変換したものが入ります
			<Batt> には電源電圧[mV]フィールドの値を10進数に変換したものが入ります
			<DI1>..<DI4> にはDI の状態ビットが Lowの場合に1, High の場合に 0 が入ります
			<AD1>..<AD4> にはAD変換値の値を10進数に変換したものが入ります

TWE_<COMPort>_CHILD_LIST (共有文字列リストChannel名)
			TWE_DATA が ":" 1文字から始まっているパケットデータを受信したときの
			<ChildID> 部分を文字列リストに保存します。文字列リストにはメッセージ中の
			送信元論理デバイスIDを10進数表現にしたものを重複なく保存しています。
]]

local str = ""
for key,val in pairs(g_params) do
	str = str .. key .. " = " .. val .. " "
end
log_msg(str,file_id)

------------------------------------------------------------
-- g_params["TWE_DATA"] データパケット文字列をデコードする
------------------------------------------------------------
local data = g_params["TWE_DATA"]
local byte_arr,key_val,tag_arr,comment
if string.match(data,"^::") then		-- タイプ(2)
	key_val = key_val_to_tbl(string.sub(data,3,-1))
elseif string.match(data,"^:%x") then	-- タイプ(1)
	byte_arr = hex_to_tbl(string.sub(data,2,-1))
	local id = tostring(byte_arr[1])
	if not add_shared_strlist("TWE_" .. g_params["COMPort"] .. "_CHILD_LIST",id,true) then error() end -- 子機のIDリストを更新
	if byte_arr[2] == 0x81 then -- 状態通知の場合には共有変数に現在のセンサ値を保存
		local di1,di2,di3,di4,ad1,ad2,ad3,ad4
		if bit_and(byte_arr[17],0x01) ~= 0 then di1 = "1" else di1 = "0" end
		if bit_and(byte_arr[17],0x02) ~= 0 then di2 = "1" else di2 = "0" end
		if bit_and(byte_arr[17],0x04) ~= 0 then di3 = "1" else di3 = "0" end
		if bit_and(byte_arr[17],0x08) ~= 0 then di4 = "1" else di4 = "0" end
		if byte_arr[19] == 0xFF then ad1 = "-1" else ad1 = tostring((byte_arr[19]*4 + bit_and(byte_arr[23],0x03))*4) end
		if byte_arr[20] == 0xFF then ad2 = "-1" else ad2 = tostring((byte_arr[20]*4 + bit_and(bit_rshift(byte_arr[23],2),0x03))*4) end
		if byte_arr[21] == 0xFF then ad3 = "-1" else ad3 = tostring((byte_arr[21]*4 + bit_and(bit_rshift(byte_arr[23],4),0x03))*4) end
		if byte_arr[22] == 0xFF then ad4 = "-1" else ad4 = tostring((byte_arr[22]*4 + bit_and(bit_rshift(byte_arr[23],6),0x03))*4) end
		local val = tostring(byte_arr[5]) .. "," .. tostring(byte_arr[14]*256 + byte_arr[15])
				.. "," .. di1 .. "," .. di2 .. "," .. di3 .. "," .. di4
				.. "," .. ad1 .. "," .. ad2 .. "," .. ad3 .. "," .. ad4
		if not set_shared_data("TWE_" .. g_params["COMPort"] .. "_" .. id,val) then error() end
		-- リレーサーバーに最新データの配信を依頼する場合には下記のコメントを削除する
		script_exec("RELAY_SERVER_UPLINK","COM,TYPE,NodeID,LQI,Batt,DI1,DI2,DI3,DI4,AD1,AD2,AD3,AD4",g_params["COMPort"] .. ",TWE_UPDATE," .. id .. "," .. val)
	end
elseif string.match(data,"^;") then		-- タイプ(3)
	tag_arr = ssv_to_tbl(string.sub(data,2,-2))
else									-- タイプ(4),(5)
	comment = data
end

--[[
********************************************************************

TWE(Samp_Monitor)->MQTT Gateway 機能の実装例

Samp_Monitor ファームウエアで動作中のリモート TWEデバイスから送信されたタグ・データを MQTT に登録します。
Samp_Monitor ファームウエアのオプション設定によって、送信されるタグの項目は変わります。詳しくは
ファームウエアのドキュメントを参照して下さい。このスクリプトでは送信されたタグのキーと値をそのまま
文字列ペアとして JSON に変換しています。

トピック名: "/twe/<Samp_Monitor フレーム中の "ed"(MACアドレス)タグの値>/Samp_Monitor"
メッセージ文字列: JSON キー名部分は下記スクリプト中の "tag_name" テーブルに設定することで変更できます

{"id":"0","ct":"0007","ed":"81002A1E","ba":"2840","rc":"80000000","lq":"57","p0":"000","a2":"2113","a1":"11..(キーと値のペアが続く)

送信先 MQTT ブローカは、サーバー設定プログラムを使用して
エンドポイントを登録して下さい。下記スクリプト中の end_point 変数に
エンドポイントのタイトル文字列または ClientID を設定します。

********************************************************************
]]

-- データが文字列 "::" から始まるデータタイプ(2)の場合で、且つ "ed"タグが含まれているものだけを、MQTTブローカ送信対象にする
if key_val and key_val["ed"] then
	local dev = key_val["ed"]
	local end_point = "センサーデータ登録"
	local topic = "/twe/" .. dev .. "/Samp_Monitor"
	local qos = 1

	-- TWE のタグ名を変更して JSON 形式にする場合は、変更したいタグを下記テーブルに指定する
	local tag_name = {}
	tag_name["ba"] = "battery"
	tag_name["ct"] = "count"
	tag_name["lq"] = "LQI"
	tag_name["te"] = "temperature"
	tag_name["hu"] = "humidity"
	tag_name["at"] = "pressure"
	tag_name["x"] = "acc_x"
	tag_name["y"] = "acc_y"
	tag_name["z"] = "acc_z"

	local json_str = '{'
	local first = true
	for key,val in pairs(key_val) do
		if first then
			first = false
		else
			json_str = json_str .. ","
		end
		if tag_name[key] then
			json_str = json_str .. string.format('"%s":"%s"',tag_name[key],val)
		else
			json_str = json_str .. string.format('"%s":"%s"',key,val)
		end
	end
	json_str = json_str .. '}'
	mqtt_publish(end_point,topic,json_str,qos)
end

イベントハンドラの最初の部分では、TWE-Zero アプリ(ファームウエア) で使用される幾つかの種類のレコードフォーマットを解析するための共通ルーチンが定義されています。

無線タグアプリ(Samp_Monitor) は上記コメント中の タイプ(2) のレコードフォーマットとして解析されて、Lua テーブル key_val[] にタグのキーと値が対応付けられて作成されます。

スクリプトの後半部分で、MQTT Brokerに送信するための JSON 形式の文字列を作成しています。key_val[] テーブルのキーと値は、TWE無線タグ親機から送信されるタグの、キーと値にそのまま対応しています。ここではこのキー名と値を利用して下記のような JSON 形式の文字列に変換します。

{“id”:”0″,”ct”:”0007″,”ed”:”81002A1E”,”ba”:”2840″,”rc”:”80000000″,”lq”:”57″,”p0″:”000″,”a2″:”2113″,”a1″:”11″,”a2″:”334″}

“ba” や ”lq” などのタグ名を、JSON データ利用側で判りやすいように “battery”, “LQI” などの名前に変換するための機能がスクリプト中に記述されています。詳しくはスクリプト中のコメントをご覧ください。

mqtt_publish() ライブラリ関数をコールすることで、JSON 形式に変換したリモート無線タグから受信したセンサデータを MQTT Broker に送信します。

これで、リモートに設置した全てのTWE 無線タグのセンサデータが MQTT Broker に送信されるようになります。TWE無線タグ・子機のオプション設定を変更して、接続するセンサーデバイスを変更した場合でも、出力されるデータのタグ名に対応した JSON 形式に変換されて MQTT Broker に送信されます。

●MQTT Broker からTWE無線タグ・センサ・データを受信する

次に、DeviceServer 側から MQTT Broker のセンサーデータの購読する部分のスクリプトを作成します。MQTT Broker に送信したセンサデータを再び DeviceServer 側に取り込んで利用する形になります。今回のシステム構成では、MQTT Broker に送信する前にセンサデータを処理できるのであくまでも、MQTT Broker からのデータ取得の一例として紹介します。

インストール直後のデフォルトスクリプトは、MQTT Broker から購読したデータ列を文字列に変換してログに出力しているだけですが、この部分を変更して子機無線タグのAI3 (“a2″タグ) に接続した光センサの値をログに出力します。MQTT_PUBLISH.lua イベントハンドラの内容に下記の記述を追加します。

file_id = "MQTT_PUBLISH"

--[[

******************************************************************************
* イベントハンドラスクリプト実行時間について                                 *
******************************************************************************

一つのスクリプトの実行は長くても数秒以内で必ず終了するようにしてください。
処理に時間がかかると、イベント処理の終了を待つサーバー側でタイムアウトが発生します。

また、同時実行可能なスクリプトの数に制限があるため、他のスクリプトの実行開始が
待たされる原因にもなります。

頻繁には発生しないイベントで、処理時間がかかるスクリプトを実行したい場合は
スクリプトを別に作成して、このイベントハンドラ中から script_fork_exec() を使用して
別スレッドで実行することを検討してください。

******************************************************************************

MQTT_PUBLISH スクリプト起動時に渡される追加パラメータ

---------------------------------------------------------------------------------
キー値			値		            									値の例
---------------------------------------------------------------------------------
ClientID		エンドポイントの ClientID 文字列						"abs9k:2222-eagle"

Title			エンドポイントに設定されたタイトル文字列。
				タイトル文字列が設定されていない場合には、"" 空文字列
				が入ります												"センサーデバイス#1"

MessageType		MQTT プロトコルで定義されたメッセージタイプが入ります。	"3"
				PUBSLIH メッセージの場合には常に "3"が設定されます

MessageID		Brokerから送信するときに使用された MQTT メッセージID が
				入ります。(QoS = 1 または QoS = 2 の場合) 値は "1" から
				"65535" の整数値をとります。
				QoS = 0 の場合には常に "0" が設定されます。				"1234"

Dup				MQTT 固定ヘッダ中の Dup フラグの値が設定されます。
				"0" または "1" の値をとります。							"0"

QoS				MQTT 固定ヘッダ中の QoS フラグの値が設定されます。
				"0", "1", "2" の何れかの値をとります。					"0"

Retain			MQTT 固定ヘッダ中の Retain フラグの値が設定されます。
				"0" または "1" の値をとります。							"0"

PublishTopic	MQTT ブローカから受信した PUBLISH メッセージ中の Topic
				文字列。												"センサー/ノード1"

PublishData		MQTT ブローカから受信した PUBLISH メッセージ中のペイロー
				ドデータ。
				バイナリデータを16進数文字列に変換したものが格納されます
				ペイロードデータに格納されたデータが UTF-8 文字列の場合
				には文字列コードのバイト列が格納されています。
				イベントハンドラ中でこれらの文字列データをデコードする処
				理がデフォルトで記述されていますので、UTF-8 文字列を扱う
				場合にはデコード後の変数を利用することができます。		"010203414243"

PublishDataで渡されたペイロードデータを解析して作成される文字列変数

PublishString	PublishData に格納されたペイロードデータ部分のサイズが
				2048 Bytes以内の場合に、データバイト列を UTF-8形式で
				文字列にデコードした結果を PublishString に格納します。
				変換対象のバイト列のサイズを変更したいときには該当する
				スクリプト部分を変更して下さい。

]]

------------------------------------------------------------------------------------------
-- 受信したペイロードデータのサイズが 2048 bytes 以内の場合には
-- バイナリデータ列を UTF-8 文字列としてデコードしたものを PublishString 変数に格納する
------------------------------------------------------------------------------------------
local PublishString = ""
local pub_len = string.len(g_params["PublishData"]) / 2
if pub_len < 2048 then
	PublishString = readUTF_hex(bit_tohex(pub_len,4) .. g_params["PublishData"])
end

log_msg(g_params["Title"] .. "[" .. g_params["ClientID"] .. "] msg:" .. g_params["MessageID"] .. " dup:" .. g_params["Dup"]  ..
" retain:" .. g_params["Retain"]  .. " qos:" .. g_params["QoS"]  .. " topic:" .. g_params["PublishTopic"]  .. " " .. PublishString,file_id)

if g_params["Title"] == "センサーデータ取得" then

	---------------------------------------------------------------------------------------
	-- 過去データ確認用に時系列データベースに Publish されてきた文字列(JSON)を保管しておく
	---------------------------------------------------------------------------------------
	if not add_series_str(g_params["PublishTopic"],PublishString) then error() end

	------------------------------------------------
	-- その他のアクション定義
	------------------------------------------------
	json = require('json')
	local data_tbl = json.decode(PublishString) -- JSON デコードして Lua テーブル構造に変換

	if data_tbl.a2 then -- JSON データ中に "a2" キー名に対応するデータが存在するときだけ実行
		local a2_num = tonumber(data_tbl.a2)
		log_msg("A2 = " .. tostring(a2_num),file_id)
		------------------------------------------------
		-- 7セグLED表示器にメッセージ表示
		------------------------------------------------
		local tbl = {}
		tbl["com"] = "Arduino実験ボード#1"
		tbl["data"] = tostring(a2_num)
		tbl["width"] = "8"
		if not script_exec("ARDUINO/DEVICE/SPI_7SEGLED",tbl) then error() end
	end

end

add_series_str() をコールしている部分は、後で過去のデータをグラフ表示する時などに利用できるように、DeviceServer 内蔵のデータベースに取得した JSON 文字列をそのまま格納しています。

次の部分では、JSON 文字列をデコードして Lua のテーブル構造に変換しています。テーブルの形にしておくとで、センサデータの内容を取り出すことが簡単にできるようになります。data_tbl.a2 には JSON 文字列中の { …. “a2″:”xxxx” } の部分が入っていますので、これを数値に変換することで AI3 の A/D 変換値が得られます。ここでは、この値をログに出力しています。

動作中のログを下記に示します。MQTT Broker にセンサーデータを登録して、同時にそのセンサーデータを MQTT から購読した後上記スクリプト中で A/D 変換値を出力するまでがログに出力されています。

●おまけ

MQTT_PUBLISH.lua イベントハンドラスクリプト中からは、Arduino に接続した 7セグLED 表示器(秋月電子 M-06681) に現在の A/D 変換値を表示しています。

7セグLED 表示器は SPI 接続で簡単にスクリプト中から操作できますので、最新のデータを確認するのに便利です。

Arduino と DeviceServer 間はシリアル接続されいて、Firmata プロトコルで SPI 通信コマンドをやり取りしています。(Firmata プロトコルで Arduino をDeviceServerから操作するアプリ例はこちらの記事を参照してください)

動作の詳細はインストールキットに含まれている下記のスクリプトをご覧ください。また、Arduino で動作させるスケッチ(SensorControlModule.ino)もインストールキットに含まれていますのでご利用下さい。

Arduino に SPI 接続した LED表示器を DeviceServer から操作するスクリプト

C:\Program Files (x86)\AllBlueSystem\Scripts\ARDUINO\DEVICE\SPI_7SEGLED.lua

C:\Program Files (x86)\AllBlueSystem\Scripts\ARDUINO\DEVICE\SPI_WRITE.lua

それではまた。

 

MQTT から WebSocket 経由で IO データを受信してグラフ表示、XBee-MQTT Gateway (その2)

●概要

この記事では、前の記事で説明した  MQTT ブローカに登録されている XBee IO サンプリングデータを、WebSocket 経由で取得してグラフ表示をする Webアプリケーションを作成します。

リモート XBee デバイスから JSON 形式で MQTT ブローカに送信された IO サンプリングデータを、Web アプリケーション中から購読(MQTT Subscribe) します。MQTT からメッセージを受信したら、メッセージ内容からデータを取り出してグラフ表示します。MQTT ブローカからは連続してメッセージを受信しますので、グラフは最新のデータで更新されてスクロール表示されます。

下記は、XBee (Device5) のAD0 に接続した光センサの値をグラフ表示した様子です。

●MQTT ブローカ mosquitto を WebSocket 対応版にする

前回の記事までで使用していた MQTT ブローカ (mosquitto) は、RaspberryPi 上でバイナリパッケージをインストールしたものを使用していました。mosquitto の最新バージョン ver1.4.2 では WebSocket をサポートしているのですが、残念ながら記事を作成していた時点では最新バージョンのバイナリパッケージをインストールできませんでした。そのため、mosquitto のホームページから直接ソースをダウンロードしてコンパイルすることにします。

mosquitto-1.4.2.tar.gz ファイルを RaspberryPi にダウンロードして適当な場所に展開します。

デフォルトのビルド設定では WebSocket が有効にされていないので、config.mk ファイルを修正して使えるようにします。ファイル中でコメントアウトされた下記の部分を

#WITH_WEBSOCKETS:=no

以下の様に変更します

WITH_WEBSOCKETS:=yes

その後、make コマンドを実行するとコンパイルされて最新のバージョンの mosquitto が作成されます。実行する RaspberryPi の環境によっては、幾つかの足りないライブラリやパッケージを RaspberryPi にインストールする必要がでてくると思います。この場合でも コンパイルエラーで表示されるメッセージを手がかりにネットで検索すると、必要なパッケージやライブラリが簡単に見つかります。あきらめずにコンパイルに挑戦して下さい。(ライブラリをインストールしたときにはライブラリキャッシュの更新を忘れずに!)

無事にコンパイルが完了したら、既存の mosquitto パッケージをアンインストールしてプロセスを削除してください。その後、”src” ディレクトリに移動して先ほどコンパイルして作成した mosquitto を起動します。

起動時にはデフォルトの TCP/IP ポート 1883 の他に、WebSocket を使用するコンフィギュレーションファイルを指定します。下記の内容のファイルをホームディレクトリにmosquitto.conf の名前で作成しました。ここではWebSocket のポート番号を 9090 にしていますが別の値を指定しても構いません。

以前のバージョンの mosquitto で使用していたユーザーアカウントファイルを、 password_file パラメータで再利用しています。MQTT アカウントの認証を省略する場合には、このパラメータは削除してください。

listener 1883

listener 9090 127.0.0.1
protocol websockets

password_file /etc/mosquitto/password_file

作成したコンフィギュレーションファイルを使用して mosquitto MQTT ブローカを起動するまでの様子は以下になります。

mosquitto を起動したときのメッセージを確認してください。TCP/IP のポート 1883 と WebSocket のポート 9090 がそれぞれ ”listen” 状態になっていれば大丈夫です。

これで WebSocket も使用可能な MQTT ブローカ(mosquitto) の準備が完了しました。DeviceServer を再起動して MQTTT エンドポイントを接続してください。その後、前のバージョンの時と同様に XBee からの IO サンプリングデータを mosquitto_sub コマンドで確認してください。

●Webアプリケーション作成

ここからは、Web アプリケーションを作成します。最初に index.html ファイルを下記の内容で作成します。ここで紹介する Web アプリのファイルは、最新の DeviceServer インストールキットに含まれています。DeviceServer が動作している PC の “C:\Program Files (x86)\AllBlueSystem\WebRoot\web_api_sample\mqtt_xbee_chart” フォルダに Webアプリケーションに必要なファイルが格納されています。

<!DOCTYPE html>
<html>
	<head>
		<meta charset="utf-8" />
		<meta name="viewport" content="width=device-width, initial-scale=1" />
		<title>MQTT-XBee ゲートウェイ ADCグラフ</title>
		<link rel="stylesheet" href="libs/css/themes/default/jquery.mobile-1.4.5.min.css" />
		<link rel="stylesheet" href="libs/css/jquery.jqplot.css" />
		<script src="libs/js/jquery.js"></script>
		<script src="libs/js/jquery.mobile-1.4.5.js"></script>
		<script src="libs/js/mqttws31.js"></script>
		<script src="libs/js/jquery.jqplot.js"></script>
	</head>
	<body>

		<div data-role="page" id="setup_page">
			<div data-role="header" data-position="inline">
				<h3>MQTTブローカ接続設定</h3>
			</div>
			<div role="main" class="ui-content">
				<label for="host_name">MQTT broker host name</label>
				<input id="host_name" value="127.0.0.1" type="text" placeholder="hostname or IP address (WebSocket)" data-clear-btn="true"/>
				<label for="port_number">MQTT broker WebSocket port</label>
				<input id="port_number" value="9090" type="number" placeholder="port number (WebSocket)" data-clear-btn="true"/>
				<label for="mqtt_topic">Subscribe topic</label>
				<input id="mqtt_topic" value="/+/+/io" type="text" placeholder="subscribe topic ex: /xbee/NodeIdentifier/io" data-clear-btn="true"/>
				<div><h3>&nbsp</h3></div>
				<div class="ui-grid-b">
					<div class="ui-block-b">
							<a class="ui-btn ui-btn-inline ui-icon-check ui-btn-icon-left " id="connect_btn" >Connect</a>
					</div>
				</div>
			</div>
			<div data-role="footer">
				<h3>Copyright(c) 2015 All Blue System</h3>
			</div>
		</div>

		<div data-role="page" id="chart_page">
			<div data-role="header" data-position="inline">
				<a data-icon="back" id="chart_view_prev_btn">接続設定</a>
				<h3>グラフ表示</h3>
			</div>
			<div id="chart1" style="height:500px;width:100%;"></div>
			<div data-role="footer">
				<h3>Copyright(c) 2015 All Blue System</h3>
			</div>
		</div>

		<div data-role="page" id="error_quit_dialog">
			<div data-role="header" data-theme="b">
				<h1>*MQTT BROKER ERR*</h1>
			</div>
			<div role="main" class="ui-content">
				<h2>エラーが発生しました</h2>
				<p>MQTT ブローカ接続処理中にエラーが発生しました。接続設定を見直して下さい</p>
				<p><a data-role="button" id="error_ok_btn" class="ui-btn ui-shadow ui-btn-a ui-icon-check ui-btn-icon-left">OK</a></p>
			</div>
		</div>

		<script src="main.js"></script>

    </body>
</html>

index.html ファイルでは jQuery-mobile フレームワークを使用して Webアプリの画面とメッセージダイアログを定義しています。

Webアプリで最初に表示される “設定画面ページ”では MQTT ブローカ WebSocket に接続するためのパラメータを入力します。”Connect” ボタンを押すと MQTT ブローカに接続します。

MQTT ブローカ接続後に表示されるのが “グラフ表示ページ” です。グラフ表示には jplot ライブラリを使用しています。

index.html ファイル中から参照している mqttws31.js は Paho プロジェクトで公開されている JavaScript 版の MQTT クライアント・ライブラリです。これを利用して WebSocket 経由で MQTT ブローカに接続します。

次に、メインのアプリケーションロジックを実現している JavaScript ファイル(main.js)は以下になります。

//////////////////////////////////////
// グラフ表示ページ
//////////////////////////////////////

var plot1;
var ad0 = new Array();
var ad1 = new Array();
var ad2 = new Array();
var ad3 = new Array();
var ad4 = new Array();
var ad5 = new Array();

// グラフを右端から開始するために、初期データをシリーズ変数に格納する
for (var i = 0; i <= 120; i++){
	ad0.push(null);
	ad1.push(null);
	ad2.push(null);
	ad3.push(null);
	ad4.push(null);
	ad5.push(null);
}

// グラフ表示フォーマット
var chartOptions = {
	legend: { show: true, location: "nw" },
	title: "-- no data --",
	series: [{label: "AD0" },{label: "AD1" },{label: "AD2" },{label: "AD3" },
				{label: "AD4" },{label: "AD5" }],
	seriesColors: ["#000000","#A64F08","#FF0000","#FF8000","#FFFF00","#04B404"],
	seriesDefaults: {
		rendererOptions: { smooth: true },
    	pointLabels: { show: true },
		lineWidth:3,
		showMarker:false,
    	breakOnNull: true
	},
	axes: {
		xaxis: {
			label: "(past) sample",
			min: 0,
			max: 120,
			ticks: [[1,"120"],[11,"110"],[21,"100"],[31,"90"],[41,"80"],[51,"70"],
					[61,"60"],[71,"50"],[81,"40"],[91,"30"],[101,"20"],[111,"10"],[121,"0"]],
			pad: 0
		},
		yaxis: {
			label: "XBee-ADC",
			min: 0,
			max: 1023,
			tickOptions: { formatString: '%d'},
			ticks: [0,100,200,300,400,500,600,700,800,900,1000,1023]
		},
	}
};

// MQTTブローカとの接続が途中で切れた
function onConnectionLost(responseObject) {
	if (responseObject.errorCode !== 0) {
		console.log("onConnectionLost:"+responseObject.errorMessage);
		$("body").pagecontainer("change","#error_quit_dialog",{ transition: "pop",role:"dialog" });
	}
}

// MQTTブローカからメッセージを受信した
function onMessageArrived(message) {
	console.log("onMessageArrived:"+ message.destinationName + " " + message.payloadString);
	// 既存のシリーズデータ(プロットデータ)を左シフトする
	if(ad0.length > chartOptions.axes.xaxis.max) {
		ad0.shift();
		ad1.shift();
		ad2.shift();
		ad3.shift();
		ad4.shift();
		ad5.shift();
	}
	// MQTT ブローカから WebSocket 経由で受信した JSON 文字列をシリーズ変数に格納する
	// メッセージフォーマット:
	//      {"ad0":<ad0_value>, .. ,"ad1":<ad1_value>, ... ,"dio0":<dio0_value>,"dio1":<dio1_value>,... }
	// 該当チャンネルのデータが存在しないときには Null が格納されてグラフには表示されない
	var recv_data;
	try {
		recv_data = $.parseJSON(message.payloadString);
		ad0.push(recv_data.ad0);
		ad1.push(recv_data.ad1);
		ad2.push(recv_data.ad2);
		ad3.push(recv_data.ad3);
		ad4.push(recv_data.ad4);
		ad5.push(recv_data.ad5);
	}catch(e){
		console.log("invalid JSON :" +message.payloadString);
	}
	// 再描画時のメモリリーク対策用 jqplot.replot()使用NG
	if (plot1) {
		plot1.destroy();
	}
	// グラフにシリーズデータをプロット
	chartOptions.title = "XBee-MQTT Gateway ADC samples [ " + message.destinationName + " ]";
	plot1 = $.jqplot("chart1",[ad0,ad1,ad2,ad3,ad4,ad5],chartOptions);
}

// グラフ表示ページが表示された
$(document).on("pageshow","#chart_page",function(event){
	// 再描画時のメモリリーク対策用 jqplot.replot()使用NG
	if (plot1) {
		plot1.destroy();
	}
	// 既存のシリーズデータまたは、初期値の空白グラフを表示する
	plot1 = $.jqplot("chart1",[ad0,ad1,ad2,ad3,ad4,ad5],chartOptions);
});

// グラフ表示ページの "接続設定" ボタンが操作された
$("#chart_view_prev_btn").on( "click",function(event, ui){
	$("body").pagecontainer("change","#setup_page", { transition: "none" });
});

//////////////////////////////////////
// セットアップページ
//////////////////////////////////////

var mqtt_client;
var topic;

// MQTTクライアント接続毎にユニークなID を生成
function get_clientid() {
  function s4() {
    return Math.floor((1 + Math.random()) * 0x10000).toString(16).substring(1);
  }
  return 'mqtt-' + s4() + '-' + s4() + '-' + s4();
}

// MQTTブローカに接続した
function onConnect() {
	console.log("connect to MQTT broker");
	// センサーデータのトピック購読
	mqtt_client.subscribe(topic);
	// グラフ画面ページに移動する
	$("body").pagecontainer("change","#chart_page", { transition: "pop" });
}

// MQTTブローカとの接続に失敗した
function onConnectFailure(responseObject) {
	console.log("onConnectFailure:"+responseObject.errorMessage);
	$("body").pagecontainer("change","#error_quit_dialog", { transition: "pop",role:"dialog" });
}

// セットアップページの "Connect" ボタンを押した
$( "#connect_btn" ).on( "click", function(event, ui){
	var mqtt_host = $("#host_name").val();
	var mqtt_port = parseInt($("#port_number").val());
	topic = $("#mqtt_topic").val();
	// MQTT Client 作成
	mqtt_client = new Paho.MQTT.Client(mqtt_host,mqtt_port,"/mqtt",get_clientid());
	mqtt_client.onConnectionLost = onConnectionLost;
	mqtt_client.onMessageArrived = onMessageArrived;
	// MQTT ブローカ WebSocket に接続
	mqtt_client.connect({ onSuccess:onConnect, onFailure:onConnectFailure });
});

// セットアップページが表示された
$(document).on("pageshow","#setup_page",function(event){
	// 既存の MQTT Client オブジェトを削除する(もしあれば)
	if (mqtt_client) {
		try{
			// ConnectionLost 発生時には disconnect() で例外が発生するが無視する。
			mqtt_client.disconnect();
		}catch(e){
			console.log("disconnect() failed");
		}
		delete mqtt_client;
	}
});

// エラーダイアログから復帰する場合はセットアップページに戻る
$( "#error_ok_btn" ).on( "click", function(event, ui){
	session_token = "";
	$("body").pagecontainer("change","#setup_page", { transition: "pop" });
});

設定画面で入力されたパラメータで MQTT ブローカに接続します。

接続に成功すると、設定画面で指定したトピックを購読します。デフォルトでは “/+/+/io” になっていますので XBee, XBee-ZB から送信される全てのリモート IO サンプリングデータを受信することになります。

MQTT ブローカからトピック・メッセージを受信すると、JSON 文字列をオブジェクトに変換した後、個々の AD サンプリング値を取り出して配列に格納します。配列はグラフ表示するときの X 軸方向の目盛り分のサイズを確保しています。もし最新のサンプリングデータを格納するときに、配列のサイズを超える場合には古いデータを順に削除します。これによってグラフ表示したときに左スクロールするように見えます。

最新のサンプリングデータを配列に格納したら、jqplot ライブラリを使用してグラフ表示します。MQTT ブローカからメッセージを受信する毎にこれらの動作を繰り返します。

●Webアプリを動作させる

早速 Web アプリを起動してみます。DeviceServer をインストールしていた場合には “http://<IPアドレス>/web_api_sample/mqtt_xbee_chart/index.html” をWebブラウザで開いて下さい。

この Webアプリは DeviceServer 側の Web API 機能を一切使用しませんので、”mqtt_xbee_chart” フォルダごと他の Webサーバーに配置して動作させることもできます。WebSocket では Webブラウザで実行中の JavaScript からのネットワークアクセスを、配信元サーバーと同一ドメインに制限する “Same Origin Policy” から除外されています。このためMQTT ブローカが動作している RaspberryPi 以外のWebサーバーに配置しても大丈夫です。”index.html” ファイルをダブルクリックして直接 “file” 形式のURI でアクセスしても動作します。

Web アプリを起動すると最初に設定画面が表示されます。

MQTT ブローカのホスト名(IP アドレス) と WebSocket ポート番号を入力します。ここで指定するポート番号は DeviceServer 側から XBee IO サンプリングデータを Publish している TCP/IP ポート番号(1883) ではありませんので注意してください。必ず、この記事の最初で mosquitto.conf に設定した WebSocket ポート番号を指定します。

“Connect” ボタンを押すと、MQTT ブローカに接続してトピック購読を開始します。

グラフ画面です。この画面では IO サンプリングデータ中に含まれる AD0 .. AD5 までの IOデータをプロットします。存在しない ADxデータ項目はグラフ表示されません。実際にデータが到着すると下記の様なグラフが表示されます。

複数のリモート XBee からのデータを同時に受信すると、グラフで表示するデータ内容が混在してしまいます。その場合には “接続設定” ボタンを押して設定画面に戻って、トピック文字列を設定し直してください。たとえばトピックを “/xbee/Device5/io” にすると、XBee(Series1) でかつ NodeIdentifier が “Device5″ のサンプリングデータのみをグラフ表示させることができます。

●動作例の動画

MQTT ブローカから受信した IO サンプリングデータをグラフ表示しているときの動画を載せましたのでご覧ください。(音量注意)

それではまた。

 

リモート XBee IO データを MQTT Broker に送信、XBee-MQTT Gateway (その1)

●概要

今回の記事では、リモートから送信したXBee IO サンプリングデータを MQTT ブローカに自動送信するシステムを構築します。

XBee(Series1) や XBee-ZB(Series2) デバイスには A/D や DIO の値を定期的に送信するIOサンプリング機能が予め備わっています。このシステムでは XBee から送信された IO サンプリングデータを JSON 形式に変換して、MQTT ブローカに送信するシステムを構築します。

リモートに設置した複数の XBee(Series1) や XBee-ZB(Series2) デバイスから IO サンプリングパケットは、DeviceServer に接続したXBee デバイスで受信します。

Series1 の場合にはスター接続の中央に配置されたコントローラデバイスで、Series2 の場合には Coordinator デバイスが DeviceServer に接続されています。DeviceServer で受信したIO サンプリングパケットはイベントハンドラ中で解析して、JSON 文字列に変換した後 MQTT ブローカに Publish メッセージとして配信します。

複数のリモート XBee デバイスからの IO サンプリングデータを、 MQTT ブローカの購読側で簡単に選別できるように、トピック名をデバイス名(NodeIdentifier) を含んだ毎にユニークな文字列 “/<”xbee” | “zb”>/<NodeIdentifier>/”io” にして送信します。またメッセージ内容は JSON 形式で下記のフォーマットで送信します

{“ad0″:<ad0_value>, .. ,”ad1″:<ad1_value>, … ,”dio0″:<dio0_value>,”dio1″:<dio1_value>,… }

JSON 形式にすることで、IO サンプリングデータを MQTT メッセージ購読側のアプリで利用しやすくなります。また、XBee デバイスからは複数の IO 値が1つのサンプリングパケットにまとめて送信されますので、MQTT ブローカに送信するときも IO ポート毎にトピックを分解しないほうが元のデータを正しく表現することができると思います。

●MQTT ブローカを準備

センサデータを配信する MQTT ブローカをセットアップします。今回は RaspberryPi にインストールした mosquitto を使用します。

セットアップの方法は此方の記事を参照にしてください。

これ以外にも LAN やインターネット上に設置された MQTT ブローカを使用できます。送信するセンサデータは JSON 文字列で数十バイト程度なので、もし利用する MQTT ブローカでペイロードサイズの制限があったとしても引っかかることはないと思います。

ただ、XBee  IO サンプリングデータの送信頻度を百ミリ秒未満にする場合にはMQTT ブローカ間とのネットワーク遅延などを考慮してください。

●リモート側XBee デバイスを設置

ここではリモート側の XBee デバイスに XBee(Series1) を使用していますが、XBee-ZB(Series2)を使用することもできます。光センサ(フォトダイオード) を XBee デバイスの AD0 に接続しています。

フォトダイオードは 浜松ホトニクス S9648 を 負荷抵抗 10KΩで使用しています。またフィルタ用に 0.1μ コンデンサを並列に接続しています。XBee の Vcc と GND の他に、Vref 端子を忘れないように配線してください(Series1 の場合)。

●DeviceServer 側のエンドポイントを作成

DeviceServer 側に MQTT ブローカとの接続を管理するためのエンドポイントを作成します。今回のアプリケーションでは、エンドポイントを XBee から受信した IO サンプリングデータを MQTT ブローカに送信(Publish) する時のみに使用しています。

DeviceServer のサーバー設定プログラムを起動します。

“次へ” ボタンを押して DeviceServer の設定を行います。

MQTT タブを選択して、MQTT クライアント機能の設定とエンドポイントの作成を行います。ここで “MQTT 機能を有効にする” にチェックを付けます。KeepAliveTimer はデフォルトの 60秒のままにしておいて下さい。ここで設定した間隔で、DeviceServer 側から MQTT ブローカに対して PINGREQ メッセージを定期的に送信します。また、エンドポイントのソケット接続でエラーを検出したときには再接続処理が自動で行われます。

“追加” ボタンを押して、新規のエンドポイントを作成します。

エンドポイントのタイトルを上記のように設定します。Broker のホスト名と TCP/IP ソケット・ポート番号をここで入力します。その他の設定は空白のままで構いません。

このエンドポイントは XBee のIO サンプリングデータを MQTT ブローカに送信するためだけに使用する予定なので、”起動時に購読するトピック” 項目などは空白のままで大丈夫です。

“OK” を押してエンドポイントを作成した後、サーバー設定プログラムの “次へ” ボタンを押すとDeviceServer が再起動します。同時に、エンドポイントに設定した MQTT ブローカへの接続が自動的に開始されます。

●XBee のイベントハンドラスクリプト設定

XBee デバイスから IO サンプリングデータを受信したときに、DeviceServer 側で実行されるイベントハンドラスクリプトを設定します。XBee(Series1) の場合には XBEE_IO_DATA.lua が自動起動される Lua スクリプトです。

このスクリプトを修正して、MQTT ブローカに JSON 形式で IO データを送信するようにします。スクリプトの内容は以下になります。最新の DeviceServer インストールキットでインストールすると、下記の内容が既にコメントで囲まれた状態で記述されていますので簡単に設定できます。

file_id = "XBEE_IO_DATA"

--[[

******************************************************************************
* イベントハンドラスクリプト実行時間について                                 *
******************************************************************************

一つのスクリプトの実行は長くても数秒以内で必ず終了するようにしてください。
処理に時間がかかると、イベント処理の終了を待つサーバー側でタイムアウトが発生します。

また、同時実行可能なスクリプトの数に制限があるため、他のスクリプトの実行開始が
待たされる原因にもなります。

頻繁には発生しないイベントで、処理時間がかかるスクリプトを実行したい場合は
スクリプトを別に作成して、このイベントハンドラ中から script_fork_exec() を使用して
別スレッドで実行することを検討してください。

******************************************************************************

XBEE_IO_DATA スクリプト起動時に渡される追加パラメータ

---------------------------------------------------------------------------------
キー値			値		            									値の例
---------------------------------------------------------------------------------

APIType			フレームデータ中のAPI Type(16進数2桁)					83

SourceAddress	フレームデータ中のSourceAddress
				16bit アドレスの場合(16進数4桁)							0A01
				64bit アドレスの場合(16進数16桁)						0013A200404AC397

SerialNumber	XBee デバイスの SerialNumber
				DeviceServer に保持されたマスターファイルを使用して、
				SourceAddress から変換した値が設定される。				0013A200404AC397

NodeIdentifier	XBee デバイスの NodeIdentifier。
				DeviceServer に保持されたマスターファイルを使用して、
				SourceAddress から変換した値が設定される。				Device1
				マスターにNodeIdentifier未登録の場合は"" が設定される

RSSI			フレームデータ中のRSSI(16進数2桁)						45

Options			フレームデータ中Options(16進数2桁)						00

SAMPLE_COUNT	I/O データのサンプル数									1

SAMPLE_DIO		I/O データ中のサンプル対象となったDIOビット番号リスト
				(10進数、カンマ区切り)									0,1,4

SAMPLE_ADC		I/O データ中のサンプル対象となったADCビット番号リスト
				(10進数、カンマ区切り)									2,3

SAMPLE_<Sample#>_<"DIO"|"ADC">_<Bit#>

				I/O サンプルデータ値。
				DIO の場合は、High で "1"、Low で "0"。					1
				ADC の場合は 10進数。									1023

				<Sample#> には 最大、SAMPLE_COUNT まで 1から順番に
				インクリメントされた値が入る。

				<"DIO"|"ADC">は、I/O サンプルデータが ADC
				もしくは、DIO のどちらであるかを示す。

				<Bit#>は、サンプルデータのビット番号。10進数。

		例:"SAMPLE_1_ADC_0" は、第一サンプルデータ中の #0番ポートのADC変換値を示す。

]]

--[[
log_msg("start..",file_id)
for key,val in pairs(g_params) do
	log_msg(string.format("g_params[%s] = %s",key,val),file_id)
end
]]

--[[
********************************************************************

XBee->MQTT Gateway 機能の実装例

リモート XBee から送信された I/O パケットデータを MQTT に登録します。
トピック名: "/xbee/<NodeIdentifier>/io"
メッセージ文字列:
 {"ad0":<ad0_value>, .. ,"ad1":<ad1_value>, ... ,"dio0":<dio0_value>,"dio1":<dio1_value>,... }

XBee の IO 設定で有効になっている A/D, DIO ポート値のみが上記のフォーマット
で格納されます。

送信先 MQTT ブローカは、サーバー設定プログラムを使用して
エンドポイントを登録して下さい。下記スクリプト中の end_point 変数に
エンドポイントのタイトル文字列または ClientID を設定します。

XBee デバイスの "Sample Before TX" の設定値を1以上にした場合には
最後にサンプリングしたデータのみを MQTT に送信しています

********************************************************************
]]

local end_point = "センサーデータ登録"
local qos = 1
local topic = "/xbee/" .. g_params["NodeIdentifier"] .. "/io"

local ad_list = csv_to_tbl(g_params["SAMPLE_ADC"])
local dio_list = csv_to_tbl(g_params["SAMPLE_DIO"])
local json_str = '{'
local first = true
for i,v in ipairs(ad_list) do
	if first then
		first = false
	else
		json_str = json_str .. ","
	end
	json_str = json_str .. string.format('"ad%s":%s',v,
				g_params["SAMPLE_" .. g_params["SAMPLE_COUNT"] .. "_ADC_" .. v])
end
for i,v in ipairs(dio_list) do
	if first then
		first = false
	else
		json_str = json_str .. ","
	end
	json_str = json_str .. string.format('"dio%s":%s',v,
				g_params["SAMPLE_" .. g_params["SAMPLE_COUNT"] .. "_DIO_" .. v])
end
json_str = json_str .. '}'
mqtt_publish(end_point,topic,json_str,qos)

上記スクリプト中の “end_point” 変数に設定している名前が、先にサーバー設定プログラムで作成したエンドポイントのタイトル名と一致していることを確認してください。

XBEE_IO_DATA イベントハンドラスクリプトでは、リモートの XBee(Series1) デバイスから送信された IO サンプリングパケットは自動的に解析されて、既にスクリプトパラメータに格納されtた状態で起動されます。

そのため、このスクリプトパラメータを利用してMQTT に送信する JSON 文字列を作成します。XBee デバイスの ADC, DIO ポートが有効になっていると、各々のポート値がスクリプトパラメータに設定されていますので、これを連結して JSON 形式に変換します。変換するときの詳しいフォーマットはスクリプト中のコメントを参照してください。

JSON 形式になったIO サンプリングデータは mqtt_publish() ライブラリ関数を使用して、MQTT ブローカに送信(Publish) します。このとき、トピック名には “/xbee/<NodeIdentifier>/io” を使用することで、購読側でデバイスを選択し易くしています。

続いて、XBee-ZB(Series2) のイベントハンドラスクリプト(ZB_IO_DATA.lua) も同様に設定します。

file_id = "ZB_IO_DATA"

--[[

******************************************************************************
* イベントハンドラスクリプト実行時間について                                 *
******************************************************************************

一つのスクリプトの実行は長くても数秒以内で必ず終了するようにしてください。
処理に時間がかかると、イベント処理の終了を待つサーバー側でタイムアウトが発生します。

また、同時実行可能なスクリプトの数に制限があるため、他のスクリプトの実行開始が
待たされる原因にもなります。

頻繁には発生しないイベントで、処理時間がかかるスクリプトを実行したい場合は
スクリプトを別に作成して、このイベントハンドラ中から script_fork_exec() を使用して
別スレッドで実行することを検討してください。

******************************************************************************

ZB_IO_DATA スクリプト起動時に渡される追加パラメータ

---------------------------------------------------------------------------------
キー値			値		            									値の例
---------------------------------------------------------------------------------
FrameType		フレームデータ中のFrame Type
				(16進数2桁)												92

SourceAddress	フレームデータ中のSourceAddress
				64bit アドレス(16進数16桁)								0013A200404AC397

NetworkAddress	フレームデータ中の SourceNetworkAddress
				16bit アドレス(16進数4桁)								D565

NodeIdentifier	XBee デバイスの NodeIdentifier。
				DeviceServerのマスターファイルを検索して設定される。	Node1
				マスターにNodeIdentifier未登録の場合は"" が設定される

DeviceType		XBee デバイスの Device Type
				DeviceServerのマスターファイルを検索して設定される。	01
				マスターにDeviceType未登録の場合は"" が設定される
				8bit値(16進数2桁)
				00: coordinator
                01: router
                02: end device

DeviceTypeID	XBee デバイスの Device Type Identifier
				DeviceServerのマスターファイルを検索して設定される。
				マスターにDeviceTypeID未登録の場合は"" が設定される
				32bit値(16進数8桁)										00030000

ReceiveOptions	フレームデータ中 ReceiveOptions							01
				8bit値(16進数2桁)

SAMPLE_COUNT	I/O データのサンプル数									1

SAMPLE_DIO		I/O データ中のサンプル対象となったDIOビット番号リスト
				(10進数、カンマ区切り)									0,1,4

SAMPLE_ADC		I/O データ中のサンプル対象となったADCビット番号リスト
				(10進数、カンマ区切り)									2,3

SAMPLE_<Sample#>_<"DIO"|"ADC">_<Bit#>

				I/O サンプルデータ値。
				DIO の場合は、High で "1"、Low で "0"。					1
				ADC の場合は 10進数。									1023

				<Sample#> には 最大、SAMPLE_COUNT まで 1から順番に
				インクリメントされた値が入る。

				<"DIO"|"ADC">は、I/O サンプルデータが ADC
				もしくは、DIO のどちらであるかを示す。

				<Bit#>は、サンプルデータのビット番号。10進数。

		例:"SAMPLE_1_ADC_0" は、第一サンプルデータ中の #0番ポートのADC変換値を示す。

]]

--[[
log_msg("start..",file_id)
for key,val in orderedPairs(g_params) do
	log_msg(string.format("g_params[%s] = %s",key,val),file_id)
end
]]

--[[
********************************************************************

XBee->MQTT Gateway 機能の実装例

リモート XBee から送信された I/O パケットデータを MQTT に登録します。
トピック名: "/zb/<NodeIdentifier>/io"
メッセージ文字列:
 {"ad0":<ad0_value>, .. ,"ad1":<ad1_value>, ... ,"dio0":<dio0_value>,"dio1":<dio1_value>,... }

XBee の IO 設定で有効になっている A/D, DIO ポート値のみが上記のフォーマット
で格納されます。

送信先 MQTT ブローカは、サーバー設定プログラムを使用して
エンドポイントを登録して下さい。下記スクリプト中の end_point 変数に
エンドポイントのタイトル文字列または ClientID を設定します。

********************************************************************
]]

local end_point = "センサーデータ登録"
local qos = 1
local topic = "/zb/" .. g_params["NodeIdentifier"] .. "/io"

local ad_list = csv_to_tbl(g_params["SAMPLE_ADC"])
local dio_list = csv_to_tbl(g_params["SAMPLE_DIO"])
local json_str = '{'
local first = true
for i,v in ipairs(ad_list) do
	if first then
		first = false
	else
		json_str = json_str .. ","
	end
	json_str = json_str .. string.format('"ad%s":%s',v,
				g_params["SAMPLE_" .. g_params["SAMPLE_COUNT"] .. "_ADC_" .. v])
end
for i,v in ipairs(dio_list) do
	if first then
		first = false
	else
		json_str = json_str .. ","
	end
	json_str = json_str .. string.format('"dio%s":%s',v,
				g_params["SAMPLE_" .. g_params["SAMPLE_COUNT"] .. "_DIO_" .. v])
end
json_str = json_str .. '}'
mqtt_publish(end_point,topic,json_str,qos)

スクリプトの内容は XBee(Series1) とほぼ同じですが、MQTT ブローカに送信するときのトピック名を “/zb/<NodeIdentifier>/io” に変更しています。

イベントハンドラスクリプトが完成したら、今回の XBee-MQTT Gateway の機能はほぼ実現していることになります。

●リモート側XBee デバイスの IO 設定

次に、光センサを接続したリモート側 XBee デバイスの IO 設定を変更して、IO サンプリングデータが送信されるようにします。

DeviceServer のクライアントを起動してログインします。

ログインしたら、”XBee” ツールボタンを押してPAN 内の XBee デバイス一覧を表示させます。

光センサを接続しているリモート側XBee (Device5) をダブルクリックするか、または選択した後に “設定変更” ツールボタンを押します。現在の XBee 設定値がリモートからロードされた後、詳細設定画面が表示されます。

ここで DIO0 ポートタブを選択して、ADC にチェックをつけます。これで AD0 が有効になりました。次に “Sample Before TX” を 1にして “Sample Rate” を 200ms に設定します。これによって XBee デバイスが 200ms 毎に IO サンプリングを実行して、その結果を DeviceServer に接続した XBee に送信するようになります。

その後 DeviceServer 側では、先ほど設定したイベントハンドラスクリプト中から MQTT ブローカに IO データが JSON 形式で送信されます。

複数の XBee デバイスからの IO サンプリングデータを、同時に MQTT ブローカに送信することもできます。その場合にはそれぞれの XBee デバイスの IO 設定を同様に変更してください。

“OK” を押すと同時に、リモート側 XBee デバイスの IO サンプリングが開始されて MQTT ブローカに送信されるようになります。

●RaspberryPi のコンソール上で、MQTT メッセージを購読して IO データを確認

ここで、MQTT ブローカに送信されている IO サンプリングを見てみましょう。RaspberryPi にログインして MQTT ブローカからメッセージを購読します。

mosquitto_sub コマンドを使用して、MQTT ブローカからメッセージを受信している様子です。XBee デバイスで有効になっている全ての IO 値が JSON 形式で送信されています。光センサに手をかざすと ad0 の値が変化するのを確認できます。

●動作例の動画

XBee-MQTT gateway が動作しているときの動画を載せましたのでご覧ください。(音量注意)

今回は、XBee データを MQTT に変換する例を紹介しましたが、同様のスクリプトを用意することで DeviceServer で取得した様々なセンサデータを MQTT に送信することが可能になります。

また、今回のシステムのセンサデータとは逆方向の Gateway も簡単に作成できます。DeviceServer 側に作成したエンドポイントで MQTT のブローカから特定のトピックを購読して、そのデータを元にリモート側の XBee のポートを変更させることもできます。この時には、MQTT ブローカからトピック・メッセージを受信するときに自動実行される MQTT_PUBLISH イベントハンドラに処理を記述します。

ここで紹介した DeviceServer の機能は、ABS-9000 DeviceServer インストールキットをダウンロードして、直ぐに使用することができます。イベントハンドラで使用したスクリプトファイルも全て格納されていますので是非お試しください。デモライセンスが添付されていますので直ちに使用可能です。こちらから最新のインストールキットやセットアップマニュアル、ユーザーマニュアルをダウンロードできます。

次の記事 “XBee-MQTT Gateway (その2)” では、今回作成したシステムで MQTT ブローカに配信されているセンサデータを WebSocket 経由で受信して、グラフ表示するWebアプリを紹介する予定です。

それではまた。

 

MQTT クライアントとテスト用プログラムを作成しました

●MQTT を使ってみよう

センサーネットワークなどを構築するときには、センサーで取得したデータを何らかの方法で他のシステムに送信する必要がありますが、もし、センサーデバイスに TCP/IP プロトコルを載せた Ethernet インターフェイスが付いていれば、FTP, HTTPなどのプロトコルや独自のプロトコルを利用してソケット通信で簡単に転送できます。これらの標準的なプロトコルとして注目されているのが MQTT とよばれるプロトコルです。MQTT は IBM社 が開発したプロトコル ( http://mqtt.org/ )で、最近 OASIS Standard にも認定されました。特徴としては、

(1) 送信側と受信側の間に Broker とよばれる仲介サーバーを介してデータのやりとりを行う。このため、センサーデータ配信側と利用側が直接連携をとる必要がない。

(2) TCP/IP のソケット通信を使用する( WebSocket で実装されているものもあります )ので送信データが確実に伝わることが期待できる。

(3) 標準機能を実装した Broker ( http://mosquitto.org/ ) や クライアントライブラリ ( http://eclipse.org/paho/ ) が豊富に用意されている

(4) 仕様が公開されていて( http://mqtt.org/documentation ) 、(3) と相まってアプリケーションへの実装が容易

(5) QoS と呼ばれる送達保障レベルをメッセージや購読項目毎に自由に選択可能。CPU リソースが少ないセンサーノードからの通信時には簡単な送信手順が用意されているなど実装の自由度が高い。

今後、 MQTT プロトコルはセンサーネットワーク等に幅広く利用されていくと思います。

●MQTT テストクライアントを作成しました

今回、DeviceServer 製品に MQTT クライアント機能を追加することを想定して、MQTT クライアントライブラリを作成しました。また、このライブラリの機能試験を行うためにテスト用クライアントプログラム(スタンドアロンで動作します)も同時に作成しました。

このMQTT クライアントプログラムは、Windows 環境(Windows XP SP3,Windows 7 64bit で動作確認済み) で動作します。もし興味がありましたら、こちらのリンクからダウンロードできますので記事の内容を見ながら使用してみて下さい(テスト用に作成したものですが、個人用・商用問わず自由に使用していだだいて構いません)。

ダウンロードすると、プログラム本体と DLLファイル が格納されています。プログラム本体をダブルクリックすると下記の画面が表示されます。DLLファイル はメモリ監視用に組み込んでありますが気にしないでこのまま使用してください。

MQTT テストプログラムでは動作時の詳細ログ情報を ABS-9000 DeviceServer のログサーバーとログコンソールに出力しています。DeviceServer のインストールキットは此方からダウンロードできますので併せてインストールしてください。DeviceServer のライセンスはデモライセンスのままで構いません。ログサーバーとログコンソールはデモライセンス期間に関係なく何時までも使用することができます。

●iot.eclipse.org で公開されている MQTT Broker を使用します

クライアントプログラムだけでは試験できませんので、接続先の MQTT Broker を用意する必要があります。ここでは http://iot.eclipse.org が試験目的で使用可能な Broker を提供していていますの最初はこれを利用すると簡単に MQTT を試せます。この Broker はユーザー登録などは不要で常に利用可能になっているようなので早速接続してみます。

“Broker HostName” に “iot.eclipse.org” を指定して、”Port” には “1883″ を指定します。その他の設定は初期値のままにしておいて下さい。 “Open” ボタンを押すとソケット接続を開始します。このとき、ログコンソールプログラムを起動していると下記の様に表示されます。”connecting…” と表示されている部分がソケット接続時のメッセージになります。

エラー無く接続されたら、以降は MQTT のメッセージをやり取りすることになります。

最初に “CONNECT” ボタンを押して、CONNECT メッセージを送信します。すると直後に Broker 側から CONNACK が返ってくるのをログで確認できます。現状ではユーザー名やパスワードは指定しなくても “iot.eclipse.org” の Broker には接続できるようです。

次に、”定期的にPING送信” にチェックを付けます。チェックをつけなくても、”PINGREQ” ボタンを1分以内に1回程度の頻度で手動で押しても構いません。これによって PINGREQ メッセージをBroker に送信して、クライアントがまだちゃんと動作していることを伝えることができます。送信しない状態で “KeepAlive” 値に設定した秒数+α 経過すると Broker は勝手に接続を切ってしまいます。

次に “SUBSCRIBE” ボタンを押します。これで、”hello/world” と “センサー/ノード1″ という2つのトピックの購読を Broker に伝えます。トピックのメッセージを受け取るときにはそれぞれ QoS の 2 と 0 のプロトコルを使用することを指定しています。ここでは1度に2つのトピックと QoS をカンマ区切りで指定していますが、”SUBSCRIBE” ボタンを複数回押してトピックの購読を後から追加していくこともできます。

最後に、”PUBLISH(str)” ボタンを押して、トピック名 “hello/world” でメッセージを送信します。このときにペイロードに格納されるデータは “PublishData(str)” のテキストエリアに入力されている文字列(UTF8文字列)になります。送信するときに指定する QoS はデフォルトで2になっています。

ログには、クライアントプログラムから送信された PUBLISH データと Broker 側からクライアント側に配信されて戻ってきたデータを確認できます。ログ中の “—- PublishData —-” と表示されている部分が購読しているトピックのデータを受信したときのログになります。Broker 側から配信されたデータが 256Bytes 以内の場合には、データバイト列を UTF8 文字列に変換してログにも表示します。また同時に、クライアントプログラムが配置されているフォルダには受信したデータバイト列がファイルとして保存されます。

“Pub_xxxxxxxxxxxxx.dat” のファイル名で保存されているのが受信した PUBLISH のペイロード部分をファイル書き出したものです。このファイルは PUBLISH メッセージを受信する度に増えていきますので、いらなくなったら削除して下さい。

Brokerとの接続を切るときには、最初に “DISCONNECT” ボタンを押します。その後、”Close” ボタンを押してソケットを閉じます。このとき、”Close” を押さずにプログラムを終了するとMQTT接続で使用しているリソースに関するメモリー情報がダイアログに出力されますが、気にしないで下さい。

●クライアントを複数起動してチャット(LINE?) のような事もできます

MQTT クライアントプログラムは同じ PC 上で複数同時に起動することもできます。下記の画面をご覧ください。

このとき、”CONNECT” ボタンを押すときに “ClientID” エリアに入力されているデフォルト文字列が必ず異なっていることを確認してください。数字部分を乱数で生成していますのでそのままで大丈夫だと思います。

ここで、双方のアプリで “SUBSCRIBE” を押して “PUBLISH(str)” で好きなメッセージを送信することができます。同じトピック “hello/world” を購読していますのでチャットのような動作になります。

“PUBLISH(str)” ボタンを押すときに “PublishQoS” を 0, 1,2 にそれぞれ変更すると、MQTT プロトコルでやり取りされるパケットの種類が変化するのをログで確認できると思います。

●RaspberryPi にMQTT Broker をインストール

ここからは、Will メッセージ送信やデータファイル送信などを試してみたいと思います。強制的にソケットを切断したり、Broker に負荷がかかるデータ送信試験などを行いたいので、パブリックに公開されている Broker を使用しないでここからは、自前で用意した Broker を使用します。

ここでは、RaspberryPi (下記写真) に MQTT Broker をインストールします。

RaspberryPi には Raspbian OS が動作しています。ここに、オープンソースで開発されている MQTT Broker “mosquitto” をインストールします。(蚊?スペルが似てるからですね…)

インストールの方法は http://mosquitto.org/ に詳しく書かれています。RaspberryPi 用には予めコンパイル済みのパッケージを利用できますのでこれを利用するのが簡単です。インストールするときのコマンド例のみを以下に紹介しますが、詳しい手順については http://mosquitto.org/2013/01/mosquitto-debian-repository/ に詳しく書かれていますので確認してください。

(1) レポジトリにパッケージ追加

wget http://repo.mosquitto.org/debian/mosquitto-repo.gpg.key
sudo apt-key add mosquitto-repo.gpg.key

cd /etc/apt/sources.list.d/
sudo wget http://repo.mosquitto.org/debian/mosquitto-stable.list

(2) パッケージアップデート

apt-get update

(3) mosquitto Broker とクライアントプログラムをインストール

apt-get install mosquitto
apt-get install mosquitto-clients

これでインストール完了です。mosquitto Broker をインストールすると自動的に MQTT Broker プロセスが起動している筈ですが、起動していない場合や手動で起動する場合には、下記の様にコマンドを実行します。

これで、自前の Broker が作成できました。ここからはこの Broker を使用して試験をします。

●Will メッセージを受信する

MQTT プロトコルには、予期しないネットワーク切断が発生したときにSubscribe しているクライアントに対してメッセージを出力する機能 “Will Message” が用意されています。先ほど RaspberryPi に作成した Broker を使用してこのメッセージを出力してみます。

最初に、MQTT クライアントプログラムを使用して RaspberryPi (この例ではIP アドレス 192.168.100.14 になっています)に接続します。

“Broker HostName” にRaspberryPi の IP アドレスを設定して “Open” を押します。その後、”WillTopic” と “WillMessage” に文字列が設定されているのを確認した後、”CONNECT” を押して Broker に接続します。ここで、”SUBSCRIBE” を押した後、”PUBLISH(str)” ボタンでデータを送信するたびに、Broker 側から同じ文字列が配信されてくる様子をログで確認してください。

ここで、別のコンソールを使用して RaspberryPi に接続して RaspberryPi 上でも Subscribe を実行します(MQTT クライアントプログラムをもう一つ起動する方法でも構いません)。 コマンド “mosquitto_sub -d -v -t hello/my_will ” を実行してください。ここで指定する “hello/my_will” は、クライアントプログラムで “CONNECT” したときに指定した WillTopic の内容に合わせています。

ここで、クライアントプログラムの “Close” ボタンを押すと RaspberryPi のコンソールには WillMessage (この例では “さようなら”) が表示されると思います。”DISCONNECT” ボタンを押してから “Close” を押した場合には正常な切断方法ですので WillMessage は表示されません。

ちなみに、クライアント側からの切断だけでなく Broker 側からの切断時にも WillMessage が配信されます。クライアントプログラムで “CONNECT” ボタンを押した後にもう一度 “CONNECT” を押してみて下さい。このときには Broker で異常事態を検出してソケットを勝手に切断してしまいます。このときにも RaspberryPi のコンソールにWillMessage が表示されるのを確認できると思います。

●大きなサイズのメッセージを Publish する

MQTT クライアントで送信するデータは、MQTT PUBLISH メッセージフレーム中のペイロードと呼ばれるエリアに格納されます。今までの動作例ではこの部分に UTF-8 エンコードされた文字列データを格納していました。

MQTT の仕様上 PUBLISH ペイロードは格納するデータ内容は自由なので、任意のバイナリデータを格納することもできます。また、ペイロード部分とヘッダ情報を合わせて最大 256MBytes までのデータを PUBLISH メッセージに格納することができる仕様になっています。

もちろん、Broker を動作させるRaspberryPi の搭載メモリやCPUパワー、クライアントプログラムの動作環境に依存しますので、常に 256MBytes のデータをやり取りすることはできないと思います。そこで、どれぐらいのデータサイズまで PUBLISH 可能かを試してみます。

MQTT クライアントアプリには “PUBLISH(file)” ボタンが用意されています。これを利用するとファイルの内容をバイナリ列として PUBLISH フレーム中のペイロードに格納して送信できます。そこで 20MBytes 程度のファイルを転送してみます。(**注意** 必ずローカルに設置した自前の Broker で試験してください。高い負荷がかかると Broker 側がハングする可能性があります!! また、他の人が同じ Topic を購読していると大変なことになります!!)

ここでは、適当な映像ファイル (test2.wmv) ファイルを PUBLISH すると同時に、配信されてきたデータを受信します。このとき Broker 側から受信したデータはMQTTテストクライアントプログラムと同じフォルダにファイルの形で格納されますのでこのファイルの内容を確認します。

Pub_xxxxxxx.dat のファイル拡張子を元のファイルと同じ “.wmv” へ変更すると、内容が正しく配信されているかを再生することで確認できます。一々再生しなくても MD5 ハッシュ値を求めて確認する方法がスマートかもしれません。

私の環境で RaspberryPi を Broker に使用した場合には、実用的な速度で送信可能な最大サイズは 20MBytes ぐらいになりました。そこで、どうしても 100MBytes を転送してみたくなったので、Windowsマシン(Windows7 64Bit,CPU i7-4770,メモリ 16G)に Windows 版 mosquitto Broker をインストールして試してみました。

コマンドプロンプトから Broker を起動して、MQTT クライアントアプリを localhost に接続して試験した様子です。なんとか転送できているのを確認することができます。(同じ環境で 200MBytes までは正常な転送を確認できました!!)

実際の環境では Subscribe を依頼しているエンドポイントの数だけ Broker から送信しますので、実用的には数MBytes が限度かもしれません。

今回紹介した MQTT クライアントプログラムを使っていて、不具合を見つけた場合や要望などがありましたら、遠慮なく contact@allbluesystem.com までメールお寄せ下さい。

それではまた。

 

TWE-Lite をWebAPIとWebアプリから操作する

概要

今回の記事では、東京コスモス電機より販売されているワイヤレスモジュール TWE-Lite をリモートから操作する例を紹介したいと思います。TWE-Lite は XBee と同じように簡単にワイヤレス機能を利用することができ、無線モジュールのファームウエアをユーザーが書き換えて外付けマイコン無しでセンサーノードを作成することができます。今回の記事では、ファームウエアはデフォルトでロードされている “超簡単!TWE標準アプリ” を使用しています。

リモートに設置したTWE-Lite デバイスをWebAPI から簡単に操作できるようにします。また、専用のWeb アプリを作成して、スマートフォンや PC のWebブラウザから GUI を使用して簡単に操作できるようにします。

記事の最後に動画を掲載していますので、最初にこれをご覧になると記事の内容が判り易いと思います。

TWE-Lite デバイスの準備

今回使用する TWE-Lite デバイスはブレッドボードなどで簡単に使用できるように、TWE-Lite DIP タイプを3つ使用しています。1つを PC(Windows) に接続する親機として使用して、残りの2つを子機として使用します。

親機用 TWE-Lite DIP デバイスには、PC と仮想COM ポートでアクセスできるように USBシリアルアダプタ(秋月電子 “FT232RL USBシリアル変換モジュールキット”)を接続しています。このシリアルアダプタを使用する代わりに、USBに直接接続できる ToCoStick やTWE-Lite R を利用してももちろん構いません。

親機をPCに接続した様子です。ブレッドボード上にUSBシリアルアダプタと TWE-Lite DIP を配置しています。後の項で説明する TWE-Lite デバイスの初期設定やファームウエアの書き換えにも使用できるように、リセットボタンとプログラムボタンも接続しています。このときブレッドボードを使用しているとTWE-Lite DIP の入れ替えが簡単にできます。

TWE-Lite の電源は USB シリアルアダプタから出力される 3.3V を使用しています。上記の回路は TWE-Lite のホームページに公開されている、 “TWE-Lite のファームウエア書き込み方法” に関するマニュアルを参考にしました。

子機で使用する TWE-Lite も同様にブレッドボード上に配置しました。子機#1(Device ID:1) にはPWM出力確認用の LED が4つ接続されています。子機#2(Device ID:2) にはDO(デジタル出力)確認用の LED が4つと A/D(AD#4)入力用に可変抵抗器を接続しています。また、DI (デジタル入力)ピンを GND に接続するためのワイヤーも引き出しています。

子機#1にはI2C の試験用に 24LC256 EEPROM とTMP102 温度センサを I2C バスに接続しています。I2C バスはブレッドボード上に接続した4.7Kの抵抗でプルアップしています。子機の電源は AC アダプタから 3.3V を供給して動作させています。

TWE-Lite デバイスの初期設定

最初に、TWE-Lite デバイスの初期設定を行います。前述の、ブレッドボード上で作成した親機に搭載する TWE-Lite デバイスを入れ替えて、子機2台と親機のモジュール設定をシリアルコンソールから操作します。

下記は、親機に使用する TWE-Lite をターミナルエミュレータソフト(TeraTermを使用しています) から接続した様子です。

“+” 文字を3回押してコンフィギュレーション画面を表示しています。

ここで必ずファームウエアのバージョンを確認してください。上記の場合には v1.7.1 になっています。最新バージョンの v1.6.6. または v.1.7.1 よりも古いバージョンの場合にはファームエアの更新が必要です。購入した直後のデバイスには古いファームウエアが格納されている場合がありますので必ず確認するようにしてください。

ファームエアを更新する場合には、プログラムボタン(オレンジのタクトスイッチ)を押しながらリセットボタン(白のタクトスイッチ)を押して、その後プログラムボタンを離すことでプログラムモードに入ります。TWE-Lite のホームページから書き込みソフトとファームエアファイルをダウンロードして書き込みを行います。詳しい手順はTWE-Lite のホームページを参考にしてください。

最新バージョンのファームウエアを使用していることを確認したら、設定画面で Application ID(PAN ID)を任意の値に設定します。ここでは 0x00aabbcc に設定しています。Application ID の値は親機と子機全てに同じ値を設定します。次に Option Bits を 0×00000012 に設定します。この設定を行うと親機側のADC変化検出と定期送信を停止することができます。

今回のアプリケーションの様に子機側の I/O を個々にリモート操作する場合には必ずこの設定を行います。この設定を行わないと(デフォルト設定値のままだと)親機側の デジタル入力や A/D 値が子機側のデジタル出力や PWM 出力値に自動的に反映されて、うまくリモート操作することがきませんので注意してください。

親機の設定が終了したら、ブレッドボード上の TWE-Lite DIP を入れ替えて子機#1 の設定を行います。設定値は以下のようになります。

親機と同様に Application IDを 0x00aabbcc に設定しています。子機では Device ID を設定してそれぞれの子機を個別に操作できるようにします。ここでは 0×01 に設定しています。

また、Option Bits は 0×00000002に設定して定期送信を停止していますが、デフォルトの 0×00000000 のままでも構いません。どちらの値に設定しても、デジタル入力が変化した時や A/D 変換値が一定以上変化した場合には、自動的に親機側にイベントが送信されます。このイベント情報によってサーバー側が現在の子機のデジタル入力値とA/D 変換値がどのようになっているかをその都度、子機側に問い合わせなくても把握することができます。

子機#1 の設定が終了したら、TWE-Lite デバイスを子機#2 に入れ替えて同様の設定をしてください。このとき、Device ID の設定値のみを変更して 0×02 にして後の設定値は子機#1 と同じにします。

PC(DeviceServer)に親機を接続

親機を PC に接続した後、子機側の電源も入れて通信可能な状態にします。次に、PC 側にインストールした DeviceServer の “サーバー設定” プログラムを起動して、親機を接続しているシリアルポート(仮想 COMポート)を新規のシリアルデバイスとして登録します。

登録する、シリアルデバイスの設定は上記のようになります。COM ポート名は親機のシリアルアダプタ(FT232RL) で作成された仮想COM ポートを指定します。ボーレートは TWE-Lite DIP のデフォルト値 115200 を指定します。デバイスタイプには “TWE” を指定します。この指定によって DeviceServer ではこのシリアルポートに対して以下の機能が有効になります。

COM ポートから入力されたアスキー形式の TWE-Lite パケットを受信した時に、自動的にイベントハンドラ (SERIAL_TWE.lua) が起動されてパケット内容を解析します。また、DeviceServer に作成したユーザースクリプトやイベントハンドラ中から twe_print() ライブラリ関数を使用して、アスキー形式のパケット送信や、リクエスト・リプライタイプのコマンドの送受信を行うことが可能になります。

デフォルトで動作している ”超簡単!TWE標準アプリ” ファームウエアを独自に拡張して新しいコマンドを作成した場合でも、同様のアスキー形式にしておくことで、新しいコマンドを簡単に DeviceServer から利用することができます。

シリアルデバイス登録後の “サーバー設定” プログラムのデバイス一覧は以下のようになります。

この設定画面では複数の親機を同時に登録することもできます。別々のPAN(Application ID) で管理されている子機グループ間の操作も簡単に行うこともできます。

“次へ” ボタンを押して”サーバー設定” プログラムの操作を完了させると、自動的にDeviceServer が再起動した後 TWE-Lite デバイスを使用することができるようになります。

WebAPI からTWE-Lite 子機を操作する

最初の使用例として リモートの TWE-Lite 子機#1 のデジタル出力ピンを操作してみます。Web API を使用して /command/json/script のURL にアクセスします。

URL パラメータ “name” で指定する Lua スクリプトファイルは “TWE/DO_PIN_SET” でスクリプトの説明は後述します。”com” パラメータには親機が接続されている COM ポート名を指定します。”id” , “pin”, “value” パラメータには操作対象の子機の Device ID, DO ピン番号、出力する値を指定します。この例では子機#1 のDO#3 を Low に設定しています。

Web API で実行する “TWE/DO_PIN_SET”  Lua スクリプトファイルは以下の様に記述されています。

file_id = "TWE/DO_PIN_SET"

--[[

●機能概要

TWEワイヤレスデバイス子機の指定したデジタルピンの値を設定する

●リクエストパラメータ

---------------------------------------------------------------------------------
キー値			値		            									値の例
---------------------------------------------------------------------------------
com			TWEワイヤレスデバイス親機が接続された COM ポート名
			またはタイトル名									"COM4"

id			取得対象のTWEワイヤレスデバイス子機の論理IDを10進数の文字列で
			指定する											"1","120"

pin			DO#番号(1 から 4 までの整数)						"4"

value		pin に指定したI/Oポートに設定する値(0 または 1)		"1"
			TWEワイヤレスデバイスの場合には "1" で Low出力,
			"0" で High出力になります

●リターンパラメータ

---------------------------------------------------------------------------------
キー値			値		            									値の例
---------------------------------------------------------------------------------

]]

-------------------------
-- パラメータチェック
-------------------------
if not (g_params["com"] and g_params["id"] and g_params["pin"] and g_params["value"]) then
	log_msg("parameter error",file_id)
	error()
end
local stat,com = serial_find_device(g_params["com"])
if not stat then
	log_msg("COM port not found",file_id)
	error()
end
local pin = tonumber(g_params["pin"]) - 1
if (pin < 0) or (pin > 3) then
	log_msg("invalid DO# number",file_id)
	error()
end
----------------------------------------------------------------------
-- 0x80 コマンド送信
----------------------------------------------------------------------
local mask = bit_tohex(bit_lshift(1,pin),2)
local io = "00"
if g_params["value"] == "1" then
	io = mask
end

local command_str = ":" .. bit_tohex(tonumber(g_params["id"]),2) .. "8001" ..
                    io .. mask .. "FFFFFFFFFFFFFFFFX"

for cnt = 1,2,1 do -- 確実に操作するために同一コマンドを2回送信する
	if not twe_print(com,command_str) then error() end
	wait_time(10)
end

URL で指定された複数のパラメータは、Lua スクリプト実行時に g_params[] 連想配列に格納されています。

最初に必要なパラメータが指定されているかを調べた後、command_str 文字変数に TWE-Lite のアスキー形式で送信する文字列データを格納していきます。その後、twe_print() ライブラリ関数を使用して、DeviceServer に登録したシリアルポートからデータパケットが送信されます。データパケットを受信した親機では 0×80 コマンドが実行されてリモート側の子機#1 の DO#3 が変更されます。

次の動作例では、子機のデジタル入力と A/D 変換値を Web API から取得します。

デジタル出力の時と同様に、DeviceServer で公開されている WebAPI コマンドパス /command/json/script にアクセスます。 “name” パラメータには “TWE/AD_DI_GET” を指定して子機のデジタル入力ポートと A/D 変換値を取得します。スクリプトの実行結果は、JSON 形式で返りますのでこの内容がブラウザ画面に表示されています。

Web アプリや、外部のアプリケーションサーバーから同様の URL にアクセスするだけで、リモートに設置している子機の状態を簡単に取得することができることになります。

TWE/AD_DI_GET Lua スクリプトファイルは以下の様に記述されています。

file_id = "TWE/AD_DI_GET"

--[[

●機能概要

TWEワイヤレスデバイス子機のA/D値, DI 値を取得する

●リクエストパラメータ

---------------------------------------------------------------------------------
キー値			値		    									値の例
---------------------------------------------------------------------------------
com			TWEワイヤレスデバイス親機が接続された COM ポート名
			またはタイトル名									"COM4"

id			取得対象のTWEワイヤレスデバイス子機の論理IDを10進数の文字列で
			指定する											"1"

●リターンパラメータ

---------------------------------------------------------------------------------
キー値			値		            									値の例
---------------------------------------------------------------------------------
AD1				TWEワイヤレスデバイス子機 AD1 の値					"0"
AD2				TWEワイヤレスデバイス子機 AD2 の値					"-1"
AD3				TWEワイヤレスデバイス子機 AD3 の値					"1980"
AD4				TWEワイヤレスデバイス子機 AD4 の値					"500"

DI1				TWEワイヤレスデバイス子機 DI1 の値					"1"
DI2				TWEワイヤレスデバイス子機 DI2 の値					"1"
DI3				TWEワイヤレスデバイス子機 DI3 の値					"1"
DI4				TWEワイヤレスデバイス子機 DI4 の値					"1"

STATUS			スクリプト実行が正常に終了した場合には "OK"、
				エラー発生時には"ERROR" が設定される				"OK"

]]

-------------------------
-- パラメータチェック
-------------------------
if not (g_params["com"] and g_params["id"]) then
	log_msg("parameter error",file_id)
	error()
end
local stat,com = serial_find_device(g_params["com"])
if not stat then
	log_msg("COM port not found",file_id)
	error()
end

----------------------------------------------------------------------
-- 子機の最新のデバイス情報をグローバル共有変数から取得
----------------------------------------------------------------------
local key = "TWE_" .. com .. "_" .. g_params["id"]
local val
stat,val = get_shared_data(key)
if (not stat) or (val == "") then
	if not script_result(g_taskid,"STATUS","ERROR") then error() end
	return
end

local tbl= csv_to_tbl(val)
if tbl[3] and tbl[4] and tbl[5] and tbl[6] and tbl[7] and tbl[8] and tbl[9] and tbl[10] then
	if not script_result(g_taskid,"DI1",tbl[3]) then error() end
	if not script_result(g_taskid,"DI2",tbl[4]) then error() end
	if not script_result(g_taskid,"DI3",tbl[5]) then error() end
	if not script_result(g_taskid,"DI4",tbl[6]) then error() end
	if not script_result(g_taskid,"AD1",tbl[7]) then error() end
	if not script_result(g_taskid,"AD2",tbl[8]) then error() end
	if not script_result(g_taskid,"AD3",tbl[9]) then error() end
	if not script_result(g_taskid,"AD4",tbl[10]) then error() end
	if not script_result(g_taskid,"STATUS","OK") then error() end
else
	if not script_result(g_taskid,"STATUS","ERROR") then error() end
end

このスクリプトではTWE-Lite 子機を操作するために、親機に対してコマンドパケットを送信していない点に注意してください。

TWE-Lite 子機はデジタル入力値やA/D 変換値を、定期的にまたは変化したときに親機に対してイベントデータを送信しています。DeviceServer では親機で受信したイベントデータをイベントハンドラで処理して、子機ごとの最新の I/O 値をグローバル共有データに保存しています。

このスクリプトではそのグローバル共有データの値を利用して子機のデジタル入力とA/D 変換値を返しています。親機がイベントパケットデータを受信したときに、DeviceServer 側で実行するイベントハンドラ(SERIAL_TWE) については後の項で説明します。

続いて子機の I2C バスを WebAPI で操作する例を紹介したいと思います。最初に子機で I2C データを書き込み用スクリプト(TWE/I2C_WRITE) をご覧ください。

file_id = "TWE/I2C_WRITE"

--[[

●機能概要

TWEワイヤレスデバイス子機の I2C バスに接続したスレーブデバイスにデータを書き込む

●リクエストパラメータ

---------------------------------------------------------------------------------
キー値			値		            									値の例
---------------------------------------------------------------------------------
com			TWEワイヤレスデバイス親機が接続された COM ポート名
			またはタイトル名									"COM4"

id			取得対象のTWEワイヤレスデバイス子機の論理IDを10進数の文字列で
			指定する											"1"

slave_addr		I2C スレーブデバイスアドレス(16進数2桁)					"50"

data			スレーブデバイスに書き込むデータ(16進数)列				"0A0B0C"
				最大31バイトまで

●リターンパラメータ

---------------------------------------------------------------------------------
キー値			値		            									値の例
---------------------------------------------------------------------------------

]]

-------------------------
-- パラメータチェック
-------------------------
if not (g_params["com"] and g_params["id"] and g_params["slave_addr"] and g_params["data"]) then
	log_msg("parameter error",file_id)
	error()
end
local stat,com = serial_find_device(g_params["com"])
if not stat then
	log_msg("COM port not found",file_id)
	error()
end

local data_len =  math.floor(string.len(g_params["data"]) / 2)
if data_len < 1 then
	log_msg("data parameter error",file_id)
	error()
end

----------------------------------------------------------------------
-- 排他制御開始
-- 同じ TWE親デバイスに対して、QUERY コマンドが複数同時実行される場合に備えています。
----------------------------------------------------------------------
local cstat,handle = critical_section_enter("TWEQuery" .. com,5000);
if not cstat then
	log_msg("critical_section_enter() failed",file_id)
	error()
end

------------------------------------------------------------------------------------------------
-- リクエストフレーム送信とリプライ受信
------------------------------------------------------------------------------------------------
local command_str = ":" .. bit_tohex(tonumber(g_params["id"]),2) .. "880101" ..
                    bit_tohex(tonumber("0x" .. g_params["slave_addr"]),2)
if data_len == 1 then
	command_str = command_str .. g_params["data"] .. "00X"
elseif data_len > 1 then
	command_str = command_str .. string.sub(g_params["data"],1,2) .. bit_tohex(data_len - 1,2) .. string.sub(g_params["data"],3,-1) .. "X"
end

stat,rdata = twe_print(com,command_str,"89")

----------------------------------------------------------------------
-- 排他制御終了
----------------------------------------------------------------------
cstat = critical_section_leave(handle)
if not cstat then
	log_msg("critical_section_leave() failed",file_id)
	error()
end
if not stat then
	log_msg("twe_print() failed",file_id)
	error()
end
if string.sub(rdata,10,11) ~= "01" then -- TWE レスポンスフレームで SUCCESS 以外を受信した
	log_msg("twe remote operation failed",file_id)
	error()
end

このスクリプトでは TWE-Lite のファームウエアで用意されている、子機の I2C バスを操作するためのコマンドパケット(0×88) を送信しています。twe_print() ライブラリでリクエストパケットを送信するときに、リプライパケット(0×89) を受信するまで内部で待機するようにパラメータを指定しています。リプライパケットには I2C 操作が正常に完了したかどうかを示すステータスが格納されていますので、これを確認しています。

またI2Cバス操作のコマンドの様に、リクエストパケット送信とその結果をリプライパケットで受信するようなタイプのコマンドを処理する場合には、クライアント(Web APIを利用しているプログラム)側から同時にリクエストが発生した場合に備える必要があります。Lua スクリプト中に排他処理を記述して、Web API を使用する側からは同時使用しても問題が発生しないようになっています。

次は子機のI2C データを読み込むためのスクリプト(TWE/I2C_READ)で、以下の様になっています。

file_id = "TWE/I2C_READ"

--[[

●機能概要

TWEワイヤレスデバイス子機の I2C バスに接続したスレーブデバイスから
指定バイト数分のデータ読み込みを行う

●リクエストパラメータ

---------------------------------------------------------------------------------
キー値			値		            									値の例
---------------------------------------------------------------------------------
com			TWEワイヤレスデバイス親機が接続された COM ポート名
			またはタイトル名									"COM4"

id			取得対象のTWEワイヤレスデバイス子機の論理IDを10進数の文字列で
			指定する											"1"

slave_addr		I2C スレーブデバイスアドレス(16進数2桁)					"50"

count			データ読み込みバイト数(32 以下の10進整数)				"32"

●リターンパラメータ

---------------------------------------------------------------------------------
キー値			値		            									値の例
---------------------------------------------------------------------------------
I2C_DATA		スレーブデバイスから読み込んだデータ(16進数)列
				最大32 バイト(64文字)まで								"0A0B0C

]]

-------------------------
-- パラメータチェック
-------------------------
if not (g_params["com"] and g_params["id"] and g_params["slave_addr"] and g_params["count"]) then
	log_msg("parameter error",file_id)
	error()
end
local stat,com = serial_find_device(g_params["com"])
if not stat then
	log_msg("COM port not found",file_id)
	error()
end

----------------------------------------------------------------------
-- 排他制御開始
-- 同じ TWE親デバイスに対して、QUERY コマンドが複数同時実行される場合に備えています。
----------------------------------------------------------------------
local cstat,handle = critical_section_enter("TWEQuery" .. com,5000);
if not cstat then
	log_msg("critical_section_enter() failed",file_id)
	error()
end

------------------------------------------------------------------------------------------------
-- リクエストフレーム送信とリプライ受信
------------------------------------------------------------------------------------------------
local command_str = ":" .. bit_tohex(tonumber(g_params["id"]),2) .. "880102" ..
                    bit_tohex(tonumber("0x" .. g_params["slave_addr"]),2) .. "00" ..
					bit_tohex(tonumber(g_params["count"]),2) .. "X"

stat,rdata = twe_print(com,command_str,"89")

----------------------------------------------------------------------
-- 排他制御終了
----------------------------------------------------------------------
cstat = critical_section_leave(handle)
if not cstat then
	log_msg("critical_section_leave() failed",file_id)
	error()
end
if not stat then
	log_msg("twe_print() failed",file_id)
	error()
end
if string.sub(rdata,10,11) ~= "01" then -- TWE レスポンスフレームで SUCCESS 以外を受信した
	log_msg("twe remote operation failed",file_id)
	error()
end

---------------------------------------------------------------
-- リターンパラメータ設定
---------------------------------------------------------------
if not script_result(g_taskid,"I2C_DATA",string.sub(rdata,14,-3)) then error() end

殆ど、I2C_WRITE スクリプトの内容と同じですが、リプライパケットで受信したバイトデータをスクリプトリターンパラメータで返す部分が追加されています。

前述の I2C_WRITE と I2C_READ スクリプトを組み合わせて、I2C データの書き込みと読み込みをする I2C_WRITE_READ スクリプトも作成してあります。内容は以下になります。

file_id = "TWE/I2C_WRITE_READ"

--[[

●機能概要

TWEワイヤレスデバイス子機の I2C バスに接続したスレーブデバイスにデータを書き込んだ後、
指定バイト数分のデータ読み込みを行う

●リクエストパラメータ

---------------------------------------------------------------------------------
キー値			値		            									値の例
---------------------------------------------------------------------------------
com			TWEワイヤレスデバイス親機が接続された COM ポート名
			またはタイトル名									"COM4"

id			取得対象のTWEワイヤレスデバイス子機の論理IDを10進数の文字列で
			指定する											"1"

slave_addr		I2C スレーブデバイスアドレス(16進数2桁)					"50"

count			データ読み込みバイト数(32 以下の10進整数)				"32"

data			スレーブデバイスに書き込むデータ(16進数)列				"0A0B0C"
				最大31バイトまで

●リターンパラメータ

---------------------------------------------------------------------------------
キー値			値		            									値の例
---------------------------------------------------------------------------------

I2C_DATA		スレーブで倍しから読み込んだデータ(16進数)列
				最大32 バイトまで										"0A0B0C

]]

-------------------------
-- パラメータチェック
-------------------------
if not (g_params["com"] and g_params["id"] and g_params["slave_addr"] and g_params["data"] and g_params["count"]) then
	log_msg("parameter error",file_id)
	error()
end

-------------------------
-- I2C write操作
-------------------------
local param = {}
param["com"] = g_params["com"]
param["id"] = g_params["id"]
param["slave_addr"] = g_params["slave_addr"]
param["data"] = g_params["data"]
local stat,result = script_exec2("TWE/I2C_WRITE",param)
if not stat then error() end

-------------------------
-- I2C read操作
-------------------------
param["count"] = g_params["count"]
local stat,result = script_exec2("TWE/I2C_READ",param)
if not stat then error() end

script_result(g_taskid,"I2C_DATA",result["I2C_DATA"])

このスクリプトは、最初に I2C 書き込みトランザクションを実行した後、読み込みトランザクションを実行します。読み込んだデータ列をスクリプトパラメータで返します。内容は、単に前述の2つのスクリプトを順番にコールしているだけです。

この I2C_WRITE_READ スクリプトを使用して、TWE-Lite 子機#1 に接続した 24LC256 EEPROM のデータをリードしてみます。接続の様子は前の項で紹介した子機の写真を参考にしてください。

“slave_addr” パラメータには 24LC256 のI2Cスレーブアドレス0×50 を指定しています。”data” パラメータに “0000″ を指定してEEPROM デバイス内のアドレスポインタを示す 0×00, 0×00 の2バイトを書き込みます。その後、”count” パラメータで指定した32バイト分のデータを JSON フォーマットで取得しています。

次の動作例は、同じ子機のI2C バスに搭載されている TMP102 温度センサの値を取得してみます。I2Cバス操作と温度計算を以下のスクリプト(TWE/DEVICE/TMP102_READ)で実行します。

file_id = "TWE/DEVICE/TMP102_READ"

--[[

●機能概要

I2C バスに接続した温度センサー(TMP102) の値を取得する

●リクエストパラメータ

---------------------------------------------------------------------------------
キー値			値		            									値の例
---------------------------------------------------------------------------------
com			TWEワイヤレスデバイス親機が接続された COM ポート名
			またはタイトル名									"COM4"

id			取得対象のTWEワイヤレスデバイス子機の論理IDを10進数の文字列で
			指定する											"1"

●リターンパラメータ

---------------------------------------------------------------------------------
キー値			値		            									値の例
---------------------------------------------------------------------------------

temperature			センサーから取得した摂氏温度						"12.5"
 					                                                    "-25.0"
]]

local slave_addr = "48"

-------------------------
-- パラメータチェック
-------------------------
if not (g_params["com"] and g_params["id"]) then
	log_msg("parameter error",file_id)
	error()
end

----------------------------------------
-- 12 bit 幅の2の補数を符号付整数に変換
----------------------------------------
function calc_2comp(val)
	if(bit_and(val,0x800) ~= 0) then
		return -1 * (bit_and(bit_not(val),0xfff) + 1)
	else
		return val
	end
end

-----------------------------------------------------------------------
-- TMP102温度レジスタの値を取得する
-- pointer register 0x00 をセットした後、2 バイトのレジスタ値を取得する
-----------------------------------------------------------------------
local param = {}
param["com"] = g_params["com"]
param["id"] = g_params["id"]
param["slave_addr"] = slave_addr
param["data"] = "00"
param["count"] = "2"
local stat,result = script_exec2("TWE/I2C_WRITE_READ",param)
if not stat then error() end

---------------------------------------
-- 温度レジスタ値から摂氏温度を計算する
---------------------------------------
local reg = {}
reg = hex_to_tbl(result["I2C_DATA"])
local temp_int = bit_lshift(reg[1],4) + bit_rshift(reg[2],4)
local temperature = 0.0625 * calc_2comp(temp_int)
script_result(g_taskid,"temperature",string.format("%3.1f",temperature))

このスクリプト中からは、先ほど紹介した I2C_WRITE_READ スクリプトをコールして子機#1 のI2C バスを操作して温度レジスタ値をリードしています。その後摂氏温度を計算してリターンパラメータに返しています。このスクリプトを Web API から実行したときの様子が以下になります。

JSON で返されたデータ内の “temperature” 部分が子機#1で計測された現在の温度になります。

ここで紹介した以外にも子機の PWM を操作するためのスクリプトやデジタル出力と PWM の全チャンネルを同時に更新するためのスクリプト、親機に接続されている全子機のID リスト取得などのスクリプトが予め用意されています。これらのスクリプトファイルは DeviceServer インストール時に “C:\Program Files (x86)\AllBlueSystem\Scripts\TWE” フォルダに格納されていますので Web API から直ぐに使用することができます。

Lua スクリプトはテキストファイル(UTF-8) ですので、簡単にコピーしたり独自のコマンド処理用に改造することができます。

TWE-Lite 親機からパケットを受信したときの動作

TWE-Lite 子機からは、定期的に現在のステータスは送信されていたり、子機のA/D 変換値やデジタル入力の変化を検出した時にはイベントデータが親機に対して送信されます。

イベントデータを受信すると親機からはアスキー形式のパケットデータが送信されます。DeviceServer では親機から送信されるこのようなパケットデータを処理するためのスクリプト(SERIAL_TWE)が予め設定されています。スクリプトの内容は以下の様になっています。

file_id = "SERIAL_TWE"

--[[

SERIAL_TWE スクリプト起動時に渡される追加パラメータ
---------------------------------------------------------------------------------
キー値			値		            									値の例
---------------------------------------------------------------------------------
COMPort			イベントを送信したシリアルデバイスの COMポート名		"COM10"

Title			イベントを送信したシリアルデバイスのタイトル名			"TWE-Lite PAN#1"
				タイトルが設定されていない場合にはこのパラメータは
				設定されません

TWE_DATA		COM ポートから入力されたアスキー形式のデータパケット全体を格納しています。

	値の例

	タイプ(1)	":01890902010A010203040405060708092F"
	タイプ(2)	"::rc=80000000:lq=84:ct=0001:ed=81002A1E:id=1:ba=3320:a1=0009:a2=0009:p0=001:p1=000"
	タイプ(3)	";116;00000000;054;001;1002ecd;3330;0007;0042;0007;0007;S;"
	タイプ(4)	"!INF TOCOS TWELITE DIP APP V1-00-2, SID=0x81000038, LID=0x78"
	タイプ(5)	"*** Samp_Monitor (Parent) 1.03-3 *** Title = TWE-Zero"

	文字列は、下記の何れかのデータで終端されたものです。
	ヌル文字(0x00),CR(0x0D),LF(0x0A),CR-LF(0x0D,0x0A)
	TWE_DATA パラメータには、終端文字を含まない文字列部分が格納されています

TWE_DATAを解析してこのスクリプト中で作成されるテーブルと文字列変数
---------------------------------------------------------------------------------
テーブルまたは文字列変数名		説明									値の例
---------------------------------------------------------------------------------
byte_arr	TWE_DATA が ":" 1文字から始まっている場合に、16進数文字列部分を
			1バイト毎に数値に変換して配列に格納したものが入る
			上記 TWE_DATA データ例タイプ(1)を参照

			byte_arr[1] = 0x01
			byte_arr[2] = 0x89
			byte_arr[3] = 0x09
			..

key_val		TWE_DATA が "::" 2文字から始まっている場合に、続く ":" 文字毎にカラムを
			分けて "<key>=<val>" で記述された部分を連想配列に格納したものが入る。
			上記 TWE_DATA データ例タイプ(2)を参照

			key_val["rc"] = "80000000"
			key_val["lq"] = "84"
			key_val["ct"] = "0001"
			key_val["ed"] = "81002A1E"
			..

tag_arr		TWE_DATA が ";" 1文字から始まっている場合に、続く ";" 文字毎にカラムを
			分けたものを文字列形式で配列に格納したものが入る。
			上記 TWE_DATA データ例タイプ(3)を参照

			tag_arr[1] = "116"
			tag_arr[2] = "00000000"
			tag_arr[3] = "054"
			tag_arr[4] = "001"
			..

comment		TWE_DATA が ":"または ";" 文字以外から始まっている場合に、
			データパケット全体の文字列を格納したものが入る
			上記 TWE_DATA データ例タイプ(4),(5)を参照

			COMMENT = "!INF TOCOS TWELITE DIP APP V1-00-2, SID=0x81000038, LID=0x78"

TWE_DATAを解析してこのスクリプト中で作成されるグローバル共有変数と共有文字列リスト
---------------------------------------------------------------------------------
グローバル共有変数名						説明
または、共有文字列リストChannel名
---------------------------------------------------------------------------------

TWE_<COMPort>_<ChildID>

			TWE_DATA が ":" 1文字から始まっていて、かつコマンド種別を示すバイト値が
			0x81(状態通知)の場合に、メッセージ内容を解析した値がカンマ区切りで
			グローバル共有変数に格納される。この変数の値は常に最後のイベント発生時
			の内容で更新されます。

			<COMPort>は、イベントを送信したシリアルデバイスの COMポート名になります
			<ChildID>は、メッセージ中の送信元論理デバイスIDを10進数にしたものになります

			変数の内容に設定されるカンマ区切りの文字列は下記のフォーマットになります。

			<LQI>,<Batt>,<DI1>,<DI2>,<DI3>,<DI4>,<AD1>,<AD2>,<AD3>,<AD4>

			<LQI> にはLQI値フィールドの値を10進数に変換したものが入ります
			<Batt> には電源電圧[mV]フィールドの値を10進数に変換したものが入ります
			<DI1>..<DI4> にはDI の状態ビットが Lowの場合に1, High の場合に 0 が入ります
			<AD1>..<AD4> にはAD変換値の値を10進数に変換したものが入ります

TWE_<COMPort>_CHILD_LIST (共有文字列リストChannel名)
			TWE_DATA が ":" 1文字から始まっているパケットデータを受信したときの
			<ChildID> 部分を文字列リストに保存します。文字列リストにはメッセージ中の
			送信元論理デバイスIDを10進数表現にしたものを重複なく保存しています。

]]

local str = ""
for key,val in pairs(g_params) do
	str = str .. key .. " = " .. val .. " "
end
log_msg(str,file_id)

------------------------------------------------------------
-- g_params["TWE_DATA"] データパケット文字列をデコードする
------------------------------------------------------------
local data = g_params["TWE_DATA"]
local byte_arr,key_val,tag_arr,comment
if string.match(data,"^::") then		-- タイプ(2)
	key_val = key_val_to_tbl(string.sub(data,3,-1))
elseif string.match(data,"^:%x") then	-- タイプ(1)
	byte_arr = hex_to_tbl(string.sub(data,2,-1))
	local id = tostring(byte_arr[1])
	if not add_shared_strlist("TWE_" .. g_params["COMPort"] .. "_CHILD_LIST",id,true) then error() end -- 子機のIDリストを更新
	if byte_arr[2] == 0x81 then -- 状態通知の場合には共有変数に現在のセンサ値を保存
		local di1,di2,di3,di4,ad1,ad2,ad3,ad4
		if bit_and(byte_arr[17],0x01) ~= 0 then di1 = "1" else di1 = "0" end
		if bit_and(byte_arr[17],0x02) ~= 0 then di2 = "1" else di2 = "0" end
		if bit_and(byte_arr[17],0x04) ~= 0 then di3 = "1" else di3 = "0" end
		if bit_and(byte_arr[17],0x08) ~= 0 then di4 = "1" else di4 = "0" end
		if byte_arr[19] == 0xFF then ad1 = "-1" else ad1 = tostring((byte_arr[19]*4 + bit_and(byte_arr[23],0x03))*4) end
		if byte_arr[20] == 0xFF then ad2 = "-1" else ad2 = tostring((byte_arr[20]*4 + bit_and(bit_rshift(byte_arr[23],2),0x03))*4) end
		if byte_arr[21] == 0xFF then ad3 = "-1" else ad3 = tostring((byte_arr[21]*4 + bit_and(bit_rshift(byte_arr[23],4),0x03))*4) end
		if byte_arr[22] == 0xFF then ad4 = "-1" else ad4 = tostring((byte_arr[22]*4 + bit_and(bit_rshift(byte_arr[23],6),0x03))*4) end
		local val = tostring(byte_arr[5]) .. "," .. tostring(byte_arr[14]*256 + byte_arr[15])
				.. "," .. di1 .. "," .. di2 .. "," .. di3 .. "," .. di4
				.. "," .. ad1 .. "," .. ad2 .. "," .. ad3 .. "," .. ad4
		if not set_shared_data("TWE_" .. g_params["COMPort"] .. "_" .. id,val) then error() end
		-- リレーサーバーに最新データの配信を依頼する場合には下記のコメントを取り除く
		script_exec("RELAY_SERVER_UPLINK","COM,TYPE,NodeID,LQI,Batt,DI1,DI2,DI3,DI4,AD1,AD2,AD3,AD4",g_params["COMPort"] .. ",TWE_UPDATE," .. id .. "," .. val)
	end
elseif string.match(data,"^;") then		-- タイプ(3)
	tag_arr = ssv_to_tbl(string.sub(data,2,-2))
else									-- タイプ(4),(5)
	comment = data
end

-----------------------------------
-- デコード後のデータをログに出力
-----------------------------------
--[[
local line = ""
if key_val then
	for key,val in pairs(key_val) do
		line = line .. "[" .. key .."]" .. val .. " "
	end
end
if byte_arr then
	for key,val in ipairs(byte_arr) do
		line = line .. "0x" .. bit_tohex(val,2) .. " "
	end
end
if tag_arr then
	for key,val in ipairs(tag_arr) do
		line = line .. "[" .. tostring(key) .. "]" .. val .. " "
	end
end
if comment then
	line = comment
end
log_msg("decoded: " .. line,file_id)
]]

このスクリプトでは TWE-Lite のファームエア (TWE-Zeroアプリ)で使用されている全てのアスキー形式のパケットを解析して、DeviceServer で処理しやすい形に変換しています。

他のイベントハンドラやユーザースクリプトから TWE-Lite のイベントデータを利用し易い様に、グローバル共有変数に子機毎の最新のI/O 値などをカンマ区切りのデータで保持しています。そのほかにも親機のCOM ポート毎に、全ての子機のID リストを作成しています。

これらの詳しいデータ構造は上記スクリプトのコメントを参照してください。ユーザーが独自のファームエアを TWE-Lite に搭載した場合でも、TWE-Zero アプリで使用しているアスキー形式のフォーマットに合わせておくと、このイベントハンドラで自動的に内容が解析されるようになります。

もちろん独自のフォーマットでデータを送信することもできます。この場合にはこのイベントハンドラにフォーマットを解析するためのスクリプトを追加して対応してください。

Webアプリを作成する

ここからはWebアプリの作成例を紹介します。Webブラウザ上に表示したチェックボックスやスライダー を使用して子機をリモートコントロールできます。HTML5 アプリで作成していますのでPC の Webブラウザはもちろんのこと、iOS や Android デバイスからも実行することができます。

この Webアプリではフレームワークとして jQuery と jQuery-mobile を使用しています。もちろん、これら以外のフレームワークを利用して独自のWeb アプリを自由に作成することができます。Web アプリ中からは、前の項で紹介したWeb API をコールして TWE-Lite デバイスを操作しています。

ここで紹介するWeb アプリは、DeviceServer インストール時に”C:\Program Files (x86)\AllBlueSystem\WebRoot\web_api_sample\twe_control” フォルダに格納されていますので直ぐに使用することができます。Webアプリを起動させるときは、Webブラウザで “http://<DeviceServer PC ホスト>/web_api_sample/twe_control/index.html” にアクセスしてください。

最初にログイン画面が表示されます。DeviceServer に登録したユーザーアカウントでログインします。このとき、ユーザーアカウントに設定したアプリケーション許可フラグに “WebLogin” を付与して Web API 経由でログイン可能にしておいてください。

ログインに成功すると、COM ポートの選択画面が表示されます。ここで、操作したいTWE-Lite の子機が所属している親機の COM ポートを選択します。ここで表示しているCOM デバイスリストにはシリアルデバイスタイプとして “TWE” を選択しているものだけが表示されます。

上記の画面で表示されている親機のポート(TWE#1) は1つだけですが、複数の親機を DeviceServer で同時に管理してすることもできます。このようにすると、それぞれの親機に属している TWE-Lite デバイスの Application ID を分けて、別々の PAN に属している TWE-Lite デバイスを Web アプリから操作することができます。

次にノード(子機の Device ID)選択画面が表示されます。子機から送信されてきたイベントデータパケットの情報から作成した最新のノードリスト(子機の Device ID リスト)を表示しています。

子機のノードを選択すると I/O 画面が表示されます。

デジタル入力と A/D 変換値は最後に親機で受信したイベントデータを元に表示されます。この部分は表示のみで操作することはできません。スクロールダウンすると、デジタル出力と PWM 出力を操作する画面が現れます。

チェックボックスを操作すると、子機の指定したデジタル出力ポートの値を High または Low に設定できます。”全てのDO#を更新” ボタンはデジタル出力ポートの全ピンの値を現在のチェックボックスの状態に合わせて全て更新することができます。

このボタンは TWE-Lite のファームウエアの制限から現在の出力ポートの値が取得できないため、最初にこのボタンを押してチェックボックスの状態と子機のデジタル出力の値を一致させるときに使用します。この部分については後の”考察”の項でも説明しています。

子機のPWM 出力は、スライダーを操作することで簡単に設定することができます。

別の子機を操作したくなった場合にはブラウザの “戻る” ボタンを使用してノード選択画面やポート選択画面に移動して選択するデバイスを変更できます。

下記にこの Webアプリで使用している HTML ファイルを載せます。HTMLファイルではWebアプリの GUI やダイアログの定義のみを行っています。

<!DOCTYPE html>
<html>
	<head>
		<meta charset="utf-8" />
		<meta name="viewport" content="width=device-width, initial-scale=1" />
		<title>TWE Control</title>
		<link rel="stylesheet" href="libs/css/themes/default/jquery.mobile-1.4.5.min.css" />
		<script src="libs/js/jquery.js"></script>
		<script src="libs/js/jquery.mobile-1.4.5.js"></script>
		<script src="libs/js/socket.io.js"></script>
		<script src="libs/device_server/webapi.js"></script>
	</head>
	<body>

		<div data-role="page" id="login">
			<div data-role="header" data-position="inline">
				<h3>ユーザー認証</h3>
			</div>
			<div role="main" class="ui-content">
				<label for="login_name">Name</label>
				<input id="login_name" value="" type="text" data-clear-btn="true"/>
				<label for="login_password">Password</label>
				<input id="login_password" value="" type="password" data-clear-btn="true"/>
				<div><h3>&nbsp</h3></div>
				<div class="ui-grid-b">
					<div class="ui-block-b">
							<a class="ui-btn ui-btn-inline ui-icon-check ui-btn-icon-left " id="login_btn" >Login</a>
					</div>
				</div>
			</div>
			<div data-role="footer">
				<h3>ABS-9000 DeviceServer</h3>
			</div>
		</div>

		<div data-role="page" id="select_device">
			<div data-role="header" data-position="inline">
				<h3>ポート選択</h3>
				<a data-icon="home" id="logout_btn" href="#logout_caution" data-rel="dialog" data-transition="pop">Logout</a>
			</div>
			<ul data-role="listview" id="device_list" data-inset="true"></ul>
			<div data-role="footer">
				<h3>ABS-9000 DeviceServer</h3>
			</div>
		</div>

		<div data-role="page" id="select_node"  data-theme="a">
			<div data-role="header" data-position="inline">
				<a data-icon="back" id="select_node_prev_btn">戻る</a>
				<h3>ノード選択</h3>
				<a data-icon="home" id="logout_btn" href="#logout_caution" data-rel="dialog" data-transition="pop">Logout</a>
			</div>

			<ul data-role="listview" id="node_list" data-inset="true"></ul>
			<div data-role="footer">
				<h3>ABS-9000 DeviceServer</h3>
			</div>
		</div>

		<div data-role="page" id="twe_control">
			<div data-role="header" data-position="inline">
				<a data-icon="refresh" id="reloadBtn">Reload</a>
				<h3 id="main_title">TWE Control</h3>
				<a data-icon="home" id="logout_btn" href="#logout_caution" data-rel="dialog" data-transition="pop">Logout</a>
			</div>
            <div role="main" class="ui-content">
                <div data-role="fieldcontain">
                    <fieldset data-role="controlgroup" data-type="vertical">
                        <input name="checkbox1" id="checkbox1" type="checkbox" class="di_pin" pin="1" disabled="disabled"/>
                        <label for="checkbox1">DI#1</label>
                        <input name="checkbox2" id="checkbox2" type="checkbox" class="di_pin" pin="2" disabled="disabled"/>
                        <label for="checkbox2">DI#2</label>
                        <input name="checkbox3" id="checkbox3" type="checkbox" class="di_pin" pin="3" disabled="disabled"/>
                        <label for="checkbox3">DI#3</label>
                        <input name="checkbox4" id="checkbox4" type="checkbox" class="di_pin" pin="4" disabled="disabled"/>
                        <label for="checkbox4">DI#4</label>
                    </fieldset>
                </div>
            </div>
            <div role="main" class="ui-content">
				<fieldset data-role="controlgroup" data-type="vertical">
					<div data-role="fieldcontain">
						<label for="slider-1">AD#1</label>
						<input type="range" name="slider-1" id="slider-1" style="width : 58px;" value="-1" min="-1" max="1024" data-highlight="true" disabled="disabled"/>
					</div>
					<div data-role="fieldcontain">
						<label for="slider-2">AD#2</label>
						<input type="range" name="slider-2" id="slider-2" style="width : 58px;" value="-1" min="-1" max="1024" data-highlight="true" disabled="disabled"/>
					</div>
					<div data-role="fieldcontain">
						<label for="slider-3">AD#3</label>
						<input type="range" name="slider-3" id="slider-3" style="width : 58px;" value="-1" min="-1" max="1024" data-highlight="true" disabled="disabled"/>
					</div>
					<div data-role="fieldcontain">
						<label for="slider-4">AD#4</label>
						<input type="range" name="slider-4" id="slider-4" style="width : 58px;" value="-1" min="-1" max="1024" data-highlight="true" disabled="disabled"/>
					</div>
				</fieldset>
			</div>
            <div role="main" class="ui-content">
                <fieldset data-role="controlgroup" data-type="vertical">
						<a class="ui-btn ui-btn-inline ui-icon-gear ui-btn-icon-left ui-mini" id="do_all_btn" >全ての DO# 更新</a>
                </fieldset>
                <fieldset data-role="controlgroup" data-type="vertical">
	                <div data-role="fieldcontain">
                        <input name="checkbox5" id="checkbox5" type="checkbox" class="do_pin" pin="1"/>
                        <label for="checkbox5">DO#1</label>
                        <input name="checkbox6" id="checkbox6" type="checkbox" class="do_pin" pin="2"/>
                        <label for="checkbox6">DO#2</label>
                        <input name="checkbox7" id="checkbox7" type="checkbox" class="do_pin" pin="3"/>
                        <label for="checkbox7">DO#3</label>
                        <input name="checkbox8" id="checkbox8" type="checkbox" class="do_pin" pin="4"/>
                        <label for="checkbox8">DO#4</label>
                	</div>
                </fieldset>
            </div>
            <div role="main" class="ui-content">
				<fieldset data-role="controlgroup" data-type="vertical">
					<a class="ui-btn ui-btn-inline ui-icon-gear ui-btn-icon-left ui-mini" id="pwm_all_btn" >全ての PWM# 更新</a>
					<div class="ui-field-contain">
						<label for="slider-5">PWM#1</label>
						<input type="range" name="slider-5" id="slider-5" style="width : 58px;" value="0" min="0" max="1024" class="pwm_pin" pin="1" data-highlight="true"/>
					</div>
					<div data-role="fieldcontain">
						<label for="slider-6">PWM#2</label>
						<input type="range" name="slider-6" id="slider-6" style="width : 58px;" value="0" min="0" max="1024" class="pwm_pin" pin="2" data-highlight="true"/>
					</div>
					<div data-role="fieldcontain">
						<label for="slider-7">PWM#3</label>
						<input type="range" name="slider-7" id="slider-7" style="width : 58px;" value="0" min="0" max="1024" class="pwm_pin" pin="3" data-highlight="true"/>
					</div>
					<div data-role="fieldcontain">
						<label for="slider-8">PWM#4</label>
						<input type="range" name="slider-8" id="slider-8" style="width : 58px;" value="0" min="0" max="1024" class="pwm_pin" pin="4" data-highlight="true"/>
					</div>
				</fieldset>
			</div>
			<div data-role="footer">
				<h3>ABS-9000 DeviceServer</h3>
			</div>
		</div>

		<div data-role="page" id="login_error_dialog">
			<div data-role="header" data-theme="b">
				<h1>*LOGIN ERR*</h1>
			</div>
			<div role="main" class="ui-content">
				<h2>ログインに失敗しました</h2>
				<p>ユーザー名またはパスワードが間違っています。システムのログイン制限により失敗している場合があります</p>
				<p>
					<a href="#login" data-rel="back" class="ui-btn ui-shadow ui-btn-a ui-icon-check ui-btn-icon-left">戻る</a>
				</p>
			</div>
		</div>

		<div data-role="page" id="logout_caution">
			<div data-role="header" data-theme="b">
				<h1>*WARNING*</h1>
			</div>
			<div role="main" class="ui-content">
				<h2>ログアウトしますか?</h2>
				<p>ログアウト操作を行う場合には "OK" を押してください。"キャンセル" で元の画面に戻ります</p>
				<p><a data-rel="back" class="ui-btn ui-btn-inline ui-shadow ui-btn-a ui-icon-back ui-btn-icon-left">キャンセル</a>
				   <a id="logout_ok_btn" class="ui-btn ui-btn-inline ui-shadow ui-btn-a ui-icon-check ui-btn-icon-left">OK</a></p>
			</div>
		</div>

		<div data-role="page" id="error_quit_dialog">
			<div data-role="header" data-theme="b">
				<h1>*USER ERR*</h1>
			</div>
			<div role="main" class="ui-content">
				<h2>セッションが無効です</h2>
				<p>サーバー処理中にエラーが発生しました。現在のセッションが無効になっている場合があります。再ログイン操作を行ってください</p>
				<p><a data-role="button" id="server_error_ok_btn" class="ui-btn ui-shadow ui-btn-a ui-icon-check ui-btn-icon-left">OK</a></p>
			</div>
		</div>

		<div data-role="page" id="error_back_dialog">
			<div data-role="header" data-theme="b">
				<h1>*SERVER ERR*</h1>
			</div>
			<div role="main" class="ui-content">
				<h3>サーバー側でエラーが発生しました</h3>
				<p>サーバー処理中にエラーが発生しました。スクリプト実行中にエラーが発生した可能性がありますのでサーバー側のログを確認して下さい</p>
				<p><a data-role="button" data-rel="back" class="ui-btn ui-shadow ui-btn-a ui-icon-check ui-btn-icon-left">OK</a></p>
			</div>
		</div>

		<script src="main.js"></script>

    </body>
</html>

Web アプリケーションのロジック部分は、下記のmain.js(JavaScript) で作成しています。このスクリプト中から、先に説明した Web API をコールすることで、TWE-Lite 子機を操作しています。

//////////////////////////////////////
// common function
//////////////////////////////////////

// スクリプト実行結果ステータスのみをチェック
function script_exec_callback(data){
	if (data.Result != "Success"){
		if(data.ErrorText.match(/CertifyUpdateSession failed/i)) {
			$("#login_password").val("");
			$("body").pagecontainer("change","#error_quit_dialog", { transition: "pop",role:"dialog" });
		} else {
			$("body").pagecontainer("change","#error_back_dialog", { transition: "pop",role:"dialog" });
		}
	}
}

// UI コンポーネントの xml 属性値を検索取得
function getAttrVal(node,name){
	var val = "";
	var attr =  node.attributes;
	for (var i=0; i<attr.length; i++){
		if (attr[i].nodeName == name){
			val = attr[i].nodeValue;
		}
	}
	return val;
}

//////////////////////////////////////
// twe_control page
//////////////////////////////////////

// IO 値の配列を受け取って GUI表示に反映させる
// data パラメータ例
// {"DI1":"1","DI2":"0","DI3":"0","DI4":"0","AD1":"-1","AD2":"-1","AD3":"4","AD4":"248"}
function apply_ui(data){
	var	flag;
	flag = ( data.DI1 == "0"); // TWE DIは負論理だが、チェック状態の時に High出力とみなす
	$("#checkbox1").prop("checked",flag).checkboxradio("refresh");
	flag = ( data.DI2 == "0");
	$("#checkbox2").prop("checked",flag).checkboxradio("refresh");
	flag = ( data.DI3 == "0");
	$("#checkbox3").prop("checked",flag).checkboxradio("refresh");
	flag = ( data.DI4 == "0");
	$("#checkbox4").prop("checked",flag).checkboxradio("refresh");

	if ($("#slider-1").val() != data.AD1) $("#slider-1").val(data.AD1).slider("refresh");
	if ($("#slider-2").val() != data.AD2) $("#slider-2").val(data.AD2).slider("refresh");
	if ($("#slider-3").val() != data.AD3) $("#slider-3").val(data.AD3).slider("refresh");
	if ($("#slider-4").val() != data.AD4) $("#slider-4").val(data.AD4).slider("refresh");
}

// TWE/AD_DI_GETスクリプト実行結果のイベントハンドラ。
function io_get_handler(data){
	if (data.Result != "Success"){
		if(data.ErrorText.match(/CertifyUpdateSession failed/i)) {
			$("#login_password").val("");
			$.mobile.changePage( "#error_quit_dialog", {transition: "pop",role:"dialog"});
		} else {
			$.mobile.changePage( "#error_back_dialog", {transition: "pop",role:"dialog"});
		}
		return;
	}
	apply_ui(data.ResultParams);
}

// デバイスから最新の I/O 値を取得する
function load_device_io(){
	var params = {};
	params["com"] = serial_comport;
	params["id"] = node_id;
	script_exec("TWE/AD_DI_GET",params,"io_get_handler");
}

// スライダーを操作して PWM#<n> ピンの値が更新された
$("body").on("slidestop",".pwm_pin",function(event, ui){
	var params = {};
	var attrVal = getAttrVal(this,"pin");
	if (attrVal != ""){
		params["com"] = serial_comport;
		params["id"] = node_id;
		params["pin"] = attrVal;
		params["value"] = event.target.value;
		script_exec("TWE/PWM_SET",params,"script_exec_callback");
	}
});

// チェックボックスを操作して DO#<n> ピンの値が更新された
$("body").on("change",".do_pin",function(event, ui){
	var params = {};
	var attrVal = getAttrVal(this,"pin");
	if (attrVal != ""){
		params["com"] = serial_comport;
		params["id"] = node_id;
		params["pin"] = attrVal;
		// TWE DOは負論理だが、チェック状態の時に High出力にする
		if (this.checked){
			params["value"] = "0";
		} else {
			params["value"] = "1";
		}
		script_exec("TWE/DO_PIN_SET",params,"script_exec_callback");
	}
});

// 全ての PWM# 更新ボタンを押した
$("#pwm_all_btn").on( "click",function(event, ui){
	var params = {};
	var pwm_val = $("#slider-5").val();
	pwm_val = pwm_val + "," + $("#slider-6").val();
	pwm_val = pwm_val + "," + $("#slider-7").val();
	pwm_val = pwm_val + "," + $("#slider-8").val();
	params["com"] = serial_comport;
	params["id"] = node_id;
	params["value"] = pwm_val;
	script_exec("TWE/PWM_ALL_SET",params,"script_exec_callback");
});

// 全ての DO# 更新ボタンを押した
$("#do_all_btn").on( "click",function(event, ui){
	var params = {};
	var flag = 0;
	if (! $("#checkbox5").is(':checked')){ flag = flag | 0x01; }
	if (! $("#checkbox6").is(':checked')){ flag = flag | 0x02; }
	if (! $("#checkbox7").is(':checked')){ flag = flag | 0x04; }
	if (! $("#checkbox8").is(':checked')){ flag = flag | 0x08; }
	params["com"] = serial_comport;
	params["id"] = node_id;
	params["value"] = flag.toString(16);
	script_exec("TWE/DO_PUT",params,"script_exec_callback");
});

// ページが表示された
$(document).on("pageshow","#twe_control",function(event){
	load_device_io();
});

// リロードボタンが操作された
$("#reloadBtn").on( "click",function(event, ui){
	load_device_io();
});

//////////////////////////////////////
// select_node page
//////////////////////////////////////

// アプリで選択した TWEデバイス NodeID
var node_id = ""

// TWE(子)ノードリストを取得する
function list_node_device(){
	var params = {};
	params["noquote"] = "1";
	params["com"] = serial_comport;
	script_exec("TWE/LIST_JSON",params,"list_node_handler");
}

// ノードデバイスが選択されたらデバイス操作画面に移動する
$(document).on( "click",".node_select", function(event, ui){
	var params = {};
	var attrVal = getAttrVal(this,"device");
	if (attrVal != ""){
		node_id = attrVal;
		// TWEデバイス操作画面に移動する
		$( "#main_title" ).text(serial_comport + " Node#" + node_id);
		$("body").pagecontainer("change","#twe_control", { transition: "none" });
	}
});

// TWE/LIST_JSON スクリプト実行結果のイベントハンドラ。
function list_node_handler(data){
	if (data.Result != "Success"){
		if(data.ErrorText.match(/CertifyUpdateSession failed/i)) {
			$("body").pagecontainer("change","#error_quit_dialog", { transition: "pop",role:"dialog" });
		} else {
			$("body").pagecontainer("change","#error_back_dialog", { transition: "pop",role:"dialog" });
		}
		return;
	}
	// リストビューに ノード番号を表示する
	$("#node_list li").remove();
	for(i in data.ResultParams.DeviceList){
		$('<li data-theme="a"><a data-transition="none" device="' + data.ResultParams.DeviceList[i].ID + '" class="node_select">' +
            "TWE Node#" + data.ResultParams.DeviceList[i].ID + '</a></li>').appendTo($('#node_list'));
	}
	$("#node_list").listview("refresh");
}

// ページが表示された
$(document).on("pageshow","#select_node",function(event){
	list_node_device();
});

// ノード選択画面の Prevボタンが操作された
$("#select_node_prev_btn").on( "click",function(event, ui){
	$("body").pagecontainer("change","#select_device", { transition: "none" });
});

//////////////////////////////////////
// select_device page
//////////////////////////////////////

// アプリで選択したシリアルデバイスの COM ポート名またはタイトル名
var serial_comport = ""

// シリアルデバイスリストを取得する
function list_serial_device(){
	var params = {};
	params["type"] = "TWE";
	params["noquote"] = "1";
	script_exec("SERIAL_DEVICE_LIST",params,"list_serial_handler");
}

// SERIAL_DEVICE_LIST スクリプト実行結果のイベントハンドラ。
function list_serial_handler(data){
	if (data.Result != "Success"){
		if(data.ErrorText.match(/CertifyUpdateSession failed/i)) {
			$("body").pagecontainer("change","#error_quit_dialog", { transition: "pop",role:"dialog" });
		} else {
			$("body").pagecontainer("change","#error_back_dialog", { transition: "pop",role:"dialog" });
		}
		return;
	}
	// リストビューに シリアルデバイス名を表示する
	$("#device_list li").remove();
	for(i in data.ResultParams.DeviceList){
		$('<li data-theme="a"><a data-transition="none" device="' + data.ResultParams.DeviceList[i].COM + '" class="dev_select">' +
            data.ResultParams.DeviceList[i].Title + '</a></li>').appendTo($('#device_list'));
	}
	$("#device_list").listview("refresh");
}

// シリアルデバイスが選択されたらノード選択画面に移動する
$(document).on('click', '.dev_select', function () {
	var params = {};
	var attrVal = getAttrVal(this,"device");
	if (attrVal != ""){
		serial_comport = attrVal;
		$("body").pagecontainer("change","#select_node", { transition: "none" });
	}
});

// ページが表示された
$(document).on("pageshow","#select_device",function(event){
	list_serial_device();
});

//////////////////////////////////////
// login page
//////////////////////////////////////

// サーバー側のログイン処理が成功したときにメイン画面に移動する
function login_callback(data){
	if (data.Result == "Success"){
		session_token = data.SessionToken;
		$("body").pagecontainer("change","#select_device", { transition: "none" });
	} else {
		$("body").pagecontainer("change","#login_error_dialog", { transition: "pop",role:"dialog" });
	}
}

// サーバー側のログアウト処理が完了したらログイン画面に戻る
function logout_callback(data){
	session_token = "";
	$("#login_password").val("");

	$("body").pagecontainer("change","#login", { transition: "pop" });
}

// ログインボタンを押した
$( "#login_btn" ).on( "click", function(event, ui){
	var user = $("#login_name").val();
	var pass = $("#login_password").val();
	login(user,pass,"login_callback");
});

// ログアウトボタンを押した
$( "#logout_ok_btn" ).on( "click", function(event, ui){
	logout("logout_callback");
});

// サーバーエラーのダイアログから復帰する場合はログイン画面に戻る
$( "#server_error_ok_btn" ).on( "click", function(event, ui){
	session_token = "";
	$("body").pagecontainer("change","#login", { transition: "pop" });
});

// ログインページが表示された
$(document).on("pageshow","#login",function(event){
	// セッショントークンが指定されている場合にはユーザー認証を省略する
	if (session_token != ""){
		$("body").pagecontainer("change","#select_device", { transition: "pop" });
	}
});

////////////////////////////////////////////////////////////////
// (オプション機能)
//
// デバイスの I/O 状態が変更された場合に最新のI/O データが配信されるように、
// WebSocket(socket.io) でリレーサーバーに接続する
// この機能を使用する場合には、サーバー側でデバイスからのイベントデータを
// ブラウザに配信する node.js + socket.io で作成されたリレーサーバーを
// 実行して下さい。(node relay_server.jsで実行できます)
//
//
//var socket = io.connect('/',{ port:9090});
var socket = io.connect(':9090');

// リレーサーバーから 'broadcast' タグの付いたメッセージを受信した
socket.on('broadcast', function (data) {
	// 配信されてきたJSON データを取得
	var obj = $.parseJSON(data["message"]);

	// Webアプリで自動更新の対象となるイベントデータを含んでいた場合には、
	// 最新のイベントデータで GUI の状態を更新する
	if((session_token != "") && (obj.COM == serial_comport) && (obj.NodeID == node_id) && (obj.TYPE == "TWE_UPDATE")){
		apply_ui(obj);
	}
});

リアルタイム更新用のリレーサーバーを node.js で作成する

Web アプリを使用するとリモート側の デジタル出力 や PWM をリアルタイムに更新することができますが、デジタル入力と A/D 変換値は “Reload” ボタンを押さないと最新の情報に更新できないのは困ります。

ここでは、WebSocket を利用して子機側でデジタル入力や A/D 変換値が変化したときに、自動的に最新の値に Web アプリの GUI を更新させたいと思います。

この項で紹介する方法は以前の記事で紹介した内容と同じ node.js を使用してリレーサーバーを外部に作成する方法を採っています。リレーサーバーの仕組みや node.js のセットアップ方法については此方の(記事1,記事2) を参照してください。

親機からは、子機側で発生した I/O 変化時のイベントデータがシリアルに出力されていますので、このタイミングでイベントデータを WebSocket に配信します。先に紹介したイベントハンドラ (SERIAL_TWE) 中の

-- リレーサーバーに最新データの配信を依頼する場合には下記のコメントを取り除く
script_exec("RELAY_SERVER_UPLINK","COM,TYPE,NodeID,LQI,Batt,DI1,DI2,DI3,DI4,AD1,AD2,AD3,AD4",g_params["COMPort"] .. ",TWE_UPDATE," .. id .. "," .. val)

の部分で RELAY_SERVER_UPLINK Lua スクリプトに最新のイベントデータを渡しています。このスクリプトは以下の様になっています。

file_id = "RELAY_SERVER_UPLINK"

--[[

●機能概要

リレーサーバーに配信用のデータをアップロードする

●スクリプト中の変数に初期設定が必要な項目

---------------------------------------------------------------------------------
変数名			値		            									値の例
---------------------------------------------------------------------------------
host			リレーサーバーが動作している PC のホスト名				"localhost"
				リレーサーバーは node.js プログラムで起動された
				relay_server.js ファイルで実行されます。

port			リレーサーバーのポート番号								9080

●リクエストパラメータ

---------------------------------------------------------------------------------
キー値			値		            									値の例
---------------------------------------------------------------------------------
<RelayServerParamKey#1>	<RelayServerParamValue#1>				"AD0" "-1"
..
..
<RelayServerParamKey#n>	<RelayServerParamValue#n>

リレーサーバーで配信するメッセージ中に格納するデータ値を任意の数だけ指定できる。
このスクリプトを起動する時に指定した全てのパラメータ(キー値と値)はそのまま
リレーサーバーに渡されて、その後 WebSocketで接続している全てのクライアントに配信される。

●リターンパラメータ

---------------------------------------------------------------------------------
キー値			値		            									値の例
---------------------------------------------------------------------------------

●備考

スクリプト中で実行している tcp_send_recv_data() 関数は、相手側のサーバーがダウン
しているときにネットワークエラー検出までに時間がかかることが想定されます。
このとき、イベントハンドラなど別スレッドで同時にこのスクリプトを続けて起動すると、
スクリプトプールの未使用エントリ数がなくなり、システム全体の動作に影響する可能性
があります。これを防ぐために、スクリプトプールの未使用エントリ数が一定以下になっ
た場合には、このスクリプトの実行をすぐに中止させるようにしています

中止させるためのフラグは abort_key のキー名で設定されたグローバル共有変数を使用
しています。一度このフラグが設定されるとこのスクリプトは直ぐに終了して、ログに
*ABORT* が記録されるようになります。再びこのスクリプトを実行可能にするためには、
DeviceServerを再起動させるか abort_key に設定されたグローバル共有変数を削除して
ください。このとき PERIODIC_TIMER.lua 中に dec_shared_data() 関数を使用すると
簡単に一定期間後にグローバル共有変数を削除することができます。このスクリプトでは
中止フラグの値に "60" を設定していますので、下記のスクリプトをPERIODIC_TIMER.lua 中
に記述すると、60分後に中止フラグが自動的に削除されます。

dec_shared_data("$ABORT_RELAY_SERVER_UPLINK")

●変更履歴

2014/11/8	初版作成

ABS-9000 DeviceServer        copyright(c) All Blue System

]]

local host = "localhost"
local port = 9080

-----------------------------------------------------------------------------------------------------
-- リレーサーバー接続が失敗する場合にスクリプトプールの逼迫を防ぐため、スクリプト実行中止の判断をする
-----------------------------------------------------------------------------------------------------
local abort_key = "$ABORT_" .. file_id
local stat, val = get_shared_data(abort_key)
if val ~= "" then
	log_msg("*ABORT*",file_id)
	return
end
if script_free_count() < 5 then
	if not set_shared_data(abort_key,"60") then error() end
	log_msg("*ABORT SET*",file_id)
	return
end

-----------------------------------------------------------------------------------
-- スクリプトパラメータで渡されたキーと値を JSON 文字列に変換する
-----------------------------------------------------------------------------------
local json_str = '{'
local first = true
for key,val in pairs(g_params) do
	if first then
		first = false
	else
		json_str = json_str .. ","
	end
	json_str = json_str .. string.format('"%s":"%s"',key,val)
end
json_str = json_str .. '}'

------------------------------------------
-- リレーサーバーにメッセージを送信する
------------------------------------------
log_msg(json_str,file_id)
local nstat,rdata = tcp_send_recv_data(host,port,json_str,2,2)

スクリプトパラメータで渡されてきた子機の最新の デジタル入力値、A/D 変換値などを node.js で作成するリレーサーバーにTCP/IP ソケット通信で送信します。送信データは相手側で利用しやすいように予め JSON フォーマットに加工しています。

node.js で作成するリレーサーバー本体(relay_server.js)は以下になります。

//////////////////////////////////////////////////////////////////////////////////////
//
// RelayServer                                             All Blue System
//
// このプログラムではソケット通信(TCP)で受信した文字列データを
// WebSocket(socket.io)に接続している全てのクライアントにブロードキャスト配信します。
//
// プログラムを起動するときは、予め node.js プログラムをインストールしておきます。
// その後、node.js で提供されているパッケージ管理プログラム npm を使用して
// socket.io モジュールをインストールします。
//
// >npm install socket.io
//
// 環境変数 NODE_PATH を node.js をインストールしたフォルダにある node_modules フォルダ名に設定します。
// デフォルトでは NODE_PATH = C:\Program Files\nodejs\node_modules になります。
//
// コマンドプロンプトから node コマンドにスクリプトファイル名をパラメータに指定して RelayServerを起動します。
//
// >node relay_server.js
//
// uplink ポートにメッセージを送信するための DeviceServer側スクリプトは
// C:\Program Files (x86)\AllBlueSystem\Scripts\RELAY_SERVER_UPLINK.lua に
// 格納されています。
//
// downlinkポートからメッセージを受信してWebアプリケーションからブラウザに配信するための
// サンプルは、C:\Program Files (x86)\AllBlueSystem\WebRoot\web_api_sample\twe_control
// フォルダ中の main.js ファイルを参照してください。
//
//////////////////////////////////////////////////////////////////////////////////////

// RelayServer から複数の Webブラウザへデータを配信するためのポート
// 最初にWeb ブラウザ側から WebSocket(socket.io) を使用してコネクションが張られる。
// コネクションが確立した後ブラウザ側は RelayServer から送信される
// ブロードキャストメッセージを受信する。
var downlink_port = 9090;

// 予め socket.io を npm を使用してインストールしておくこと
var downlink = require('socket.io').listen(downlink_port);
//downlink.configure(function(){
//  downlink.set('log level', 1); // socket.io の debug ログを抑止
//});

// DeviceServer からWeb ブラウザに配信するためのデータを受け付けるためのポート
// 通常のソケットサーバー(net)経由で JSON 文字列で記述された配信用データを受信する
// 文字列の終端は \n で判断して、受信後に短い ACK 文字列をDeviceServer 側に送信する。
// この ACK 文字列は、DeviceServer側 API tcd_send_recv_data()が、通信が完了したことを判断する
// ために使用している。
var uplink_port = 9080;

var net = require('net');

var relay_server = net.createServer(function (uplink_stream) {
	var buffer = "";
	var msg = "";

  	uplink_stream.setEncoding("utf8");

	uplink_stream.on("data", function (data) {

		// 配信用データをDeviceServer から受信する
    	if ( data.indexOf('\n') < 0) {
			buffer += data;
    	} else {
			// 配信用データ末尾の空白文字を除去
			msg = buffer + data.substring(0, data.indexOf('\n') );
			msg.replace(/\s+$/g, ""); // trim right

			// DeviceServer に受信完了を知らせる
	    	uplink_stream.write("OK\n"); // sendback an ack
	    	uplink_stream.end();

			// WebSocketで接続中の全ブラウザに対して配信データを送信する
			downlink.sockets.emit('broadcast',{ message: msg });

			console.log('broadcast:' + msg);
		}
	});
});

// 配信用 RelayServer起動
relay_server.listen(uplink_port);

子機からのイベントデータを受信受信するための uplink ポートをTCPソケットサーバーで作成しています。また、Web アプリ側に WebSocket で配信するための downlink ポートを socket.io ライブラリを使用して作成しています。

ここで使用している node.js のインストール方法と、socket.io モジュールの設置方法に関しては此方(記事1,記事2) を参照して下さい。

早速 node.js を使用してリレーサーバーを起動します。

リレーサーバーを記述した JavaScript ファイル(relay_server.js) を node コマンドで起動しています。

リレーサーバーが起動している状態で Web アプリを動作させると、自動的に WebSocket で配信されるメッセージをリレーサーバーから受信するようになります。

子機側のデジタル入力やA/D 値を変化させると、リレーサーバー側には以下の様にログメッセージが表示され、最新のI/O 値がブロードキャストされると同時に、Web アプリ側のデジタル入力のチェックボックスと A/D スライダーの値がリアルタイムに変化するようになります。

Web ソケットで配信された JSON データは Web アプリ(main.js) 内の後半部分に記述したイベントハンドラ部分で受信されて、GUI の更新を行っています。

また、リレーサーバーに子機のイベントデータを送信するためのスクリプト(RELAY_SERVER_UPLINK) の最初の部分で、ソケット通信エラーが発生する場合に備えて、DeviceServer のスクリプトプールの残りを常にチェックするようにしています。

これによって node.js で作成されたリレーサーバーがダウンした場合などに、DeviceServer 側のリソースが一時的に不足するのを防止しています。詳しくは前述の(RELAY_SERVER_UPLINK)スクリプト中のコメントをご覧ください。下記のログ画面は子機からのイベントを受信中にリレーサーバーを強制的に停止させたときの様子です。

ソケット通信を行っている tcp_send_recv_data()関数がエラーを検出するまでの間に、イベントデータが次々に到着している状態です。このとき、マルチスレッドで起動しているイベントハンドラがスクリプトプールの残りが少なくなってきているのを検出して、abort フラグを共有変数に設定しています(*ABORT SET* のログ部分)。

abort フラグが設定されると、それ以降はイベントハンドラは直ぐに終了するようになり、スクリプトプールの逼迫を防いでシステム全体の動作に影響が及ばないようにしています。

考察

TWE-Lite でデフォルトで動作しているファームウエアでは、現在の子機のデジタル出力と PWM 設定値を取得するための方法がありません。このため、Web アプリを操作するときに”望まない出力操作” を行う必要がでてきます。

また、デジタル出力や PWM 設定値を変更した場合にもイベントは送信されませんので、リレーサーバーを使用しても、複数の Web アプリの画面のデジタル出力や PWM スライダーの設定を同期させて最新の状態にすることができません。

サーバー側で擬似的に子機を操作したときのタイミングでイベントデータを出力することもできますが、DeviceServer に接続した親機を経由しないで操作された場合にはやはり検出することができません。

これらを解決するためには、既存のファームエアを一部改造して以下の機能を追加するのが望ましいと思います。

(1) デジタル出力とPWM 設定値を取得するためのコマンドとレスポンスパケットを追加

(2) デジタル出力とPWM 設定変更時に新規のイベントデータを作成するか、または既存のイベントデータ中にこれらの最新の状態を含めるようにする

幸いファームウエアのソースと開発環境は TWE-Lite のホームページで公開されていますので、追加するのも出来そうな気がします?

動作例

Web アプリを操作した時の動画を載せましたのでご覧ください。(音量注意)

ここで紹介した DeviceServer の機能は、ABS-9000 DeviceServer インストールキットをダウンロードして、直ぐに使用することができます。Web API で使用したスクリプトファイルや Webアプリのソースファイルも全て格納されていますので是非お試しください。デモライセンスが添付されていますので直ちに使用可能です。

それではまた。