■電源監視デバイスができたので、そうなるとやはり継続的な監視をやってみたい。すでに試行は始めているけど、ZigBeeの通信が思った以上に不安定なのがネックになっている。特に電源監視デバイスはまだバラックということもあって、床置きになっているのも不利なようだ。不利な条件はもう一つあって、アドホックに起きるリモコン操作の通信が割り込むのもあまりよくない。電源監視とリモコン操作の要求元になるプロセスが別物なのに、通信先のXBeeは１つしかないわけで、その送受信がごちゃごちゃになってしまう。こうなってくるとお気楽に書き流してもいられなくて、ちゃんとメッセージングを考えないといけない。キューイングが必要だ。
PHPはOSが持つプロセス間通信用のメッセージングや排他制御を利用できる関数がある。プロセス制御→セマフォにあるセマフォ関数として分類されているのがそれで、今回使ったのはそのうち'msg_'ではじまるメッセージキュー関係の関数。
プログラムの構成は単純なサーバー・クライアントモデルで、サーバーはメッセージキューとXBeeの仲立ちをする。XBeeの各デバイスは全てコール-レスポンス構造を持っていて、送信メッセージに対し必ず応答があることを期待して良いから、サーバーはクライアントから受け取ったメッセージをXBeeに送り、XBeeからの応答を要求元のクライアントだけにリレーする。このサーバーとXBeeとの送受信はペアにできて、その間サーバーは他のクライアントからの要求を受け取れず、クライアントは待つことになるから、そこで排他制御がかかることになる。
クライアント側では今まで実装していたXBeeとのやりとりに使っていたクラスのメソッドをほぼそのままにして、中身をttyとのダイレクトIOではなく、サーバーとのメッセージング機構に置き換える。つまり、ラッパー関数にする。
サーバーとクライアントは別々に動いていて、メッセージの読み書きのタイミングはもちろん同期されていない。なので、メッセージの識別は送信先ごとにユニークになるようmessageTypeを設定した。サーバーはmessageTypeを1にして、クライアントは自身のプロセスIDを使った。こうしないと、タイミングによって書き込んだ側が先に読み出してしまう可能性が高い。問題はクライアントが自身のmessageTypeをサーバーに伝える必要があることで、このために、クライアントはメッセージの先頭７バイトにmessageTypeを埋め込んでいる。逆にサーバー側は自身のmessageTypeがクライアント側に自明となっているのでmessageTypeの埋め込みはしていない。
長時間使っていると、XBeeの比較的不安定な通信に起因するエラーがちょくちょく発生するから、そこでデバイスやサーバー側のプログラムがスタックしないようにそのたびに手直ししています。今の実装もたぶん仮のもので、安定や利便性のためにまだまだ手直しは続く気がしています。
