ブログ - 監視/防犯/みまもり/遠隔カテゴリのエントリ
ドコデモセンサーをBCPサイトに取り付けた件．
緑色がトイレ前，青色が玄関前．我ながらいい感じ．もうちょっとセンサーを増やしたいかな．
問題は，プラネックスのこのサービスがいつまで続くのか，ということだ．続かなかったら，これらのセンサーはただのガラクタ．
緑色がトイレ前，青色が玄関前．我ながらいい感じ．もうちょっとセンサーを増やしたいかな．
問題は，プラネックスのこのサービスがいつまで続くのか，ということだ．続かなかったら，これらのセンサーはただのガラクタ．
メーカサポートにも問い合わせしながら，４ヶ月ほど試して見たけれど，どうにか使い物になると判断して，この年末年始をきっかけに使えるようにセットアップしました．
今回購入したのは２台．
玄関とトイレ前にセンサーを設置．結果は次の通り．
夜中にトイレに起きる回数が多いといっていたけれど，それを裏付けるような結果．逆に日中，全くトイレに行ってないのが気になるが，出かけているのかな？
と思うけれど，玄関前に付けたセンサーにはちょいちょい反応している．トイレに行く導線の問題かな．ベッドルームからトイレに行く道に設置したけれど，それだけだとキッチンからトイレに移動する際のルートに反応しないようである．設置場所については検討の余地があるね．
キッチンにも付けた方がいいけれど，家の中心にあるので少し電波の入りが悪い．メッシュ型のWi-Fiルータの設置を検討すべきかな．
今回購入したのは２台．
玄関とトイレ前にセンサーを設置．結果は次の通り．
夜中にトイレに起きる回数が多いといっていたけれど，それを裏付けるような結果．逆に日中，全くトイレに行ってないのが気になるが，出かけているのかな？
と思うけれど，玄関前に付けたセンサーにはちょいちょい反応している．トイレに行く導線の問題かな．ベッドルームからトイレに行く道に設置したけれど，それだけだとキッチンからトイレに移動する際のルートに反応しないようである．設置場所については検討の余地があるね．
キッチンにも付けた方がいいけれど，家の中心にあるので少し電波の入りが悪い．メッシュ型のWi-Fiルータの設置を検討すべきかな．
メーカのPlanexの回答は早くて具体的だけれど逆にAPI改善は絶望的？な感じなので，視点を変えてメール通知にしてみた．
ほんとはAPIを利用てグラフを書くのがやって見たかったのだけれど，それはまたいつかということで．
今回はメールの到着数，つまりファイル数をカウントしてグラフを出す様にして見た．
あいかわらず人間がずっと止まる場合に大量の検知＝大量のメールが来るのだけれど，メール件数は多くても問題ないので，まずは5分間隔でカウントしてみた．
まだグラフが粗いので，カウントの間隔などを調整してみようと思うけれど，目的は達成できそうな気がしてきた．
ほんとはAPIを利用てグラフを書くのがやって見たかったのだけれど，それはまたいつかということで．
今回はメールの到着数，つまりファイル数をカウントしてグラフを出す様にして見た．
あいかわらず人間がずっと止まる場合に大量の検知＝大量のメールが来るのだけれど，メール件数は多くても問題ないので，まずは5分間隔でカウントしてみた．
まだグラフが粗いので，カウントの間隔などを調整してみようと思うけれど，目的は達成できそうな気がしてきた．
APIリクエストが過負荷になっていて，データが取得できないとプラネックスのドコデモセンサー．公式サイト上でお知らせを出すというので，見守っていたけれど一向に実現されないので，センサーの値をAPIで取る，ということをやめることにした．
代わりに，メール．
センサーが反応したら，メール通知が来るように設定できるということなので，設定して見た．
１回で１通くるらしいので，そのメール件数をカウントすれば，目的が達成されるかなと考えた．
センサーが過剰すぎてメール来すぎても困るけど，とりあえず様子見してみる．
代わりに，メール．
センサーが反応したら，メール通知が来るように設定できるということなので，設定して見た．
１回で１通くるらしいので，そのメール件数をカウントすれば，目的が達成されるかなと考えた．
センサーが過剰すぎてメール来すぎても困るけど，とりあえず様子見してみる．
プラネックスから返答が来た．いつも意外と速いレスポンスで，状況がどうであれ印象は良い．プラネックスは好きなデザインもメーカだしね．
crontabで実行しているタイミングを毎時0分からの5分毎から毎時4分からの5分毎という程度にずらしてみたけれど，結果は変わらず．
試しに，コマンドを手動で連打してみた．
たまーに値が取得できる模様．ここで気になったのはこの文言．
データが取得できないけれど，何度もリトライすれば取れる様なので，取れるまでリクエストするんじゃなかろうか．つまり，悪循環の可能性も否定できない．．．？
まぁ，単純に大量にアクセスしてくる人もいると思うけど，センサー１つに対して１リクエストなので，業務とかで工場？とかで大量にセンサーを設置した場合は，デバイスの数だけアクセスされることになるから，１リクエストあたりのデバイス取得数を増やす必要がある様で，その改善中だそうです．
APIのデーター取得に関してでございますが、
APIの過剰な呼び出しによるサーバーへの負荷が重く、
センサデータの取得が正常に行えない事象が発生したため、
APIを１スレッドに制限する修正を行っております。
１スレッドを複数のユーザーで共有することになり、他のユーザーがAPIを使っている間は、
他のユーザーには、ご申告のエラーが返る仕様となっております。
しかし、スレッドが空いていれば、正常に値は返されます。
制限措置後も、現在、過剰なAPIリクエストを出されているユーザー様がいらっしゃるため、
今後は、IPアドレス遮断も含めて対応を検討しているところとなります。
エラー表示が出た場合は、お手数をおかけしますが、
画面の更新を何度か行っていただくか、お時間を空けてアクセスいただければと存じます。
誠に申し訳ございません。
試しに，コマンドを手動で連打してみた．
$ ./DocodemoSensor.sh
Server too busy. Please try again later..[MBA2013: ujpadmin 16:14:06 ]
$ ./DocodemoSensor.sh
[
["2019-09-14 07:01:14", "40"]
,["2019-09-14 07:03:13", "40"]
,["2019-09-14 07:04:24", "40"]
,["2019-09-14 07:13:25", "40"]
,["2019-09-14 07:13:38", "40"]
,["2019-09-14 07:13:50", "40"]
]
[MBA2013:itunes 16:14:11 ~/mrtg/bin ]
$ ./DocodemoSensor.sh
Server too busy. Please try again later..[MBA2013: ujpadmin 16:14:15 ]
$ ./DocodemoSensor.sh
Server too busy. Please try again later..[MBA2013: ujpadmin 16:14:17 ]
$ ./DocodemoSensor.sh
Server too busy. Please try again later..[MBA2013: ujpadmin 16:14:18 ]
$ ./DocodemoSensor.sh
Server too busy. Please try again later..[MBA2013: ujpadmin 16:14:19 ]
$ ./DocodemoSensor.sh
Server too busy. Please try again later..[MBA2013: ujpadmin 16:14:20 ]
$ ./DocodemoSensor.sh
[
["2019-09-14 07:01:14", "40"]
,["2019-09-14 07:03:13", "40"]
,["2019-09-14 07:04:24", "40"]
,["2019-09-14 07:13:25", "40"]
,["2019-09-14 07:13:38", "40"]
,["2019-09-14 07:13:50", "40"]
]
[MBA2013: ujpadmin 16:14:21 ]
$
制限措置後も、現在、過剰なAPIリクエストを出されているユーザー様がいらっしゃるため、
まぁ，単純に大量にアクセスしてくる人もいると思うけど，センサー１つに対して１リクエストなので，業務とかで工場？とかで大量にセンサーを設置した場合は，デバイスの数だけアクセスされることになるから，１リクエストあたりのデバイス取得数を増やす必要がある様で，その改善中だそうです．
プラネックスの人感センサー，WS-USB02-PIRを使って試験継続中．
メーカに不具合問い合わせして見た結果，PIRの値を24から40に変えて数値に根拠は全くないまま様子見．
なんとなくそれっぽい数値は獲れ続けていて，プラネックスクラウドに接続すると，それらしきグラフは現在も取れている．
しかし，相変わらずAPIを呼び出していると，エラーになる．
現在，crontabで5分おきに取得スクリプトを実行しているので，これを逆に集中しなさそうな時間にずらして見ることにする．
メーカに不具合問い合わせして見た結果，PIRの値を24から40に変えて数値に根拠は全くないまま様子見．
なんとなくそれっぽい数値は獲れ続けていて，プラネックスクラウドに接続すると，それらしきグラフは現在も取れている．
しかし，相変わらずAPIを呼び出していると，エラーになる．
Server too busy. Please try again later..
前回，プラネックスに不具合の連絡をしたところまで記録しているのですが，その後進展があり．．．
意外とすぐ応答があって，丁寧に状況が記載されていました．抜粋するとこんな感じ．
異常なカウントは、検知感度の「PIR」を上げると改善する場合ある
APIの過剰な呼び出しによるサーバーへの負荷が重い
センサデータの取得低下、WEBへのログオン不可、レスポンスの低下など不具合あり
8/16からAPIを１スレッドに制限する修正
１スレッドを複数のユーザーで共有することになる
他のユーザーがAPIを使っている間は、他のユーザーには「server busy」が返る仕様
制限措置後も、現在、最高で一日に1万回以上の、APIリクエストするユーザーがいる
まず，既にというか最初からリクエスト数は5分に1回なのと，制限上の仕組みからこれ以下の頻度にしてもタイミングが悪いとどうしようもないので，ユーザとしでできることはPIR値を変更することかと．
PIRとは，Passive Infrared Rayのことで，赤外線放射の変化によって人間の接近を検知するセンサのこと．検出範囲内で動きがあると検知するのだけれど，今回推奨された対処方法は，その数値を上げることによって鈍くする感じかな．
初期設定値が24となっていたけれど，これを変更．
マニュアルとかないのでどう行った数値が良いのかわからないけれど，一旦40としてみた．
そうして半日〜1日程度放置していて，プラネックスクラウドに接続してみたら，デバイスがオンライン表示に．この間，デバイスは電源OFF/ONや設定変更はしていない状態．PIR値を変更して大量アクセスが行われなくなった効果なのか，サーバ側の改善効果なのかわかりませんが．．．
その後，プラネックスクラウド側にアクセスするとグラフが生成されるようになっていました．
この記事を書く直前の状態．
センサーのある部屋にずっと座っていても，１時間あたり200オーバーなどの異常値にはならない感じだけれど，ここで20回とか14回とかの数値があるけれど，これが適正なのかどうか．
サンプリングが20秒に1回だそうなので，ずっとセンサーの前に座り続けていたら1分間で3回検知．1時間で180回という感じかな．
プラネックスクラウドに接続してのグラフ表示は問題なさそうなのだけれど，API呼び出しの方は相変わらずServer too busy. Please try again later..のままです．．．
意外とすぐ応答があって，丁寧に状況が記載されていました．抜粋するとこんな感じ．
まず，既にというか最初からリクエスト数は5分に1回なのと，制限上の仕組みからこれ以下の頻度にしてもタイミングが悪いとどうしようもないので，ユーザとしでできることはPIR値を変更することかと．
PIRとは，Passive Infrared Rayのことで，赤外線放射の変化によって人間の接近を検知するセンサのこと．検出範囲内で動きがあると検知するのだけれど，今回推奨された対処方法は，その数値を上げることによって鈍くする感じかな．
初期設定値が24となっていたけれど，これを変更．
マニュアルとかないのでどう行った数値が良いのかわからないけれど，一旦40としてみた．
そうして半日〜1日程度放置していて，プラネックスクラウドに接続してみたら，デバイスがオンライン表示に．この間，デバイスは電源OFF/ONや設定変更はしていない状態．PIR値を変更して大量アクセスが行われなくなった効果なのか，サーバ側の改善効果なのかわかりませんが．．．
その後，プラネックスクラウド側にアクセスするとグラフが生成されるようになっていました．
この記事を書く直前の状態．
センサーのある部屋にずっと座っていても，１時間あたり200オーバーなどの異常値にはならない感じだけれど，ここで20回とか14回とかの数値があるけれど，これが適正なのかどうか．
サンプリングが20秒に1回だそうなので，ずっとセンサーの前に座り続けていたら1分間で3回検知．1時間で180回という感じかな．
プラネックスクラウドに接続してのグラフ表示は問題なさそうなのだけれど，API呼び出しの方は相変わらずServer too busy. Please try again later..のままです．．．
何度か電源OFF/ONをしたり，時間を空けてクラウド側をチェックしてみているが，一向に治る気配がないので，故障かもしれない？とおもって，プラネックスのサイトから問い合わせして見た．
問い合わせフォームでは，状況／環境，問い合わせ内容，シリアルナンバーなどを入力して送信するのだけれど，カーボンコピーがメールで送られてこない模様．．．
問い合わせ番号だけでていたのでメモ．
問い合わせフォームでは，状況／環境，問い合わせ内容，シリアルナンバーなどを入力して送信するのだけれど，カーボンコピーがメールで送られてこない模様．．．
問い合わせ番号だけでていたのでメモ．
たった一人，最大二人しかいない部屋で，無人なのに毎時人感センサーが記録されていた件．これはドコデモセンサーの暴走？かとおもって電源OFF/ONしました．電源ボタンは無いから，抜き差し．
グラフを見ると，止まってます．ただし，日中のデータは，もうちょっと出入りが記録されていても良いのだけれど．．．
そして，翌日．というか今日．
夜中の3時になぜかまた，多めに記録された後，無反応になった．．．
ちなみに，コマンドを打つとこんな感じ．
無反応というわけでもなく，括弧だけレスポンスしてきている．エラーコードなどは無いので，たぶんサーバ側で何か不具合があるのでしょう．．．
高負荷アクセスがあるとして，端末の総数は出荷した数をメーカが知っているわけだから，そしてどれくらいの頻度でデータを送信するかという事も，非公開なので逆にメーカしかわからないわけで，そこでサイジングができてないのは，素人っぽい仕事だ．
現状，このドコデモセンサーは業務用として使えないのでは無いかなぁ．
グラフを見ると，止まってます．ただし，日中のデータは，もうちょっと出入りが記録されていても良いのだけれど．．．
そして，翌日．というか今日．
夜中の3時になぜかまた，多めに記録された後，無反応になった．．．
ちなみに，コマンドを打つとこんな感じ．
$ ./DocodemoSensor.sh
[
]
$
高負荷アクセスがあるとして，端末の総数は出荷した数をメーカが知っているわけだから，そしてどれくらいの頻度でデータを送信するかという事も，非公開なので逆にメーカしかわからないわけで，そこでサイジングができてないのは，素人っぽい仕事だ．
現状，このドコデモセンサーは業務用として使えないのでは無いかなぁ．
プラネックスのドコデモセンサーのPIP，人感センサーを使って遠隔オカン監視を構築，検証中の件．
シェルを作ってMRTGを使ってグラフ化してみているのだけれど，12時からグラフがでてない．．．
こんな感じ．コマンドを打ってどういうステータスになっているのか確認してみた．
なんだサーバが応答してない．．．相手のあることなので，しかたない．放置．
と半日ほど知らんふりして再度MRTGをみてみたら，グラフが復活していた．コマンドもレスポンスするようになっていた．自然復旧．
ただし，グラフのデータはMRTG上に設定した上限の15を超えているのでグラフの意味がない〜
どういうことか，プラネックスクラウドに接続してみた．
なんだかトンデモナイ数字になっている．
13時以降，17時ごろまでセンサーの設置してある部屋にいたので検知されているのなら，それは仕方ないが，前日の夜の0時は95だったのに，1時間あたり200カウントを超えている．
そしてなにより，21時30分から，くら寿司を予約してカミさんと出て行ったので，21時〜23時は家に，その部屋に人がいないのに検知されている．．．
ちょっと思ったのは，このドコデモセンサーが暴走？して，大量にアクセスしているから，APIで情報を取り出そうとするコマンドプログラムのリクエスト数と合算されてtoo manyではじかれているので無いだろうか．．．？
とりあえず，ドコデモセンサーの電源をOFF/ON（USBポートから引き抜き）してみた．これで様子を見てみよう．
シェルを作ってMRTGを使ってグラフ化してみているのだけれど，12時からグラフがでてない．．．
こんな感じ．コマンドを打ってどういうステータスになっているのか確認してみた．
$ ./DocodemoSensor.sh
Server too busy. Please try again later..
$
と半日ほど知らんふりして再度MRTGをみてみたら，グラフが復活していた．コマンドもレスポンスするようになっていた．自然復旧．
ただし，グラフのデータはMRTG上に設定した上限の15を超えているのでグラフの意味がない〜
どういうことか，プラネックスクラウドに接続してみた．
なんだかトンデモナイ数字になっている．
13時以降，17時ごろまでセンサーの設置してある部屋にいたので検知されているのなら，それは仕方ないが，前日の夜の0時は95だったのに，1時間あたり200カウントを超えている．
そしてなにより，21時30分から，くら寿司を予約してカミさんと出て行ったので，21時〜23時は家に，その部屋に人がいないのに検知されている．．．
ちょっと思ったのは，このドコデモセンサーが暴走？して，大量にアクセスしているから，APIで情報を取り出そうとするコマンドプログラムのリクエスト数と合算されてtoo manyではじかれているので無いだろうか．．．？
とりあえず，ドコデモセンサーの電源をOFF/ON（USBポートから引き抜き）してみた．これで様子を見てみよう．
ドコデモセンサーのデータが保存されるPlanex Cloud上のデータは，時刻がUTCで保存されているので日本のJSTとは9時間差がある．日本は日出ずる国なのでUTCが9時間早い．
そこで，9時間差をコマンドで計算する．
まずは現在時間．
そして，9時間前を計算．
これは現在時間からの相対時間で計算されるから，日付をまたいでも問題なく計算されます．
そしてこれを応用して作ったコマンドがこれ．
なんかcurlのパラメータを作るのに苦労してこんなことになった．とりあえず動くので腕のある人は整形してもらえればと．．．
このコマンドでは，実行した日時の間のデータを取得することになる．
応用する為には，これの数をカウントする．
実際のデータが11点なので，３行多いことを念頭に入れて利用する．
ここで使ったのは，GNU dateコマンドなので注意．
そこで，9時間差をコマンドで計算する．
まずは現在時間．
$ date
月 8 12 19:00:38 JST 2019
$
$ date --date "`date +%Y%m%d` `date +%H:%M` 9 hours ago" "+%Y%m%d %H:%S"
20190812 10:00
$
そしてこれを応用して作ったコマンドがこれ．
$ cat DocodemoSensor.sh🆑
#!/bin/bash
main () {
MODEL='"WS-USB02-PIR"'
MACADDR='"24:72:60:40:XX:XX"'
TOKEN=2f2887db3498XXXXXXXXXXXXXXXXXX
DATE1=`date +%Y%m%d`
DATE2=`date +%H:%M`
DATEUTC1=`date --date "${DATE1} ${DATE2} 9 hours ago" "+%Y-%m-%d %H"`
DATEUTC=`echo ${DATEUTC1}|sed 's/ /+/g'`
DATE1=${DATEUTC}:00:00
DATE2=${DATEUTC}:59:59
DATEF="${DATE1}"
DATET="${DATE2}"
PARAM1="https://svcipp.planex.co.jp/api/get_data.php?type=${MODEL}&mac=${MACADDR}&"
PARAM3="from="
PARAM4="${DATEF}"
PARAM5="&to="
PARAM6="${DATET}"
PARAM7="&token=${TOKEN}"
/usr/local/opt/curl/bin/curl -s ${PARAM1}${PARAM3}\"${PARAM4}\"${PARAM5}\"${PARAM6}\"${PARAM7}
}
main
$
このコマンドでは，実行した日時の間のデータを取得することになる．
$ ./DocodemoSensor.sh🆑
[
["2019-08-13 10:04:34", "24"]
,["2019-08-13 10:06:46", "24"]
,["2019-08-13 10:12:11", "24"]
,["2019-08-13 10:12:38", "24"]
,["2019-08-13 10:21:31", "24"]
,["2019-08-13 10:21:36", "24"]
,["2019-08-13 10:22:48", "24"]
,["2019-08-13 10:25:15", "24"]
,["2019-08-13 10:27:26", "24"]
,["2019-08-13 10:27:31", "24"]
,["2019-08-13 10:36:17", "24"]
]
$ ./DocodemoSensor.sh|wc -l🆑
14
$
ここで使ったのは，GNU dateコマンドなので注意．
ドコデモセンサーの醍醐味は，クラウド上に保存されたデータを取り出して加工して利用すること．
APIの仕様は，Planex Cloud Serviceにログインして閲覧できるAPI情報から確認できる．
8月7日に過度のアクセスがあったようで，同一IPアドレスからのAPIアクセスは現在は1日500回に限られている模様．
500回となると，1時間あたり20回程度か．人感センサーの場合はタイムラグがあっても問題ないので，５分に１回とすると288回／日なのでクリアできるかな．ドコデモセンサーを複数利用する場合は，もっと頻度を少なくする必要がある．
APIの仕様では，ドコデモセンサーのMAC情報と，デバイス毎に割り当てられているTOKENが必要になる．TOKENは，Planex Cloud Serviceのサイトにログインすれば掲載されている．
で，まずはAPIを組み立ててデータを取り出してみる．
なにかデータが取り出せるた．人感センサーなので，検知した日時が設定されているけれど，２列目の24については意味はわからない．サンプルだと10,20,30なんて書いてあるけれど．．．
そして厄介なことがわかった．Planex Cloud Serviceにログインすると参照できるグラフがこれ．
グラフでは，夜19時に15回カウントされているけれど，APIで取り出した情報だと10時台に15回記録されている．9時間差がある．
これは，Planex Cloud Serviceで記録しているデータがUTC（協定世界時）で記録されていて，グラフはJSTで表示されているからで，APIの結果データもUTCであるから9時間マイナスになっている． これを調整しなければならない．
APIの仕様は，Planex Cloud Serviceにログインして閲覧できるAPI情報から確認できる．
API情報
ドコデモセンサーAPI
エンドポイント
URL=https://svcipp.planex.co.jp/api/
GET ./get_data.php?type="WS-USB02-PIR"&mac="xxxxxxxxxxxx"&
from="2019-01-01 11:22:33"&to="2019-01-31 22:33:44"&token="zzzzzzzzzzzzzz"
RETURN(JSON)
[
["2019-01-01 11:22:33", "10"]
,["2019-01-02 12:22:33", "20"]
,["2019-01-03 13:22:33", "30"]
]
このAPIはPIRの数値を返します。
tokenは、デバイスごとに割り当てられた32桁の英数字です。「デバイス情報」
のページから参照してください。
from,to,返値の時刻はUTC時間です。
データーの保存期間は一ヶ月です。データをダウンロードする場合、一ヶ月以内に
ダウンロードしてください
GET ./get_data.php?type="WS-USB01-THP"&mac="xxxxxxxxxxxx"&from=
"2019-01-01 11:22:33"&to="22019-01-31 22:33:44"&token="zzzzzzzzzzzzzz"
RETURN(JSON)
[
["2019-01-01 11:22:33", "11.1", "41", "1010" ]
,["2019-01-02 12:22:33", "22.2" , "42", "1020" ]
,["2019-01-03 13:22:33", "33.3" , "43", "1030" ]
]
このAPIは温度、湿度、気圧の数値を返します。
tokenは、デバイスごとに割り当てられた32桁の英数字です。「デバイス情報」
のページから参照してください。
from,to,返値の時刻はUTC時間です。
データーの保存期間は一ヶ月です。データをダウンロードする場合、一ヶ月以内に
ダウンロードしてください
【重要なお知らせ】一部のIPアドレスからの集中的なアクセスのため、APIの利用回数に
制限をかけさせて頂きました(約500回/日)。ご協力をお願いいたします。
500回となると，1時間あたり20回程度か．人感センサーの場合はタイムラグがあっても問題ないので，５分に１回とすると288回／日なのでクリアできるかな．ドコデモセンサーを複数利用する場合は，もっと頻度を少なくする必要がある．
APIの仕様では，ドコデモセンサーのMAC情報と，デバイス毎に割り当てられているTOKENが必要になる．TOKENは，Planex Cloud Serviceのサイトにログインすれば掲載されている．
で，まずはAPIを組み立ててデータを取り出してみる．
$ curl "https://svcipp.planex.co.jp/api/get_data.php?type="WS-USB02-PIR"
&mac="MACアドレスを設定"&from="2019-08-10+00:00:00"
&to="2019-08-10+23:59:59"
&token=トークンを設定"
[
["2019-08-10 02:47:46", "24"]
,["2019-08-10 02:57:23", "24"]
,["2019-08-10 06:07:02", "24"]
,["2019-08-10 06:07:45", "24"]
,["2019-08-10 06:08:17", "24"]
,["2019-08-10 08:48:42", "24"]
,["2019-08-10 08:49:53", "24"]
,["2019-08-10 09:19:13", "24"]
,["2019-08-10 09:19:44", "24"]
,["2019-08-10 09:25:39", "24"]
,["2019-08-10 09:25:53", "24"]
,["2019-08-10 09:26:06", "24"]
,["2019-08-10 10:10:34", "24"]
,["2019-08-10 10:10:48", "24"]
,["2019-08-10 10:11:59", "24"]
,["2019-08-10 10:12:05", "24"]
,["2019-08-10 10:13:05", "24"]
,["2019-08-10 10:13:23", "24"]
,["2019-08-10 10:30:21", "24"]
,["2019-08-10 10:30:36", "24"]
,["2019-08-10 10:31:06", "24"]
,["2019-08-10 10:31:19", "24"]
,["2019-08-10 10:33:14", "24"]
,["2019-08-10 10:36:28", "24"]
,["2019-08-10 10:36:54", "24"]
,["2019-08-10 10:37:56", "24"]
,["2019-08-10 10:38:09", "24"]
,["2019-08-10 13:25:28", "24"]
,["2019-08-10 14:05:50", "24"]
,["2019-08-10 14:07:01", "24"]
,["2019-08-10 14:07:17", "24"]
,["2019-08-10 14:07:25", "24"]
,["2019-08-10 14:27:01", "24"]
,["2019-08-10 14:27:10", "24"]
,["2019-08-10 14:27:16", "24"]
,["2019-08-10 14:27:21", "24"]
,["2019-08-10 15:13:45", "24"]
,["2019-08-10 15:16:07", "24"]
,["2019-08-10 15:16:13", "24"]
,["2019-08-10 15:17:03", "24"]
,["2019-08-10 15:18:26", "24"]
,["2019-08-10 15:19:46", "24"]
,["2019-08-10 15:19:55", "24"]
,["2019-08-10 17:21:17", "24"]
,["2019-08-10 17:22:09", "24"]
,["2019-08-10 18:00:03", "24"]
,["2019-08-10 18:06:40", "24"]
]
そして厄介なことがわかった．Planex Cloud Serviceにログインすると参照できるグラフがこれ．
グラフでは，夜19時に15回カウントされているけれど，APIで取り出した情報だと10時台に15回記録されている．9時間差がある．
これは，Planex Cloud Serviceで記録しているデータがUTC（協定世界時）で記録されていて，グラフはJSTで表示されているからで，APIの結果データもUTCであるから9時間マイナスになっている． これを調整しなければならない．
2019年2月にプラネックスから発売されたドコデモセンサーを買って見た．3800円ほど．既に店頭にはない模様．．．
この機械は，いわゆるIoTデバイスで，見守り監視用として整えようとしているものです．
まずは開封の儀．箱は豆腐１丁を半分に切った程度のもので，内容物は本体と説明書のみ．
端子はUSBとなっているけれど，これは電源を取るためだけのもの．つまり，モバイルバッテリーなどを使って電源が取れないところにセンサーを置くことができる．普通にパソコンにつけたらセンサー部分が下を向いているので，パソコンに繋げて使うとなると，使いづらいかもしれない．
セットアップはこんな感じ．
・ドコデモセンサーをUSBポートに接続すると給電され，自動的に電源が入る．
・給電や稼働中がわかるランプは無い．
・デフォルトのWi-Fiアクセスポイントになっているので，パソコンやスマホで接続．
・Webブラウザで接続．
・ドコデモセンサーが接続するWi-Fiのアクセスポイントを設定する．
・勝手にリブート．
それだけで取得したデータがメーカのプラネックスのサーバ（クラウド）に記録されるようになる．あとは，プラネックスでアカウントと取得して，ドコデモセンサーのシリアル番号を登録すると，その状態を見ることができるようになる．
クラウドにデータが保存されるのは１ヶ月ということなので，これをAPIで取り出して何らかの仕組みとして使えば良いです．
この機械は，いわゆるIoTデバイスで，見守り監視用として整えようとしているものです．
まずは開封の儀．箱は豆腐１丁を半分に切った程度のもので，内容物は本体と説明書のみ．
端子はUSBとなっているけれど，これは電源を取るためだけのもの．つまり，モバイルバッテリーなどを使って電源が取れないところにセンサーを置くことができる．普通にパソコンにつけたらセンサー部分が下を向いているので，パソコンに繋げて使うとなると，使いづらいかもしれない．
セットアップはこんな感じ．
・ドコデモセンサーをUSBポートに接続すると給電され，自動的に電源が入る．
・給電や稼働中がわかるランプは無い．
・デフォルトのWi-Fiアクセスポイントになっているので，パソコンやスマホで接続．
・Webブラウザで接続．
・ドコデモセンサーが接続するWi-Fiのアクセスポイントを設定する．
・勝手にリブート．
それだけで取得したデータがメーカのプラネックスのサーバ（クラウド）に記録されるようになる．あとは，プラネックスでアカウントと取得して，ドコデモセンサーのシリアル番号を登録すると，その状態を見ることができるようになる．
クラウドにデータが保存されるのは１ヶ月ということなので，これをAPIで取り出して何らかの仕組みとして使えば良いです．
