PrivateCA（オレオレ認証局）の作成

webサーバーにするMac miniではなく、手元のMacBookProの方で作業をします。
同じマシンでもいいのですが、念のためCAは別マシンでやっています。
OS Xにはopensslが入っているので自己認証局は簡単です。

作業directoryを掘って移動します。

# /System/Library/OpenSSL/misc/CA.sh -newca

を実行し、CA用のpass phraseを２度入力します。
countryName,stateOrProvinceName,LocalNameはJP,Tokyo,など適当に。
OrganizationNameはhogehoge PrivateCA
Organization Unit Nameはhoge
Common Nameもhogehoge PrivateCA
Email Addrは自分のアドレス
extraの方は空欄で構いません。
もう一度pass phraseを聞かれるので先ほどのpass phraseを入力します。
demoCA/の下にcacert.pemが出来上がります。

次に、

# openssl x509 -in cacert.pem -outform der -out cacert.der

を実行し、PrivateCAの認証局証明書を作成します。
demoCAの下にcacert.derが出来上がります。
あとで、クライアント証明書と一緒にアクセスする端末に配ります。

Web経由の外からの制御

色々とやり方を検討してみたのですが、今のところ一番安く（追加費用が無料）上がるのでXBeeの制御をさせているMac miniにapacheを立ててDynamic DNSで外に見せることにしました。
ただ、単純に外に開放すると色々と危ないのでセキュリティを厳しくしなくてはなりません。
ちょっと面倒臭いですが、自己認証CA（いわゆるオレオレ認証）を立てて、サーバー認証と操作する端末ごとにクライアント認証をかけることでセキュリティを確保します。
今回の使い方では、アクセスしてきた端末の正当性が確保できて、落としたりした時にrevokeできればよいので十分かと思います。
色々とハマりましたが、ひと通り動くようになったので順次やったことを書いていきます。

温度センサーが増えました

エアコンのコントロールモジュールに温度センサーを入れ、温度センサーをエアコン本体の温度センサー付近に取り付けました。

エアコンは１８°Cの設定で暖房を使用していますが、グラフをみるとonしている期間がよく分かります。
西側のエアコンはちゃんと１８°C付近になるように一生懸命制御していますね。
南側のエアコンは人がいる辺りは暖まっても暖房し続けているのでoffしまうことが多いのですが、窓のすぐ下にあるせいか冷気が降りてきて温度センサーの温度が低めに出ているようです。

XBeeの入力トリガー機能の対応

XBeeのモジュールはデジタル入力の状態変化を検知して通知してくる機能があります。
この機能を使って、状態変化に応じてコマンドを実行できる機能を追加しました。

設定ファイルに下記のような記述を追加しています。


sensor:
#wait_port                     event   command
north_window_stat       open    aircon_off
south_window_stat       open    aircon_off
aircon_south_stat          on       window_close
aircon_west_stat           on       window_close

北側、南側の窓がclose->openに変化したらエアコンをoffにする

南側、西側のエアコンがoff->onに変化したら窓を閉める

という事を自動でするようにしました。

エアコンにも取り付けました

寒くなってきたので、エアコンも制御できるようにモジュールを取り付けました。

ついでに、エアコン付近の温度も計測できるように温度センサーも付けておきました。
写真のオレンジ色のものが温度センサーです。

ZigBeeと電子レンジ

XBeeのシステムを組んで２週間くらい様子を見ていますが、定期的にZigBeeネットワークが通信できない状態が観測されています。

傾向的に朝の6時～８時くらいと、夕方の４時～７時くらいに何度かエラー４(Remote Command Transmission Failed)が連続して発生します。

Retry動作を連続しても暫くは復帰しないのでどんどんQueueに溜まっておかしな状態になっていきます。電子レンジかと思っているのですが、使っていない時にも発生しています。

もしかすると近所の家の電子レンジからも影響を受けてるのかもしれません。

Retry動作を少し間を開けながら実行するように変更し、コマンドを投げて応答待ちしている場合は、応答が帰ってくるかTimeoutするまでは次を投げないようにして様子をみています。

ここ３日くらいは、たまにエラー４が発生していますが、連続してはっせいしてQueueに溜まってしまっているような状況にはならなくなりました。

もう暫く様子をみて問題無さそうならこのQueue管理の仕方で行こうかと思います。

pselectの罠

XBeeからの通信とsocketからのコマンド通信、iRemoconとの通信の応答、アメッシュ監視processからの通信を待つためにpselectを使用していたのですが、OSXはrace conditonがあるようではまってしまいました。

たまに時間指定で開くはずのシャッターが開かなかったりしていたので、仕込みを入れて追っていたのですがようやく原因にたどり着きました。

pselectの通信待ちの間にtimer eventを受けるためにsetitimerでSIGALRM通知を受けているのですが、タイミングによってはpselectから戻って来ません。

仕込みを入れてみるとsigactionで設定しているhandlerには飛んでいるのですが、pselectがblockしたままになっているケースがありました。

pselectがatomicにできていないようで、SIGALRMを受けるタイミングがうまく合ってしまうと判別できないことがあるようです。

ネットで検索してみるとよく知られている現象のようで、selfpipeでhandlerからselectの監視portにnonblock ioでwriteすることで通知することで回避できるようです。

直したところ取りこぼすことがなくなりました。

Raspberry Pi

サーバーに使っているMacMiniを置き換えるためにRSコンポーネンツでRaspberry Piを注文してみました。

ケース込みで$49.49です。電源はiPhone用のACアダプタを別途用意しようと思います。

(Wikipediaより)

5week待ちですが一時期の20week待ちとかに比べると供給が安定してきてますね。

アメッシュからの雨指数

アメッシュのgifデータから計算した雨指数のグラフを取りました。

スケールを合わせるために雨センサーの値は1/2にアメッシュの雨指数は1/4にしてグラフに表示しています。

だいたい、昨晩の雨の傾向が出ているかと思います。
雨センサーの値は日射がないと雨が上がっても高いままですが、屋外南と屋外北の温度センサーの差分で日射があるのかどうかがわかるのでうまく判断できそうです。

アメッシュの値は、雨の量と距離を係数に値を出していますが、リニアに反映してしまうと値のブレが大きすぎるので雨レベルの累乗と距離の累乗から計算した値をうまく感覚的にリニアに感じる値になるように平方根をとって調整しています。

これらの値を使って指定された値を超えると窓を閉めるようにプログラムを変更しました。

雨センサー修理

先日異常値を示していた屋外南面の気温センサーを修理しました。

緑色の線です。ちゃんと普通の値を示すようになりました。

原因はセンサー部分の半田付けをした時に基板のB面のVccの線が外れてしまっていたようです。

温度が高くなると膨張して接触不良を起こしていたようです。

今朝から丁度雨が降っていて雨センサーとアメッシュから計算している雨指数の値の調整ができそうです。

雨センサーの値は乾燥時で6。雨で濡れている状態で50~60を示しています。

これはこんなものでしょう。

アメッシュから計算している雨指数ですが、こちらは要調整ですね。

オレンジ色の線なのですが、値が0~4000位を暴れています。

gifファイルの色から雨の強度をだして、自宅の位置からの距離を係数にして半径５ｋｍ以内を重み付けしながら計算していますが、もう少し計算式を試行錯誤する必要がありそうです。

弱い雨でも近い場合はある程度値が出てくれないと判断できないし、遠くで強い雨が発生しているときはやはりある程度の値になるようにバランスをとらないと実用になりません。 

計算式を変更して今晩一晩、様子を見てみます。