2014年10月13日

WOL(Wake On LAN)非対応のNUCにリモートから電源を入れる

去年購入したNUC(DC3217BY)ですが、投げ売りされていただだけあって有線LANを持たず、WOL(Wake On LAN)を使ってリモートから電源を入れることができませんでした。

なので今までは省スペースPCという事もあり電源入れっぱで運用していたのですが、さすがにそれだと電気代が気になってくるので、こちらの記事を参考にしてRaspberry Pi経由で電源を入れる機能に挑戦してみました。

ピンヘッダをショート?

PCに電源ボタン以外で電源を入れる場合、マザーボードから出ているピンヘッダをショート(短絡)させるらしいのですが、”ショートって壊れるイメージ”ってくらいド素人なので、まずはこちらの資料をみつつジャンパーコードを使って手動で試して(よく映画とかで盗んだ車のエンジンを入れるイメージw)みたところ、確かに電源が入りました。

パーツを調達


ピンヘッダから電源が入ることを確認できたので、早速アキバで必要なパーツを調達する事に。購入した(使った)パーツは以下の通り。
前にRaspberry Piに温度/気圧センサーをつけた時は、単純にジャンパーワイヤーで所定の箇所につなぐだけでよかったのですが、今回ははんだづけが必要な様子。

しかも「降圧」「抵抗分圧」など専門用語が飛び交ってて何がなんやら。。ググってみたところ、前者はRaspberry PiのGPIOから3.3Vの信号がくるのに対し、LK-RB1は2Vの入力感度になるため抵抗を使って電圧を落とす?必要があり、後者は抵抗を使ったその方法になるようです。

確かにこちらの計算式に従って計算してみると、確かに出力は2.2Vになり参考記事の値と一致しました。

ブレッドボードを使っての仮組みとテスト

パーツが揃った(LK-RB1は先にはんだづけして組み上げ)段階で、まずはブレッドボードとクリップ付コードを使って本当に動作するか仮組みしてしてみたところ動作せず。。

てかそもそもどこが悪いのかさっぱり分からないので、追加でテスターを調達して改めて仮組みしてみたところ、「パチッ」というリレーの音とともにPCとつなぐ部分端子からテスターの反応を確認する事ができました!

NUCに配線して本組み

動作確認が取れたところで、NUCのマザーボードにあるピンヘッダからリレースイッチまでのコードを配線。NUC側はケンジントンロックの穴にわずかな隙間があったので、そこにコード線を無理やり通して対応しました。最後にRaspberry Pi側から以下のプログラムを実行して電源が入るかをテストしたところ。。無事電源が入ることを確認!
#!/bin/bash
GPIO_ID=17
B_TIME=0.5
echo ${GPIO_ID} > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio${GPIO_ID}/direction
echo 0 > /sys/class/gpio/gpio${GPIO_ID}/value
echo 1 > /sys/class/gpio/gpio${GPIO_ID}/value
sleep ${B_TIME}
echo 0 > /sys/class/gpio/gpio${GPIO_ID}/value
一つ一つの作業自体は大変でしたが、電子工作?初心者には手軽でかつ実用的な範囲に収まってよかったです。でもテスター購入とかあって”電気代節約”という本来の目的とは程遠い結果になってしまったので、これを使って次のネタを考えねばと思っています(苦笑)

    2014年9月15日

    ConoHaオブジェクトストレージを使ってみた

    今月上旬にVPSサービスのConoHaで、オブジェクトストレージのモニターを募集していたので応募してみたところ、当選の通知が来ておりました。

    というわけで、まずは技術ブログの手順に従ってAPIユーザを作成し、別途ソフトウェアのインストールを伴わないcurlコマンドで触ってみました。
    (さくらのBASE Storageと同様にs3cmdで、と説明も見ずにインストールしてたら、OpenStackのswiftというオブジェクトストレージを使っているというのを知ってcurlコマンドを使ったという。。)
    APIユーザの作成が完了すると、テナントID/テナント名/ユーザ名/API Auth URL/オブジェクトストレージエンドポイントが発行されます。

    トークンを取得

    curlコマンドでオブジェクトストレージを操作するためには、前述のAPIユーザ情報を使ってトークンを取得する必要があります。
    curl -i -X POST 'https://*****-*****.*****.jp/v2.0/tokens' \
      -H "Content-Type: application/json" \
      -H "Accept: application/json" \
      -d '{"auth":{"tenantName":"1234567","passwordCredentials":{"username":"1234567","password":"*******"}}}'
    実行すると{"access":{"token":...から始まるJSONが返却されますが、この中の"token"オブジェクトに含まれる"id"がトークンになります。以後のAPI呼び出しは"X-Auth-Token"ヘッダにトークンをつけて呼び出す形になります。

    コンテナの作成

    オブジェクトをストレージに格納するためには、まず「コンテナ」を作成する必要があります。コンテナはAmazon S3でいうところのBucketになる概念かと思われますが、特に全サーバで共通の名前でないといけないような感じではありませんでした("hoge"とかでも作れた)。また、ConoHa独自の機能として、コンテナの中にフォルダを作成する事ができるようです。
    curl -i -X PUT https://*****-*****.*****.jp/v1/3134..cdef/hoge \
      -H "X-Auth-Token: 0123..abcd"

    オブジェクトのアップロード

    コンテナを作成したらそこに対してオブジェクトをアップロードします。
    基本的にはコンテナの作成で使用したエンドポイントの末尾にファイル名を指定し、curlコマンドの-Tオプションでアップロードするファイル名のパスを指定する事でアップロードができました。
    curl -i -X PUT https://*****-*****.*****.jp/v1/3134..cdef/hoge/image.jpg \
      -T /Users/test/image.jpg \
      -H "X-Auth-Token: 0123..abcd"

    オブジェクトのダウンロード

    オブジェクトのダウンロードは、アップロードのPUTメソッドをGETメソッドに変えるだけです。
    curl -i -X GET https://*****-*****.*****.jp/v1/3134..cdef/hoge/image.jpg -O \
      -H "X-Auth-Token: 0123..abcd"

    オブジェクトのコピー

    ちょっと珍しいと思ったのがオブジェクトのコピーで、COPYメソッドを指定してコピー先をDestinationヘッダで指定する方式を取ってました。「HTTPにコピーメソッドって定義されてたっけ?」と調べたら、WebDAV関連で定義されているようです。
    curl -i -X COPY https://*****-*****.*****.jp/v1/3134..cdef/hoge/image.jpg \
      -H "Destination: hoge/image2.jpg" \
      -H "X-Auth-Token: 0123..abcd"

    オブジェクトの削除

    DELETEメソッドを指定する事でオブジェクトの削除となります。レスポンスヘッダが"204 No Content"と返ってくると削除成功となります。コンテナの削除も同様の手順で実行できますが、コンテナ下にオブジェクトがあると"409 Conflict"が返ってきて削除できませんでした。

    感想など

    以前試してみたさくらのBASE Storageと違ってAmazon S3互換が無いのはどうかなーと思っていたのですが、API自体はシンプルなので利用の障害にはならなそうな印象でした。しかもこちらの方は容量による課金でAPIコール数や転送量に対しては課金されないことから、用途によってはAmazon S3よりメリットがありそうです。

    2014年9月6日

    MQTT Meetup Tokyoに参加してきました

    今日は仕事をちょっと早く切り上げて、株式会社ドワンゴさんで行われた「MQTT Meetup Tokyo」に参加してきました。実は先週同じイベントがあったのですが、そちらは人気があって急遽同じ会を行う事になったそうです。

    今回は、ツキノワ株式会社の若山氏(@r_rudi)と、株式会社時雨堂の@voluntas氏の講演が行われました。

    MQTTの機能概要 〜新仕様の紹介も少し〜


    MQTT meetup in Tokyo 機能概要 from r_rudi

    MQTTの特徴を、できたてホヤホヤのMQTTクライアントを使ったデモを交えてご紹介。特にWill/Retain/CleanSessionのデモは、「確かに遺言だー」「CleanSession復帰した瞬間送られてきたー」というのが分かりやすくてよかったです。

    休憩の際にどら焼きを頂きました。

    MQTTブローカーAKANEの実装にあたってつらかった話


    時雨堂 MQTT ブローカー (AKANE)

    先月末にサービスインしたばかりのMQTT as a ServiceのSangoで、Erlang製MQTTブローカーAKANEを実装するにあたって、仕様周りやそれに素直に従った際のつらみなどを面白おかしく聞かせて頂きました。

    メモ


    • 固定ヘッダは2バイトだけど、ペイロードが大きければHTTPと変わらない
      • MQTTではクライアントが万単位で接続される世界を想像する
      • ペイロードにはJSONやMessagePackを積む事が多い
    • (PublisherがSubscriberにもなれる事から)Microservice的プロセス間通信に使えそう
      • TopicにUUIDを指定してPub/Subすれば一対一の通信ができる
    • NATを超えて双方向通信できる
    • Topicは#や+を使って特定の階層や合致するもの全てを対象とする事ができる
      • SNMPのMIBみたいな感じ?
    • 最新のMQTT仕様が今月27日に確定する予定
      • Topic名がUTF-8固定に
    • 商用MQTTブローカーは世の中に2製品しかない
    • Will/Retain/CleanSessionのクライアント側負担が小さい分サーバ側は負担が大きい
      • QoSダウングレード
      • リトライとRetain
        • これら全てQoSダウングレード&リトライ&Retaionの面倒見る必要あり
      • $SYS Topicの統計情報管理
    • github.comはWebhookで既にMQTT対応済み(!)
      • Facebookメッセンジャーの通信もMQTTらしい
    • Erlangはメッセージパッシングすると性能劣化する
    • 同期通信をやりたいならHTTPの方が向いている
    • サービス名であるsangoの由来は色
      • 他のプロダクトも色由来らしい
    • MQTTはエラー定義が少ない
    • クライアント側でもバッファ処理などはある程度必要
    • QoS2はDBの二相コミットと同じ

    感想など


    個人的な興味から参加した会でしたが、やはり文章で見るより面と向かって語られた方が可能性をより感じる事ができました。

    元々はモバイルアプリの行動ログ送信や、リアルタイムチャットのプロトコルとして使ったら面白そうと思っていたのですが、ほとんどがQoS2の送達保証を選ぶ事になりそうで、HTTPとの差別化をどう出していくかが難しそうに感じました。

    とりあえず、自宅で部屋の温度を測定し続けているRaspberry PiにでもMQTTをしゃべってもらって、引き続き可能性を探っていきたいと思います。
    (ちなみに部屋の温度はXivelyに送っているのですが、普通にMQTTに対応してました。そりゃ"IoT Platform"を名乗るだけあって当たり前か^^;)