feature/add-sensor-framework

[mute1008]

👏👏👏👏👏👏👏👏👏👏

[macrat]

がっつり汎用的に作るなら、イベント駆動みたいな構造にした方が良いような気がする。

イベントを管理するサーバーに繋いで「ドアが開いた」みたいのを伝えると、他のやつらにも通知してくれる的な。
通知を受け取ったやつがイベントを解釈して、ドアが開いたら音楽を流すみたいな機能を実現する。

[mute1008]

イベント稼働だとイベント受け取った側で解釈ってなるのでアクションが増えるたびにイベント受け取る側での対応が必要になるのでちょっとめんどくさいかなと思いました。
macratさんが想像してるイベント稼働とあってるのかわからないですが。

今の方法だと一つのセンサーにどのアクションが結びついてるのか管理しやすいのでまあこれでもいいかなと思ってます。
サーバーのリソース的にはイベント稼働とかのがいいかもですね。

[mute1008]

上とは全く関係ないんですが、ドアのセンサーでGPIOのピンが0のときはexecute_plugins()とかなってるんですけどよく考えたらドア開いてるときずっと0なのであれだとドア開いてる間ずっと実行が続いちゃいますね。いつか暇なときに直します。

[macrat]

使わないイベントはそのまま捨てるから特に作業はいらないはず、たぶん。

とはいえ確かに、ドアセンサーとサウンドプラグインを紐付ける、的な書き方出来るのは分かりやすくて良いな。IFTTTっぽい。

やたらリソース食うとか同時実行できないとかの制約があるセンサーは別のデーモンで動かして、そことのインターフェースだけsensor/以下に入れればどうとでもなる気がしてきた。
ややこしいけど、問題は無さそう。

[macrat]

あ、でも少なくともプラグインには引数があった方がいい気がする。
ドアが開いたのか閉まったのかとか温度センサーの値とか渡せるようにしておきたい。

[mute1008]

プラグインに引数つけるとフレームワークと密結合してしまう気がしててプラグイン自体は関数として独立しててほしいなというのが僕の考えです。

self.execute_plugins() すれば紐付いたプラグインを一斉に実行する形式をあんまり崩したくないです。

温度センサーとかの値はその時必要になるものなので、できればプラグイン内で取得して使用したいです。引数で渡すようにすると多分温度の取得なんかでstart()メソッド内で処理がブロックしたりでプラグインが増えると、かなり重くなってしまう気がしてます。

[macrat]

オブジェクトを渡す形にすれば、とりあえず一斉実行の問題はクリアできるはず。
密結合にはどうしてもなっちゃう感じがするけれど…。

そうか、スレッドじゃなくてasyncioだからブロックしまくるのか。
通信に時間のかかるセンサー入れたら大変そうだ…。

センサーの値を直に読みにいかないといけないのはちょっと痒いところに手が届かない気がするなぁ…。
温度取得するしデコレーター

[macrat]

すまねぇ、編集中に送った…。

プラグイン側でセンサーの値を読みやすくする仕組みを提供してもいいのかもだけど、pythonにロックインされてしまうし…。

いっそ、reduxライクに値と紐付けられないだろうか。
このセンサーはこの値を操作する。この値が変わったらこのプラグインを呼ぶ。みたいな。