Google HomeからRM mini3を制御する方法まとめ

１８年２月のアップデートで、RM mini3、e-RemoteともにGoogle Home対応しました。
リモコンのオン・オフだけならBridgeサーバを使わずに操作できるようになりました。
~~【1月29日更新】RM mini3がついにGoogle Home正式対応！ - おばかさんよね。

赤外線リモコンがついたシーリング照明を
「OK、グーグル。電気を消して。」
で制御できると捗ります。
就寝時に布団から出なくていいし、外出時も壁スイッチを押すより早いです。

Google HomeからRM mini3を制御する方法をまとめました。
残念ながら現時点ではRM mini3単独ではGoogle Homeと連携できませんが、AndroidやRaspberry pieを経由することで連携できるようになります。
それぞれの方法ごとのメリット、デメリットを整理してみました。

＊補足
RM mini3とは1500円程度で購入できる激安スマートリモコンです。
RM mini3でも国内OEM版のeRemote miniでも連携方法は同じです。

Google Homeの連携先にBroadlinkが追加されました。近いうちに正式対応するかもしれません。

連携させる方法一覧

Google HomeとRM mini3を連携させるためには、何らかのブリッジ（橋渡し役）が必要になります。
何をブリッジにするのか、各手法の一覧です。
それぞれのメリット・デメリットを個別に紹介します。

• AndroidならRM Bridge一択
• マルチプラットフォームならopenHAB2にbinding追加
• シンプルな制御ならBroadlink RM Server for IFFT control
• Firebase経由ならポート開放不要
• ナウいのはhubot-broadlink-rm（Slackのchatbot）

RM Bridge

「RM Bridge」というAndroidアプリを使う手法です。
RM Bridge - Google Play

Broadlinkの純正アプリと違い、RM BridgeにはHTTPサーバ機能があるのが特徴です。
学習させた赤外線信号ごとに特定のURLが発行され、そのURLにアクセスすることでRM mini3を制御する仕組みです。
Google Home→IFTTT→（ポート開放もしくはngrok）→RM Bridge→RM mini3という制御フローです。

メリット

設定が超簡単。
Playストアからインストールして、ぽちぽちと学習させていくだけで使えます。
手っ取り早く使うならRM Bridgeがオススメです。

デメリット

RM BridgeはAndroid版アプリしか提供されていません。
iPhoneやラズパイは非対応です。

それとRM BridgeをインストールしたAndroid端末をサーバとして常時起動させる必要があります。
この手のスマート家電好きなアーリーアダプタにとって、自宅にラズパイやQNAPが当たり前に転がっていて、なんやかんかの用途でLinux鯖が常時起動しています。
「RM BridgeもLinuxにまとめられないの？」という不満が出てくるわけです。

openHAB2 にbinding追加

openHAB2はスマートハウスの統合制御ソフトです。
Broadlink binding for RMx, A1, SPx and MP. Any interest? - Add-ons / Bindings - openHAB Community

WiFi/Bluetooth/ZigBee等々、乱立するスマートデバイスの管理/制御をopenHAB2に一本化するというコンセプトです。

openHAB2はLinux/windows/Macのマルチプラットフォームに対応しています。
さらにDockerやラズパイ、Synology、QNAPなど各種環境向けパッケージも提供されています。

openHAB2はbindingと呼ぶモジュールを追加するとサポートするデバイスを拡張できます。BroadlingのRM mini3に対応したbidingをCato氏がフォーラムで公開しています。

メリット

グラフィカルなUIで各種センサーを一覧できるのがカッコイイです。
スマートセンサーを複数個、持っている人にオススメです。

デメリット

とりあえずRM mini3とGoogle Homeを連携させるだけなら、ちょっと大げさです。

Broadlink RM Server for IFTTT control

Node.jsで動く「Broadlink RM Server for IFTTT control」というソフトを使う方法です。
GitHub - jor3l/broadlinkrm-ifttt: Broadlink RM server for IFTTT

Google Home→IFTTT→（ポート開放もしくはngrok）→ Broadlink RM Server for IF TTT control→RM mini3という制御フローです。

メリット

シンプルなプログラムで、古いラズパイでも余裕で動きます。

デメリット

RM BridgeもopenHAB2も同じですが、外部（WAN）から制御するためにポート開放が必要です。
セキュリティ的にはポート開放しないほうがベター。

それとURLをコマンドごとにぽちぽちと登録するのがイケてないです。
ドメイン名、ディレクトリ、ポート番号を変更してしまうと、毎回、登録修正する羽目になります。

Firebase経由

FirebaseはGoogleが運営しているクラウドサービスです。
Firebaseにはデータベースの更新をリアルタイムに通知する機能があります。
この機能を使うことでIFTTTのwebhookを宅内サーバで受け取ることができ、ポート開放やngrokが不要になります。

具体的な設定方法は@miso_developさんのQiitaをみてください。
Google Homeに話しかけてエアコンを操作してみる - Qiita

メリット

@miso_developさんのプログラムは音声コマンドの動詞（つけて、消して）をオプションとして受け取れるのでIFTTTへのコマンド登録がスマートです。

デメリット

強いて言えば、無料枠だと外部アクセスに色々と制約があるFirebaseを使っていることでしょうか。

hubot-broadlink-rm（Slackのchatbot）

Firebaseの代わりにhubotというSlackのchatbotを使うアイデアです。
Google Home→IFTTT→Slack→hubotサーバ→RM mini3というフローで制御します。
スマート家電も赤外線家電もGoogle Homeでまとめて操作 - Qiita

メリット

エアコンの温度やテレビのチャンネルなど細かい制御を設定しやすいです。
ドキュメントも充実していて、インストールが簡単そうです。

まとめ

温度センサーとエアコンの連携など色々できて面白そうなのがopenHAB2です。
とはいえ、音声操作のインタフェースとして割り切るなら、hubotを使うのが一番便利そうです。

ただ、私の場合は色々試した結果、Google Homeとの連携はあきらめて、
Alexa(Amazon echo)とRM mini3の組み合わせに落ち着きました。
Alexaは公式対応していてブリッジサーバが不要なのが決め手でした。
私にとって設定が楽チンなのが一番のペインポイントでした。

それとAlexaの米国版スキルはBroadlink、日本版スキルはLinkJapanと分かれているのでご注意を。
LinkJapanのスキルはeRemoteしか登録できません。
MACアドレスでeRemoteとRM miniを判別しています。

RM mini3のecho対応は機能がかなりしょぼくて、「照明」カテゴリのオンオフしか制御できない糞仕様です。
ですが、音声操作で使うのはもっぱらオンオフなので、あんまり不満は感じません。

本当は、テレビをつけて、入力切り替えて、録画番組を再生のように、
学習リモコンのマクロ機能のように制御できたらベストなんですけどね。
Google Home版の公式対応と機能追加に期待しましょう。

ちなみに。
赤外線リモコン自体が時代遅れなインタフェースで、エアコンやシーリングをぽちぽち操作するのは日本くらいだと聞きます。
複雑な制御を学習リモコンでやろうとすること自体、イケてない発想なのかもしれません。