部屋の使用状況をTweetするデバイスを会社の会議室で使ってみた
こんにちは.
以前の記事で,PIRセンサを使って部屋の使用状況を監視し,入退室をTweetするデバイスをラズパイで作製しましたが,それを朝から夜まで会社の会議室に設置したので結果をレビューしてみようと思います.
1. 設置環境
アドイノベーション株式会社の6Fの大会議室「Yama」に設置しました.使用していない時は扉を開けておく運用なので,その時に扉の前を歩く人の動きを拾わないよう,PIRセンサの視界に入口が入らないように設置しました.ただし会議机の大部分はセンサの視界に入るようにしてあります(Fig. 1).
FIg. 1 実際の設置の様子
シェルスクリプトは以前の記事[2]で作製したものをしようしています.一応以下にも記載しておきます.
#!/bin/sh
##GPIOポートの設定
LED=4
PIR=25
##GPIOの値に応じてつぶやく内容を設定
message1="入室しました"
message2="退室しました"
##GPIOのモード設定
gpio -g mode $LED out
gpio -g mode $PIR in
##メインの部分
status1="0"
while true ; do
##センサの値を取得
status2=`gpio -g read $PIR`
##センサが0から1になった場合
if [ $status2 -eq 1 ] ; then
if [ $status1 -eq 0 ] ; then
status1="1"
echo "入室したことをTweetしています..."
gpio -g write $LED 1
ttytter -ssl -status="$message1 `date +%H:%M`"
echo "Tweetしました!"
##センサの値1から1になった場合
elif [ $status1 -eq 1 ] ; then
sleep 10
fi
##センサが1から0になった場合
elif [ $status2 -eq 0 ] ; then
if [ $status1 -eq 1 ] ; then
i=0
while [ $i -ne 30 ] ; do
if [ `gpio -g read $PIR` -eq 0 ] ; then
i=`expr $i + 1`
echo "退室カウント $i /30"
sleep 1
elif [ `gpio -g read $PIR` -eq 1 ] ; then
i=0
fi
done
status1="0"
echo "退室したことをTweetしています..."
gpio -g write $LED 0
ttytter -ssl -status="$message2 `date +%H:%M`"
echo "Tweetしました!"
elif [ $status1 -eq 0 ] ; then
sleep 1
fi
fi
done
回路は以前の記事で作製したものと同じです.実物の写真をFig. 2に示します.
Fig. 2 デバイスの外観
Macでssh接続でバックグラウンドでシェルスクリプトを実行し,午後12:00過ぎから翌日の午前9:30頃まで設置しました.
2. 取得できたデータ
その日取得したツイートの一覧を羅列すると長くなるので,入退室のタイミングをFig. 3に示しました.
Fig. 3 デバイスで感知した入退室状況
Fig. 3で青く色付けしている部分が人が入室していたとデバイスが感知していた時間を示しています.
このなかで,12:00台に非常に短い時間の入室が見られますが,これは私がこのデバイスを設置した際のものです.
15:00からは比較的長い時間入室状態になっているため,会議が行われたのだと考えられます.16:00近辺に退室したり入室したり繰り返しているのが見られますが,これは使用者が入れ替わった際に複数の人の入退室が行われたためです.
16:00台にところどころ退室が完治されていますが,会議が終わって入退室されたのかもしれませんが,通常会議室は1時間単位で予約することが多いため,30分位で会議が終わったとしてもすぐに次の会議が始まるとは考えづらいです.このため, 誤検知の可能性があります.仕組み上入室を誤検知することは少ないですが,退室を誤検知することは部屋の使用者の動きが活発でない場合などは十分に起こりえます.
18:00台から19:00台の短時間の入室は原因不明です.
3. 考察
Fig. 4は当日のサイボウズによる会議室の予約状況をFig. 3と並列したものです.
Fig. 4 サイボウズの予約状況およびデバイスで感知した入退室状況
Fig. 4において,オレンジの範囲がサイボウズで会議室が予約されていた時間帯を表しています.青い範囲はFig. 3と同様です.
これを見ると,おおよそ予約状況と会議室の使用状況は一致していることがわかります.16:00から始まった会議は少し早めに終わったことも読み取れます.
先ほど述べた16:00台の会議の半ばで不可解な入退室が繰り返されていると検知している件に関しては,社外との会議で,その内容を考えても30分で終わるものではなさそうなので,誤検知の可能性が高いと考えられます.
そこで15:00からの会議と16:00からの会議を比較したところ,16:00からの会議のほうが人数が少なかったことがわかりました.このデバイスではセンサの視界でものが動くことを検知して入室と判断し,一定時間動きがない場合に退室と判断するため,人数が少ないとその分動きが発生する可能性が低くなり,退室を誤検知してしまう可能性が高いことがわかりました.
18:00台から19:00台にかけての入室検知は,仕組み上入室の誤検知は考えづらいので,誰かがちょっとした用事で使ったと考えられます.
また,冒頭でこのデバイスの設置時間を12:00すぎから翌日までと書きましたが,19:30頃を最後に入退室を検知していませんでした.翌朝動作を確認したところ,シェルスクリプトは動作していましたが,TwitterへはTweetされていませんでした.また,その際にSSH接続もできなかったため,無線LANへの接続が切れてしまったと考えられます.電源をONにした後,ネットに繋がっていない状態では予め設定している無線LAN設定を順に試してつなげてくれますが,一度つながったあとになんらかの理由でネットワークから切断された場合,再接続はされないようです.
4. 今後の予定
今回わかった問題点は,退室の誤検知と無線ネットワークから切断された際に再接続しないという2点です.
前者は退室と判断するまでの秒数を現在の30秒から伸ばすことで最適化を図ります.後者はwicd-curses[3]というアプリケーションを使用することで解決ができそうなのでそれを調べてみようと思います.
参考文献
[1]PIRセンサデータシート
[2]ものづくりブログ「Raspberry PiでGPIOの値をTweetする方法」(http://daisukekmr.hatenablog.com/entry/2015/02/02/193000)
[3]ITは遊び「RaspberryPiで、無線LANの自動再接続と、有線をさした時は有線でつなぐような設定をする」(http://74th.hateblo.jp/entry/2015/01/10/234910)
変更履歴
2015/2/13 前回の記事へのリンク先が間違っていたので修正