インターネットのサービス同士をつなぐオンラインサービスでもっとも人気なのがIFTTT（If This Then That）だが、それがMakerがハックしたハードウェアにも対応し始めた。
IFTTTは、オンラインツールやサービスをつなぐことを目的に始まったサービスだ。たとえば、IFTTTで言うところの「レシピ」を使うと、Instagramに新しい写真をアップするごとに、Dropboxにも保存されるというようなものだ。If thisが「写真をアップすれば」で、Then thatが「Dropboxに保存される」だ。実際、非常に便利で、見たところとてもシンプルな構造なようだから発展性が感じられる。
しかし去年あたり、このサービスはさらにパワフルになった。サイトが純粋なオンラインサービスだけでなく、モノにもつながるようになったからだ。たとえば、Nestサーモスタット、SmartThings、WeMoスイッチ、Winkデバイスなどだ。データを受け取ったりコントロールできるIFTTTが「コネクテッドホーム」製品と呼ぶデバイスのリストはどんどん大きくなっている。
ただこれは、DIY愛好家にとっては、それほど面白いニュースではなかった。ほとんどのハードウェアは強力な市販品だったからだ。しかしIFTTTは先日、我々のためのあるものを追加してくれた。Maker Channelだ。
これは、自分で作ったハードウェアをIFTTTにつなげるようにするものだ。ネットワークにつなげたArduinoやRaspberry Piなどの自作プロジェクトをトリガーできるレシピも自分で書くことができる。さらにネットワークに接続したArduinoにIFTTTから直接メッセージを送ったり、既存のサービスからトリガーしたりすることができる。その方法を教えよう。
Eventsをトリガーする方法
IFTTTをMaker Channelにつないだら、イベントのトリガー（IFTTTのifの部分）を作るのは簡単。イベント名とソケットキー（チャンネルに接続したときに割り当てられる）を付けてGETまたはPOSTを送るだけだ。
https://maker.ifttt.com/trigger/{event_name}/with/key/{secret_key}
これにオプションで、レシピの中のアクションに渡したい値（文字列）をJSON型で3つまで付けられる。イベントのトリガーがcurlのコマンドラインと同じぐらいシンプルであるため、とてもパワフルだ。なぜなら、これによってIFTTTレシピをRaspberry PiやネットワークにつないだArduinoからトリガーすることが本当に簡単になるからだ。
サービスの呼び出し
レシピからサービスを呼び出す（つまりIFTTTのthatの部分）もシンプルだ。エンドポイント（ウェブアドレス、URL）を提供すればよい。レシピは、GET、POST、DELETEの要求を受けることができる。オプションとして、変数やコンテントを含めることもできる。これで、トリガー側のサービスやデバイスから遠くのウェブサービスへデータを渡すことができる。
このサービスはクラウドでもホストできるが、静的IPアドレスを家に持っていたり、DynDNSなどの動的DNSサービスを利用している場合でも、Raspberry Piや家に設置したArduinoとうまくやってくれる。
…そしてThen That。しかしThatも？
IFTTTについて人々が文句を言うとしたら、その名前だ。もし、何かが起こったら、ひとつのイベントをトリガーするという意味だが、複数のイベントを連続的にトリガーすることはできない。また、サービスは判断ができない。つまり、ひとつではなく2つをトリガーすることが不可能なのだ。
だが、新しいMaker Channelでは、それがごく簡単にできてしまう。リモートサービスへMaker Web Requestを送るレシピが書けるのだ。サービスから逆にMaker Channelがトリガーされて、他のIFTTTアクション、または複数のアクションを起こすことになる。
コンセプトの実証
これをテストするために、私はシンプルなレシピを書いた。これは、私の家のNetatmo Rain Gauge天気ステーションが雨を検知するごとに、簡単なCGIスクリプトが私のサーバーのひとつに送られるというもの（私は万一のために2台のサーバーをラックに設置している種類の人間なのだ）。
呼び出しのスクリプトは簡単だ。IFTTTに応答して2つの異なるMaker Channelレシピをトリガーする。これはコンセプトの実証実験なので、めちゃくちゃいい加減な方法だが、簡単なBashスクリプトとcurlコマンドを使っている。
#!/bin/bash
echo "Content-type: text/html"
echo ""
echo "<html><head><title>Maker Channel"
echo "</title></head><body>"
secret_key="SECRET_KEY"
string=$IFS
IFS='=&'
param=($QUERY_STRING)
IFS=$string
echo "<p>${param[0]} = ${param[1]}</p>"
curl https://maker.ifttt.com/trigger/remote_trigger/with/key/${secret_key}
echo "</p>"
curl https://maker.ifttt.com/trigger/other_trigger/with/key/${secret_key}
echo "</body></html>"
見てわかるとおり、このスクリプトは、私がサーバーに設定しておいた、あと2つのIFTTTレシピを呼び出しているだけだ。最初にBlink(1)をオンに切り替えて、雨を知らせる。
雨が降ると我が家のホームオフィスは暗くなるので、次に私のBelkin WeMoスイッチを入れ、デスクのランプを点灯させる。
このケースでは、最初のイベント（雨）でトリガーされる2つのレシピ、つまりBlink(1)を点灯させるレシピとデスクのランプを点灯させるレシピを設定しておけばもっと簡単だったかもしれない。ただ、これはあくまで実証テストだということを覚えておいていただきたい。
または、判断ができるもっと複雑なサービスに雨が降ってきたという知らせを送るという方法もあった。他のことも勘案して、IFTTTのシンプルなエンジンにはできない高度な判断をさせる。または、Arduinoなどのハードウェアをトリガーして、窓や雨除けシートをコントロールさせるとか。これまでIFTTTでは命令できなかったことだ。
セキュリティについて
ここで私がやったことは、恐ろしいほどに危険だ。世界にスクリプト（ウェブアプリ）を露出してしまっているし、それを使って我が家の照明をコントロールできてしまう。それは困る。だからこそ、IFTTTのサービスはリモートサービスに多くの情報を送れる能力があるのだ。
たとえば、リンクの双方にTOTP認証を設定するのは簡単だ。またはトークンやキーを交換させる。では、IFTTTのアカウント自体をプロテクトするには？ そのために、2段階認証が追加された。
［原文］
