前回までで、トイレ側および Azure 側の構成が決まりました。
かなりシンプルな構成なのでスムーズに進むかと思いきや、落とし穴はありました。
EnOcean など無線タイプのセンサーを使用する場合は、特に問題になりやすいポイントと思います。
シリアルポートのボーレート設定が違うと、異なるデータを読み出してしまう
ゲートウェイ PC の USB に接続する受信機はシリアルポートとして認識されますが、ボーレートは57,600固定で設定されています。異なるボーレート設定ではシリアルポートのデータ受信イベントは発火しますが、正しくない電文(センサーから送信されたデータのこと)で拾ってしまいます。
センサーから信号受信時にシリアルポート受信イベントが複数回発火することがある
今回利用するドア開閉センサーから送信される信号は16バイト(人感センサーは21バイト)のバイナリデータです(データサイズはセンサーの種類によって異なります)。
多くの場合、1回のデータ受信イベントで16バイトのバイナリデータ全てを読み出すことが出来ます。しかし、まれに14バイトと2バイトなど2回に分かれてデータ受信イベントが発生する場合があります。そのため特定の受信イベントで取得したデータにはセンサーデータの一部しか入っていないことがあるので、複数のイベントに対応する必要があります。
人感センサーは退室を即時検知できない
赤外線を使用した人感センサーは人の動きを検知して在室・空室の判断を行います。そのため、人の動作を一定期間検知しなかった時点で「空室」の信号を発信します。他の人感センサーも検証しましたが、空室信号の発信までは10分かかるセンサーもあり、その場合は退室してから10分間は使用中のままになってしまいます(空室信号発信までの時間を調整可能なセンサーもあります)。
開発時の机上テストではセンサーと受信機を並べて一連の動作を確認します。センサーに磁石を近づけると複数のブラウザの画面が同時に更新されるのは、なかなか気持ちが良いものです。しかし実環境でテストを行ってみると、ブラウザに開閉状況が反映されないことがしばしば発生してしまいました。
受信機側で無線信号の強度を測ってみると、信号として拾えるか拾えないかのギリギリのラインでした。センサーと受信機の距離や壁の材質の関係で、電波がかなり減衰していると思われます。
そこでゲートウェイ PC を持ってより良く受信できる場所を求め、ウロウロと横の移動をするだけでなく、受信機の高さを変えるために USB 延長ケーブルも使いました。良好な受信場所を見つけるための試行錯誤が、一番のポイントと言っても過言ではありません。
電源やネットワークの確保が難しいという条件で、トイレ IoT システムの構成を組んでみました。IoT のキーワードで語られる世界としては小さなシステムですが、以下のことが分かりました。
適切なセンサーとデータを処理する今回の構成は、トイレに限らずオフィス設備の稼働率の問題を解決する IoT として、身近に感じることが出来るのではないかと思います。
次回予告
