masato-ka's diary

日々思ったこととか、やったことの備忘録。

IoT・AIなデバイスを開発するのにAndroid Thingsが控えめに言って最高だった話

更新

2019年2月12日付けで以下のアナウンスがありました。内容としてはAndroidThingsはスマートディスプレイ向けに再フォーカスするとの内容です。一応当面はRaspberry Pi3Bは利用できるとのことでしたが、非商用での利用です。 2019年以降はCloud IoT CoreやCloud IoT Edgeを利用してくださいとのことです。

https://android-developers.googleblog.com/2019/02/an-update-on-android-things.html?m=1

この記事について

 この記事ではAndroid Thingsを触ってみた感想をつらつらと記載している。あくまで個人的な感想を記載してあり、異論は多々あるだろう。しかし控えめに言ってAndroid Thingsは最高だった。1ヶ月ほど遊んでみてこれは面白いことができそうという感想しか出てこない。現在、IoTデバイスのトレンドはAIをはじめとするエッジヘビーな処理、デバイス管理、セキュリティなど求められるものが多くなっている。そしてAndroid Thingsはいとも簡単にこれらの要件を叶えてくれる。ちなみにAzure IoT EdgeとかAmazon Free RTOSなんかはこれから触りたい候補に入っているので「それ['Azure IoT Edge' | 'Amazon Free RTOS']でもできるよ」という話は知りたいし、たくさん突っ込んでほしい。

1. なぜAndroid Thingsなのか?

 2018年5月にGAから1.0.0正式リリースになったのを機にAndroid Thigs使ってみるかという機運になった。またGCPのCloud IoT Coreとかその辺りを触っていて、エッジ側のOSとかの使い勝手も知りたくなり手を出してみた。最初は軽い遊びのつもりだったけど本気になってしまった。反省はしていない。

2. Android Thingsプロフィール

まずはAndorid Thingsのプロフィールについて見ていこう。

2.2. Android Things

 大雑把に説明するとAndroid ThingsはAndroid Oから派生して作られている。Android のCore framework APIにI/Oなどを直接コントロールできるようにしたThings APIを追加したものになる。これ以外にAndroidとは以下のポイントが違う。

  1. 設定などを行うシステムアプリがないこと
  2. 1つのアプリケーションしか実行できない
  3. 起動時にアプリケーションが自動的に立ち上がる

こうすることでにAndroid Thingsは組み込みアプリケーションを実行するプラットフォームとして最適化されている。AndroidスマホをIoTデバイスとして使おうとかそういう甘っちょろい考えとはそもそも次元が違うのである。ただし開発環境は普通のAndroid と同じようにAndroidStudioが利用できる(利用せざるおえない)。私はIntteliJ IDEAを使っているけど問題なく使える。

Overview  |  Android Things  |  Android Developers

2.3. Android Thingsで使える。ハードウェア

 Android Thingsが動くハードウェアは決まっている。一番入手しやすいのはRaspberry Pi 3 Bだろう。それ以外でホビー用だと公式入門キットに付属しているNXP Pico i.MX7Dが使えるそうだ。商用ではSnapdragonなんかも動くようだ。自分はおとなしくRaspberry Pi 3 Bを使っている。自分で用意するのであれば一択な気がする。

Supported hardware  |  Android Things  |  Android Developers

2.4. Android Thingsのインストールについて

Android ThingsのインストールはAndroid Things Consoleにユーザ登録するところから始まる。ユーザ登録後、インストールツールがダウンロードできるのでツールを使いSDカードへOSを書き込むことができる。Android Things Consoleはツールのダウンロードだけでなく、カスタムイメージの作成やアプリケーションの配布がきでる。(後述)

3. Android Thingsが最高なポイント

じゃあ、Android Thingsの何が最高なのか、何ができるのかを見ていきたい。

3.1. Peripheralの操作ができて最高

 I/O, I2C, SPI, UART, I2Sなど一通りのペリフェラルを扱うことができる。最近のプロトタイピングボードを使ってやりたいことはそのまま実現できる。しかもこれがAndroidの開発環境から開発できる。Javaさえ書ければ思いのままに扱うことができる。さらにAndroidStudioのデバッグ機能が使えるので、ソフトウェア周りのデバックはこれで十分である。printfデバッグのためにひたすらprint文を埋め込んだりしなくていい。AndroidThingsを始めるにはRainbowHATを買うのがオススメ。2018年7月22日現在スイッチサイエンスでは在庫切れだ。Amazonでは割高で売られている。なんとか在庫復活してほしさある。

www.switch-science.com

 RainbowHATはAndroidThingsのcodelabやチュートリアルで採用されているボードなので、一通りの機能をすぐに触ることができる。

f:id:masato-ka:20180722193802j:plain

しかしRainbowHATだけで遊ぼうと思ってたらいつの間にかディスプレイとカメラを買っていた。ただただ最高かよ。

3.2. ユーザドライバ開発ができて最高

 Androdi ThingsではAndroidデバイスドライバをUser-space driversという形でアプリケーションの一部に実装することができる。例えばPeripheralにGPSや加速度センサを接続してアプリケーションから直接UARTやI2Cを叩いて情報を取ることができる。しかしUser-space-driverとしてこれらの処理をラップすると普通のAndroid端末と同じようにAndroidのframeworkを介してそれぞれの値を取得できるようになる。例えばSPI接続の安いRasPi用ディスプレイはSPIでタッチパネルのデータを受け渡す。これをUser-space-driverを介さずに利用しようとすると、SPIでX,Yの座標を受け取り、UIの座標と当たり判定して。。。と実装する必要がある。しかしHIDのポインティングデバイスドライバとしてSPIをラップして書けば、通常のAndroid端末のタッチパネル操作と何ら変わりなくただViewを実装すればHIDの処理はOS側がイベントとして処理してくれる。SPIでとってきたデータを意識する必要はない。ちなみにこれを1.0.1向けに実装したのものは以下のリポジトリにある。

github.com

動くとこんな感じなる。

User-space-driverはLocation HID Sensor, LoWPANなど4種類サポートされている

 IoTサービスの初期検討ではデバイスがないのでAndroidスマホで実装する。そのフィードバックを元にハードウェア要件を固めAndroidThingsで実装する。スマホで作ったアプリのソフトウェア資産をAndroidThingsに移植することでソフトウェア開発を簡素化できる。こういったIoTのプロジェクトを進める上でとても強力な開発プロセスを提供してくれるのではないだろうか。IoTサービス開発にも役立って最高かよ。

3.3. BLEが使えて最高

 Android ThingsはもちろんBLEも使える。Raspberry Pi 3BのBLEも制御することができるらしい。らしいというのはまだ触っていないのでこの部分については語れる部分がほとんどない。1ヶ月以上遊んでてもまだ試すことが多いの最高かよ。

3.4. カメラが使えて最高

 Android Thingsではカメラを使うことができる。Raspberry Piの公式カメラを利用することができる。ただしUSBカメラを接続して使うのはRaspberry Piでは今の所できないようだ。少々残念なところだけどUSBのカメラのドライバを用意するなどAndroidでは難しい部分もあるのだろうか。もちろん撮影した画像はファイルに保存できるし、画面に表示することもできる。画像が取れることで画像認識など夢が広がりまくって最高かよ。

3.5. デバイスでのAIが簡単すぎて最高

画像認識

 Androidtensorflow-liteFirebase ML Kitといったモバイルデバイス向けディープラーニングフレームワークを使い物体認識などを実装することができる。同じ方法でAndroid Thingsも利用することができる。サンプルも豊富にあって既存モデルを使うだけであればすぐに実行することができる。例えば一般物体認識のサンプルは以下。Raspberry Piでも動く。

GitHub - androidthings/sample-tensorflow-imageclassifier: Classify camera images locally using TensorFlow models

 大きくtensorflow-liteを直接実行する方法とFirebase ML Kitを使う方法があるが後者をおすすめしたい。どちらもtensorflow-liteとそのモデルを利用するみたいだが(と思ってる)Firebase ML Kitでは何種類かのよくありそうな認識モデルを提供してくれる。OCRや顔発見、シーン認識、ランドマーク認識だ。もちろんtensorflow向けに用意したカスタムモデルを圧縮して使うこともできる。ここまで読んでRaspbianでも同じことできると思ってしまう。しかしtensorflow-liteのビルドなど面倒な環境構築作業が必要だ。Android Thingsでは環境構築をすっ飛ばして目的のアプリケーション実装に取り組めるところにアドバンテージがある。さらにFirebaseからモデルファイルをアプリケーションへ配信してデバイスのモデルを更新することができる。こういった管理機能まで含めて利用することができるのだ。そして、Android Things上での実装も数十行で終わる。たとえばFirebase ML Kitだとこうなる。もちろん実際にはカメラで画像をとってくるなど処理はあるが。

private void recongnizeText(FirebaseVisionImage image){
        FirebaseVisionTextDetector detector = FirebaseVision.getInstance().getVisionTextDetector();
        Task<FirebaseVisionText> result = detector.detectInImage(image)
                .addOnSuccessListener(new OnSuccessListener<FirebaseVisionText>() {
                    @Override
                    public void onSuccess(FirebaseVisionText firebaseVisionText) {
                        StringBuffer sb = new StringBuffer();
                        sb.append("Result: ");
                        for (FirebaseVisionText.Block block : firebaseVisionText.getBlocks()) {
                            sb.append(block.getText());
                            sb.append(", ");

                            Log.i(LOG_TAG, "Recognize text: " + block.getText());
                        }
                        textView.setText(sb.toString());
                    }
                }).addOnFailureListener(
                        new OnFailureListener() {
                            @Override
                            public void onFailure(@NonNull Exception e) {
                                Log.e(LOG_TAG, "failed recognize text", e);
                            }
                        }
                );
    }

顔認識をやりたければDetectorの種類を変えるだけだ。さらにクラウドAPI を使う処理にしたい場合もそれ用のDetectorを使えばいいだけだ。リファレンスがなくてもかける気がする。簡単に最新のAIをIoTデバイスに取り込めるの本当に最高かよ。

TPU対応(8月1日追記)

先日行われたGoogle Cloud Nextでは「Edge TPU」と呼ばれるTensorFlow-Liteを実行するための組み込み向けASICが発表された。また開発ボードが秋に発売され、対応OSはDebianとAndroidThingsになるそうだ。また同時に発表されたCloud IoT EdgeではEdge上でのML機能のを実現するランタイムとそれをGCPのプラットフォームをつなげる機能が提供されるようだ。詳細わかり次第また記載をしたい。 また、AndroidIntel Movidiusにも対応しているらしい、AndroidThingsでも使えるのか検証したい。

音声対話アシスタント

今はやりの音声対話アシスタントもAndroid Thingsで作ることができる。こちらはVoice KitのソフトウェアをAndroid Thingsで動かせるようだ。まだ試していないがぜひやってみたい。マイクやスピーカも使えるっぽい。Peripheralにモータとセンサをつなげればコミュニケーションロボットも簡単に作れそうで最高かよ。

3.6. クラウド連携が至れり尽くせりで最高

当然、クラウドとの連携も充実している。

アプリケーションとしてクラウドを使う

Google Cloud IoT Coreとの連携にはクライアントライブラリが公開されている。これを使うと簡単にGoogle Cloud IoT Coreと接続することができた。これでAndroid Thingsで取得したセンサデータや画像認識の結果をGoogle Cloud IoT Coreに投げCloud Dataflowを経由し、BigQueryに投げ込むことができる。後のデータ処理や可視化は思いのままだ。

developers-jp.googleblog.com

Googleクラウドプラットフォームへのコネクティビティが整備されてて最高かよ。

管理方法としてクラウドを使う

クラウドとの連携はアプリケーションだけではなく、デバイスの運用においても力を発揮する。Android Thingsをインストールするときに利用したAndroid Things Consoleを使えばアプリケーションの配信やアップデートができるようになる。また、OSの更新はOTAで実行できるようになる。つまりプロダクトとして実運用に入っても至れり尽くせりになっている。この部分は先ほどのFirebaseのAIモデルの配信も同じだろう。そもそも向こうはスマホアプリを対象としているのでこういう機能がないと実用として使えないのだろう。デバイスの数が増えても最高かよ。

IoT端末のソフトウェアを管理できるツール「Android Things Console」を使ってみました - GIGAZINE

3.7. IoTデバイスとしての取り回しが楽で最高

 AndroidThingsは電源を入れたらOSが立ち上がり、そのままアプリが起動する。電源一発ぽんだ。変なアプリケーション立ち上げ操作やそのための設定は必要ない。また、デバイスの電源はそのままデンプチできる。これでOSは壊れることはない。(一応そういうことになっている。)そのためにOSの設定をする必要はない。まさにIoT向けOSで最高かよ。

4. Android Thingsの弱いところ

ここまでAndroid Thingsの最高なところを見てきた。しかし光あれば影がある。最高じゃない部分だって多々あるのだ。

4.1. LTE接続や3Gサポート

Raspberry PiだとLTEモデムドライバなどサポートがない。QualcommがSnapdragonあたりで使えるようにするみたいなニュースがあるようだがRaspberry Piでもなんとかならんだろうか。今後に期待したいところだ。

Qualcomm to announce LTE chipset for Google’s IoT, Android Things

 またUSBやUARTのLTEモデムを接続し、ATコマンドで無理やりSMS送ってる人はいる。自分でドライバとか書けばなんとかなるんだろうか修羅の道な気もする。 これにSORACOMつなげたいんじゃと思いつつ、SORACOM Kryptonでソラコムのサービスにつなぎ込むんでいくのがいいのかもしれない。

4.2. Javaで開発

 Androidなので開発言語はJavaJavaだと辛い人は辛い。ただしIDEを使えばそこまで辛くはないと個人的には思っている。AndroidStudioはIntteliJ IDEAをベースにしているので開発環境としてもいい方だと思っている。このIDEの使い方を知ればむしろJavaを書くのが楽しくなると思う。どうしてもJavaとか嫌だという人はKotlinを使うことができる。

4.3. Androidの知識

 これまで最高ポイントで「Android開発と同じ知識で」や「Androidと同じソースで」などと書いた。しかし裏を返せばAndroid開発の知識やスキルを強制的に求められるのだ。これはAndroid開発初心者には学習コストが必要になる。しかし、幸いにも世のAndroid 開発者は多い。トラブル発生時のググラビリティは非常に高い。また、Googleのcodelabなど上質なチュートリアルやドキュメントも揃っている。Androidだけなら書籍もあるのでそんなに困らない。事実私はAndroid開発ほぼ初心者だがAndroid Thingsは難なく使えるようになった。もちろんAndroid Things 固有の問題だと辛いけどPeripheral周りとかかな。

4.4. まだ少し不安定

1.0.0とはいえこの安定性はどうなんだという状況がたまに発生する。まず最初に遭遇したのがWiFiの問題だ。家でWiFiを設定すると突然再起動を繰り返すようになった。WiFi設定後だったので電源の問題かと3AのACに変えたが状況が変わらずだった。途方に暮れてバグとして報告をした。

https://issuetracker.google.com/issues/110793391

結果として類似の報告が上がっているらしく、特定の設定のWiFiアクセスポイントが近くにあると起こる問題とのこと。。。家の中で別の部屋に移動するだけで再起動は発生しなくなった。また外に持って作業することもあるが今の所外では発生しない。本当に特異な状況だったのだろう。再起動をかなりの回数繰り返すうちにOSが起動しなくなる事象も確認している。この辺りも電プチが原因なのか、再起動ループが原因なのかは不明だ。今後改善されることを願う。

4.5. 対応ハードウェの選択肢が少ない。

Raspberry Pi 3 Bが使えればそんなに困りはしないが、もう少し選択肢があってもいい気がする。また新しいボードに対応するまでのタイムラグもきになるところだ。ちょっと前まではIntel Edisonなども使えていたようだが奴のことはもう忘れよう。これからシングルボードコンピュータが新規に作られたらぜひAndroid Things対応ボードにしてほしい。

5. まとめ

Android Thignsは最高だった。確かに難はあるしイロモノ感も否めない。しかし、控えめに言って最高かよだった。盛り上がりはイマイチな気がする。もちろん使ってる人もいるにはいるが、よく見るって感じでもない。正式リリースされてまだ日が浅いというのもあるかもしれないが、これから日本でも盛り上がって欲しい。この記事を見てAndroid Thingsに興味を持ってくれたら嬉しい。また、Android Thingsのもくもく会を企画してみたので実際に触って見たくなったら是非参加して欲しい。

connpass.com

このブログでもAndroid Thigsは追っていきたいテーマだ。

SORACOM Discovery 2018に参加した記録

この記事について

この記事では2018年7月4日に開催された株式会社ソラコムさんのイベントSORACOM ディスカバリーに参加した記録と感想・所感について書いています。

SORACOM Discovery 2018について

 SORACOM Discovery 2018は2017年に続き2回目の開催です。キーノートを含めた29のセッションと30を超えるユーザ企業やパートナーの展示、またIoT製品に触って試せるタッチアンドトライコーナーやハンズオンセミナーなど盛りだくさんの内容になっていました。  IoTに関する技術トピックやビジネス動向、実際の応用事例まで一度に見れた貴重な機会でした。これが無料で参加できるとは。。。来年も同様のイベントがあればぜひ参加したいです。

discovery2018.soracom.jp

また夜に行われたSORACOM UG(ユーザグループ)も面白い内容でした。実は今回のUGでは運営のお手伝いをさせていただきました。リストバンドとか作るとこやってました。

UGは9月に大きなイベントを開催予定だということで、そちらもぜひ手伝っていければと思っています。

全体所感

 今回のSORACOM Discovery2018では午前のキーノートセッションで行われた新発表祭りがハイライトだったと思います。特にクラウドへの認証代行を行うKのサービスSORACOM KryptoとSORACOM Harvestに続くLのダッシュボードサービス(SORACOM Lagoon)https://soracom.jp/services/lagoon/の発表が印象深かったです。また、SORACOM LTE-M Buttonの発表も見逃せない内容でした。

  • Lagoon

  • SORACOM LTE-M Buttonを聞いた瞬間の感想

 また、当日セッションを直接聞けなかったのですが懇親会でソラコムのソリューションアーキテクト松本さんご本人から伺ったSORACOM Beamへの認証情報がSIMごとに複数設定できる新機能もF-2SORACOMサービスを利用したIoTアプリケーションのクラウド連携で発表されたようです。個人的には嬉しい内容です。以下資料の37ページ目です。

www.slideshare.net

このブログでも紹介しているSORACOM BeamからGoogle Cloud IoT Coreへ接続する際にそうです。課題感は以下の過去記事に記載があります。今回の機能を使った接続検証の記事は別途記載します。

masato-ka.hatenablog.com

このようにセッション中にもアップデートがあるので、他にも見逃せないものがないか気になるます。本当の意味でのキャッチアップは大変そう。

聴講セッション

聴講したセッションは以下のセッションです。

  1. 《キーノートパネル》Discovery、Digitalization、Democratization 〜つながるデータがもたらす新価値〜
  2. IoTシステムにおけるデバイス管理とセキュリティ
  3. 動態管理 モノ・ヒトの位置情報をビジネスに活かす 〜車両管理・作業管理における実践効果〜
  4. IoT システム 最新アーキテクチャ・リファレンス ~デバイスからクラウドまでの最適解を求めて~

1. Discovery、Digitalization、Democratization 〜つながるデータがもたらす新価値〜

 内容は非公開とのことだったので記載しませんが、ウェザーニュースの石橋さんが印象的でした。ウェザーニュースの流星特番が好きなので、生石橋さんが見れたのは嬉しかったです。

2. IoTシステムにおけるデバイス管理とセキュリティ

 「IoTシステムにおけるデバイス管理とセキュリティ」では当日発表されたSORACOM Kriptonの解説がありました。SIMを認証キーとして利用するというコンセプト自体はソラコムサービスの当初からあった考え方だったと思います。これまでもこのコンセプトを体現するためSORACOM Endorseやメタデータサービスが存在していました。今回のSORACOM Kriptonではこの考え方をさらに進め、SIM認証を中心として、クラウド(現在はAWSの一部サービス)の鍵を作成、デバイスに対して提供する部分をSORACOM Kriptonが担うという形になります。また、認証時にSIMの情報が使えれば LTE/3GでなくてもWiFi・有線で接続するインターネット回線が使えるというのがポイントです。この場合インターネットに全くでずにセキュリティを守るというメリットはなくなりますが、大容量データや非構造化データを取り扱う際にSORACOMのサービスと連携できるのは有利になるのではないでしょうか。最近ではエッジコンピューティングなどでローカル側でデータを処理して送る方法を取ればLTE/3Gでもできなくはないと思います。どう棲みわけ関わりを作るかがポイントとなりそうだと個人的にです。いずれにせよ選択肢が増えることは良いことだと思います。

3. 動態管理 モノ・ヒトの位置情報をビジネスに活かす 〜車両管理・作業管理における実践効果〜

 「動態管理 モノ・ヒトの位置情報をビジネスに活かす 〜車両管理・作業管理における実践効果〜」では物の位置情報や利用履歴などをロギングし可視化する動態管理についてのパネルディスカッションでした。ただ可視化するだけではなく、それを使って業務の改善につなげていくのがポイントというお話でした。データをどのように活用するのか、まずは仮説を立てることが重要ということが語られ、意識はしているけど重要なポイントだと思いました。

4. IoT システム 最新アーキテクチャ・リファレンス ~デバイスからクラウドまでの最適解を求めて~

 SORACOMを使った複数パターンのリファレンスアーキテクチャが公開されていました。資料だけでも大変参考になるので、これからIoTのシステム構築を検討される方は見た方が良いと思います。(近いうちに公開されると思います)デジタルサイネージのシステムなどソラコムのサービスを使わない場合でもそのエッセンスは共通的で参考になります。さらにそれらがソラコムサービスを使うとより簡単に構築できることがわかると思います。

まとめ

 カンファレンス自体は大変楽しめる作りになっており、魅力的なセッションばかりでどれを見るか迷うものが多かったです。ビジネスからテクノロジー、エンジニアリングまで幅広くカバーされている話を1日で聞けるのは非常に貴重な機会なので今後も続けていただきたいと思います。また、ソラコムさんの今後の方向性として通信サービスではなくSIMを中心としたIoTのインフラ提供を行っていくという強い意志みたいなものを感じました。常々ソラコムさんのサービスはIoTデバイスのPaaSサービスみたいなものだと考えています。現場にいかに素早くデバイスを開発してデプロイしていくか。そのためのプラットフォームとしてソラコムのサービスが大変便利だと考えています。(以前のLTでもそんなつもりでしゃべりました。)これからも目が離せないIoTのプレーヤーです。  話は横に逸れますがソラコムの社員さんともお話しする機会があり、みなさん気さくで中が良さそうな人たちでした。雰囲気の良いチームや組織からはやはりそれにあった素晴らしいプロダクトが出るのだなと改めて思いました。自分のチームもそうあるように頑張りたい。

SORACOM BeamにGoogle Cloud IoT Coreへの接続設定をソラコムのAPI経由で設定する。

この記事について

この記事ではSORACOM APIを使って Google Cloud IoT Coreへの接続設定を行う方法を記載します。前回の記事ではSORACOMの管理画面からSORACOM Beamの設定を行い、Cloud IoT Coreへの接続設定を行いましたが今回はソラコムが提供するWEB APIを利用して設定を行ってみます。基本的にAPIを叩くだけですが、SORACOM BeamのCloud IoT Core向け設定をAPIで実効する方法など公式ドキュメント化されていない箇所があるので備忘録的に記載しています。

APIで接続設定する利点

前回の記事にも記載しましたが、SORACOM BeamからCloud IoT Coreへ接続する場合、Cloud IoT Coreに登録したデバイスとSORACOM Beamの設定は一対一の関係にする必要があります。これはCloud IoT Coreではデバイスが個別の証明書(秘密鍵)を持つのに対して、SORACOM Beamの仕様では1設定ごと(=1グループ)に証明書を1つしか設定できないことが理由です。そのため、複数のデバイスを接続するためにはデバイス(=SORACOM Air SIM)ごとにグループを作成し、SORACOM Beamの設定を行う必要があります。

f:id:masato-ka:20180623131229p:plain
GCPのデバイス設定とSORACOM Beam設定は一対一

複数の設定をSORACOM のユーザコンソールから設定するのは煩雑ですが、SORACOM Beamの設定はSORACOM APIから設定することができるため、APIでグループの作成と、SORACOM Beamの設定をすることで煩雑さから解放されます。この方法がわかればCloud IoT Coreの設定と合わせて管理ツールを作ることもできます。

APIからの設定

 ソラコムの提供するサービスは全てAPI経由で設定を行うことができます。当然Beamの設定についてもAPIから設定を行うことができます。今回はAPIのクライアントとしてCURLコマンドを利用します。その他のクライアントを使う場合は適宜よみかえを行ってください。soracom-cliAPI のSwaggerドキュメント、各言語のAPIクライアントライブラリが存在しています。現在のバージョンでは証明書の登録ができませんが、私が開発しているVisual Studio CodeのExtentionも利用できます。

 Cloud IoT Coreの設定やデバイスの登録、証明書の発行については以下の過去記事を参考にしてください。

masato-ka.hatenablog.com

なお以降のサンプルでは「//」をコメントとして扱っています。必要に応じて取り除いてください。

証明書の登録

まずはじめにCloud IoT Coreに接続するための認証情報を登録します。あらかじめ、Cloud IoT Coreにデバイスを登録する際に設定した公開鍵のついとなる秘密鍵を用意しておきます。以下のリクエスト送ることで、credential-device01と言うcredentialIDを持つ認証情報を作成することができます。

curl -X POST --header 'Content-Type: application/json;charset=UTF-8' --header 'Accept: application/json' \
--header 'X-Soracom-API-Key: API KEY' \
--header 'X-Soracom-Token: APIのトークン' \
-d '  {
    "description": "api-registry", //(1)
    "type": "googleIoT-credentials", //(2)
    "credentials": {//(3)
      "projectId": "careful-maxim-150804", 
      "region": "us-central1", 
      "registryId": "my-registry", 
      "deviceId": "newcamer", 
      "algorithm": "RS256", 
      "privateKey":"-----BEGIN RSA PRIVATE KEY-----\n..."(4)
    }
}' 'https://api.soracom.io/v1/credentials/credential-device01' //(5)
  • (1) 認証情報の概要を記載しておきます。
  • (2) type要素にCloud IoT Coreの認証情報であることを指定しておきます。
  • (3) credentials要素内ではCloud IoT Coreへの接続情報を入れます。Userコンソール画面を参考に入力します。先述の過去記事を参考にしてください。
  • (4) privateKeyにはpem形式の秘密鍵を設定します。この際、改行を「\n」に置き換えて1行の文字列として貼り付けてください。
  • (5) 認証情報のIDはAPIのパスバリューとして私ます。上記の例ではURL末尾のcredential-device01がcredentialIDとなります。任意の値を指定してください。デバイスごとに認証情報を使う必要があるため、「credential-デバイスID」など命名規則を決めておくと良いでしょう。

credentialIDは次のSORACOM Beamの設定で利用するため書き留めておきましょう。

SORACOM Beamの設定

SORACOM Beamの設定はSIMグループに対して設定します。また、SORACOM BeamからCloud IoT Coreへ接続する場合は前述の通り、1デバイスにつき、1グループが必要になります。そこで、API/groups エンドポイントに対して以下のリクエストを投げ、SIMグループの作成とSORACOM Beamの設定を行います。リクエストに成功した場合、レスポンスボディにgroupIdが含まれていますので書き留めておきましょう。SIMをグループに追加する際に利用します。

curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' \
--header 'X-Soracom-API-Key: APIキー' \
--header 'X-Soracom-Token: APIトークン' \
-d ' {
    "configuration": {
      "SoracomBeam": {
        "mqtt://beam.soracom.io:1883": {
          "enabled": true,
          "name": "IoTCore",// (1)任意の設定名を追加する。
          "addEquipmentHeader": false,
          "addSignature": false,
          "addSubscriberHeader": false,
          "customHeaders": {},
          "skipStatusCode": false,
          "useClientCert": false,
          "useGoogleIoT": true,
          "googleIoTCredential": {
            "$credentialsId": "credential-device01" //(2)証明書の登録で登録した認証情報を指定する。
          },
          "addDeviceIdHeader": false,
          "destination": "mqtts://mqtt.googleapis.com:8883"//(3)Cloud IoT Coreの設定
        }
      }
    },
    "tags": {
      "name": "IoTCore2" //(4) グループ名固有の名前になるよう、デバイス名などを指定しておく。
    }
  }' 'https://api.soracom.io/v1/groups'

グループに対する設定はconfigurationセクションで行われます。また、SORACOM Beamへの設定はその中のSoracomBeamネームスペースに設定を記載します。各設定の要点を以下にまとめています。

  • (1) SORACOM Beamの設定名、任意の名前を指定可能。
  • (2) 「証明書の登録セクションで設定した認証情報を指定する。」
  • (3) Cloud IoT Coreのエンドポイントの設定 固定値になります。
  • (4) グループ名、どのデバイスの設定かわかりやすくするため、デバイス名+Groupなど命名規則を決めておくといいと思います。

なお、SORACOM Technology Camp の際に質問し回答をいただいた範囲ではグループ作成の上限数は決まっていないとのことです。

GroupへSIMを追加する。

以下のリクエストでSIMをグループに追加します。

curl -X POST --header 'Content-Type: application/json' --header 'Accept: application/json' \
--header 'X-Soracom-API-Key: APIキー' \
--header 'X-Soracom-Token: APIトークン' \
-d '{
  "groupId": "グループ作成時に取得した値",
}' 'https://api.soracom.io/v1/subscribers/{imsi}/set_group'

groupIdを記録し忘れた場合は以下のAPIを実効することでグループの情報を再度確認することができます。このリクエストは/v1/groupsのエンドポイントにリクエストパラメータでタグ名とその値のクエリを渡して検索しています。SORACOM Beamの設定でリクエストとして送ったJSON(4)の要素を指定しています。もしグループのタグ情報としてnameを指定していない場合は適宜グループの検索条件を指定してください。また、リクエストパラメータを設定しない場合は全てのグループを取得することが可能です。

https://api.soracom.io/v1/groups?tag_name=name&tag_value=IoTCore&tag_value_match_mode=exact

以上で設定は完了となります。追加したSIMを使いSORACOM BeamのMQTTエンドポイントmqtt://beam.soracom.io:1883へpub-subすることでCloud IoT Coreにメッセージが送れるようになります。

まとめ

 今回はSORACOM Beamの設定のみでしたが、Google Cloud IoT Coreへのデバイス追加を行うGCPAPIと組み合わせればデバイス追加を行うための管理サービスを作ることができます。実際に運用するためには証明書の管理などポイントがあると思いますが、小規模なデバイスを管理するのであればこの方法で十分ではないでしょうか。証明書自身はサーバ側で作り、ファイルに保存することなく、SORACOMとGCPの証明書管理サービスに投げ込めばセキュアに実現できるでしょうか。

Google IoT CoreとSORACOM Beamをつなげてみた。

この記事について

前回はGoogle Cloud IoT Core(以下 IoT Core)とSORACOM Beamを連携させた場合のメリットデメリットについて考察しました。今回はIoT CoreとSORACOM Beamを接続する設定方法について説明します。GCPのコンソール画面とSORACOM Beamの基本的な設定方法には触れませんので公式を参考にしてください。 前回までの記事は以下です。

masato-ka.hatenablog.com

IoT Coreの準備

GCPGetting StartedBefore you beginを参考にCloud IoT Coreを 利用できるようにしてください。クラインとのインストールは実施しなくても大丈夫です。IoT Core利用の準備は以下の手順で行います。  もちろんそれぞれの手順は公式チュートリアルに記載があります。特別な設定はないですが、SORACOM Beam連携でのポイントを説明します。

  1. レジストリの作成(MQTTSエンドポイントを作成する。)
  2. バイス認証用CA証明書秘密鍵の作成
  3. バイス登録

レジストリの作成

レジストリ作成時は「レジストリID」、「リージョン」の値が必要になるので控えておいてください。下の画像だと「hogehoge」,「us-central1」が必要な値です。 またプロトコルの「MQTTにチェックが」入っていることを確認します。「cloud pub/sub」のトピック名も設定してください。Cloud IoTは受信したデータはここで設定した Cloud Pub/Subのトピックに送られます。レジストリへの証明書登録はオプションのため、必要ありません。

f:id:masato-ka:20180411081131p:plain

CA証明書秘密鍵と公開鍵の作成

CA証明書秘密鍵は以下のコマンドで作成します。opensslがない場合はあらかじめインストールしてください。RSA256 2048bitのキーサイズです。

> openssl genrsa -out rsa_private.pem 2048
> openssl rsa -in rsa_private.pem -pubout -out rsa_cert.pem

バイスの登録

バイス 登録を行う場合は端末 IDをメモってください。以下の画像中の「my-device」です。認証の項目で入力方法を「アップロード」 を選択して公開鍵の選択します。作成した証明書に従って「RS256」を選択してください。他の選択肢は「ES256」のみ利用できます。 残り二つはおそらくSORACOM側で選択できません。デバイスを登録する際に証明書のアップロードが求められるので作成した公開鍵を 設定します。上記コマンド実行の場合は「rsa_cert.pem」です。手動で入力する場合はファイルの内容をコピペしてください。

f:id:masato-ka:20180411081149p:plain

SORACOM Beamの準備

次に SORACOM Beam側の設定です。あらかじめ、グループを作成し、接続に使うSIMをグループへ所属させてください。

SORACOM Beamの設定

グループ設定からSORACOM BeamのMQTTエントリポイントを作成します。種別はGoogle IoTを選択して認証情報を新規に登録します。

f:id:masato-ka:20180411082025p:plain

認証情報IDは任意の値を入力してください。種別がGoogle IoT 認証情報になっていることを確認します。ProjectIDにはGCPのプロジェクト IDを入力します。RegionにIoT Coreのリージョン情報(今回はus-central1)Registry ID(my-registry), Device ID (my-device)を入力します。AlgorithmはRS256を選択します。private keyには作成したCA証明書のプライベートキー秘密鍵を設定します。「-----BEGIN RSA PRIVATE KEY-----」から「-----END RSA PRIVATE KEY-----」までコピペしてください。

f:id:masato-ka:20180411082623p:plain

以上で設定は完了となります。

クライアント

利用方法はSORACOM Beamのエンドポイントmqtt://beam.soracom.io:1883に接続し、IoT Coreのテレメトリデータトピック「'/devices/{device ID}/events'」にパブリッシュするのみです。もちろん、サブスクライブと他のIoT Coreのトピックにメッセージを投げることができます。Pythonでクライアントコードを作成しました。接続後、「Cloud IoT Core」を投げて終了します。

#!/usr/bin/python
# -*- coding: utf-8 -*-

import paho.mqtt.client as mqtt

host = 'beam.soracom.io'
port = 1883
project_id = '' # Please setting your Project ID.
cloud_region = '' # Please setting your Region.
registry_id = '' # Please setting your registry ID. 
device_id = '' # Please setting your device ID. 

topic = '/devices/{}/events'.format(device_id)
message = 'Cloud IoT Core!'

def on_connect(unused_client, unused_userdata, unused_flags, rc):
    """Callback for when a device connects."""
    print('on_connect')
    client.publish(topic, message)

def on_publish(unused_client, unused_userdata, unused_mid):
    """Paho callback when a message is sent to the broker."""
    client.disconnect()

if __name__ == '__main__':
    client = mqtt.Client(protocol=mqtt.MQTTv311)
    client.on_connect = on_connect
    client.on_publish = on_publish
    client.connect(host, port=port)
    client.loop_forever()

動作や機能が違うので一概に比較はできませんが、以下のサンプルコードに比べてJWTやMQTTSの部分がシンプルになっています。このようにJWTやMQTTSの設定が不要な分、ローカルのMQTTブローカにメッセージを投げる感覚でコードが書けます。

github.com

まとめ

ここまででGoogle IoT CoreとSORACOM Beam連携の概要と実際の方法を試してきました。引き続き、GCP周りを触っていきたいと思います。

Google IoT CoreとSORACOM Beamの連携について調査してみた。

この記事について

この記事ではSORACOM BeamからGoogle Cloud IoT Core(以下 IoT Core)へ接続する方法について調査しました。SORACOM Beamではエンドポイントで受けた通信をGoogle IoT Coreへ転送することができます。今回はSORACOM Beamと IoT Coreを組み合わせることで何が実現できるのか考えてみました。

具体的な設定方法などは以下の記事を参考にしてください。

masato-ka.hatenablog.com

IoT CoreとSORACOM Beam接続について

IoT CoreとSORACOM Beam連携のメリット

通常、IoT Coreへデバイスを接続する場合、デバイスCA証明書で署名された秘密鍵で署名をしたJWTトークンを作成する必要があり、デバイスCA証明書のプライベートキー秘密鍵を保持する必要があります。IoT CoreへSORACOM Beamを利用して接続した場合、SORACOM Beam側で証明書を秘密鍵を保持し、JWTトークンの作成もBeamが代替します。そのため、デバイスCA証明書秘密鍵は必要ないので、デバイスの管理が楽になります。デバイスへの遠隔配置よりもサーバ側への配置の方がハードルが低くなると思います。さらにJWTトークンをデバイス側で作成する必要がありません。そして、IoT CoreへはMQTTSで接続する必要がありますが、SORACOM Beamを使うことでデバイスはMQTTのみで通信することができます。  まとめると、連携のメリットは以下のようになります。

  1. バイス(証明書)の管理を簡略化できる。
  2. JWTトークンの作成やMQTTSといった高負荷処理をクラウドへオフロードできる。

ちなみにこの辺りの処理をArduino向けに愚直に実装したのが、以下のライブラリになります大変そう。

github.com

IoT CoreとSORACOM Beam連携の不便な点

現状、SORACOM BeamとIoT Coreの接続設定の関係は、SORACOM Beamの1設定につき、IoT Coreの1デバイスIDのみ接続できるようです。SORACOM Beamの設定はSIM グループに複数設定可能ですが、同一の宛先には1つのみですので、複数のデバイスIDを接続したい場合はSIMごとにグループを作る必要がありそうです。メリットで述べたデバイスの管理を簡略化できますが、SORACOM側の設定管理が煩雑になりそうです。またCA証明書の暗号化方式もGCP側は4種類に対して、SORACOM側で現在対応している方式が2種類です。SORACOM BeamのIoT Coreとの連携は2017年6月にリリースされましたが、IoT Core自体は2018年2月にGAになりました。今後SORACOM Beamのサービスアップデートでこの辺りが改善されるのではないかと考えています。

まとめ

今回はGoogle Cloud IoT Core とSORACOM Beamについて調査をしました。連携のメリットはありますが、実際に使おうとすると考えなければいけないポイントがありそうです。もしかすると想定する使い方以外の方法があるかもしれませんが、もう少し公式のドキュメントを増やして欲しいと思いました。次の記事では具体的にIoT CoreとSORACOM Beamを連携させる方法について紹介していきます。

SORACOM Airを管理できるVSCode Extentionを作ってみた。

この記事について

この記事では自作のVSCode Extentionを紹介します。今回はSORACOM AIrVSCode上から管理できるExtentionです。

作った理由

最近ではWioLTEを使い、SORACOM Beamを利用してMicrosoft Azure IoT Hubや他のクラウドサービスに接続する機会が行くかありました。WioLTEの開発では、 以前紹介したVSCode + PlatformIOを利用した環境で開発をしています。

masato-ka.hatenablog.com

また、Azure IoT HubもVSCodeのExtentionから管理することができます。そのため、Azure IoT Hubの設定とWioLTEの開発はVSCode側で完結させることができます。 WioLTEの開発を進める上で、SORACOMのサービスを利用しようとすると、どうしてもSIMへの設定が必要であったり、SORACOM Beamへの設定が必要になります。また、動作テスト時には正常にSIMが接続されているかを確認する場面が多くありました。その度に、ブラウザからSORACOMの管理画面に移動するのが煩わしく感じました。そこで、SORACOMのAPIを使い、SORACOM サービスの設定もVSCodeからできるExtentionがあると便利だなと思い開発に至りました。

開発中のプラグインについて

2018年4月1日の段階で、バージョン0.3.0として公開しています。VSCodeマーケットプレイスには公開していないため、使ってみたい方がいたら、個別にインストールしてください。いずれ、マーケットプレイスに公開したいと思っています。ライセンスはMITです。

github.com

また、SORACOM APIJavaScriptライブラリとして以下のライブラリを使わせていただきました。

github.com

主な機能

主な機能を紹介していきます。

1. SIM一覧の確認

Extentionをインストールすると、VSCodeのサイドバーに"SORACOM MANAGER"が表示されるようになります。VSCodeの設定ファイルにAPI Key IDとシークレットキーを設定することで認証を自動で行い、SIM一覧を取得できます。現状SIMの数が多くなるとすべて取得することができないため、修正する予定です。また今後はグループごとにサブツリー化して表示するなど考えています。

ちなみに、立ち上げっぱなしで、API tokenの有効期限が切れると使えなくなるので、VSCodeを再起動してください。次のバージョンでで直す予定です。ひどいバグだ。

2. SIMの操作

SIMのリストを右クリックで選択することで、各SIMに対して操作をすることができます。現在操作できるコマンドは以下の通りです。また、これらのコマンドはもちろんコマンドパレットから実行することができます。

f:id:masato-ka:20180401232340p:plain

コマンド名 意味
Get sim details SIMの詳細情報を取得する。
Update sim speed SIMの通信速度を変更する。
Update sim name SIMの名前を変更する。
Add new tag to sim SIMにタグを追加する。
Delete tag タグの削除
Show stats Air of SIM Airの通信量を取得する。
Show stats Beam of SIM Beamの通信量を取得する。

SIMのTagはメタデータサービスにより、SIM固有のデータとしてデバイス側から参照できます。WioLTEでメタデータサービスを使う場合、"Add new tag to sim"など開発時やデバック時に便利です。

Update sim speedを実行すると以下のようにSIM スピードを選択できるようになります。

f:id:masato-ka:20180401231237p:plain

3. 利用料金の確認

SIMの操作以外では利用料の確認ができます。これはそのうち常駐させたい。。。

f:id:masato-ka:20180401232404p:plain

こんな感じでダイアログが表示されます。SIM2枚持ちですが、ほとんど使ってないのがバレてしまいます。

f:id:masato-ka:20180401232014p:plain

まとめ

 VSCode Extentionの作り方についてはなんとなくわかったという程度でした。が、なれるとサクサク作れそうです。どちらかというと今回はJavaScriptの非同期処理周りではまった時間が多かった気がします。コールバック地獄にならないように、Promiseでラップしまくりましたが、なんかバットノウハウな気もしています。(理由はありませんが。)この辺りのTipsは後ほど記事にしていこうと思っています。  今後もExtentionを拡張していこうと考えています。もし使ってみたと言う方がいたら改善要望やバグをあげていただけると嬉しいです。次はグループの管理機能を追加していきたいと思います。また、依存しているライブラリの関係で、テストの実行には本番のAPIを利用しています。sandboxのAPIを活用してテストができるようにしていきたいです。JavaScriptのDIとかちょっと使ってみたいです。

Microbot Push2のAPIについて調べてみた。

この記事について

この記事ではMicrobot Push2を制御するにためにBLEのインタフェースについて調べた内容についてまとめました。Microbot Push 2とのペアリングと、モータの制御方法について記載します。

Microbot Push 2について

Microbot Push 2はNARAN社から発売されている物理的なスイッチを押すためのデバイスです。このデバイスを使うとスマホのアプリから物理的なスイッチを押すことができます。照明のスイッチや家電製品などを手軽に遠隔操作することができます。

我が家の寝室の照明スイッチはなぜか部屋の一番奥にあります。そのため、夜部屋に入る時に電気をつけるのが大変めんどくさいです。そこで今回実現したかったことはGoogle Homeにお願いするとMicrobot Push 2が部屋の照明を押してくれる仕組みです。 Microbot Push 2単体ではBLEのインタフェースしか存在しませんが、IFTTTやスマートスピーカーと連携させる仕組みがいくつかあります。

1. Prota S

Prota SはNaran社から発売されているMicrobot Push 2と接続できるハブです。こちらを購入することでMicrobot Push 2をIFTTTから制御することができます。 以下商品ぺーじは並行輸入品のページです。ご注意ください。

Prota S [並行輸入品]

Prota S [並行輸入品]

2. Raspberry Pi + Prota Pi

Prota OSな高額なので買うのはちょっとという場合は、ご家庭にあるRaspberry Piが利用できます。公式から配布されているRaspberry Pi用のOS、Prota Piを利用するとProta S相当のものが作れます。

prota.info

BLEのインタフェースの調査

上記2の方法でおおよそのユースケースはカバーできそうですがもう少し柔軟な構成でMicrobot Push2を使いたい場合はBLEのインタフェースを直接叩く必要があります。そこで、BLEのインタフェースがどのようになっているか調査しました。

参考にしたプロジェクト

Microbot Push2用のサーバをOSSで開発していらっしゃる方がいます。

github.com

このリポジトリの以下のディレクトリでMicrobot Push 2のBLEインタフェースについて記載があります。

https://github.com/VRGhost/PyPush/blob/master/docs/microbot_ble_api.md

このドキュメンではMicrobot Push 2のBLEサービスとキャラクタリスティックについて記載があります。しかし、ペアリングをどのように実施するか、実際に使うための記載になっていません。(不明瞭の部分も多いです)そこで、上記のドキュメントとこのかたのソースコードを参考にしながらMicrobot Push 2をペアリングしてスイッチの制御を行うまでを、Bluezのgatttoolで実行するコマンドを組み立ててみました。

$ sudo gatttool -b [Microbot pushのMAC] -t random -I 
[xx:xx:xx:xx:xx:xx][LE]> connect
Attempting to connect to xx:xx:xx:xx:xx:xx
Connection successful
[XX:XX:XX:XX:XX:XX][LE]> char-write-req 0x2A90 0000
Characteristic value was written successfully
[XX:XX:XX:XX:XX:XX][LE]> char-write-req 0x2A90 000000
Characteristic value was written successfully
#このタイミングでMicrobot Push2がペアリングモードになるので本体のボタンを押す。
[XX:XX:XX:XX:XX:XX][LE]> char-write-req 0x2A11 01 # スイッチ動作
Characteristic value was written successfully

connect から最初の書き込みまでに30秒以内に実行しないとMicrobot Push 2側から切断されます。また char-write-req 0x2A90 0000char-write-req 0x2A90 000000のコマンドのペイロードは本来接続元のMACアドレスをベースに組み立てるようですが、これでもgatttool上から接続できました。ただ、Python ラッパのgattoollibから実行すると''' char-write-req 0x2A90 000000 '''の部分で動作が止まってしまいます。LightBlueなどのツールではうまく動作します。何が原因かわかりませんが、この部分時間があるときにまた調べてみたいとお思います。