実際の画面
こんな感じです。健気でかわいいですね。
この会話で実際に我が家のエアコンがついたり消えたりしています。
もくろみ
人間用のインタフェイスを LINE にしたのは、いつも出先から帰り始めるときに帰り始める宣言を LINE でしていたからで、そしてそれをトリガにできれば日常にすんなり入り込ませられることが期待できたからです。
もともと Nature Remo には、『帰り際に出先からエアコンをつけて、家に着くころには家は涼しくなっている』ことの実現を期待していたのですが、プロダクト自体には充分すぎるポテンシャルがあるものの、実際は『出先からエアコンをつける』という操作が存在することそれ自体にぼくの脳が馴染めず、結局、最近のめたくそに暑い家に帰る日々はまったく改善されなかったのでした……。
で、そうすると、つまり『エアコンの操作のために人間に特別な運用が要求される状態』そのものを回避する必要が出てくるわけです。よって、
- 日常的に使う文化が醸成できていないモノをインタフェイスにしても結局忘れるだろう。つまり、Slack や Nature Remo のネイティブアプリケーション、専用の Web インタフェイス、メールなどは、それをトリガとして運用を定めても使わなくなりそうだ
- 位置情報をトリガにした設定は、エリアの設定のよい塩梅を探るのが難しく（遅すぎ・早すぎ、動きすぎ・動かなすぎ）、また、Nature Remo のアプリケーションのバックグラウンド動作が殺されるとそもそも操作がトリガされない（ように見えた）ので、信頼性はそこまで高くない
な感じで、エアコンをつけてほしいタイミングで日常的にしている操作、つまり帰り始める宣言をトリガにするくらいが現実的な落としどころでは、という判断です。
LINE のボットは、ボット側で設定すればグループトークにも参加させられるので、今回の実装であれば、家族のグループに足してしまえばあとは何もしなくても、勝手にボット側から質問してきてくれます。
つくり
LINE@（と Messaging API）と AWS の Lambda（と API Gateway）、Nature Remo の API でできています。Lambda のランタイムは Node.js です。
前述のとおり、インタフェイスが LINE でさえあればバックエンド側の実装はもはや何でもよかったので、このあたりは完全に興味だけで選んでいます。なるべく自分が触ったことがない技術で、なるべくレガシィは避けてイマドキ感のあるアーキテクチャで、ググってあまり事例がたくさん出てこないヤツ……くらいの基準です。
最近のこの手のオートメーションって、同じことを実現するだけでもその手段は本当に山のようにあって、今回も例えば IFTTT の API を使ってもよかったし、Integromat もアリだったし、Heroku でもよかったし、Lambda にしても Python でもよかったし、Node.js でも Promise 使わずコールバック地獄に溺れてもよかったし、とか。ただ、おしごとではなく趣味でやっているわけで、難易度や実装速度、実績や堅牢・安定性よりも、なによりも興味関心の充足に全フリできるように要素を組み合わせたかったのでした。
普段のおしごとはべつに Web やさんでも AWS やさんでもないので、まだ全然ぼくの知らない解はたくさんあるのだろうと思うと、日常的に情報を吸い上げて選択肢を増やしておかないとこの世界は生きていけない感が強いですね。存在すら知らないものは、そもそも使う使わないの選択肢に乗せられないですし。
しかしいざ作り始めると、とにかく動くだけの状態に持っていくのは思っていたよりも本当に相当簡単で、サーバレスアーキテクチャも流行るわけだなあという気持ちです。便利な世の中ですね。触り始めたらおもしろくなってきたので、エアコンの操作を充実させるだけでなく、連携させる家電も増やしていきたいです。
朝起きたらコーヒーが入っている状態にできないかな……。
