obniz IoTコンテストに参加して、ドアの鍵閉め忘れ検知アプリを作った話
こんにちは遠藤です。
先月までobnizとelchika(エルチカ)を提供するエイミーが共催のobzni Boardを使った電子工作コンテスト「obniz IoTコンテスト」が開催されていました。
こちらに私も応募してみたので、投稿作品のご紹介と所感などを書いてみます。
コンテストへの応募は、電子工作の作品をつくり、その動作が確認できる動画を含む記事を投稿するというもので、最終的に175作品の応募がありました。
なかなか盛況でしたね。応募作品は、上記の特設ページに作品一覧があります。楽しい作品がたくさんあるのでぜひ見てみてください。
また、コンテストで記事を集めていたelchikaは言わば電子工作版のQiitaです。私は今回のコンテストで知りましたが、なかなか良くできています。
まだまだ電子工作もQiitaの方が記事をよく目にしますが今回をきっかけにして投稿が増えていくことを期待したいです。
個人的には、パーツリストを作る際に部品名を入れると秋月電子通商やスイッチサイエンスのページのリンクが簡単に埋められるといったような、電子工作ならではの機能があったらいいなあとか思ったりしてます。
応募作品
では、今回のコンテストで私が投稿した作品についてですが、こちらの「obniz Board 1Yと距離センサー VL53L0X 使用した鍵閉め忘れ通知アプリ 」という記事になります。
家の鍵を締め忘れていたらスマフォに通知するという割とシンプルなシステムです。
まあQrioなど市販のスマートロックでいいんじゃね？と突っ込まれそうですがｗ、サムターンが上下に2つあるドアだったり、形状が特殊でドアに取り付けられない、また、鍵が閉まっているかどうかだけわかれば十分というケースもあるのではと思います。
そこで、サムターンの向きだけ検出して通知できないかなとセンサーを探し、私は距離センサーにたどり着きました。
実際の動きは動画を見てください。
今回のチャレンジとしては、ドアにケーブルを這わせず電池で動かす。実際に使えるようになるべく小型にまとめるあたりを頑張りました。
動画でも確認できますが、以下のように玄関の景観を壊さず設置できたかなと思います。
小さくまとめるにあたっては、パーツの配置に合わせたケースを設計し、なかなか活躍の場がなかった3Dプリンタを使って出力しました。
改めて振り返ると、昨年3Dプリンタを購入してから登場させた記事はこちらのみ。。今回役に立てられてよかった。
また、鍵の状態の表示と締め忘れの通知はPWAとして仕上げています。PWAでPUSH通知を受け取れるのはAndroidのみですが、ホームに追加するとアプリっぽい使用感にできます。
通知先はIFTTTまたはSlcakなどのチャットアプリへの投稿でも良かったのですが、個人的にアプリとして独立させてそれっぽくしたく、PWAでそれは実現できたかなと思います。
実は鍵閉め忘れ検知のアイディアは、175の応募作品の中で他に3つの投稿がありました。鍵の締め忘れってみんな結構気になる課題のようですね。それぞれ目的が同じでも実装方法が異なっていてなかなか興味深く面白いです。
今後の改善
今回のアイディアは、コンテストの限られた期間の中でそこそこまとまったものになったかなとは思っていますが、以下のようなところは改善したいなと思っています。
１つ目は小型化です。コンテストはobniz Board縛りがありましたが、以下を検討することで省スペース化できそうです。
・ もっと小さなマイコンに置き換える
・ スリープ復帰のトリガーを人感センサーではなく距離センサーのみで実装
・ スリープを細かく調整して起動時間を減らし電池も単4にする
2つ目はデザイン、ケースも四角で味気がないのでもう少し見た目に楽しい、またはドアに付けても違和感がないデザインに仕上げたい。
あとは、iOS対応、PWAはPUSH通知に対応しているのはAndroidのみなのでiPhoneユーザでも使えるようにしたいところです。
この辺り構成を変えてコピペテックの記事にするかもしれませんので、お楽しみに！(記事にならないかもですがw)
コンテストに参加してみて
最後に、久しぶりにプログラミングコンテストに参加してみた感想を。
限られた時間と自分の現在の知識と調査力を駆使して最大限のアウトプットを出すという過程がプログラミングコンテストやハッカソンの醍醐味ですが、実はそれだけではなく割と目標とする大会に向けたスポーツのトレーニングにも近い感覚なのではと思いました。
普段の仕事だと瞬間最大的に取り組むと言うよりは平均的に質を高めるような動きをしているので、割と頭は余裕のある状態を保っているような気がします。
年に1,2回はこういった頭の使い方をしておくといざというときの馬力に役立ちそうだし、なにより頭の老化も防止にもなりそうですｗ。
あとは、リアルなイベントには参加できるのは今年いっぱいくらいは無理そうですし、そんななかでの一つの楽しみとしてもとても良かったなと思います。
本編はここまで、以下は蛇足ですが今回の投稿に行き着く過程のようなものを残しておこうかと、興味がある方は引き続きどうぞー。
試行錯誤の過程
3月の終わり頃にニュース記事でobniz IoTコンテストの記事を見て少しずつ準備をしてきたわけですが、コンテストの記事には完成形しか書いてないのでその過程をまとめておきます。
私はハードウェアは完全に趣味なのでアプローチが合っているのかさっぱりわかりませんが、私と同じ用に電子工作レベルでマイコンやセンサーをいじっている人にとっては、今回の作品を完成させるまでの思考の過程は結構役に立つのではないかと思います。
1. センサーは何を使うか？
ドアの鍵の締め忘れ検知を距離センサーでできそうだなというアイディアはもともとあったのですが、なんのセンサーを使うのかというのはそれまでにいくつか案がありました。
1-1. カメラで撮影して機械学習でサムターンの状態を検出する
最初に思いついたのはこれで、自分としては写真をたくさん撮って学習させるのが想像しただけでも大変なのでやる気が出なかったのですが、今回のコンテストでもこのアイディアを実装している作品があります。いやあほんとすごいです。
1-2. 加速度センサーの傾きで状態を検出する
加速度センサーは、MPU-6050搭載の小型のモジュールがあるので、サムターンにアタッチするようなパーツを3Dプリンタで作ってみるというのも良さそうだったのですが、サムターンからコードで出ていると回しにくくなったりと難がありそうで、こちらはボツに。
1-3. 距離センサーで計測した距離で状態を判定する
きっかけは覚えていませんが、物理的なものをサムターンに取り付ける必要がなく、あれ簡単じゃね？とふと思いついて、とりあえずM5Stick-C用のToF Hatを買ってきて検証したところ使えそうだなとなって距離センサーを利用する案に決めました。
obnizがパーツライブラリを提供している距離センサーはGP2Y0A21YK0F、HC-SR04、VL53L0Xの3つあります(他の2つは派生です)。
今回は、小型のモジュールが用意できるVL53L0Xを使うことにしました。こちらはM5Stick-C用のToF Hatに内蔵されている距離センサーでもあります。
2. ドアにどうやって固定するのか？
今回、もっとも難しいのは実はこれな気がして、ToC Hatと同じく最初に検証した課題になります。
で何で解決したかと言うとコクヨの「ひっつき虫」を使いました。
こいつはなかなか優秀で接着力がありながらきれいに剥がれます。
検証は、パーツの中で単3電池 x 3本を入れた電池ボックスが一番重いので、それをしばらくひっつき虫で壁に付けておいて落ちないことが確認できた時点で、コンテストの参加フォームの入力をはじめました。
3. 単3電池か単4電池か？
記事中でも軽く触れていますが、今回は単3電池でobnizを駆動しています。
obniz Board 1Yの動作電圧は推奨 5v (3.3-5.5v)ですので、乾電池ですと1.5v x 3本 = 4.5vで動かします。
電池の容量は、単3電池だと2000mAh、単4電池だと大容量でもその半分になります。
2000mAhの電池で、obniz Board 1Yは、2分間/日の起動で1年持つとドキュメントに記載されていますが、今回のアプリの動作時間は5分/日とするとobnizだけでおおよそ5ヶ月、実際には低商品電力ながらも人感センサーが常時動いているので、4ヶ月から5ヶ月の間くらい持つ計算になります。
と考えると、半分でも2ヶ月ほど持つので単4電池仕様にして小型化を優先させても良かった気もします。
あとは候補としては、リチウムイオン電池ですが扱ったことがなく充電の取り回しも面倒そうなので今回は対象から外しています。
4. ブレッドボードがやっぱり必要だがスペースの問題も
人感センサーがなければ、obniz Board、距離センサー、電池ボックスのみなので空中配線でなんとか行けそうだったのですが、人感センサーも必要となると電源周りをどう配線するかが悩みどころでした。
ユニバーサル基板にはんだ付けとかすると再現が難しくなるのでブレッドボードを使いたいけど、ブレッドボードを入れると小型化できなくなるというジレンマが。
で、たまたまコロナ過の中、一度だけ都心に行く機会があったので、秋月電子通商にふらっと寄ることに。そこで、このとても小さなブレッドボードを見つけて、おおこれは！と採用することにしました。
なんだかんだとお店をフラフラするのは、新しい出会いがあって良いものだなと。
このブレッドボードをケースに収める工夫については本編の記事に書いてあるのでそちらをご覧ください。
5. 距離センサーが上手く動かない。。
概ね構成も決まりプログラムを書き始めたわけですが、距離センサーはVL53L0Xのobnizのパーツライブラリを試したところ、シンプルなアプリでは問題なく動くのに、Firebase functionsで実行すると計測エラーが結構な頻度で発生することがわかりました。
また、計測ができなかった場合はプログラム的にエラーを返してくれればよいのですが、なぜか計測値「20」が返されます。パーツライブラリの中をデバッグしてみましたがI2Cのreadした値が「20」なので、これ以上追うのを難しそうだなと判断して、「20」の場合は処理をスキップするようにしました。
このあたりは、obnizはとても便利な半面、問題が発生した場合にjsライブラリ側をデバッグしたり、obniz Cloudの動きを想像する必要があるので、逆に難しくなってしまう場面も多々ある気がします。
6. obniz Cloudのサーバーレスイベントが起動されない。。
当初はobnizを使用するならせっかくなので距離の計測はサーバーレスイベントのみで行う予定でした。しかし、今回使用した人感センサーのように、信号が連続して発生するような入力の場合はサーバーレスイベントでスリープ後すぐに起動し、その時はサーバーレスイベントが呼ばれないということがわかりました。
ESP32で直にIOトリガーでスリープするケースでは、復帰してから再びスリープに入る間に数秒delayを入れることで回避できます。とするとobnizOSプラグインなら問題解決しそう。
とはいえ、人感センサーの入力でスリープから復帰するってのがそもそも筋が悪いのかもしれないです。
7. Firebase functionsからobnizの接続ができない。。
node.jsのプロセスを常時起動するサーバーは用意したくないので、今回obniz CloudとのやりとりはFirebase functionsで実装しています。
ただ、サーバーレスな環境では、obniz Cloudとの接続をきちんと閉じてあげないと、デバイスとの接続数がすぐにオーバーフローしてしまします。
コンテストの記事でも触れていますが投稿間近に結構ハマってしまいました。
このことは、公式ドキュメント「AWS LambdaとAPI Gatewayを使う」の中にもちゃんと記載されています。ドキュメントはきちんと目を通すべきですね。。
しかし、今回、実装してみてわかったことですが、スリープ機能を利用してobnizを間欠駆動させつつ、サーバーレスなプロセスからのobniz Cloudへの接続という組み合わせはデバイスのアイドル時間が長くなり無駄な電力消費が発生してしましす。とはいえ、常時サーバーを起動しておくのも管理が大変でやりたくありません。
obnizを使った常時利用を前提としたアプリケーションのシステム構成のベストプラクティスはどうするのが良いのかは今だ悩みどころです。
以上、こんな感じでかなり試行錯誤しています。時間の無い中よく形になったなと振り返ると思います。
この記事が気に入ったらサポートをしてみませんか？