「IoT」タグアーカイブ

【DIY?】名古屋ハッカソンに参加してきました

41517463_2010415452361231_3341189912941559808_n

モノづくり大好きなみなさん、暑い暑いと怪訝な顔をして温度計を恨めしく観た夏が過ぎ去ろうとしている中、終わってしまうことにやや寂しさも感じているのではないでしょうか。
勝手ですねw

さて、そんな夏の終わりに、名古屋市が主催となっている名古屋ハッカソンに参加してまいりました。
こちら。

NAGOYA HACKATHON開催概要
http://jellyware.jp/nagoyaboost/hackathon.html

本イベントは、名古屋市が取り組む起業家育成プロセスの一環で、他にも様々な起業家支援イベントが開催されています。

起業を目指す方、事業化に向けた新しいアイデアを持っている方など、参考にしてみてはどうでしょうか。

NAGOYA BOOST 10000とは
http://jellyware.jp/nagoyaboost/

IMG_20180908_093521316_HDR

まずは結果から

ハッカソンなので作品に対する評価・審査があるのですが、結論から先に申し上げますと、見事優秀賞をいただくことができました。
嬉しい、わーい。(最優秀賞1点、優秀賞2点)

IMG_20180909_184524576_HDR

そういえば春先に開催された中京テレビのHack-Chuでも優秀賞をいただいたので、今年二つ目の優秀賞です!やった!

が、素直に喜べない理由も。
それは後述。

ちなみに当日名古屋市の大ボスも来てました。

IMG_20180908_102332245_HDR

テーマ

今回の名古屋ハッカソンは、「ヘルステックナゴヤ」が主テーマになっており、さらに協賛企業さんがメインテーマに沿った小テーマを出されていました。

各企業様の事業内容に沿って、独特の小テーマが展開されており、その小テーマを眺めているだけでも楽しかったです。
(中には少々強引な感じもありw)

今回参加時に、介護事業を営む水野さんとチーム参加することを決めていたので、個人的に選択したテーマも介護に関するもの。

・・・違うか。

小テーマは、事前に開催された事前説明会でいくつか発表されており、その際に目に留まった介護に関する小テーマで行こうかな…と介護に関するテーマがあったので水野さんをお誘いしたのでした。

巻き込んでゴメンナサイ。

アイデア

ということで、事前に小テーマが決まっていたので、アイデアは介護に関するものから考えよう!ということで、事前にいくつか挙げておいて、その中から・・・

  • 課題の重要度
  • 実現可能性
  • マネタイズの考えやすさ
  • ハッカソンでのプロトの実現性
  • SWの実装方法
  • 審査員受け
  • ハッカソンだけではない、イベント全体でのテーマ性

など鑑みて、水野さんと数案は決めておきました。
あとは当日の空気など鑑みて、よさげなアイデアを選択する方向で当日に臨みました。

で、当日の流れの中で一つに絞ったのがコレ。

IMG_20180908_150529399_HDR

主に高齢者をターゲットとした服薬管理システムです。
高齢者のみならず、自分のようなサプリメント常用者や子供の服薬管理にも応用できますね。

幸い、参加者ウケも良かったので、介護系全般にピボットする可能性を残しつつ、これを軸に水野さんの案も交えつつチームビルディングすることにしました。

ちなみに、薬の発注からサービス化しているところで、一回の服用単位でパッキングしてくれるサービスというのは既にあります。(アメリカですけど。)

 

チーム

幸いにも参加者投票が多かったので事前に参加者の前で簡単なピッチをすることができ、チームビルディングはしやすい状況にありました。

エンジニアリングは主に私、テーマに沿った発表資料作成は水野さんを主体にするという方向でチームの機軸を決めました。

しかしながらこのチームの弱点は事前にいろいろと情報共有やディスカッションを進めていたこともあり、やや進め方に偏りがあることを感じていたため、意外な視点で新しい要素を提案してくれるチームメンバーが欲しいなと考えました。

テーマが介護ということもあり、介護に係る機会が多い属性が理想的・・・それって女性だよね?ということで、会場内で目についた女性に声をかけまくるという破廉恥なチームビルディングとなりました。

結果、このような素晴らしいメンバーに恵まれました。
いや、偶然の産物なんですが、ホントに素晴らしいバランス。

41445854_2170440363167824_3053580095139610624_n
最高のチームメンバー!

プレゼンテーションチーム

  • 資料作成/統括・・・水野さん
  • 起案/調査・・・渡辺さん
  • 起案/調査・・・吉崎さん

エンジニアチーム

  • サーバサイド/基盤・・・入口さん
  • クライアントサイド・・・諏訪さん
  • ハードウェア製作・・・榊原(私)

綺麗に担当を分けることができ、またそれぞれ技術やノウハウのバランスも良く、最初に大まかに方向性を共有し、役割分担をしたらあとは勝手に作業が進んでいきました!
素晴らしい!

モノづくりの経過

iriguchiandsuwa
エンジニアチームの大黒柱二人

大方作るものと構成は考えていたので、エンジニアリングチーム内での役割分担もうまくいき、前述のように

  • サーバサイド/基盤・・・入口さん
  • クライアントサイド・・・諏訪さん
  • ハードウェア製作・・・榊原(私)

な割り振りにしました。
HWは例によってSeeed社のWio nodeとサーボの組み合わせで薬剤排出部分の制御を行いますので、サーバ側からはWioのAPIを呼ぶだけです。

参考までに過去のエントリーを紹介

Wio node + Azure Logic Appsでお手軽IoT【Wio node初期設定編】

【PC & Gadget】WIO NODE + AZURE LOGIC APPSでお手軽IOT【データ取得編】

自分だけなら、UIをPowerAppsで、基本処理をFlowでサラっと作るところでしたが、各メンバーの得意な分野での実装に任せる方向にしました。幸い実装技術もうまく分かれていたし!

プロト版の目標は

  • 3回程度、実際に薬剤排出するデモができること
  • オマケ機能は、基本ができたら

に絞りました。
発表時間も限られるため、HWを使ったデモはあまり重要視せず実現可能性を示すだけに留めることとしました。
無理してもショーがないし。

IMG_20180908_223643261_HDR

薬剤排出の仕組みは、箱を多数用意してふたを開閉する方式を最初思いついたのですが、蓋の数だけ動力が必要になるため、デモ向けのプロトにしてもやや製作が面倒+100均で売っているピルケースと見た目が似通うためUI/UX的に新しさが無いということで、観覧車のゴンドラに薬剤を載せて、観覧車を一定角度回してゴンドラの薬剤を輩出するという仕組みをとりました。

 

この方式だと、デモ用プロトの範囲だけなら、サーボ一個で動作させられます。(プロト版は観覧車の軸にサーボの軸を直結したので、最大160度しか回らないというデモ限定仕様)
本来はちゃんとステッピングモータなどでやるべきですね。

IMG_20180909_100418367_HDR
サーボの動作異常が見られたので、電源取り直すために小加工。

初日にWio nodeとサーボは持ち込んでいたので、エンジニアチームに簡単な動作デモを見せてAPIを紹介したら、あとは入口さんと諏訪さんにUI~制御周りの実装はお任せしてしまいました。

すぐに近所のイオンに実際のハード部分の資材調達に!
全部100均で揃えました。
紙皿にマヨカップ、フォトスタンドにPPシート、ゼムクリップに押しピンと、まさに誰でも手に入る資材です。

製作の過程はめんどいので割愛して、実際にはこんなものが出来 上がりました。

IMG_20180909_161532728_HDR
正面。

41539683_10216282599439533_948689852562407424_n
背面。

IMG_20180909_161500005_HDR
中身の排出機構。紙皿とマヨカップ、ゼムクリップとフォトスタンド!

中身の観覧車はそこそこに、外装にちょっとこだわってます。
ただ、外装の接着のためのタブがあまりにもみっともない・・・別のうまい接合方法も考え付いたんですが、考え付いたのが外装5割できてからだったのでそのまま進めることに・・・残念。

実際にサーボ接続して、カップに薬剤投入しての初動。
(事務所で徹夜製作して動作テストはしていたんですけどね)

ああああ薬がwww
排出というより拡散になってるwww
原因を確認すると、サーボが想定仕様通り動いてない疑い。
Seeedさん!ということでSeeed社の松岡さんにHELPをお願いしたところ、どうやらサーボ制御用のライブラリにバグがあった模様で、ソッコー対応いただきました。松岡さん超感謝!

で、バグ修正の間に外装が整ってきたので外装付けた状態で再度テスト。

この動作を目指していたので仕様通りと言えば仕様通りなんですが、割とギリギリで調整していたので、思わず声が出ましたw

iOS の画像
なにやら怪しいドーピングアイテムが並ぶエンジニアチームの一コマ。

この時点でかなり時間が迫っていたので、製作はここまでとし、実際のデモは行わずプレゼンの中で動画を紹介する方向に。
本番でモタつくより、その方が確実ですね。

満足はいきませんが、最低限目指すところまでは動作したのでほっとしました。
エンジニアチームの入口さん諏訪さんありがとう!
最高のチームだ!!
(HWに係りすぎて彼らいなかったらホント動いてなかったカモ。)

プレゼンテーション

もう一つの大事な要素、プレゼンテーションは、水野さんをはじめとしたプレゼンテーションチームが最初の目標設定とポイントの共有だけでモリモリ進めてくれました。

時々方向性や数字の確認をされた程度でスバラシイ資料が出来上がってる!
いつもはどっちかというとそっちの役割の方が多かったりするので、チョッピリ寂しくも、とても新鮮でした。勉強させてもらうポイント多かったし。

社会課題の提示の仕方や、裏付けとなる数字の調査や表現、また解決策の提示の仕方も素晴らしかったし、発表時間を上回るチームが多い中、キッチリ時間内に収める構成力、なにをとってもうまくまとまっていて、最高でした!

プレゼンテーションチームの水野さん、渡辺さん、吉崎さん、お前ら最高だよ!!!!!

感謝

今回は私のアイデアベースにハッカソンが進んでいったのですが、HWに必死になりすぎて本当に要所要所しか全体を見てませんでした。

そんな中・・・

  • 資料を作成しながらプレゼンテーションチームを引っ張ってくれた水野さん
  • 水野さんのサポートをしながらいろんな調査をしつつ、助言をしてくれつついいムードメイカーにもなってくれた渡辺さん
  • プレゼンテーションチームが忙しく資料作成する中、年長者二人が手の届かないところにうまくサポートとして入っていただいた吉崎さん
  • エンジニアチームのクライアントサイド担当として、最低限の指示しかしてないにもかかわらず自力で頑張って実装してくれた諏訪さん
  • エンジニアチームのサーバーサイド担当として、(いいかげんで)抽象的な指示を的確に咀嚼して実装してくれた入口さん
  • サーボ制御ライブラリのバグを速攻調査してくれた上に修正してくれたSeeedの松岡さん

皆さんがいてくれたからモノができました!
そして見事優秀賞!本当にありがとうございます!

それからこんな面白いハッカソンを企画・運営していただいた開催側の皆様、お疲れさまでした&ありがとうございました。

41322986_2170440343167826_894842314269130752_n

素直に喜べないところ・・・

最後に、冒頭でちょっと触れた素直に喜べないところ。

上述した、アイデア出しただけで、あとは夏休みの工作レベルのハード作成に必死になってしまっていたところですね・・・
情けない。

Hack-Chuも同じく、インフルエンザとはいえチームメンバーに頼りっきりで実現した優秀賞・・・私の価値って・・・orz

ハッカソンは楽しいぞ!

出るからにはなんらかの賞をもらいたいところですが、ハッカソンって結果はもちろんのこと、そのプロセスから学ぶことがとても多い、貴重なイベントだと思います。

みなさんも、周りでハッカソンが開催されていたらぜひ参加してみて下さい。

エンジニア寄りのイベントに見えますが、エンジニアリングにしか目が向かないわがままで一辺倒なエンジニアをうまく誘導するデザイナーやプランナーの存在もとても重要です。

【PC & Gadget】WIO NODE + AZURE LOGIC APPSでお手軽IOT【データ取得編】

このエントリーは、このエントリーの関連です。

【車DIY】車のエアコンが効かない!!!!!(2)

さて、IoTしてますか?
Office365してますか?
SharePointしてますか?

と、煽りながらのスタートですが、いずれのカテゴリーにしてもそれほど高度な内容ではないので、玄人諸氏はそっとタブの「閉じる」ボタンをクリックがよろしです。

今回は、ずいぶん前にエントリーした本記事の続編とも関連記事とも言うべき内容です。

Wio node + Azure Logic Appsでお手軽IoT【Wio node初期設定編】

以前のエントリーでは、Wio nodeのセットアップについて解説しましたが、本エントリーではセットアップ後、データ取得ができるようになったIoTエッジ(Wio node)からデータを取得し、可視化していく方法を記載しています。

ざっくりいうとこんな感じですね。

  1. Azure Logic appsを利用可能にする。(※1)
  2. Azure Logic apps からWio nodeのAPIにアクセスして、現在の値を取得する
  3. 取得した値をSharePoint Onlineの任意のリストに格納する

※1:Office365のFlowでも可能ですが、今回の要件の場合Flowでは実現できなかったため、Logic  appsを使用しています。(後述)

うーんむ、超簡単。
では実際やってみましょう。

IoTエッジ(Wio node)からの値を取得する

最近IoT関連のデバイスで特にお気に入りなのが、SeeedのWio nodeです。MFTでお手伝いしたからとかそういう政治的な忖度は全くなく、純粋に圧倒的に使いやすいからです。

パッケージを開けて、電源を投入してセットアップすれば、10分後にはWio nodeのセンサに接続されたデータを利用したり、接続された機器を制御できます。
しかもお値段僅か1000円(Wio nodeのみで)。

Wio nodeからのデータ取得(機器制御)は、煩わしいコーディングをすることなく、Seeed社が提供するサーバーに用意されたAPIに、トークンを付与して呼び出すだけ。

反対に、呼び出す頻度やタイミング、呼び出して取得した後のデータの操作はこちら側で用意する必要がありますが、一般的なソフトウェアエンジニアにとって、不慣れなハードウェア操作の煩わしさがなくなるだけでずいぶんと敷居が下がります。

では実際に、値を取得してみましょう。

Microsoft Azure Logic appsから取得する

Micrsoft Azureの利用方法、Logic Appsのセットアップ方法はここでは割愛しますが、要望が多ければ別にエントリー作成します。

Logic Appsがセットアップされて、Logic Apps デザイナー(編集画面)が表示されている状態からWio nodeの値を取得してみます。

2018-08-29_09h07_40

Logic Appsの初期画面から、「一般的なトリガーで開始する」にあるサンプルトリガー「繰り返し」を選択します。

2018-08-29_09h09_26

すると編集画面に遷移します。

2018-08-29_09h14_56

または新規に作成し、トリガーを「スケジュール」で検索して選択します。

2018-08-29_09h16_21

全く同じ機能なのに、見出しが違うものが存在します・・・。
一応どっちでも動作することを確認しています。

Wio APIにリクエストを送る

2018-08-29_09h45_09

Wio APIから情報を取得するために、新しいステップを追加し「HTTP」アクションを選択します。

2018-08-29_09h45_32

「HTTP」にも数種ありますが、シンプルな「HTTP(リクエスト)」を選択。

2018-08-29_09h46_57

いろいろなパラメタが並んでいますが、Wio APIの場合は

  • 方法
  • URL

の二項目だけを入力すればOKです。
方法は「GET」を選択し、URLにはWio APIで表示されるURLを入力します。

2018-08-29_09h59_28

この画面ですね。
(この画面そのものは、前回の記事を参考にアプリから参照してください。)

2018-08-29_09h49_01

最後に、必須ではありませんが該当タスクの名前を変更します。
今回は一つだけなので悩まないんですが、取得するセンサーの数が増えるとホントに困ることになります。

2018-08-29_09h50_07

「Wio nodeからの温度の取得 001」にしました。
こんな感じで、どのセンサーの値からかわかるようにするとよいでしょう。数字で管理も実はやめた方がいいですが。

これで「HTTP」のタスク内での、Wio nodeからの値の取得まではOKです。
ここまでの流れでWio APIに値取得のためのリクエストを投げ、JSONで値が返ってくるところまでが完了です。

JSONを解析する

2018-08-29_09h48_12

続いての処理。
アクションの追加を行い、「JSON」で検索を行うと、「JSONの操作」というアクションが見つかります。
クリックして追加すると

  • コンテンツ
  • スキーマ

の項目が現れます。

2018-08-30_18h28_36

コンテンツは、入力欄をクリックすると現れる「動的なコンテンツの追加」から展開されるダイアログから入力します。

2018-08-29_09h51_34

「Wio nodeからの温度の取得 001」というグループから、「本文」を選択します。
この本文が実はJSONなんですが、それを解析するということですね。

続いて、どのように解析するかを指示してやります。
「スキーマ」に受け取ったJSONのスキーマを設定してやりますが、0からコード書くのはめんどうなので、「スキーマ」入力欄の下にある

「サンプルのペイロードを解析してスキーマを生成する」

を利用します。

2018-08-29_09h59_28

Wio APIのWeb画面には、実際にリクエストを送ってテストする機能まで備わっているので、遠慮なく利用します。
画面上の「GET」ボタンを押すと、実際に接続されたWio nodeから取得した値が表示されます。
(この画面そのものは、前回の記事を参考にアプリから参照してください。)

上手だと下の赤枠内、「Response:」の下ですね。
これをコピーして

2018-08-29_10h01_19

先ほどの「サンプルのペイロードを解析してスキーマを生成する」をクリックして開いたダイアログに張り付け、「完了」ボタンをクリックします。

2018-08-29_10h03_22

すると、「スキーマ」欄に解析されたJSONのスキーマが読みだされます。
うーんむ、超便利。

が、一つここで問題が。
読み取ったセンサーの値によっては、型の判定がうまくいかない場合があるので、一度テストしてみてうまく取得できない場合、肩を変更してやる必要があります。

今回の場合、自動で生成したスキーマでの型は「integer」でしたが、実際は型指定のエラーが発生したため「number」に変更しています。

image

実際のエラー

2018-08-29_10h04_28

型を「number」に変更

これで、リクエスト→値取得までができたことになります。
次以降のステップで、任意のWebサービスなりアクションなりを利用してデータを利用していく形となりますが、今回はOffice365のSharePointで値を収集してみました。

なんというか、使い慣れていて楽なんですよね。

SharePointに値を格納する

SharePoint上には、すでにカスタムリストで「温度測定実験」というデータ格納先を作ってあります。

image

ここにLogic Appsから接続し、値を格納していきます。

2018-08-29_10h09_11

追加したステップで「SharePoint」アクションを検索し、リストから「項目の作成」を選択します。

2018-08-29_10h10_08

「項目の作成」アクションでは、接続先のSharePointのサイトアドレスを求められます。
またサインイン状態にない場合、サインインを求められます。
うまく接続できると、リストの一覧などが表示されるため、該当するリストを選択します。

リストを選択すると、リストに含まれる変更可能な要素が入力欄として表示されるため、値を設定してきます。

今回の場合

  • タイトル
  • 温度
  • 取得時間

が要入力項目です。

2018-08-29_10h07_26

タイトルはとりあえず何でもいいので、今回は「測定値」としました。
次の「温度」」が肝心なのですが、その他のアクションと同じように「動的なコンテンツの追加」から展開されるダイアログから入力します。

2018-08-29_20h41_06

基本的にはこれでOK

2018-08-29_10h22_41

最後にステップ全体を「保存」して終了です。

二つ隣にある「実行」をクリックして、エラーが無いか確認しましょう。うまく動作すれば、SharePointに値が登録されていくはずです。

image

ということで、うまく登録されていますね。

今回のネタ元のエントリーでは、ここからExcel出力してグラフ化しました。

Office365 Flowからの場合

Office365のFlowからの場合でも、大きな手順は変わりません。
ほとんどLogic Appsと同じ感覚で取得できますが、一点だけ異なる点が。

2018-08-29_09h31_39

新たなフローを作成

2018-08-29_09h32_37

イチから作成

2018-08-29_09h33_09 2018-08-29_09h33_35

スケジュールのトリガーを選択

2018-08-29_09h17_33

ここで、10秒ごとのトリガー作成を試みたところ、契約しているプランではこのタイミングの設定はできないとのこと。
私が契約しているのはBusiness Premium のため、E3などならできるかもしれません。

E3で契約しているテナントお持ちの方、誰か試してみてください。

2018-08-29_09h35_10

本当はOffice365で完結させたかったのですが、上記の理由でやむを得ずLogic Appsでの対応となったわけです。
Flowの場合、最低60秒=1分から可能のようです。

ということで終了です。
ちゃちゃっと書くつもりがずいぶんと長くなってしまいました。

そのうち続編書きます。

Wio node + Azure Logic Appsでお手軽IoT【Wio node初期設定編】

こんにちわ。

先日とうとうインフルBを被弾してしまい、一週間ほど臥せっておりました。この季節ホントいろいろ萎えます。早く夏来ないかな。

さて、そんな冬に差し掛かる昨年秋のころ、SeeedさんからWio LTEという面白いプロダクトのハンズオンが企画され一瞬沸き立ったのですが、その時はそれほどLTEの必要性もなく、またLTEモジュール搭載のせいもあってかややお高めの値段設定もあってスルーしておりました。

が、実はその裏に自分にとってとても要件にフィットしやすいデバイスがすでにラインナップあったことを先日のHack-Chu2018の際に知りました。それがWio node。
巷ではすでに試してみた記事がたくさんあり、ネタ的には今更感がありますが、個人的にちょうどWio nodeの仕様にピタリくる要件があり、あーこれは一度試してみないと!

ってことで試してみました。

Azure 各種サービスとWio nodeでPCを物理制御したい

今回は明確に用途が決まっており、事務所に設置してある特殊用途PC(謎)の・・・

  • 状態監視
  • インターネット経由の電源制御

が目的です。
このPCが結構めんどくさくて、常時動いていてほしいんだけどそこそこの負荷で動いているので時々困ったことにハングアップするという曲者。
ハングアップ状態を検知したうえで、リモート(TeamViewerなりリモデ)での復旧が困難と判断されたときに、電源を強制遮断し再起動するという荒業を担ってもらいます。

構成図はこんな感じ。

matome

AzureのLogicAppsを中心に、いろいろと都合のいいサービスにつなげている状態です。
通常自分が見るUIは、監視用にPowerBIのリポート、緊急時に通知が来たBot経由で電源制御を行うといった感じです。

まずは図の緑枠のWio node単体の動作テストまで。
最終的には、温度センサーからの取得データをAzure上に蓄積し、さらには電源制御をBot経由で実装する予定です。

ということでとにもかくにも物がなけりゃってことで注文しました。今回はマルツオンライン。

https://www.marutsu.co.jp/

で、届いたのがこちら。

IMG_20180302_195911166_HDR

Wio node二つに、温度計測用のセンサーが二つ、電源制御用のリレーが二つです。制御したいPCは3台あるのですが、とりあえず2台でテスト運用してみることに。

Wio nodeの設定

まずはWio nodeをWeb APIから操作するための設定を行います。

これが結構ハマったなぁ・・・

流れはこんな感じ

  1. Wio nodeに電源投入
  2. スイッチ長押しして設定モードに突入
  3. 設定用アプリを立ち上げ設定開始(iOSまたはAndroid)
  4. 設定完了したらREST API叩いてテスト

これだけのはずが・・・当初自宅のWi-fiのセキュリティ設定のまずさもあって苦戦。結局Android版ではNGのまま、iOS版で設定完了。以下その手順

まずはWio nodeに電源投入。
電源用のカプラを用いるか、MicroUSBにモバイル電源を用意する。電源用のカプラに二次電池を搭載した場合、このMicroUSB端子からの充電にも対応する模様。おもしろい。

IMG_20180303_162638742_HDR

Android版設定手順(結局設定完了せず)

Google Playで「Wio link」で検索し、アプリをインストールします。

Screenshot_20180303-162721

上記ではすでに1デバイス登録されていますが、新規登録時は右肩の「+」をクリックします。

Screenshot_20180303-162725

導入するデバイスを選択します。
今回は当然「Wio node」。

Screenshot_20180303-162730

Android版はこのまま「Next」をクリック

Screenshot_20180303-162745

Wio nodeに接続するWi-fiを選択します。

Screenshot_20180303-162750

選択したWi-fiのパスワードを入力します。
(※なぜかこのwi-fiパスワードがうまく通らない瞬間もあった)

Screenshot_20180303-162755

Wi-fi接続が完了すると、該当するWio nodeが表示されるので、クリック。

Screenshot_20180303-162802

AndroidからWio nodeへファームの更新処理が渡されている(と思われる)

Screenshot_20180303-162818

同様にWi-fiのパスワードが渡される(と思われる)
この後、ここまで緩い点滅だった青LEDがはっきりとした短滅に代わるため、Wio node内部ではセットアップができているのではと思われる。
あとはパスワード設定したWi-fi経由でAndroid↔Wio node間で通信が成立すればセットアップ終了と思われるのだが…

Screenshot_20180303-162832

残念ながら何度やってもここで終了。

この時点でコマンドラインツールの存在を知るも、一旦手持ちのiOS機でテストすることを思い立ちiOSで設定実施。

iOS版設定手順(正常に設定完了)

 

 

 

IMG_0678

Android同様右上の「+」から設定開始。

IMG_0679

同じようにWio nodeを選択し

IMG_0680

ただしここでiOS版はちょっと動きが異なる。
Android版は上位接続用のwi-fiの設定が求められるが、まずWio nodeへの接続が必要になる。

しかも、画面の「Goto wifi list」を押しても無情に
「手動でiOSとWi-fi接続してくれ」とダイアログが出るだけ。
仕方がないので、iOSのWi-fi設定からWio nodeを探し出して接続する。

IMG_0682

接続後設定画面に戻って再度「Goto wifi list」をタップすると画面が切り替わり、ようやくWi-fiの接続リストが表示される。

IMG_0683

該当のwi-fiをタップし

IMG_0684

パスワードを入力し「Join」をタップ。

IMG_0685

するとAndroid版と同じようにWio nodeに接続しセットアップを開始するのだが・・・・

IMG_0686

あっけなく設定が完了する。
この時の青LEDの動きはAndroid版と同じなので、検証は必要だがAndroid版の場合、セットアップ後のキャッチアップがうまくいっていないのでは?と思われる。

IMG_0687

すでに一つ目のセットアップが完了しているが、二つ目も無事登録された。(両方とも、Android版で設定→NG→iOS版で設定→OKという流れ。)

 

コマンドラインツール

上記のパターンでiOS版を用意できない場合は、コマンドラインツールも用意されている。

今回はテストしていないが、八方塞がった場合はお試しあれ。

https://github.com/Seeed-Studio/wio-cli

REST API

すでに長くなっているけど、ここからが本番。

Wio nodeの最大の便利ポイントが、Seeed社が運用するクラウドサーバ経由で、セットアップしたWio nodeの操作ができること。
しかもわかりやすいREST API経由。

自分のWio nodeデバイス固有のアクセストークンが含まれたURLを、各デバイスに用意された仕様に基づいて投げてやると・・・

Screenshot_20180303-231318

こいつの場合はリレーの制御。
ON=1なのでパラメタ設定して「POST」。

Screenshot_20180303-231332

ほどなくしてレスポンスあり。
例によってJSONなので、PG処理も簡単。

IMG_20180303_005602791_HDR

実際のHWの動き。
バッテリーに接続されたLEDが、リレーON(1)で点灯。
(基板上の小さなLEDもONしているのがわかる)

IMG_20180303_005616504_HDR

リレーOFF(0)を送ってやると、OFFになる。

ネット経由ということもあり若干の遅延はあるものの、数秒あるかないか。今回の用途では十分なレスポンス。

初期セットアップに手間取ったものの、そこから動作検証まではものの3分。これは便利。

次回は、温度センサーからの測定値をAzure経由で処理する。

追記

ということで、続編書きました。

https://shinya.nagoya/2018/08/30/wioazure002/