他人に講師役を任せたり、ある程度独習もできるようにしたつもりなので、よかったらご活用ください。
@methane
他人に講師役を任せたり、ある程度独習もできるようにしたつもりなので、よかったらご活用ください。
QR コードはインターネットアドレスなど所定のテキストデータを簡単に機器に取り込むための手段として広く利用されています。印刷物に限らずさまざまな媒体で扱えるのも便利ですね。
先日、公開鍵暗号を使う Android アプリを試作していた折に、自分の端末 A で生成した秘密鍵を手持ちの別の端末 B へ安全に輸送する手段の検討が必要になりました。やり方はいろいろありそうですが、よりシンプルな方法をとあれこれ考えている内に、机上に無造作に置いたチラシの QR コードにふと目が留まりました。
QR コードからのデータ取り込みは通常光学的に行われます。このことは電子機器の視覚を利用したデータ通信と考えることができるでしょう。第三者による情報窃取の可能性がしばしば問題となるネットワーク通信とは異なり、「目」を使っての情報伝達には物理的に介入することが難しいため、デジタルデータを画像で表現する QR コードは秘匿性の求められる局面での通信手段としても有用と考えられます。
今回の話題はふたつの端末の間でのデータ授受なので、送り側の端末で QR コードの生成と画面表示を行い、受け側の端末でそれを読み取ればよさそうです。情報の受け渡しさえできればコードを残しておく必要はないので QR コードは常に動的に生成し使い捨てとすればよいでしょう。
一件の QR コードに格納できるデータの量には上限があります。QR コードの開発元である株式会社デンソーウェーブ様のサイトの記事から概要を示す表を以下に引用します。
| コードの大きさ | 21セル×21セル～177セル×177セル(4セル /辺毎に増加) | |
| 情報の種類及び
情報量(混在も可) QRコードの情報量とバージョンについて |
数字 英数字 ８ビットバイト(バイナリ) 漢字 |
最大7,089文字 最大4,296文字 最大2,953文字 最大1,817文字 |
|
誤り訂正能力 (データ復元機能) 誤り訂正能力について |
レベルL レベルM レベルQ レベルH |
コードワードの約 7% が復元可能 コードワードの約 15% が復元可能 コードワードの約 25% が復元可能 コードワードの約 30% が復元可能 |
| コード連結機能 | 最大16分割 (細長いエリアなどへの印刷) | |
下の QR コードには半角英数記号 1675 文字を格納しています。これを一般的なサイズ・解像度の PC のモニタで表示した状態であればおそらく多くの携帯端末の QR コードリーダーで読み取ることが可能でしょう。しかし、スマートフォンの小さな画面にこれを表示した状態だと読み取りに失敗するリーダーが出てくるかもしれません。また、一般に情報の密度が高くなるほど読み取りにより多くの時間がかかるため、たとえ成功しても別のストレスが残る可能性もあります。
そういった事情を考え合わせると、今回のような目的で QR コードを利用する場合は、一件のコードに強引に多くのデータを押し込むのではなく、複数のコードに分けて利用することを前提に余裕を持ってデータを扱うほうが賢明でしょう。
実は上の表にも記述があるように、QR コードには一件のデータを最大 16 件のコードに分割して格納することの可能な「コード連結」という仕様があります。次の記事には分割 QR コードの実例が掲載されています。 「IT4206,QRコードの連結機能に対応していますか。」 - 株式会社エイポック様 公式サイトより -
残念ながらすべてのリーダー・ライブラリがこの機能に対応しているわけではなく、現在手元で使っているメジャーな ZXing のライブラリも未対応のようです。しかし、今回はリーダーだけではなくライターも自作することが前提なので、両者間で整合性のとれる内容で独自の分割プロトコルを用意すれば事足りると判断しました。また、二台の端末を操作しながら複数のコードを順番に処理していくのは想像するだけで非常に面倒なので、両者の連携にネットワーク通信を併用し、リーダーが正しくコードを読み取ったらライターが自動的に次のコードを表示することにしました。
ちなみに、先日の記事で操作性の良い QR コードリーダーを自作するために行った取り組みを紹介しましたが、そのきっかけは今回の一連の話題にありました。リーダーを自分で実装すれば上記のような細かい取り回しも柔軟に実現できるわけですね。QR コードの読み取りが主目的ではないアプリへ補助機能としてリーダー処理を組み込むことにはちょっと新鮮な印象があります。
そんなわけで次のような QR コードライターアプリと QR コードリーダーアプリを作ってみました。
動作の様子です。奥の端末で QR コードライター、手前の端末でリーダーを動かしています。
今回試作したソフトウェア一式を公開します。興味のある方はお試し下さい。
QR コードリーダーのビルドずみ apk
http://dsas.blog.klab.org/data/qr_secret/MyQRCodeReaderEx.apk
タイトルの通り、 innodb_flush_log_at_trx_commit=1 の場合も、トランザクションログが fsync されません。トランザクションがディスクに書かれるシーケンスは次のようになります。
1. prepare (fsync) 2. write binlog (grouped, fsync) 3. commit
このうち 1 は従来通り各スレッドで並列に実行され、 2 と 3 が昨日紹介した sql/binlog.cc の MYSQL_BIN_LOG::ordered_commit() の中のでグループ化されてシーケンシャルに実行される処理です。 この ordered_commit() は先頭で
thd->durability_property= HA_IGNORE_DURABILITY;
というようなフラグを立てています。このフラグは MySQL のソースコードの中で参照しているのは storage/innobase/trx/trx0trx.cc だけで、 HA_IGNORE_DURABILITY の時は flush_log_at_trx_commit=0 のように振る舞い、フラッシュ (fsync) を実行しません。
この場合、データの永続性は prepare されたトランザクションの内容と binlog で担保されます。 クラッシュリカバリの時は、 binlog を読み込んで、そこに書かれているprepare済みトランザクションをコミットしていきます。 (このため、クラッシュしたマシンからDBをコピーしてMySQLを再起動する場合など、binlogのコピーをサボるとコミットしたはずのトランザクションが消えてしまうので注意が必要です。今のところリカバリに読まれるのは最後の binlog だけで、 binlog のローテート時はトランザクションログにも fsync します)
最終的に、トランザクションごとの fsync の数は、 MySQL 5.5 の場合は (sync_binlog=0 の場合) 2回だったのに対して、 MySQL 5.6 では2回のうち1回は負荷が高くなるほどグループ化されて複数のコミットを1度で fsync されることになります。この点で MariaDB の方が速そうというのは勘違いでした。
この辺りはドキュメントが整ってなくて、 MySQL-internals に質問のスレッドが立っているのでそこが参考になります。
これKristianがMonty Program ABの人で、MatsがOracleの人で、「お前の設計はおかしい」って喧嘩してるスレッドじゃないか。面白すぎる lists.mysql.com/internals/38705
— SH2さん (@sh2nd) 2013年4月26日さらにZardoshtがTokuDBの人だった RT @sh2nd: これKristianがMonty Program ABの人で、MatsがOracleの人で、「お前の設計はおかしい」って喧嘩してるスレッドじゃないか。面白すぎる lists.mysql.com/internals/38705
— SH2さん (@sh2nd) 2013年4月26日昨日の記事 で innodb_support_xa = 0にすると RDS が速くなることを紹介したのですが、その後 Twitter で innodb_support_xa = 0 にするとクラッシュ時だけでなく通常時も binlog とトランザクションログの一貫性が無くなる（コミットする順序が前後する）可能性があることを指摘していただきました。
innodb_support_xa=0すると、トランザクションがコミットされた順番でバイナリログに載ることが保証できなくなるんだけどいいのかな？ DSAS開発者の部屋:AWS RDS の書き込み性能チューニング dsas.blog.klab.org/archives/52108…
— ts. yokuさん (@yoku0825) 2013年4月24日実際に、 MySQL 5.5 と 5.6 両方で、 innodb_support_xa の説明にそう書かれています。
もともと、 innodb_support_xa = 0 を設定した時は、// innodb_support_xa = 1 のとき 1. prepare (sync) 2. lock 3. write binlog (sync if sync_binlog) 4. commit (sync) 5. unlock // innodb_support_xa = 0 のとき 1. lock 2. write binlog (sync if sync_binlog) 3. commit (sync) 4. unlockとなることを期待していました。こうであれば、 fsync が prepare の分だけ減り、コミットに失敗しない限りは binlog とコミットログの一貫性は保たれるはずです。
しかし、 MySQL 5.5.31 のコードを見ると、実際には次のようになっていました。
// innodb_support_xa = 1 のとき 1. prepare (sync, lock) 2. write binlog (sync if sync_binlog) 3. commit (unlock, sync) // innodb_support_xa = 0 のとき 1. prepare (do nothing) 2. write binlog (sync if sync_binlog) 3. commit (sync)XA を OFF にすると、 prepare 時に取られていたロックが取られなくなり、複数スレッドで実行された時に binlog の書き込みとコミットの順序が守られなくなってしまいます。
しかし、 MySQL 5.5 と 5.6 では大幅に書きなおされているらしいです。
prepare_commit_mutexがMySQL 5.6に見当たらないんです
— SH2さん (@sh2nd) 2013年4月24日@methane 了解です。ha_innodb.ccのinnobase_xa_prepareでmutex取ってた部分がMySQL 5.6では空になっていて、だいぶリファクタリングされた感じです
— SH2さん (@sh2nd) 2013年4月24日MySQL 5.6 のソースを呼んでみたところ、 sql/binlog.cc の MYSQL_BIN_LOG::ordered_commit() という関数で、 binlog とトランザクションの順序を守る処理が入っていました。 (というか、 5.5 で呼び出し側がそれを保証しないせいで innodb 側でロックをとると言う設計が無理矢理過ぎですよね)
この関数は binlog の書き込み、 sync, トランザクションのコミットまで順番に行う関数で、複数スレッドで実行されても大丈夫なようにしつつ、 binlog をグループコミットするような実装になっています。
1. トランザクションを flush キューに入れる
2. lock(log)
3. (stage1) flush キュー内の全てのトランザクションを binlog に書き、 sync キューに入れる
4. lock(sync) & unlock(log)
5. (stage2) sync キュー内の全てのトランザクションを取り出し、
必要であれば最後のトランザクションまでのbinlogを sync してから、 commit キューに入れる
6. lock(commit) & unlock(sync)
7. (stage 3) commit キューの中身をすべて取り出し、順番にコミットしていく
8. unlock(commit)
この動作の解説とベンチマークが Binary Log Group Commit in MySQL 5.6 にありました。 XA を OFF にしてもトランザクションが失敗しない限りは binlog とトランザクションの一貫性が崩れないとはいえ、 innodb_support_xa=1 の時の性能が大幅に上がっているので、危険を冒してまで XA を OFF にする必要性は無さそうです。
この改善により、高負荷時は複数のトランザクションの binlog がまとめて書かれ sync されるのですが、残念なのは innodb 側のコミットは順番に1つずつ実行してしまうことです。 せっかく複数のトランザクションをコミット順に並べたのですから、トランザクションログへの書き込みも1回の fsync にまとめられたら性能が上がりそうです。
そういう改善がされていないのか検索してみたところ、 MySQL ではなくて MariaDB の方に見つけました。
[MDEV-232] Remove one fsync() inside engine's commit() method
この MDEV-232 により、各 commit ではトランザクションログを書くだけで fsync せず、最後にまとめて fsync するようになります。 最近いくつかのLinuxディストリビューションで採用されたことで話題の MariaDB ですが、 AWS の Multi-AZ のように fsync が遅い環境では MySQL よりも高い性能を出せそうです。また機会があれば、 MySQL 5.6 と Maria DB のベンチマークを取ってみたいと思います。
KLab でも最近は AWS を使ったプロジェクトがかなり増えてきました。 AWS で問題になりがちなのが、 RDB の性能が DSAS 環境に比べて低いことです。
DSAS ではバッテリーバックアップ付きのRAID + 非同期レプリケーションを使っているのですが、 RDS では Multi-AZ を使って耐障害性を確保しています。
この違いによって書き込み性能のチューニングのポイントが変わってきます。RAIDカードはデータが書き込みバッファに乗っている間は fsync が高速なのに対して、 Multi-AZ では別のAZにあるブロックデバイスに対して同期書き込みが実行されるので、 fsync のレイテンシが増えてしまいます。そこで、 fsync の数を減らすことと、書き込み並列度を上げることがより重要になってきます。
と、いうことは理屈でわかるのですが、実際にパラメータチューニングでどれくらい性能が上がるのかを実験してみました。対象となるパラメータは innodb_support_xa (デフォルト=1)と innodb_write_io_threads (デフォルト=4) です。
innodb_support_xa は2層コミットを有効にするオプションで、 mysql の内部でトランザクションログとbinlogの整合性をとるために利用されています。具体的には両方のログを書いて同期し、それが終わってからコミットして同期します。 これをオフにするとトランザクションログを書いてコミットして同期するだけで済む (デフォルトで sync_binlog=0 なので binlog 側は同期されない) ので、 fsync の数が減ります。
innodb_write_io_threads はバックグラウンドの書き込みスレッド数らしく、並列に同期する数ではないので、数字を上げてもどれくらい効果があるのかわからないのですが、とりあえず上限は16なのでこちらも設定してみます。
ということで、実際に試してみたときのスクリプトと結果がこちらです。
RDSベンチマーク結果
autocommit=1 の状態で簡単な update 文をひたすら並列に発行してトランザクション数を数えた結果、秒間トランザクション数が最大で2倍になりました。
注意点として、 innodb_support_xa を無効にすることで、フェイルオーバー時に binlog の整合性が保たれないので、 read replica を作り直す必要があります。これはDBのサイズによっては結構時間がかかるので、フェイルオーバー後は数時間サービスを停止するか、一時的にアプリのスレーブ参照をマスターに向けるか、（スレーブ参照はもともとレプリケーション遅延を見込んでいるはずなので）古い read replica をレプリケーションが止まったまま参照し続けるかする必要があります。
障害時の動作も試してみたかったのですが、電源ケーブルを抜いたりLANケーブルを抜いて突然死させられないのが RDS の難点ですね。
このライブラリの優秀さはスマートフォンでバーコード／QR コードを処理する際の実質標準の座にある状況からも裏打ちされていますが、ZXing スキャナの「使いやすさ」は本ライブラリの性能のみに依るものではなくアプリの実装に大きく支えられています。ZXing スキャナのソースコードは公開されているので、それに学べば本家と同等の使いやすさを備えた QR コードリーダーの自作が可能となるはずですね。操作性の良いリーダーを自作できるのであれば QR コード読み取り機能をアプリへ組み込む際にわざわざ ZXing スキャナをインテントで呼び出す必要はなく、独自の処理を柔軟に組み込むこともできるでしょう。また、上記ライブラリを知り尽くした ZXing 謹製スキャナのコードはライブラリの性能を最大限に引き出すための最良のお手本となりそうです。zxing Multi-format 1D/2D barcode image processing library with clients for Android, Java
ZXing スキャナのソースコードを正面から分析した情報はほとんど見当たらないようですが、手元での調査を通じて得られた情報と、そのエッセンスを小さくまとめた形で試作した自作リーダーのリソース一式を公開します。なお、この記事では ZXing 2.1 Release 中の zxing-2.1/android/ 配下のソースコードを対象としています。
なぜ ZXing スキャナは QR コードリーダーとして使いやすいのでしょう？その要素こそが実装を調べる上で注目すべきポイントとなるでしょう。特長をみっつピックアップしてみます。
コード読みの途中で迷子にならないための道具としてホワイトボード代わりにエクセルシートを使いました。あくまでも作業用なので決して見た目の良いものではありませんが記録としてそのまま掲載します。
コードリーディング時のメモ
以下、ソースコードから得られた情報を整理してみます。
以上のように、全体像が見えてしまえば ZXing スキャナの操作性を支えているのは意外なほどシンプルなしくみであることがわかります。それを自作のコードに組み込むことは難しくなさそうですね。そこで ZXing スキャナの実装に倣いつつできるだけ短いコードでざっくりとリーダーを作ってみることにしました。認識結果はダイアログ表示のみとしています。動作確認は一部の環境でのみ行っており、不具合があれば適宜手を入れて下さい。
ソースコードの一覧と概要を以下に示します。
ビルドずみの apk はここにあります
http://dsas.blog.klab.org/data/zxing_qr_scanner/MyQRCodeReader.apk
以前紹介した時のグリーン破壊は fork して複数プロセスから攻撃する方式だったのですが、 execnet というライブラリを用いて実際に攻撃を行う外部プロセスを作成するようにしました。
execnet は fork&exec だけでなく、 ssh 経由でリモートマシン上に外部プロセスを 作ることができます。グリーン破壊もこれを利用して分散攻撃ができるようになりました。
設定ファイル (YAML) に次のようなセクションを書くと、ローカルに2プロセス、
attacker ホスト上に 4 プロセスの合計6プロセスから攻撃を仕掛けることができます。
#破壊ノード
nodes:
- host: localhost # localhost の場合は ssh ではなくて popen します
proc: 2 # この host で起動するプロセス数
- host: ghakai@attacker # ssh先
proc: 4
注意点として、外部ホスト上で攻撃プロセスを立ち上げる時も、グリーン破壊を起動したマシンと同じ ディレクトリにある Python を利用するので、グリーン破壊をインストールしたディレクトリを rsync かなにかで同期しておく必要があります。
グリーン破壊を AWS で使う場合、1インスタンス当たりの性能は物理マシンほどでない ことが多いので、 Spot Instance と組み合わせて使うのがお勧めです。
過去のグリーン破壊は普通に、名前を問い合わせて、結果を上から順番に利用するという形で名前解決をしていました。
しかし、 Keep-Alive が無効のサービスに対して負荷試験するときに名前解決がボトルネックになったり、 AWS の ELB を利用したプロジェクトに対して負荷試験するときにローカルのDNSキャッシュのせいで 攻撃先IPアドレスが分散しなかったりすることがありました。
そこで、最初に名前解決を実行し、解決結果を全て覚えておき、接続する時は上から順ではなくて ランダムに利用するという方式に変更しました。
ただし、長時間攻撃を継続する場合、 ELB がスケールアウトしてもグリーン破壊は追従しません。 もともと可能な限り Keep-Alive する上に、接続が切れても再接続時に名前解決をしないからです。 ELB 経由で負荷試験を行う場合は、一度グリーン破壊を実行してウォームアップして ELB をスケールアウトさせてから、グリーン破壊を再実行してください。
また、思ったように負荷がかからないでレスポンスタイムが低下するときに ELB の問題と アプリの問題を切り分けるとか、 ELB のウォームアップが面倒なときのため、負荷分散を 通さず直接攻撃する機能も搭載しました。
設定ファイルに domain と addresslist の両方を定義すると、接続先は addresslist
からランダムに選ばれ、 HTTP の Host ヘッダには domain の内容が記述されます。
#攻撃先のドメイン. これ以外のドメインは攻撃しない.
# Host ヘッダにこのドメインが書かれる.
domain: "http://localhost:8889"
#接続先アドレスリスト. 省略した場合は domain を利用する.
addresslist:
- 127.0.0.1:8889
- localhost:8889
git annex とか、本格的なアセット管理システムとか使えば良いんだけど、普通のgitコマンド覚えるだけでいっぱいいっぱいな人にさらに他のツールまで覚えてもらうのは大変です。
そこで、登録しておいた拡張子のファイルはハッシュ値だけをリポジトリに格納し、ファイルの内容は別のディレクトリやAmazon S3に格納する git-largefile/gits3 を作りました。
git-largefile/gits3 は git の filter として動きます。 filter は通常改行コードの変換をしたり $Id$ のようなキーワードを変換したり行末のスペースを消す、文字通りフィルターなのですが、ここでファイル本体からハッシュ値へ、ハッシュ値からファイル本体への変換をしてしまいます。
これで、事前に設定ファイルと実行バイナリを配置しておいてもらうだけで、新しいコマンドを覚えることなく、 SourceTree for Windows などの GUI ツールもそのまま使いながら、リポジトリサイズの爆発を抑えることができます。
gits3 は Python でプロトタイプを作った後、 go で作りなおしました。
Go はシステムコールを発行する所がアセンブラで書かれていて、 libc にすら依存しない静的リンクされた実行ファイルが作れますし、クロスコンパイルも簡単です。msvcrt のバージョンとかでハマることもありませんし、 cygwin 上でシェルスクリプトや Perl スクリプト動かすのに比べて起動速度も早いです。
Go に興味はあるけど Go のメリットが活かせるアプリを開発する機会がなくて、、、という方は、 Windows ユーザーにも使ってもらいやすいコマンドラインツールの開発言語として使いはじめるのはいかがでしょうか？
その予習というわけでもないですが、最近 WebSocket を実サービスへの 導入方法を考えながら遊んでいたので、 WebSocket の負荷分散方法について 考えていることを書いておこうと思います。
HTTP サービスは基本的にステートレスな実装になっており、リクエストが来るたびに DBサーバーや memcached などのバックエンドから情報を取得して返していました。
この構成では Web アプリ自体は完全にステートレス化することができているので、 負荷分散機はラウンドロビン等のアプリケーションを無視した負荷分散をすることができました。
しかし、 WebSocket が登場してリアルタイム Web が普及し、それがリッチ化してくると、 ステートレス型では効率が悪くなる事があります。
たとえば複数のチャットルームを持つチャットアプリを作る場合、チャットの内容を Redis に格納し、 Redis の pubsub 機能を使って他の Web サーバーに更新を通知することができますが、 Redis は subscribe している Web サーバー全てに通知を送り、チャットログを取得するリクエストを さばかなければなりません.
MMO ゲームのようにアプリサーバーのメモリ上にチャットログを格納し、同じチャットルームにいる ユーザーが全員同じアプリサーバーに接続するようにすればどうでしょうか？ アプリサーバーはバックエンドから通知を受け取ったりメッセージを取得しなくても全員に メッセージを配信できます。これならバックエンドとの通信はログを保存する1回で済みます。
正攻法でこの構成を組む場合、アプリをステートレスなフロントWebアプリとステートフルな バックエンドアプリの2段構成にすることができます。 でも、この程度ならリバースプロキシで直接リクエストの振り分けをやってしまったほうが 楽だし低コストですよね。
そこで、 redis に URL のパスごとに分散先を格納しておき、それを使って動的に リバースプロキシする構成を考えてみました。
効率や応答速度のことを考えたら、リバースプロキシは WebSocket のデコード＆エンコードをする よりも、HTTP サーバーが Upgrade ヘッダを見つけると TCP プロキシとして動作するほうがいいはずです。
最初に目をつけたのは Go です。nginx よりはコードを読み書きしやすいからです。 (node.js でも良いのですが個人的には JavaScript よりも Go の方が好きです)
Go の標準ライブラリ "net/http" にはそのものズバリな revserseproxy があります。 ただしこれは WebSocket に対応していないので、ちょっと改造して Upgrade ヘッダを見つけると TCP プロキシになる機能を追加しました。 (methane/rproxy)
あとは redigo という Redis クライアント(名前がカッコイイ！) と組み合わせればお手軽に賢いリバースプロキシの完成です。
そういえば nginx も最近 WebSocket に対応したって話題になってたなーと思って調べてみると、 これも Upgrade ヘッダを見て TCP プロキシとしてふるまうようです。 さらに調べてみたら Redis + Lua を使って動的な負荷分散するサンプルもいくつかみつかりました。
ただし、 nginx のサブリクエストは基本的に HTTP 用であまり memcached や redis に格納した 生の文字列を扱うのに向いていないので、 lua-resty-redis という pure Lua のライブラリを使って書きなおしてみました。
これもちゃんと nginx の非同期機能を使ってくれるので Redis に問い合わせしている間 ブロックしたりはしませんし、コネクションプールも可能です。
せっかく作ったので Go 版を紹介したものの, nginx が使えるならもう nginx でいいですね。 でも、毎回 Redis に問い合わせるのではなく expire 付きの LRU キャッシュをインメモリでやるとか、 Socket.IO のセッションを解析して自分で Redis に格納するとか複雑なことをするなら Go の強みが生きてくるかもしれません。
お待たせしました。サンプルはこちらになります。
KLab/websocket-reverseproxy-demo
このサンプルでは、 Tornado を使ったオンメモリで動くチャットアプリを2つのポートで立ち上げ、 Redis にチャットルームごとのバックエンドを格納した上で、 nginx と go によるリバースプロクシの動作を確認しています。
Go も nginx も開発版を使っているので少しハードルが高いかもしれませんが、 SPDY & WS 勉強会の 参加者はぜひ予習として試してみてください。
昨年末、調べごとをしていた時にちょっと気になる商品が目に留まりました。 株式会社ビット・トレード・ワン 様の「USB 接続 赤外線リモコン KIT」という製品です。
特徴をざっくりまとめてみるとこんな感じです。
PC から制御可能な学習型赤外線リモコンといえば 2006 年の発売以来ロングセラーを続ける PC-OP-RS1 がとても有名ですが、このキットは昨年（2012年）発売された製品とのことで、ソフトウェア要素の多くがオープンであることに魅力を感じました。一方で 公式フォーラムを覗いてみるとエアコンまわりをはじめいろいろ制約もあるようで、それをどう考えるかは価格とのバランスの解釈次第でしょう。そういった話題も含めて好奇心をそそられ、年明け早々に入手しました。画像は「フリスク」と並べてみた様子です。
- [パソコンから家庭用機器をリモコン操作]、[リモコンでパソコンを操作] の２つの機能を持つ
- 赤外線送信用のライブラリやツール・ファームウェアのソースコードが公開されている
- 家電協/ NEC/ SONY の各リモコンコードフォーマットに対応
- 某清涼菓子のケースにぴったり収まるサイズ
- キットは 1,680 円、組立ずみ製品でも 2,480 円と低価格
- PC 側対応 OS はWindows 7, Vista, XP
PC とは A－miniB タイプの USB ケーブルで接続。Windows 上でヒューマンインターフェイスデバイスとして認識され標準の HID ドライバが使用されます。
さっそく専用の 送信用設定ツール に手元のいくつかの機器のリモコンコードを学習させ本キットから信号を出力し、それを元の機器が認識できるか否かを試してみると下の図の結果となりました。
続きを読む
]]>