【Meetupレポ】Nature Bath vol.9【エンジニア向け】両社開発陣が語る！Qrio Lock×Nature Remo連携の裏側
What's Nature Bath ?
「Nature Bath」とは、毎回様々なゲストをお呼びして各回のトピックについて語り合うMeetupです。カジュアルな雰囲気でインタラクティブに参加者のみなさまと親交を深められるような会にしたいと思っています。森林浴（Forest Bath）からとった「Nature Bath」はMeetupを通して、Natureについても少しでも理解を深めてもらえればという思いで命名しました。
私たちの生活に溶け込んでいるIoT。開発に必要な技術は非常に多岐に渡っており、難くも、面白い分野です。第9回目となる今回のNature Bathは、スマートロックのQrio開発陣をゲストにお迎えし、本日発表した、Qrio LockとNature Remoの連携における開発の裏側や、IoT開発における苦労エピソードなどを交えてお話ししました。
『Nature Remo 3とQrio Lock連携の裏側』
Qrio株式会社 モバイルアプリ/FWエンジニア 竹内 創太朗
2014年よりAndroidエンジニアとして活動。2018年Qrio入社。
入社後は、IoTデバイスのFW開発、リードエンジニアを主に担当。
竹内さん：Nature Remo 3とQrio Lock連携の裏側ということで、工夫したことや大変だったことを可能な限りお話しします。IoT開発はまだ狭い世界ではありますが、自社だけでは完結しないサービスを作るというのは面白く、少しでも今回の勉強会を通してIoTに興味を持っていただけるようでしたら嬉しいです。
今回の連携は、Qrioのデバイスを操作するための情報を共有してNatureに利用してもらうという方法を取りました。Qrio APIの仕組みですが、Qrio Lockの通信インターフェースはBLEしか搭載していないので、Qrio Lockをインターネット経由で操作する場合はQrio Hubと接続する必要があります。弊社のAPI連携は、連携する他社さんがQrio APIにQrio Lockを操作するリクエストを送り、Qrio Hub経由でQrio Lockを操作するという流れになっています。Qrio LockのステータスはQrio Hub経由でQrioのサーバーにPOSTされ、Qrio APIから他社さんはPOSTされたステータスを得ることができます。そのため、他社さんがQrioのBLE通信プロトコルに依存しているということはありません。
今回のNatureとの連携の仕組みは、Nature RemoがQrio Hubの代わりにQrio Lockと直接通信して、操作するという形をとっています。そのためNature RemoはQrio Lockのプロトコルを知っています。この部分が今回の連携の肝になります。Nature Remoのように、Qrioのプロダクト・サービスでなくても解施錠(鍵の開け閉め)はできますが、もちろん誰でもQrio Lockを開けられるようにはなっておらず、認証・認可に関してはQrio側が管理しています。解施錠のコマンドやログ取得も同様にQrioが認めたクライアントのみ利用できるようになっています。
Nature Remo側ではQrio APIコマンドを作成、それをQrio Lockに送信します。Qrio LockにBLEで情報を送信するために、Nature RemoがQrio LockのADVパケットをスキャンしてパースしたり、BLEのServiceやCharacteristicにリクエストを投げることになります。API以外では主に、開示しているのはQrio LockとBLEでどのように連携するかの方法であって、認証や認可の方法は開示していません。また、Qrio Lockそのものの知見が必要で、連携先での運用コストが高い、物理的な設定が必要な操作については、Qrio APIがありません。
連携開発において難しいポイントは、そもそもQrio Hubの移植ができるのか。特にファームウェアの改修について、使っているモジュールやSDKによってはOSSライブラリを簡単に入れられないことや、同じモジュールでもSDKのインターフェースや実装シーケンスが違ったりします。特に実装の方法についてはiOSとAndroidの比じゃないほど異なることもありますね(笑)。もちろん各社BLEの規格に基づいた実装にはなっているので、そういったインターフェースは各々のSDKの仕様に任されているということになります。また、早期のフィジビリティ検証も必要です。その中で工夫したことは、SDKに依存している層を一旦インフラ層として切ってQrio Lockのコマンドシーケンスを極力抽象化して、実装サンプルを提供したことです。Qrio Hubは二つのQrio Lockの操作ができますが、2台同時操作のためのBLEの非同期イベントハンドリングを、シングルスレッドでできるように、過去私が頑張ってリファクタしました(笑)。このような工夫が、IoTのベストプラクティスかは分かりませんが、今回の連携でそれが実際にお役に立てていたかは後ほどNatureに聞かせてもらいたいです(笑)。
もう一つは、ファームウェアアップデートによる後方互換性の影響です。ものにもよりますが基本的にファームウェアは一度出したら終わりということが多いです。デバイスそのものの管理は連携先ではなくQrioの管轄だと考えているので、ファームウェアの更新もQrio側が管理する形になります。連携先でシームレスにできればいいのですが、どうしてもそのような分担があるのでユーザーに一定の負荷があります。Qrio Lockはインターネットに繋がっていないのでQrioのアプリでしかアップデートできないところは難しいところで、これからの課題です。その辺りも今後いいスキームができたらと思っています。
IoT連携に関しては、このような難しさもありますが、サービスだけでなくエンジニアリングの文化もみんなで一緒に作って行けたら面白いと思っていますので、ぜひ私たちと一緒に作っていきませんか？これが今日いちばん言いたかったことです(笑)。
Qrio Lock × Nature Remo 3 連携開発の現場
Nature株式会社 ソフトウェアエンジニア 的場 一将
金沢大学卒業後、アイシン精機に入社し自動車のパワースライドドア開発に従事。その後Web業界を志しNatureに入社。Natureではファームウェアを担当。
的場：最初に開発の概要を話したいと思います。今回の開発は竹内さんからもお話があったように共同開発とは異なり、QrioのAPIを利用して、Remo 3に便利な機能を追加する開発の仕方をさせていただきました。そのため、APIドキュメントなどを開示していただいて、Natureのみで機能開発を行いました。8月からの実現性の検証や仕様の検討をファームウェアエンジニア1名でスタート。その後、10月から本格的に実装を始め、11月末にリリースという開発スケジュールでした。ですので実装期間は実質二ヶ月くらいです。今回の連携開発では、RemoアプリからリモートでQrio Lockを操作することと、Qrio Lockの解施錠の状態をリモートでわかるようにすること、また、操作があれば通知が来るようにするということを目標に開発を進めました。
次に連携仕様について概要を説明します。Qrio Lockのアプリを操作するときはスマートフォンとQrio LockがBLE通信をします。一方でNature Remoのアプリから操作するときはネットワークを経由して、最終的にNature RemoとQrio LockでBLE通信するという違いがあります。
次にリモートで通知を受け取る際の流れを説明します。連携をしても通知はQrio側のアプリにくるようになっています。RemoがQrio Lockのステータスを監視し、BLE通信により変化を検出したらNatureサーバーに伝えます。そしてその通知を契機にQrio APIを叩いて、より詳細なログを読み出すためのコマンドを発行してもらいます。その後は先ほどのリモート操作の流れと同じようにQrio Lockにコマンドを送信します。このコマンドに対してQrio Lockが解施錠履歴のログを返してくれるので、これをまたNatureサーバーまで返します。Natureサーバーはこのレスポンスをログ登録用のQrio APIでPOSTします。Nature側の処理はここまでで、この先の通知が実際に届くまではQrio側の仕組み乗っかる形になります。このため、Nature Remoと連携しても最終的な通知はQrioアプリに届くと言う少しユニークな動作になります。
次に今回の連携開発で試行錯誤した「実現性の検証」についてお話しさせていただきます。今回の連携において、Remo 3とQrio Lockを設置する位置によってはBLE通信ができないと言う懸念があったため、自分1人で開発前に実現性の検証を実施しました。検証にあたっては、最小限の工数で実施するためにラズベリーパイを活用しました。ラズベリーパイは、ARMプロセッサを内蔵したシングルボードコンピュータで、簡単にいうと手のひらサイズのLinuxマシンです。持ち運びが楽なのでこれをRemo3, Qrio Lockと合わせて検証キットとすることで、各社員の家庭で検証を行うことができました。
検証キットはラズベリーパイ、カスタムRemo3、Qrio Lockの3つで構成されます。ラスベリーパイには、BLE関係のデーモン、各APIを叩くスクリプト、Remo3のログ収集・アップデート用デーモンを実装し、カスタムRemo3にはQrio LockとのBLE通信機能を実装してあります。
検証のための操作はエンジニア以外の社員でも簡単にできるようにするため、検証用Webページを作成し、ブラウザから実施できるようにしました。ここではWeb Bluetooth APIやGCPのGAE, IAPを活用しています。
検証の流れとしては検証用Webページから解錠ボタンを押すと、各自のPCからBLEでラスベリーパイにリクエストが送信され、ラズベリーパイは操作に応じてQrio APIでコマンドを取ってきて、Natureサーバーを経由してカスタムRemo3にコマンドを渡します。この後Remo3とQrio LockでBLE通信が行われるため、ここでQrio Lockが動くか動かないかでBLE通信可否の判断ができます。ここまでの検証を何名かの社員の家庭で実施した結果、通常の広さの家庭であればリビングと玄関くらいの距離でもBLE通信が可能であることがわかりました。ラズベリーパイの活用により、アプリとサーバーに機能を追加することなく良いスピード感で検証ができました。
まとめとなりますが、IoTデバイス連携は登場人物が多く一見複雑そうですが、流れを一つ一つ追っていくと、ほとんどがありふれた技術で成り立っていることが伝われば幸いです。今回の開発としてはバックエンドのタスクが多くなりがちで、うまく足並みを揃えて開発していくのが難しかったです。開発ラインが多くなりがちなIoT開発ではタスクが偏りやすいのかもしれません。開発を進めるうちに手元でQrio Lockが動くようになるわけですが、物理的なモノを動かすのは改めて楽しいなと思いました。IoT開発は楽しいのでぜひ皆さんも取り組んでみてください。
Talk session
ここからは、Qrio株式会社よりバックエンドエンジニア 河本 純一さん、Nature株式会社よりソフトウェアエンジニア 亀田 京介も交えて、ご参加いただいた皆様からの疑問や質問にお答えするトークセッション行いましたので、その一部をご紹介します。
Q.IoT開発の特徴や違いは？
・Web開発から見ると？
・組み込み開発から見ると？
・アプリ開発から見ると？
竹内さん：開発の進め方が全然違うなと思いました。デバイスだと1年で計画を引いてウォーターフォールで最初に仕様をガチガチに決めてからやりますが、プロジェクトの進め方も文化も異なります。デバイス側から見るとWebでアーキがどうこうと言う話はないですし、Webから見るとデバイスが工場の生産のためにどうこうなどといったことはあまりないですね。アプリで言うと、実装面ではデバイスのバイナリー操作に絡んだりするので、lowなところの操作をしないといけないところやその辺をモデルにどのように落とし込んでいくかなどはかなり大きい特徴かなと思います。
河本さん：デバイスが絡むので、そもそもデバイスの制限がある上でサービスを作ることが非常に難易度が高いと思いました。Webだけで完結できない部分もあるので融通が効かないところがあることが特徴だと感じます。
亀田：iOS,Androidアプリを開発していた自分からすると、IoTデバイスはパワー不足だなと感じます。アプリは複数のことを同時にできるんですが、IoTのデバイスだと一緒に動かすとよくないことがあったりして、苦労させられることがあります。ただ、僕たちが作っているRemo 3はファームウェアアップデートの仕組みを力入れて作っているので、意外とどんどん機能を更新していけるんだなと言う驚きもありますね。
的場：すでに話に出ているように、組み込みは、アプリやサーバーと比べて圧倒的にデバイスのハードウェアリソースが貧弱なので、常にメモリに気を使いながら開発しています。デバイス側で小メモリな設計ができるようにサーバー側で調整する必要があるのは、普通のWeb開発とは違うところだと思います。あとは、IoT開発は、物理空間に価値を提供できると言うのが一番の違いだと思うのですが、逆に言えば危ないところもあります。制御を誤ると人に怪我をさせてしまうこともあるので、開発を行う心持ちみたいなところは違うと思います。
Q.IoT開発の魅力や今後の展開について教えてください
・IoT開発のおもしろさ
・今後の展望や野望
・IoTの未来
亀田：もともとWeb系エンジニアでしたので、実際に目の前のものが動くというのはとても面白いです。僕たちの製品はスマートリモコンなので、ユーザーさんの家庭でテレビやエアコンが動くのですが、Qrioさんのように自分で作った製品そのものが目の前で物理的に動くというのはさらに面白いなと思いました。IoTの未来は、IoTが当たり前な世の中になりなんでもお互いに連携し合うようになると思っています。
竹内さん：制約が多い中でどうアイデア出して設計していくかということが楽しいです。未来に関していうとこれは完全な個人的な意見ですが、建築がやろうとしていることをより早くできるのではないかなと思っています。建物を立てるというのはコストがかかり、スピードが遅いですが、ソフト面は早く変えていくことができると思います。ITによって住まい方は変わっていくと思いますが、スマートというところが最終的に建築と絡んでいったら面白いなと思います。
的場：制約があるなかでやっていくのは面白くて、職人気質な人はあっていると思います。あとは物理的な空間に価値を与えられるというのは、より直接的に人間に対してアクションができるので面白いです。未来では、IoTは当たり前になって、生活インフラにもな使われていくと思います。僕の中でIoTを使った何かしらの生活インフラを作るというという個人的な野望もありますね。
河本さん：総じて、人の生活をよくすることができるというのはIoTならではの面白さだと思っています。未来では色々な機器との連携が進み、Qrioとしても色々な機器との連携をして、人々により良い生活を提供できればと思っています。