さまざまな機器を1つのリモコンアプリから操作できるのはなぜ?
“自家製スマートリモコン”を作って、スマホから家電が操作できる仕組みを知る
長くて暑い夏も、秋分を過ぎてようやく少し涼しくなってきました。しかし、まだまだエアコンや扇風機を手放すことができない暑さが続いて、少しうんざりしています。家の中のIRリモコン(赤外線リモコン)も大活躍しています。
前々回、前回の記事では、身の回りにたくさんあるIRリモコンの基本的な仕組みや、赤外線を使ってどんな「おしゃべり」(通信)をしているのかを見てみました。
ところで、IRリモコンは片手で持てるほど小さな物なので、ほかの物にまぎれてどこにあるのかわからなくなりがちです。どこかに消えたリモコンをイライラしながら探す、そんな経験は皆さんもあるのではないでしょうか。
今回ご紹介する「スマートリモコン」は、スマートフォンのアプリケーション(以下、スマホアプリと略)と専用の装置を使って、一台で複数のIRリモコンの代わりをしてくれるリモコンです。これひとつあれば、TV、録画機、エアコン、扇風機、照明といった機器を操作できますから、たくさんのIRリモコンを手元に置く必要がなくなり、リモコンを探し回るイライラも減るでしょう。
市販されている最新のスマートリモコン製品は、豊富な機能を搭載しています。ただし、ここで説明をするには仕組みが複雑すぎるので、取り上げるのは少し後回しにしましょう。
その代わり、今回はシンプルな“自家製スマートリモコン”を作ります。具体的には、前回使用したマイコンキット「M5Stick C Plus 2」(以下、CPlus2と略)と、外付けのIRユニット(送信用の赤外線LED)を使って、1つのスマホアプリから、IRリモコンに対応した複数の機器を操作できるようにしてみます。
前回作成したCPlus2のプログラムには、新たに2つの機能を追加しました。スマホアプリからの指示をCPlus2が受け取るための「APIサーバー機能※注」と、CPlus2から操作対象の機器に赤外線で信号を送信する「IRリモコン機能」です。
※注:APIは「Application Programming Interface」の略語です。
「APIサーバー機能」は、CPlus2上で動作するプログラム(サーバー)が、スマホアプリからの「IRリモコン機能を実行して!」という指示を受け取る“窓口”のような仕組みです。実は、皆さんがふだん使っているスマホアプリも、その大半がAPIを使ってクラウド上のサーバーとさまざまなやおしゃべりをしています。今回作るのは、その簡易版と言えます。
ただし、スマホアプリとAPIサーバーのおしゃべりが成立するためには、「お互いの声が聞こえる」環境で「共通の話し言葉を使う」必要があります。今回は、スマホとCPlus2を同じWi-Fiネットワークに接続したうえで、APIでよく使われる「HTTP」という共通の話し言葉(プロトコル)を利用します。
もうひとつの「IRリモコン機能」は、CPlus2から機器に赤外線信号を送る仕組みです。前回の記事では、IRリモコンのボタンを押すと、そのボタンに対応した特定の言葉をしゃべる(あらかじめ決められた信号が赤外線で送信される)ことを確認しました。今回のプログラムは、あらかじめそうした信号の一覧表を持っており、スマホアプリから受け取った指示に対応する信号をIRユニットから送信します。
説明がやや難しくなってしまいましたが、今回作る“自家製スマートリモコン”における指示の流れをまとめると、下の図のようになります。
リモコン操作を行う機器は、メーカーが異なる2台の扇風機と、100円ショップで売っていたLEDライトにしました。いずれもIRリモコンが付属しています。前回記事で紹介した受信プログラムを使って、IRリモコンの各ボタンを押すとどんな言葉(信号)をおしゃべりするのかを調べておき、今回のプログラムに組み込みます。
スマホアプリの画面は、操作したい機器を選び、操作したい機能のボタンを押すだけのシンプルなものにしました。
スマホアプリとAPIサーバーは「HTTP」という共通の言葉でおしゃべりをします。そして、皆さんがふだん使っているWebブラウザもこのHTTPを話すことができます。そこで、Webブラウザを使ってAPIサーバーにアクセスしてみると、APIサーバーからの“返事”として「利用できる機器」や「実行できる操作(ボタン)」の情報が返ってきたり、その操作を実行する指示を送信したりできます。
画面の見た目こそ違いますが、先ほど示したスマホアプリも、APIサーバーとの間でこのWebブラウザと同じやり取りをしています。さらに、このやり取りの中では、ユーザーには見えない「おしゃべり」も行われています。ブラウザの通信内容を見ることができるLinuxのcurlコマンドを使って、その内容を詳しく見てみましょう。
curlコマンドを使い、自家製スマートリモコンのAPIサーバーに「fan_a(扇風機A)の電源ボタンを押して」と話しかけます(下に示したコードの1行目)。すると、APIサーバーから次のような“返事”が返ってきました(2行目以降)。
% curl -i "http://192.168.0.2/fan_a/power"
HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 28
Connection: close
Signal 'power' sent to fan_a
APIサーバーからの返事の1行目にある「HTTP/1.1 200 OK」というメッセージは、「HTTP(バージョン1.1)のおしゃべりを問題なく受信したよ」という意味です。さらにその後に続く3行は、受信したおしゃべりの細かい情報(データの形式や長さなど)です。
そして、最後の「Signal 'power' sent to fan_a」という1行は、スマートリモコンが話した「扇風機Aに『電源』の信号を送ったよ」という内容です。
前回の記事を思い出していただきたいのですが、IRリモコンと機器の間のおしゃべりは“言いっぱなしの一方通行”であり、IRリモコンは相手に言葉が届いたかどうかは気にしていませんでした。
しかし今回、スマホアプリと自家製スマートリモコンの間では、話しかけた内容に対して「受け取ったよ」という相づち(HTTP/1.1 200 OK)や、指示の実行結果(Signal 'power' sent ~)という返答がされています。これにより、スマホアプリ側で「言葉が相手に届いたか」「指示が実行されたか」が確認できます。“言いっぱなしの一方通行”ではなく、少し人間のおしゃべりに近くなってきましたね。
これで“自家製スマートリモコン”のごく基本的な機能ができましたが、まだまだ問題点もあります。次回はその問題点を、どういう仕組みにすれば解決できるのかを考えてみます。
週刊アスキーの最新情報を購読しよう