cloud

2017年01月20日

さよなら Parse

はてなブックマークに登録

はじめに

世界中の利用者の指先と視線を凝固させた突然の発表からまもなく 1年、Parse.com の全サービスが いよいよ 2017年1月28日(土)に終了します。拡張性が高く高機能でありながら使い勝手の良い優れたサービスだったので終息が惜しまれます。

      https://parse.com/

手元では 2年ほど前に IoT の実験として試作した以下のしくみ「Anpi」で Parse.com を採り入れました。

  • mbed と Parse で作る高齢者世帯安否確認システム - 当ブログ
    一般に BaaS の主な目的はアプリケーションの対向サーバ側機能を代替・補完することにあり、サーバの管理運用やサーバ側コード開発に踏み込むコストを抑制しアプリ本体の開発に注力可能となることが利用者にとってのメリットですが、Parse にはサーバ上でユーザコードを実行することのできる「Cloud Code」というしくみが用意されています。(中略)今回作った装置は Parse サーバ上に設置した自作コードをそのまま呼び出して必要な処理を行っています。このように目的に応じて柔軟に利用できることが Parse の魅力のひとつと言ってよいでしょう。
この「Anpi」はシンプルながら実用性が高く現在もプライベートで大いに役立っています。そのためすでに Parse.com からの乗り換えを完了していますが、移行の過程で複数のプラットフォームを対象として再実装を横断的に試してみました。今後必要となった際にスムースに想起できる道具立ての選択肢は多いほうが好ましく、今回のように具体的な要件があればその実装を通じて未体験のサービスの特徴や個性を見定めやすいと考えたためです。この記事はそういった試みの記録で、日本国内ではまだ知名度の低いものにも触れています。興味のある方はご覧下さい。

※文中の記述はいずれも 2016年11月から12月の時点の状況に基づくものであり現在の事情とは異なる可能性があります。あらかじめご了承下さい。

手元の要件と移行先選定基準

「Anpi」において Parse.com サイドで行っていた処理は以下の内容です。

  • 屋内に設置ずみの装置が人感センサ反応時に最短 30 分間隔で送信してくる情報をデータストアへ保存
  • 定刻に直近 60 レコード分をレポートとして所定のアドレスへメール送信
  • 装置につないだボタンが長押しされたら所定のアドレスへメールで通知(緊急メール)
  • メール配信には Parse.com が 公式 API で連携している Mailgun サービスを利用

要件に特に煩雑なものはなくこれらを吸収可能なサービスはいくつも存在するでしょう。その上で、今回は次の三点を移行先選定の基準とすることにしました。

  • 運用に手がかからないこと
  • 柔軟性があること
  • 費用がかからないこと
絵に描いたようなユーザエゴではありますが、当時 Parse.com を選んだ理由はこれらのすべてを満たしていたためでもあります。予備調査を経て次のサービス・プラットフォームを検討の対象としました。

  1. IFTTT + Google Drive + Google Apps Script
  2. Kii Cloud
  3. back4app(+ AWS Lambda)
  4. Backand

なお、要件のうち「緊急メール」の発信については以前「今、ワンボタンの IoT デバイスが面白い」でも利用した SendGrid サービスの API を装置側のコードから直接叩くことにしました。メールの内容は決め打ちなので各サービスに仲介させるよりもそのほうが合理的と考えたためです。

以下、上のよっつを順番にピックアップしてみます。

移行先候補 1: IFTTT + Google Drive + Google Apps Script

もっともシンプルに要件を満たす道具立てとしてまず IFTTT と Google サービスの組み合わせを考えました。IFTTT 経由で Google Drive 上の Spreadsheet をデータストアとして利用し Google Apps Script でサーバサイドの処理を実行する内容です。

仮移行を通じての * 個人的な * 印象

GOOD !

  • シンプルかつ柔軟
  • Google, IFTTT ともに今後課金の発生する可能性がきわめて低い
  • Google, IFTTT ともに今後サービスが終息する可能性がきわめて低い
  • コードを含めすべてをブラウザ上で操作できるため運用上の自由度が高い
! GOOD ?

  • 今回の要件には十分だが規模の大きいデータを扱うには不向き
  • あくまでも SaaS とハブサービスの組み合わせであるため当然ながらプッシュ通知など一般的な IoT プラットフォームの提供する機能は代替できない

移行先候補 2: Kii Cloud

Kii CloudKii 株式会社様の提供する日本発の BaaS です。

仮移行を通じての * 個人的な * 印象

GOOD !

  • 多機能かつ無料枠が広い
  • Parse.com と同様に BaaS でありながらサーバ機能拡張が可能
  • サーバのリージョンを自由に選択可能であり特に中国リージョンの存在は大きい
  • キーバリュー形式のデータは使用容量にカウントされないため他のサービスとの併用にも好適か
  • アクセス制御機能が充実
  • 日本語のリソースが充実している

! GOOD ?

  • ドキュメントの情報量は豊かだが通読性がもうひとつ?リンクの張り方にも改善の余地がありそうな印象(このあたりが改善されればより利用しやすくなるかも)
  • 開発者ポータルは UI・機能ともに今後の進化が期待される
  • 開発用のコマンドラインツールが Node.js ベースなのは利点と欠点が半々くらい? バッチジョブのスケジュール変更といった操作はブラウザ上でできると嬉しい・・

移行先候補 3: back4app(+ AWS Lambda)

back4appBACK4APP SERVICOS DIGITAIS LTDA(本社 米カリフォルニア)の提供する BaaS です。

仮移行を通じての * 個人的な * 印象

GOOD !

  • 無料枠が広い
  • 最初から Parse.com の代替用として起ち上げられた純度の高い Parse Alternative であるため Parse.com との親和性が高く移行が相対的に容易
  • UI, ドキュメントがわかりやすい

! GOOD ?

  • 記事中のジョブ設定の問題など現時点では荒削りな側面も見られる
  • Parse.com を継承するサービスとしては良好だが、逆にそのことが独立した BaaS としての新鮮味や個性の発露を削いでいる印象も?

移行先候補 4: Backand

BackandModuBiz Ltd(本社イスラエル Tel Aviv)の提供する BaaS です。

仮移行を通じての * 個人的な * 印象

GOOD !

  • 多機能かつ拡張性に優れている上に非常に使いやすい
  • テスト・デバッグ機能も充実しており UI もわかり易い
  • ファイルホスティングまわりの操作以外はすべてブラウザ上で完結できるため機動性が高い
  • ユーザビリティは今回の中で一番。あとは可用性とスケーラビリティ次第か

! GOOD ?

  • 無料枠の狭さが残念。また、Prototype Plan $0 -> Hobby Plan $19/月 -> Work Plan $49/月 ... といった大きめの料金差に比して待遇差が小さめ
  • 運営側の内部的な指標である「Cache Memory」「Compute Units」のように利用者が主体的にコントロールすることの難しい指標がプランの基準に含まれているため利用目処を立てにくい(むしろ、利用するならはじめから UNLIMITED な料金プランを選ぶべき)
  • 日本のみならず国外でもまだあまりメジャーではなく情報がとても少ない。優れたサービスであるにもかかわらず世間への浸透圧が低い一因は上の料金体系にもあるのではないか?

(2018-01-19 追記)
2018年1月18日、Backand より 2月28日にサービスを終了する旨のメールが届きました。その後手元では利用していませんでしたが、品質の高いサービスであっただけに残念です。

おわりに

手元要件の Parse.com からの移行にあたり以上よっつの環境を試してみました。最終的にこの中のひとつを「Anpi」の乗り換え先に決定して現在に至ります。当初はどれを選んだのかを書くつもりでしたが無粋にも思いやめておくことにしました。いずれも質の高いサービスでそれぞれに十分なメリットがあります。

ほんの10年ほど前には影もなかったものが日進月歩で進化していく状況にリアルタイムで向き合っていると10年後の世界への想像が膨らみます。この時代の傍らを去っていく Parse.com をユーザのひとりとして敬意と感謝の念をもって見送りたいと思います。


(tanabe)
klab_gijutsu2 at 14:26|この記事のURLComments(0)
2016年03月11日

「入院者と外部とのコミュニケーション」への IoT の応用

はてなブックマークに登録

フェイススケールのこと

先日身内が入院した折にこういう顔の絵の入ったクリアファイルを病棟で見かけました。

フェイススケール(英: Face scale)とは、現在」の痛みを「にっこり笑った顔」から普通の顔、
そして「しかめっ面」そして「泣き顔」までの様々な段階の顔を用意して、神経痛などの痛みを
訴えている患者にどのぐらい痛むのかを示してもらうことで、その痛み度を客観的に知るために、
ペインクリニック・麻酔科などで用いられる用具・用紙のことである。
看護師さんがベッドに横になったままのご高齢者にこれを見せながら大きな明るい声で尋ねている様子が印象に残りました。たった一枚の印刷物ですが、自由に話したり体を動かしたりすることのむずかしい状態の入院者とのやりとりには特に有用なツールであることが想像されます。

入院者と外部とのコミュニケーションへの IoT の応用

携帯端末での電子メール利用の普及により入院者と外部との連絡はメール以前の時代に比べ格段に便利になりました。病室内での通話は無理でもメールの送受信は多くの場合認められており、おそらくは施設側が伝言を取り次ぐ頻度も昔よりもずっと少なくなったことでしょう。

その一方で、症状や状況によっては小さなキーを操作することが困難であったり、あるいは携帯端末やメールとの接点を想像しにくい雰囲気の入院者も少なくないことを連日の病棟内の光景であらためて実感しました。残念なことに、現実にはそういう人たちにこそ関係者との日常的なつながりがより必要なケースが多いようにも感じられます。たとえ最小限の内容であっても当事者間で手軽にコミュニケーションをとることができれば双方の不安が確実に軽くなることを考えあわせると、社会の高齢化が進行する状況にあってこの話題は潜在的な必要性の高いテーマのひとつと言えるのではないでしょうか。

試みに、フェイススケールをヒントに病室内での使用を想定してごく簡単な操作で離れた相手とメッセージを交わすしくみを形にしてみました。身近な場面での実用性のある IoT のアイディアとして紹介します。

試作装置の外観と概要

下の写真の装置のいずれかのボタンを押すと相手側の装置の同じ絵の下の緑の LED が点滅し、併せてその絵柄を添えたメールが所定のアドレスへ届きます。
親しい間柄の人や自分自身が病室のベッドで苦しんだ経験のある方にはわかるのではないかと思いますが、いま入院者に「ボタンを押すだけの余力」と「絵柄を選択する意識」があるということを情報として伝えられることには、離れて案ずる側にとっても入院者自身にとってもそれ自体に大きな意味があります。また、一方通行ではなく相手からの反応が手元に届くことは双方の精神的な支えとなるでしょう。写真のとおり、互いに言葉や意味ではなく気持ちや意識を伝えることに主眼を置いてそれぞれのボタンの絵柄はあえて解釈の余地の広いものを選んでいます。

※クリックで大きく表示
 

装置を病室に設置したイメージ

メールには押したボタンの画像がインラインで表示されリンクのクリックで返信用のページが開く

  • インターネット接続環境を備えた入院施設が少ないことを考慮し装置は現在もっとも低コストでモバイル通信のハンドリングが可能な Raspberry Pi + 3G モデムの構成で MVNO SIM を使用しておりコンセントひとつで稼働可能
  • 自分が押したボタンは赤 LED の点灯、相手の押したボタンは緑の LED の緩やかな点滅で示される
  • 装置間のメッセージングには Milkcocoa 、メール送信には SendGrid を利用
  • 赤ボタンの押下で各 LED を消灯、5秒以上の長押しで装置をシャットダウン
  • 右端の LED は装置の稼働を示すパイロットランプ

動作の様子(動画:2分20秒 音声なし)

このデモ動画は入院者側が実装置を使用し相手側がインターネット接続環境のもとで Web 版の仮想装置を使用することを想定した内容です。もちろん二台の実装置間での応酬も可能です。

画像について

今回の試作では画像がコミュニケーションの仲介者として大きな役割を担っており、これらは病室という気持ちの沈みがちな空間に小さな癒しを灯すシンボルでもあります。一連の画像は Beeboo.SLI(ビブースライ)様が運用される画像素材サイト 「イラスト無料素材 イラストボックス」I<アイ>さん が掲載された作品を加工して使用させて頂いています。I<アイ>さんの素敵なイラストと素晴らしいサイトに謹んで御礼申し上げます。

装置づくり

メインの要素

これらに説明は要らないでしょう。いずれも「持っていると便利」な道具です。
Raspberry Pi 2 Model B

アマゾンで 5,000円前後
3G USB モデム: L-05A

2015年10月に「イオシス」で 1,180円で購入(中古)
MVNO SIM:0 SIM
デジモノステーション 2016年02月号付属版)

手元の SORACOM Air とどちらを使うか迷ったが今回は 0 SIM を使用

筐体の材料と加工

今回の装置では操作用のボタンの選定が大きなポイントでした。小さすぎず大きすぎないものを探し以下の製品を選びました。

パネル取付用押しボタンスイッチ(緑色)です。過酷な使用に耐えられるヘビーデューティー
仕様です。プッシュ機構部(樹脂製)とマイクロスイッチで構成されています。

このボタンは取りつけ時の占有直径がおよそ 34mm で、これを 5mm 程度の間隔で 7つ設置するには最低 28cm ほどの長さが必要です。100円ショップをいくつか見てまわり筐体として写真のパスタケースを選びました(長さ:30.6cm 幅:8.5cm 高さ:7.6cm)。 蓋の方が少し広めの台形で、固い底のほうを上にすれば安定感があります。

このケースの底にボタンを取りつけるには厚さ 3mm のポリプロピレン板に 30mm 程度のまるい穴が 7つ必要です。今の自分の工作力ではこのように硬く厚みのある素材に綺麗なまるい穴をあけることが難しく、練習用の予備であれこれやってみましたがなかなかうまくいきません。店先でたまたま野菜調理用の金属製の抜き型が目にとまりました。下の写真の大2 + 小2 セットの「小」の持ち手側の外径が 3cm に近く、試しにこれを熱してケースに押し当てるとちょうどよいサイズの綺麗な穴が得られました。ケースの両端には 1cm のマージンを設け、シャットダウンボタン用の一番右の穴は隣りと 1cm 離してあとは 5mm 間隔で穴をあけました。

野菜の抜き型 (金属製)

穴をあけ終えたケース

パーツの取りつけ

実際にボタンを取りつけてみると全体の印象は当初のイメージどおりでした。ただ、ボタン 7個、LED 13個分の計 40本の配線を内部の残りのスペースの四方へめぐらせるには電子工作用の一般的なワイヤでは固すぎて取り回しに融通が利かず、柔らかい導線を加工して筐体内の隙間へ這わせることにしました。スペース節約のため GND への繋ぎ込みにはメスのピンソケットのオス側をスズメッキ線で連結したものを使いました。

ざっくり結線。ワイヤが固い

導線にLEDと抵抗とハンダづけして末端をオス・メス化

裁断した色画用紙を加工

ケースへ一式を収納して動作確認

ソフトウェア要素

作成したプログラム類一式を以下の場所で公開しています。

https://github.com/mkttanabe/iot_hospital

使用しているソフトウェア資産とサービス

土台の Raspberry Pi 2 Model B には標準ディストリビューションの Raspbian をインストールずみで今回は以下のソフトウェア資産を使用しています。

また、ふたつの優れたサービスを利用しています。
  • Milkcocoa 装置間のメッセージング用
  • SendGrid 実装置からのメール送信用

メインプログラム

実装置用のプログラム本体は Node.js スクリプトとして記述しています。

/home/pi/node/iot_hospital.js

Web 版仮想装置のページは以下の URL から参照できます。

http://dsas.blog.klab.org/data/iot_hospital/index.html?ID02&ID01

注:Web 版の動作には Milkcocoa アカウントを取得し 22行めに正しい APP ID を指定する必要があります

モデムまわり

L-05A + 0 SIM の組み合わせでのインターネットへの接続には wvdial ユーティリティを使用しています。/etc/wvdial.conf は以下の内容。"sudo wvdial" の実行で接続を開始します。

/etc/wvdial.conf

[Dialer Defaults]
init1 = ATZ
init2 = AT+CGDCONT=1,"IP","so-net.jp"
Password = nuro
Username = nuro
Dial Attempts = 3
Stupid Mode = 1
Modem Type = Analog Modem
Dial Command = ATD
Stupid Mode = yes
Baud = 115200
New PPPD = yes
Modem = /dev/ttyACM0
ISDN = 0
Phone = *99***1#
Carrier Check = no

※L-05A はゼロインストール機能を内蔵しており出荷時の設定により USB 接続時にはデフォルトで CD-ROM デバイスとして認識されます。eject コマンドで毎回これを解除するのが煩わしいため手元ではデフォルトで USB モデムとして認識されるように設定を変更しています。

モデムモードに設定した L-05A は lsusb コマンドで以下の要領で表示されます。

Bus 001 Device 004: ID 1004:6124 LG Electronics, Inc. 

スタートアップまわり

システム起動時に今回の一式を自動実行するために /etc/rc.local に iot_hospital.sh の呼び出しを記述しています。 iot_hospital.sh は L-05A が装着されていれば wvdial でインターネット接続を試行し、接続に成功すれば前掲の iot_hospital.js を実行します。

/etc/rc.local

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
  printf "My IP address is %s\n" "$_IP"
fi

# run app
sudo /bin/bash /home/pi/node/iot_hospital.sh &

exit 0

/home/pi/node/iot_hospital.sh


(tanabe)
klab_gijutsu2 at 07:01|この記事のURLComments(2)TrackBack(0)
2016年01月01日

ネットワーク対応の光通知デバイスを自作してみる

はてなブックマークに登録

「blink(1)」のこと

コードネームのような製品名ですが、「blink(1)」は KickStarter 発のカスタマイズ可能な USB デバイスです。接続先の機器やネットワークから所定の情報を受けとると LED 光の色や明滅により人間への通知を行うもので、2012年に製品化され 2013年には IFTTT との連携機能を強化した blink(1) mk2 がリリースされています。

文字の情報は人間が意識的にそこに向き合わなければ伝わらず、音の情報は状況により場の環境を乱す可能性があります。一方、「光」による情報はそれが適度な明るさであれば他の何かを妨げることなく人間の視界へ届き自然に認識され得ます。そのことを応用した例は他にも見られますが、blink(1) もまた光の特性を活かした機器のひとつです。

www.kickstarter.com gigazine.net gigazine.net
※詳細なレポートが GIGAZINE 様の以下の一連の記事に掲載されています。 この blink(1)、なかなか楽しそうなので使ってみたいと思いました。ただ、日本国内には今のところ代理店がなく国外のマーケットから購入することになりますが、これが * 微妙に高価 * なのですね。 そこで、一連の機能の中でもっとも興味のあるネットワーク連携部分を自作してみることにしました。どこかで何かがあったら知らせるというのはまさに IoT 向きのテーマであり、また、普段は主にバイプレイヤーである LED が一躍主役となるちょっと面白いケースでもあります。装置は「Wi-Fi 機能つきの小さなマイコン」としてこのところ何かと重宝している ESP8266 モジュールをメインに構成すれば手近な素材のみでも USB ポートへ直挿し可能なサイズに収めることが可能でしょう。装置へのメッセージング用のソリューションには今回 PubNub を選びました。

PubNub のこと / ESP8266 との関係

PubNub は Pub/Sub モデルのリアルタイムメッセージング機能を主軸とする BaaS です。 2010年のローンチ以来スマホや Web アプリ向けのプッシュ通知サービス等を展開、近年は IoT 方面にも注力しており対応言語・環境の広い有用なプラットフォームのひとつです。サポート対象は現在も拡大中、ちなみに無料枠もなかなかの太っ腹です。

また、GET リクエストベースの REST API セットが用意されており(HTTPS, HTTP)、これを利用すれば他のシステムやデバイスからも PubNub の所定の Channel へ柔軟にメッセージを送ることが可能です。 このように便宜の大きい PubNub ですが、この記事を書いている 2015年12月時点では実は肝心の ESP8266 がまだサポートされていません。でも幸い非公式のクライアントライブラリが公開されていることを知りました。本家の GitHub リポジトリにも fork されていることから非公式ながらも公認の位置づけのようです。 上の記事のとおりこの非公式ライブラリは任意のタイミングでの双方向通信には対応していない(subscribe() 呼び出し後の受信完了前には publish() 不可)ものの、今回想定している装置はもっぱら受信側であるため特に支障はなさそうです。作者の Kurt Clothier さん自身が「can be adjusted for a particular need」と書いているようにライブラリコードは用途に応じ適宜手を加えて利用すれば良いでしょう。
なお、このライブラリは Espressif 社による純正の ESP8266 SDK 向けに記述されています。より扱いやすい Arduino IDE for ESP8266 環境でも利用できるように併せて手を加えることにしました。

試作の動作の様子 (動画:1分11秒 環境音・操作音あり)

下の動画は、作成した装置へ PubNub の Web コンソールからメッセージを送り動作を確認している様子です。各メッセージはそれぞれ一行の REST API 記述に置き換えることができます。     

手元での現在の使途

手元ではこの試作を下記の要領で使用中。「光による通知」が想像以上に便利で実用的であることを実感しています。スマートさや表現性は blink(1) に及ばないものの必要になれば好きなようにいじれることが手作りの利点ですね。

  • 黄点灯:明日の予報が雨の場合
    (IFTTT レシピを利用)

         クリックで可読大表示
    ありがちなテーマだが実際に使ってみると手放せなくなる。好天続きで何となく油断している折に不意に点灯を目にしたら直ちに予報をチェック。

  • 青点滅:高齢者世帯の安否確認装置に反応があった場合
    Parse.com サーバサイドの Cloud Code を利用)

         クリックで可読大表示
    人を検知すると最短 30分間隔で Parse.com へレポートを送出する自作装置を実家で稼働中。対向するサーバ側コードに試作への通知処理を追加。光れば安心、メールによる通知よりも即時性が高く煩雑感が小さい。

  • 赤点滅:特定のユーザからのツイートがあった場合
    (IFTTT レシピを利用)

          クリックで可読大表示

    件数は少ないがいつも非常に有用な情報を提供してくれる某氏のツイートを見落とさないために。

  • 緑点滅:所定のブログが更新された場合
    (IFTTT レシピを利用)

          クリックで可読大表示

    とりあえず昨年末 「KLab Advent Calendar 2015」のチェック用に使ってみたらとても快適。

  • 管理用 HTML フォーム

          クリックで可読大表示

    PC・スマホの Web ブラウザから装置へメッセージを手早く簡単に送るために用意。 [ソース]

装置について

外観と構成

    

       クリックで可読大表示

材料

メモ

  • blink(1) は PC など対応機器の機能を利用するが今回の装置はネットワーク専用であり通信機能を内蔵しているため USB AC アダプタでも使える
  • USB 端子は規格上両端の2本が 5V (500mA) OUT と GND
        
  • フルカラー LED ではなく赤・緑・青・黄の 4つの単色 LED を使用。LED 用の抵抗は現物の発色をみながら「赤 75Ω 緑 75Ω 青 470Ω 黄 390Ω」に
  • LED の表示は各色「点灯・点滅」の二種類で合計 8パターン。これは手元での実利用を想定し妥当と判断した数
    (複数 LED の点滅時は明滅のタイミングが重ならないようプログラム側で管理)
  • 輪ゴムは USB コネクタ外抜け防止用
  • エアキャップはタッパ蓋の下に中敷き。LED 光拡散、外観柔和化、USB コネクタとタクトスイッチの圧迫用
  • タッパ蓋の上からタクトスイッチを押すと装置がリセットされる。電源接続時と LED 消灯用に使う

プログラムについて

ESP8266 用 PubNub ライブラリ

前述のように現時点では PubNub は ESP8266 を正式にサポートしておらず Espressif 社純正 SDK 向けの非公式ライブラリが公開されているのみです。これに以下の要領で手を加えて使用しています。

  • Arduino IDE で利用できるように
  • publish() の完了通知用にコールバックを登録可能に
  • HTTPS 対応

以下にソースコードを掲載します。ライブラリ「pubnub-esp8266」はファイル一式をローカルの Arduino ライブラリフォルダ下の pubnub-esp8266/ 下へコピーして使います。

(キーワード "DSAS" 部分がオリジナルからの変更箇所)

pubnub.h - GitHub

pubnub.cpp - GitHub

Arduino スケッチ

アプリ側のコードです。Arduino の SimpleTimer ライブラリを併用しています。

LEDMessage.ino - GitHub

作るのは簡単、アイディア次第でとても便利に使えます。


(tanabe)
klab_gijutsu2 at 00:41|この記事のURLComments(0)TrackBack(0)
2015年11月06日

今、ワンボタンの IoT デバイスが面白い

はてなブックマークに登録

米アマゾンが 2015年3月31日に発表した「Amazon Dash Button」はボタンを押すだけで所定の日用品のオーダーを可能とする小さなデバイスです。電池交換は不可。アイテムごとに専用のデバイスが用意されています。

Dash Buttonはただの通過点、アマゾンが真に狙うは家電すべてとの連携ショッピング:ギズモード・ジャパン
当初 Dash Button の利用は招待制でデバイスは無料で配布されていました。その後$4.99 での販売に変更され、2015年9月に米アマゾンは Dash Button ビジネスの拡大方針を決定しています。好調のようです。

なお、今のところこのサービスの日本での開始はスケジュールされておらず、米アマゾンから Dash Button 単体を購入することもできません。

2016-12-22 追記:
Amazon.co.jp は 2016年12月5日に日本国内で Dash Button サービスを開始しました。これに伴い関連する以下の記事を当ブログに追加しています。

ワンボタンデバイスのメリットと応用例

Amazon Dash Button は事業形態としても面白そうですがこの記事ではデバイス本体に注目します。Dash Button の実体はマイコンと無線 LAN モジュールを主要素とする乾電池駆動の IoT デバイスです。

       
http://mpetroff.net/

Dash Button は独立した装置なので必要な折にスマートフォンアプリ等よりも素早く使用することが可能。ボタンひとつの単機能であることが手軽さと即応性をさらに高めています。 この迷いようのないユーザインターフェイスは、その素朴さとは裏腹に、関係者が消費者への効果的なアプローチを模索する過程において綿密に戦略を練った結果と想像されます。一見「誰でも思いつきそうなこと」はそれが本当に実現されればしばしば斬新です。手軽さといえばスマホばかりに目が向けられる現状においてあえて専用ハードの形態を選んだ発想には学ぶべき要素があるように思います。

このデバイスのアイディアはビジネス用途以外の IoT においても広く活用することが可能でしょう。「物理ボタンの押下」という手間がかからず誰にでもできる簡単な操作をトリガーにどのような処理を行うかはアイディア次第であり、その便宜と魅力に気づいた向きがこの安価な Dash Button を本来の目的以外のことに利用し始めています。以下にいくつか例を挙げます。

  • How I Hacked Amazon’s $5 WiFi Button to track Baby Data (2015ー08ー10) - medium.com
    おそらくこれが最初の Dash Button 転用例。Edward Benson 氏は自宅で乳児の排泄日時を手早く記録・管理する手段を探す中で、夜中にスマホを操作する煩わしさもなくボタン押下のみで完結する Dash Button の長所に着目した。
    "using your smart phone at night disrupts sleep. I want a simple button I can stick to the wall and push to record"

    Amazon へのオーダーを行う上で本来必要な初期設定を意図的に保留。デバイス本体をハックするのではなく、ボタン押下〜デバイス起床時に LAN 上に流れる ARP パケットに注目し、当該デバイスの MAC アドレスを検出すればそれをトリガーに PC で処理を実行する手法によって要件を実現した。


    https://medium.com/
    「The Internet of Things is already here.」という結語が印象に残る。デバイスのコストを事実上度外視して Button を供給しているアマゾンにとってはあまり歓迎できない試みと思われるが、本体を改変しているわけではなく意味的には単に「未登録」の状態に過ぎない。この手の転用が拡がれば何らかの対抗措置を敷かれる可能性が皆無ではないものの、現時点ではこうした行為に対し直接クレームをつけることは難しいだろう。

  • Amazon Dash — It’s Dinner Time! (2015ー08ー27) - theappslab.com
    Raymond Xie 氏は Dash Button のコストパフォーマンスの高さに大喜び。稼働中に熱を持つ PiTFT をコードを抜かず簡単に ON/OFF する目的にさっそく利用していたところ奥方からもっと実用的なことはできないの?と聞かれ、ヘッドホン装着率の高い二階の子供たちを夕食時にいちいち呼びに行く代わりに Dash Button で子供部屋の フィリップス ヒュー を点滅させることを思いつく。Button は台所の奥方の手に。

  • PizzaDash (2015ー09ー12) - github.com/bhberson
    前出の Benson 氏の記事に触発された、と Brody Berson 氏は Dash Button をドミノピザの宅配オーダーに利用(無論アマゾンとは無関係)。ボタン押下をトリガーに Raspberry Pi が ドミノピザ公式 API を叩いて注文成立。
    2015-11-25 追記:
    英国ドミノピザが公式にワンボタンのオーダーサービスを開始する旨の情報あり (2015-11-23) "PizzaDash" からの影響の有無は不明だが、dominos 社はこれまでに独自の様々なオンラインオーダーシステムを確立しており IT 活用にきわめて積極的

  • Amazon dash button automation silliness. (2015ー09ー26) - www.youtube.com
    Michael Donnelly 氏による Youtube への投稿動画。玄関の照明を点灯/消灯したり、ガレージの車の内部が一定の温度になったらクラクションを鳴らしたり。

  • Dash Hacking: Bare-Metal STM32 Programming - learn.adafruit.com
    Adafruit 社TONY DICOLA 氏による正面からの Dash Button ハックの試み。ファームウェアを書き換え本体の LED を自作のコードで制御。"this guide didn't touch on the Dash's WiFi module yet" とのこと。

また、米アマゾンウェブサービス(AWS)は 2015年10月の AWS IoT ベータ公開にあわせ、Amazon Dash Button と同一のハードを使った AWS IoT Button (beta)を発表しました。10月6〜9日にラスベガスで開催された「AWS re:Invent 2015」の会場では参加者へ AWS IoT 体験用に配布されています。ボタンを押すと AWS IoT サービスへ通知され利用者の記述した処理を実行できるしくみです。
        

さらに、クラウドファンディング発の次のようなオリジナルのボタン製品も登場しています。またこれからも新しいものが出てくることでしょう。

このように「ボタンひとつ」の IoT デバイスの有用性がいま注目されています。

工作と実験

こういった事情を背景にワンボタンデバイスを自作する向きもあり例 1例 2、試みに手元でも手近な材料を使って作ってみることにしました。装置が形になればそこにどのような処理を絡めるかは自由ですが、まずもっとも身近な題材のひとつとして自分あてのメール送信機能を組み込みました。

  • 今回の「ワンボタンメーラ」は試作上の題材ではありますが、実用を想定すると以前手がけた高齢者世帯安否確認のしくみと併せ、遠隔世帯からの手間いらずの ping 的定刻連絡やナースコール的な使い方ができそうです

試作の動作の様子 (動画:30秒)

    

装置について

試作した装置の材料と構成は以下の通りです。Arduino IDE for ESP8266 プロジェクトのリソースを使用し ESP8266 Wi-Fi モジュールをスタンドアロンのマイコンとして制御しています。
(価格は 2015年10月時点)

  • ESP8266 モジュール CDP-ESP8266 - Cerevo ¥842(税別)
  • バッテリー RW-111(電話機用:3.6V 800mAh) - ロワジャパン ¥780(税込) amazon
    ※説明欄の「単三電池三本の形状」の記述は「単四電池三本」が正しい
  • ブレッドボード EIC-15010 - スイッチサイエンス ¥216(税込)
  • ジャンプワイヤ・抵抗・タクトスイッチ・赤 LED
  • タッパ・ペーパータオル

     

     

メモ

  • タクトスイッチはペーパータオルをクッションにタッパ蓋のたわみを利用して操作。チープながらこの中敷きは装置を保護し外観を和らげ LED のシェードの役割も
  • ロワのバッテリーは手元の固定電話機 (ユニデン社製 UCT-002 用にストックしていたもの。定格もサイズもぴったりだが充電には電話機への装着が必要。充電器の有無を同社へ問い合わせるとやはり「本体充電のみ」とのこと
  • バッテリー消費抑制のため ESP8266 モジュールは平時はディープスリープ状態で待機させる。ボタン押下でリセットをかけると起床して必要な処理を行いふたたびスリープへ
    • ディープスリープ中の ESP8266 の使用電流は公称 10μA、手元の実測で 11μA
    • ESP8266EX の Operating Voltage は 3.0〜3.6V、Operating Current(Average value) は公称 80mA(下図)、今回の実験でボタン押下〜再スリープまでの実測では LED 点灯分を含めおよそ 60mA。処理完了までの所要時間は 10秒前後

                  ESP8266EX Datasheet Version 4.4 (2015-08-01) Page 8
                      (クリックで可読大表示)

    • バッテリー駆動可能期間を大まかに試算してみる。
      条件として、使用者が 1日に 2回、起床時と就寝時にボタンを押すものとする。この場合、前掲の値を当てはめると 1日のうち 2 × 10秒間が 80mA、残りの 86380秒間が 11μA(0.011mA)であり、平均をとるとおよそ 0.03mA。 自然放電特性を加味せず www.digikey.jp の 電池寿命カリキュレータで単純計算すると今回のロワの 800mAh のバッテリーの場合は次の結果となる
      800mAh / 0.03mA * 0.7 ≒ 18666.67 時間 ≒ 777.78 日 ≒ 25.1 月 ≒ 2.1 年

    • ちなみに Amazon Dash Button は 米エナジャイザー社Ultimate Lithium 乾電池 単4形(二次電池ではない)1本を内蔵している。アルカリ電池に比べ「最大 9倍長持ち」を惹句とする現時点でおそらく最強の乾電池。下記記事の Button 分解写真にこの電池の様子も写っている。電極がタブ付けされており電池交換は想定されていない模様
      Amazon Dash Button Teardown - mpetroff.net
      AWS IoT Buttonを分解してみた - Developers.IO
      ※プラス極側の黒地に白文字の「12-2034」「12-2035」等の表記は未使用時の品質保持期限を示す。20年!

      http://mpetroff.net/
    • データシートによると エナジャイザー Ultimate Lithium AAA は "Max Discharge: 1.5 Amps Continuous, 2.0Amps Pulse (2 sec on / 8 sec off)" と高容量であり、Dash Button のように間欠的に電力を使用する機器においては後者のメリットを最大限に享受できるものと想像される
    • 上の mpetroff.net の記事に次の記述がある。内部で 3.3V に昇圧しているとのこと
      "The Dash Button operates at 3.3 V boosted from the battery’s nominal 1.5 V, drawing 200–300 mA from the battery when on and 2.3 μA when in sleep."
      現時点では Dash Button の battery life に関する公式の記述は見当たらず
    • エナジャイザーの Ultimate Lithium 乾電池は性能相応に高価い。バッテリーだけをみても Dash Button の$4.99という価格設定への興味を誘われる
      Energizer L92BP-Energizer Ultimate Lithium AAA Battery (4-Pack) - www.amazon.com $7.99
      エナジャイザー リチウム乾電池単4形 4本パック - www.amazon.co.jp ¥1250
  • ブレッドボードを使わなければ配線部分をもっと小さくできるが全体のサイズは実験用としては手頃か

プログラムについて

メールの送信には「SendGrid」を利用しています。その方面ではメジャーなサービスであり、国内に正規代理店株式会社 構造計画研究所があり日本版の公式サイトも運営されています。濫用防止のためサインアップの際には使用目的等の詳細説明が求められアカウント発行可否は人間によって審査されます。

フリープランで 400通/日の送信が可能であり手元での利用にはまず十分そうです。ドキュメント・API も充実しています。 今回は単純明快でくみしやすい初版のほうの Web API を利用することにしました。 ところで、多くのクラウドサービスがそうであるように SendGrid Web API の利用にも HTTPS が必須です。 Arduino IDE for ESP8266 プロジェクトは 2015-08-31 より TLS 1.0/1.1 への対応を始めており利用者の一人として大いに期待しているのですが、この記事を書いている 2015年11月初旬の時点ではなお活発に開発が進行中で、stable になるまでにはまだ多少時間がかかりそうです。 そうした事情もあり、先だって「ESP8266 モジュールの AT コマンドに SSL クライアント機能を追加する」の試みで Espressif 社によるサンプルプログラムをもとに構成した HTTPS クライアントコードに手を加え、当面 Arduino IDE でライブラリとして使うことにしました。もちろんメールサービス以外の用途にも利用できるでしょう。
※手元の Arduino IDE for ESP8266 のバージョンは現時点で stable な
 2015-07-23 リリースの「1.6.5-947-g39819f0」なのですが、この版に
 同梱されている Espressif ライブラリを使ってスケッチをビルドすると
 SendGrid の API サーバ である https://api.sendgrid.com/ への接続
 要求時に異常終了の発生を確認しました。同ライブラリ群の配置された
 packages/esp8266/hardware/esp8266/1.6.5-947-g39819f0/tools/sdk/lib/
 配下の *.a を現時点で最新の esp_iot_sdk_v1.4.0_15_09_18 に
 含まれる一式に差し替えたところ問題の解消が見られました。

以下にソースコードを掲載します。ライブラリ「EspHttpsClient」はファイル一式をローカルのライブラリフォルダ下の EspHttpsClient/ 下へコピーして使います。

ライブラリ:EspHttpClient

EspHttpClient.h - GitHub

EspHttpClient.cpp - GitHub

スケッチ:OneButtonMailer

OneButtonMailer.h - GitHub

OneButtonMailer.ino

また、多少遅延が発生する可能性はあるものの、専用のサービスの代わりに手近に IFTTTMaker Channel を利用する選択肢もあるでしょう。目的がメール送信であれば下図の例の要領でレシピを作成しておきます。 (クリックで可読大表示)

     

このレシピを呼び出すスケッチです。

OneButtonMailer_IFTTT.h - GitHub

OneButtonMailer_IFTTT.ino

付録

Espressif 社のドキュメントより ESP8266 のスリープモードに関する記述箇所を以下に抜粋します。
(クリックで可読大表示)

ESP8266EX Datasheet Version 4.4 (2015-08-01) 」より

   

ESP8266 SDK API Guide Version 1.4 (2015-09-18)」中の system_deep_sleep() および system_deep_sleep_set_option() のリファレンス

   


(tanabe)
klab_gijutsu2 at 14:46|この記事のURLComments(0)
2015年02月17日

mbed と Parse で作る高齢者世帯安否確認システム

はてなブックマークに登録

2017-01-30 追記:
2017年1月末の Parse.com サービス終了に伴い以下の記事を追加しました。他サービスへの移行に関する情報等を記述しています。

さよなら Parse - 当ブログ

個人的に、高齢者世帯の安否を日常的に静かに確認できる仕組みがほしいと思っていました。要件として想定していたのは次の二点。現地にはインターネットへの接続環境が整っています。

  • 現地での被監視感や拘束感が希薄であること
  • 情報を自分でハンドリングできること
実現方法を考えると案外悩ましく、よくあるリモートカメラの類は手軽な反面 日常を生々しく監視するようでNG、自作の選択肢はあれど PC をフロントエンドとすることには何かと牛刀感があり気が進まず、また、各社様による優れたサービスの数々にも関心はあるものの恒常的に費用がかかることは当然としても自分が個人的に望む柔軟性・拡張性に適合する仕組みをなかなか見出すことができず導入には至らずにいました。
以前から頭の中でときどきそういうループを巡らせていたのですが、先日ふとマイコンとクラウドサービスを組み合わせて利用することを思いつきました。折からの「モノのインターネット(Internet of Things : IoT)」の潮流にも合致するためその視点からも面白そうです。

マイコン方面には今までほとんど馴染みがなかったのですが、情報収集を経て選択した mbed マイコンボードを利用することでフロントエンドの装置本体もそれを動かすためのプログラムも手早く作ることができました。バックエンドにはメジャーな BaaS のひとつである Parse を利用しサーバ側処理もシンプルに仕上げています。必要な費用は装置材料分のおよそ 1万円程度(2015年2月現在)のみでクラウドサービスは手元では無料枠内でゆったりと使えており、今後もいろいろ手を加えていくつもりです。なかなか便利なものになったので現時点での内容と構成を紹介します。離れて暮らす家族を気に懸けておられる方のご参考となれば幸いです。

全体像を図に示します。

動作の様子

装置の動きとクラウドサービスとの連携の様子を以下の動画に収めています。

動画1:装置が人間を検知すると Parse サーバへデータを送出

動画の内容
(無音 1分15秒)

  1. 装置へ給電 〜 初期化が完了するまで全 LED が点滅
  2. 赤外線センサが人を検知し赤 LED が点灯 〜 Parse サーバへ検知情報を送出
  3. PC 上のブラウザでは Parse アプリ「Anpi」の「Detected」 クラス(テーブル)のデータを表示中
  4. 表示を更新して新しいデータが追加されていることを確認
  5. Gmail で前日受信したレポートメール(人を検知した日付時刻と気温情報の直近の一覧)を表示してみる
  6. 最後にふたたび装置の赤外線センサに手をかざして反応を試してみる

動画2:装置の「緊急ボタン」が長押しされるとその場でメール通知

動画の内容
環境音+ブザー音あり 30秒)

  1. 緊急ボタンを押すと装置の LED が反応 〜 短時間の押下はそのまま受け流される
  2. 2秒程度長押しすると操作者にブザーで長押しの受け入れを伝え Parse サーバへ緊急ボタン押下を通知
  3. ボタン押下がメールで通知される

mbed について

ARM 社 によって開発された mbed は ARM マイコン搭載のコンピュータボードと専用の開発環境によって構成され「高速プロトタイピングツール」のキャッチフレーズの通りシンプルな手順で手早く扱うことができるように設計されています。現在さまざまな mbed ボードが販売されていますが、今回選んだのはもっとも代表的な「mbed NXP LPC1768」です。Cortex-M3 プロセッサを載せたこの単三電池二本分ほどの大きさのボードには多様な入出力ポートに加えイーサネット用コントローラまでもが実装されています。

初めて mbed に触れる場合は mbed.org へのユーザ登録が必要です。製品に同梱の USB ケーブルで mbed LPC1768 を PC へ接続するとボード上のストレージがマウントされます。ストレージ上の「MBED.HTM」をブラウザへロードするとユーザ登録画面へ遷移するのでそこへ必要な情報を投入します。登録が完了すると mbed のオンラインコンパイラをブラウザから利用できるようになります。C, C++ でコードを記述し「Compile」ボタンを押すとサーバ側でビルドが行われ、そこで生成された実行形式をダウンロード 〜 mbed の USB ストレージへコピーしてボードのリセットボタンを押下するとプログラムが実行されます。そこから先は、コードを編集したり既存のライブラリをインポートしたり mbed ボードを装着した回路に手を加えたり、、といった手順の繰り返しです。作法どおり最初はまずあれこれサンプルコードをビルドして動かしたりそれに手を加えて試したりということから始めました。なお、mbed ボードのコントローラは USB 仮想シリアルポート経由でホスト PC とのシリアル通信をサポートしており PC 側でターミナルアプリを使えばデバッグにも便利です。

mbed の世界ではコミュニティが発展しており様々な資産が共有されています。わかり易く有用な記事・文書も数多く存在するのでとても参考になります。

装置について

製作した装置の材料と組み立て方、制御用プログラムについて説明します。

材料

(※価格はいずれも2015年1月時点の税込額)

  • マイコンボード mbed NXP LPC1768 ¥5,800 秋月電子通商
  • 焦電型赤外線センサーモジュール (SB612A) ¥600 秋月電子通商
  • LAN コネクタ (mbed用イーサネット接続キット) ¥514 スイッチサイエンス
  • IC 温度センサ (LM61BIZ) ¥200 (4個入) 秋月電子通商
  • 電子ブザー (PKB24SPCH3601) ¥150 秋月電子通商  
    ※不要なら省略可
  • ブレッドボード (EIC-801) ¥257 スイッチサイエンス
  • ジャンプワイヤ (固いオス〜オス)  ¥257 (70本入) スイッチサイエンス
  • ジャンプワイヤ (柔らかいオス〜メス) ¥691 (50本入) スイッチサイエンス
  • 赤色 LED ¥350 (100個入) 秋月電子通商  
    ※不要ならカーボン抵抗とともに省略可
  • 75 Ω カーボン抵抗 ¥100 (100本入) 秋月電子通商  
    ※不要なら LED とともに省略可
  • 押しボタン・ピンコネクタ・導線 近所のホームセンターで 5〜600 円くらいで購入 
    ※不要なら省略可
  • 適当なケース 廃物利用
※上記参考価格計 ¥9,519
※LAN ケーブルと DC 5V USB-Aタイプ の AC アダプタは手持ちのものを利用

組み立て

LAN コネクタである「mbed用イーサネット接続キット」の組み立てのみハンダづけが必要ですが、その他の配線・パーツの取り回しはすべてブレッドボード上で行うため材料が揃っていれば装置の組み立ては簡単です。写真のようにブレッドボード上の配線には固いジャンプワイヤ、センサやブザーの接続にはオス−メスの柔らかいジャンプワイヤを使いました。実体配線図をあわせて掲載します。(クリックで拡大)

むき出しのままでは扱いにくいので前に買った PC 用パーツの外箱を再利用して簡単なケースを用意しました。素材が薄いプラスチックと紙なので加工しやすく耐久性もそれなりにありそうです。

焦電型赤外線センサモジュールは白いレンズの部分を露出しないと機能しないためサイズに合わせてケースに切り込みを入れました。測定誤差軽減のために IC 温度センサも外に引き出しています。外観を不透明にしているのは設置先での存在感を抑えるためで、LED は動作確認用と割り切りトラブルが起こった場合のみ点滅状態を見ることにしています。

プログラム

上記の装置構成にあわせて作成した mbed LPC1768 用プログラムを以下の場所で公開しています。

Parse サーバ上の対向処理との連携のために main.cpp の冒頭に当該 Parse アプリケーションの ID と REST API キーを記述する形にしています。公開したソースでは伏字にしていますが、後述の手順で当該 Parse アプリのコピーを作成しその ID とキーをここに記述してリビルドすれば実際に連携を試すことができます。Parse 上の所定の ID とキーは Parse へのログイン後、[Dashboard] - [(アプリ名)] - [Settings] - [Keys] から確認できます。

装置には識別用に任意の名前をつけることができます。名前は mbed ボードの USB ストレージ上の "id.txt" ファイルに記述します。この名前は装置が人を検知した際に Parse サーバへ送出する情報のひとつとして扱われます。

装置が人を検知するたびに Parse サーバへデータを送るのは不経済なので、データ送出の最短間隔を以下の定義で指定しています。
#define HTTPS_REQUEST_INTERVAL 1800 // 30分

クラウドサービスについて

装置の対向処理用に用意した Parse 用のサーバコードと、そのコードからメール送信のために呼び出している Mailgun サービスについて説明します。

Mailgun の準備

Mailgun は多くのプログラミング言語に対応したクラウドメールサービスです。REST API セットに加え Python, Ruby, Java, C#, PHP 用のライブラリが公開されており、自作のコードで簡単にメール送信をハンドリングできる便利なサービスなので今回の話題とは無関係にアカウントを作って試してみるのも良いでしょう。サインアップ時にクレジットカード情報の入力は不要です。

http://www.mailgun.com/

Mailgun にアカウントを作成すると一件の「Sandbox Domain」が割り当てられます。この Mailgun Subdomain はテスト用とされておりメール送信は 300件/日までという制約がありますが、自前のドメインがあればそれを登録することでこの制約はなくなります。なお、無料枠はこの記事の時点で 10,000件/月までとなっています。[詳細]
ちなみに手元では今のところ一日 300件もメールを送信できればまず十分なのでひとまず Sandbox Domain をそのまま使っています。

Parse からの Mailgun API 呼び出しにおいては Mailgun アカウントに紐付けられた「API Key」を使用します。Parse は Mailgun と公式に連携しているためごくシンプルなコード記述で Mailgun API を呼び出すことができます。

Parse の準備

Parse は Facebook 傘下の Parse.com が開発・運営する現在もっともメジャーな BaaS(Backend as a Service) のひとつです。ユーザ管理・データストア・スマホへのプッシュ通知・アクセス解析・ホスティング・SNS 連携・位置情報連携など多くの機能から構成されており対象プラットフォーム・言語も広範です。無料枠も広く 30リクエスト/秒まで、プッシュ通知 100万件/月までは無料、また、アクセス解析機能も自由に利用できます。[詳細]

https://parse.com/

一般に BaaS の主な目的はアプリケーションの対向サーバ側機能を代替・補完することにあり、サーバの管理運用やサーバ側コード開発に踏み込むコストを抑制しアプリ本体の開発に注力可能となることが利用者にとってのメリットですが、Parse にはサーバ上でユーザコードを実行することのできる「Cloud Code」というしくみが用意されています。これを利用することで標準の機能のみではカバーできない固有の要件に対応できる余地が大きくなり、また、フロントエンドのアプリケーションを一切伴わず所定のサーバコードのみを Parse サーバ上で実行するといった使い方も可能となります。今回作った装置は Parse サーバ上に設置した自作コードをそのまま呼び出して必要な処理を行っています。このように目的に応じて柔軟に利用できることが Parse の魅力のひとつと言ってよいでしょう。

Parse サーバ用に作成したコードを https://github.com/mkttanabe/Anpi で公開しています。このコードを自分の Parse アカウント環境で使用する手順を以下に記述します。

1. 「Anpi」アプリと「Detected」クラスの作成

Parse へログイン後、[Dashboard] - [Create a new App] をクリックして「Anpi」という名前のアプリを作成し同アプリの [Core] へ移動

[Dashboard] - [Anpi] - [Core] - [Data] の [+ Add Class] をクリックして Custom タイプの「Detected」クラスを作成
※ここでいう「クラス」とは Parse 用語であり、「テーブル」の概念とほぼ同じものです

[+Col] ボタンをクリックして Detected クラスに次の各カラムを追加。カラム並びは任意に調整可

  • 「posted」Date 型
  • 「deviceId」String 型
  • 「deviceAddress」String 型
  • 「temperature」Number 型

装置から受信した人検知情報はこの Detected クラスのデータとして保存されます。

2. Parse コマンドラインツールの導入と Cloud Code のセットアップ

Parse 用の開発を行う PC には専用のコマンドラインツールの設置が必要です。公式ドキュメント「Cloud Codeとは」の冒頭の説明にそって開発環境へツールをインストールします。インストールが終わったら任意の開発用フォルダへ移動し「parse new」コマンドで「Anpi」アプリ用 Cloud Code の雛形を生成します。

$ parse new Anpi
Email: your@mail.com
Password:
1:Anpi
Select an App: 1

github.com/mkttanabe/Anpi 下の Parse/Anpi/cloud/main.js の内容を開発用フォルダ下の Anpi/cloud/main.js へ上書きし、冒頭の下記の箇所を自分の Mailgun ドメインと API Key、送信先とするメールアドレスで書き換えます。

var MAILGUN_DOMAIN = 'sandboxXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.mailgun.org';
var MAILGUN_KEY    = 'key-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX';
var MAILGUN_TO     = 'Makoto Tanabe <XXXXXXXXXXXXX@XXXXX.XXXX>';
var MAILGUN_FROM   = 'Safety Alert <postmaster@' + MAILGUN_DOMAIN + '>';

開発用フォルダ下の Anpi/ へ移動しそこから「parse deploy」コマンドを実行すると配下の各ファイルが Parse サーバへ転送されます。

$ cd Anpi
$ parse deploy
Uploading source files
Finished uploading files
New release is named v1

Parse サーバへ転送したコードの動作は 公式ドキュメント「Cloud Codeとは] - [はじめに] - [シンプルな関数] に記述された方法で確認できます。

3. ジョブの登録

上の手順で deploy した main.js には Detected クラス上の直近 30件のデータをメールでレポートするためのジョブ用関数「report」が含まれています。 ジョブの登録・編集・削除は [Dashboard] - [Anpi] - [Core] - [Jobs] から行います。図の UI から任意の内容で設定可能です。

※無料枠の Parse アカウントでは複数のジョブを同時に実行することはできません

以上の手順・設定で、今回作成した mbed ベースの装置本体と各クラウドサービスが連携して稼動します。アイディア次第で応用も可能でしょう。こういう仕組みを低コストで自作できる時代になりました。


(tanabe)
klab_gijutsu2 at 07:54|この記事のURLComments(0)TrackBack(0)
2014年10月15日

Dropbox アカウントひとつで利用できるプッシュ通知機構

はてなブックマークに登録

2018年6月追記: Dropbox API の仕様変更により以下の内容はすでに obsolete です。記事は残しますが、過去の情報であることをご了承下さい。

Dropbox 社は広く知られるファイル系のサービスとは別に 2013年より非ファイル形式の構造化データの保存・読み出しに対応するデータストアサービスを公開しており、Dropbox アカウントを持っていれば Dropbox Datastore API 経由でこのサービスを利用できます。同 API は全体的にシンプルで SDK のサポート範囲も広いため自作のソフトウェアへ手軽に組み込むことが可能です。
自前でサーバ環境を構築・運用する手間なしにレコードイメージのデータをネットワークストレージ上で取り回せるのは便利で、また多くの人がアカウントを持っていることへの安心感もあり、この Dropbox のデータストアサービスはさまざまな用途に柔軟に活用できそうです。

Dropbox データストアの弱点としてストア上のデータのアカウント間での共有に未対応である点がしばしば挙げられていましたが、2014年9月に同社は New Datastore features! として Shared datastores のリリースをアナウンスしています。

Dropbox Datastore API のデータ変更通知機能

Dropbox Datastore API はアプリケーションをオフラインで操作した後のデータの自動同期や競合の解決を行うための機能や、ストア上のデータに変化があった際にそれをアプリへ通知するといった BaaS(Backend as a Service)風味の機能を備えています。

後者はリスナとして登録した所定の関数をデータ変更発生時に API がコールバックするしくみで、そこでの通知を適切にハンドリングすることによりあるインスタンスが行ったデータ変更を他のインスタンスへすみやかに反映することが可能です。その実装例を Dropbox Datastore API の JavaScript SDK 付属のサンプルアプリケーションで試すことができます。公式のリンクを以下に掲載します。

最初に表示される「Link to Dropbox」ボタンを押下して自分の Dropbox アカウントでログインすると UI が開きます。二台の PC の web ブラウザを使って操作を行うとわかりやすいでしょう。
※このアプリはログインしたアカウントのデータストア以外にはアクセスしません

データストアの通知機構を単体で使用?

サンプルアプリの動きはなかなか面白く新鮮に感じられました。反応も早くストアからの変更通知がアプリ内で適切に処理されている様子が見てとれます。

ところで、「データに変更が発生したら変更内容をクライアントへ知らせる」という通知のしくみはこのデータストアの機能の構成要素のひとつとして用意された独自の機構であるわけですが、その部分は単独でも実用性があるように思いました。つまり、データストアを本来の記憶領域として使うことよりも、そこでのプッシュ通知のしくみを利用することを主目的とするアプリケーションもあり得るのではないかということです。

単にストア上のデータを更新すれば通知処理が発動するシンプルさも好ましく、送信側は伝えたいメッセージの内容を所定のテーブルのレコードにデータとして乗せることでトリガーを送り、通知を受けた側はその内容に応じて所定の処理を行う形にすればよさそうです。もちろん機能的には専用のプッシュ通知機構に及びませんがメッセージの送受信さえできればあとはアプリ側の工夫次第でしょう。

わざわざそんなことをしなくても所定のプラットフォームのスタンダードな通知機構を使えばよさそうなものですが、そういうことを考えたのには理由があります。プッシュ通知というものはごくプライベートな用途で使いたい場合もあります。たとえば、以前 Android の標準のプッシュ通知機構である GCM を利用して 自宅の遊休端末を留守中の監視カメラWake on Lan マジックパケット発信器として遠隔操作するためのアプリを手がけたことがあります。通知は正しく機能したものの、GCM はこういう小さな要件に軽く使うには必要な手順や手続きにいささか牛刀の感があり、処理用の中間サーバやサーバ用のコードなども面倒に思いながら仕方なく用意していました。

だからと言って自分で似たしくみを作ることは保守・運用面で良い判断とも思えず、よくわからないサードパーティ製品に依存するのも気が進みません。あまり切実でも緊急でもないもののそういう緩いジレンマが時おり首をもたげていたのです。そんなわけで、なるべく手間をかけずシンプルに通知をハンドリングできるものがあればと思っていました。
探せば他にも便利で面白いものが色々ありそうですが、別件でたまたま触れた Dropbox Datastore API の通知のしくみはちょうどそこにあてはまる気がしました。広範なプラットフォームで利用できることにも夢があります。

ブラウザ用アプリを試作

そんなわけで、まずは JavaScript サンプルを土台に手軽に実行できるブラウザ用アプリを作ってみることにしました。「URL プッシュ機能つきオンラインブックマークアプリもどき」とでも言うべきものです。
ブラウザで下記の URL を開き Dropbox アカウントでログインすれば動かしてみることができます。もちろん自分のデータストア以外には一切アクセスしません(と言うかできません^^;)のでご安心下さい。

使い方を図に示します。「選択されたページをこのブラウザで開く」ボックスをチェックしておくと、自分を含むいずれからのインスタンス上で「選択」または「追加」された URL が現在のブラウザで開かれます。

ブラウザ版の動作の様子(動画 39秒 無音)

左:Windows 上の Firefox      右:Mac 上の Safari

Android 用アプリも試作

手元での使用頻度の高い Android 端末用にもアプリを作ってみました。インストール用の QR コードを掲載します。

使い方を図に示します。
Android 版は受信専用です。「通知への待機を開始」ボタンを押下すると自前のサービスが起動し待機状態へ移行します。サービスはシステムから強制終了されにくいフォアグラウンドサービスとしており稼動中は端末の通知領域にアイコンが常駐します。サービスを停止するには「通知への待機を停止」ボタンを押下します。


Android 版への通知はブラウザ版から行います。待機状態の Android 版は通知を受信すると次のように振舞います。
  • 通知内容が http(s)://... の形式なら URL とみなしブラウザへ渡す
  • それ以外なら Android 標準の am (activity manager) コマンドへのパラメータとみなし内容を整形して同コマンドへ渡す

Android 版の動作の様子(動画 60秒 無音)

左:Android 端末実機      右:Mac 上の Safari

付録:am コマンド書式とパラメータ記述例

$ am
usage: am [subcommand] [options]

    start an Activity: am start [-D] [-W] <INTENT>
        -D: enable debugging
        -W: wait for launch to complete

    start a Service: am startservice <INTENT>

    send a broadcast Intent: am broadcast <INTENT>

    start an Instrumentation: am instrument [flags] <COMPONENT>
        -r: print raw results (otherwise decode REPORT_KEY_STREAMRESULT)
        -e <NAME> <VALUE>: set argument <NAME> to <VALUE>
        -p <FILE>: write profiling data to <FILE>
        -w: wait for instrumentation to finish before returning

    start profiling: am profile <PROCESS> start <FILE>
    stop profiling: am profile <PROCESS> stop

    start monitoring: am monitor [--gdb <port>]
        --gdb: start gdbserv on the given port at crash/ANR

    <INTENT> specifications include these flags:
        [-a <ACTION>] [-d <DATA_URI>] [-t <MIME_TYPE>]
        [-c <CATEGORY> [-c <CATEGORY>] ...]
        [-e|--es <EXTRA_KEY> <EXTRA_STRING_VALUE> ...]
        [--esn <EXTRA_KEY> ...]
        [--ez <EXTRA_KEY> <EXTRA_BOOLEAN_VALUE> ...]
        [-e|--ei <EXTRA_KEY> <EXTRA_INT_VALUE> ...]
        [-n <COMPONENT>] [-f <FLAGS>]
        [--grant-read-uri-permission] [--grant-write-uri-permission]
        [--debug-log-resolution]
        [--activity-brought-to-front] [--activity-clear-top]
        [--activity-clear-when-task-reset] [--activity-exclude-from-recents]
        [--activity-launched-from-history] [--activity-multiple-task]
        [--activity-no-animation] [--activity-no-history]
        [--activity-no-user-action] [--activity-previous-is-top]
        [--activity-reorder-to-front] [--activity-reset-task-if-needed]
        [--activity-single-top]
        [--receiver-registered-only] [--receiver-replace-pending]
        [<URI>]
パラメータ記述例
  • start -n jp.klab.nopass/.MainActivity
    - 指定されたアプリのアクティビティを開く
  • start -a android.intent.action.VIEW -d geo:0,0?q="枕崎市"
    - 指定された場所をマップで表示
  • start -a android.intent.action.VIEW -d tel:000000000
    - 指定された電話番号の発呼準備
  • start -a android.intent.action.SENDTO -d mailto:nobody@example.com --es android.intent.extra.SUBJECT テスト --es android.intent.extra.TEXT インテント経由でメールを作ってみたり
    - 指定された宛先・件名・本文の新規メールを生成
  • start -a android.intent.action.VIEW -d vnd.youtube:qpjw62OK9Tw
    - 指定された動画を Youtube で再生

余談ながら、、

今回掲載したアプリ「NotifyIt」は Dropbox 社による事前審査を通過しています。


(tanabe)
klab_gijutsu2 at 14:03|この記事のURLComments(0)
2013年11月26日

Google ドライブのフォルダ共有で注意すべきこと

はてなブックマークに登録

利用規約とのかねあいがしばしば話題を呼びながらも、手軽に扱えるオンラインストレージとして Google ドライブは広く利用されています。関係者間での共同作業にこのサービスを活用している向きも少なくないことでしょう。手元でも Google ドライブ上に用意した共有フォルダを知人とのデータの受け渡しに利用したりしているのですが、先日あるきっかけで次のことを知りました。

  • 「アカウント A の提供する Google ドライブ共有フォルダ」の下にアカウント B がファイルをアップロードすると、そのファイルの容量はアカウント A ではなく B の割り当て領域にカウントされる
つまり Samba 等のファイルサービスのもとでのフォルダ共有とは異なるわけで、この仕様は DB システムとしての合理性に基づくものと考えられますが、実用上の興味もあり関連する話題をいくつかピックアップしてみました。

Google ドライブ上のアイテムと容量カウント

"ウェブ上の Google ドライブの保存容量のカウント方法"
- support.google.com -
"Does a shared folder take up my space?"
- Google グループ -
"Google ドキュメント、スプレッドシート、スライドのサイズ制限"
- support.google.com -
  • Google ドライブ上にアイテムを作るとその作成者がアイテムのオーナーとなる
  • アイテムの占有する容量はオーナーのアカウントの使用容量としてカウントされる
  • ただし Google Docs 文書は容量カウントの対象外であり、アップロードされたファイルなどそれ以外の形式のアイテムのみがカウントの対象となる。つまり Google ドライブの容量を消費するのは Google Docs 文書以外のアイテムである

共有フォルダとアイテムのオーナー

"ファイルのオーナー権限の譲渡"
- support.google.com -
"使用容量が大きいファイルを確認する"
- support.google.com -
"How do I transfer ownership of PDF files in my GDrive?"
- Google グループ -
  • アカウント A が作成した共有フォルダの配下にアカウント B がアイテム X を作るとそのオーナーは B となる。したがってアイテム X の占有する容量は B の使用容量としてカウントされる
  • B が アイテム X のオーナーを A に変更すれば(オーナー権限の譲渡)、アイテム X の容量負担は A へ移動する
  • ただし、一般の Google アカウントユーザは Google Docs 文書以外のアイテムのオーナーを他者に変更することはできない。Google Apps アカウントなら任意のアイテムのドメイン内のユーザへのオーナー変更が可能

ひとことで言えば、Google ドライブの共有フォルダはその配下のアイテムの共有を提供するものであって配下のアイテムへ領域を提供するものではない、ということになるでしょう。その点を一般的なファイルサービスと混同しないよう注意が必要ですね。


(tanabe)
klab_gijutsu2 at 16:00|この記事のURLComments(4)
2012年11月12日

Google Drive 上の文書をまとめて別アカウントへ移す方法

はてなブックマークに登録

Google Docs の文書はウェブブラウザから手軽に扱えるので何かと便利です。OS プラットフォームの違いを意識する必要がないため共同作業にも適していますね。
先日ちょっとした経緯から「アカウント A の Google Drive 上の Docs 文書・フォルダ群をまとめてアカウント B の環境へコピーするにはどうすればいいか?」というテーマに遭遇しました。次のみっつの条件つきです。

  • アカウント A の保持する既存のリソースの オーナーや共有設定の変更は不可
  • アカウント A の保持する既存のリソースに付与されている共有設定もコピーの対象とする
  • アカウント A とアカウント B のペアは複数存在する

今回はこの話題について考えた内容と、道具として作成したコードを紹介します。 続きを読む

klab_gijutsu2 at 10:07|この記事のURLComments(0)TrackBack(0)
Blog内検索
Archives
このブログについて
DSASとは、KLab が構築し運用しているコンテンツサービス用のLinuxベースのインフラです。現在5ヶ所のデータセンタにて構築し、運用していますが、我々はDSASをより使いやすく、より安全に、そしてより省力で運用できることを目指して、日々改良に勤しんでいます。
このブログでは、そんな DSAS で使っている技術の紹介や、実験してみた結果の報告、トラブルに巻き込まれた時の経験談など、広く深く、色々な話題を織りまぜて紹介していきたいと思います。
最新コメント