tissuemo / door-watcher

トイレのドアの開閉状況を監視して在室監視を行うソリューション

door-watcher's Issues

本番運用時のアーキテクチャーを考える

他社展開するにあたっていろいろ考えないといけない。

特に、sensorをどこのWi-Fiに接続するのかを決めないとそもそも導入自体が困難なケースが出てくるおそれがある。

[server] DB初期レコードの整理

おそらく初号機稼働の時点では 6FMale のみとなるはずなので、他のトイレは無効状態にしておく必要がある。
トイレ入退室トランザクションも空の状態で始まるように、テスト用のコードをコメントアウトしておく。

[server] 例外捕捉・ログ出し整備

入口と出口、DBに変更を加える箇所でログを出すようにする。
SQL発行している箇所にはSQL文をログに出したい。

エラーで返すときはAPIのレスポンスにメッセージ入れるようにする。
これに伴って、例外処理も整備する必要がある。

センサーの異常検知方法を考える

本番運用するにあたり、センサーの異常をシステム側から自動的に検知できる仕組みを導入したい。

安直ではあるが、一定日数経ってもセンサーデータが送られてこない場合に異常が発生したとみなすようにする？

[sensor] センサー過剰に反応するのを防止したい

open/close のAPI呼び出しは同じトイレIDに対して最小時間制限を設けるようにする。
だいたい5秒あれば十分な気がする。

[front] ダッシュボードのAPIレスポンスを同一画面内でキャッシュするようにする

現状、5秒おきに変更がなくてもローディングスピナーが出てきて気持ち悪いので、
変更がないときはローディングスピナーも要素変更も行わないようにしたい。

ひとつ前のレスポンスJSONを取っておいて、それと差分比較する処理を追加する。

[server] [front] コードリファクタリング

現状まだコードが汚いので整理する。

[front] [server] 入退室ログのグラフの出し方改善

現状は入退室を一括りにして、単位時間あたりのイベントの件数をただグラフに出しているだけ。

欲を言えばフロント側で期間を変更したり、刻み分数を変更したりできるようにしたい。
入退室を分離して出すにはどういう見せ方がよいのやら・・・

Proposal .

Great project i just read trough mostly the sensor side.I saw that you basically using http request. It is a easy simple solution. I would be interesting in your opinion about using mqtt. An example client https://gist.github.com/eLement87/133cddc5bd0472daf5cb35a20bfd811e . with this protocol you can securely post data to your mqtt broker on the server side. Because at this moment if someone start sending http request for the server with the give strings,that would cause a bit of a problem later on.

README書く

front / server / sensor

あと各種ライセンス表記も。