小動物か?

3月7日から地中温度データのロスが発生。

他のデータは採取できている事から、ハード的な要因が強いと思い現地調査へ。

予想は的中。

何かが噛んだ跡と、無残にひきちぎられたケーブルがそこにありました。
ひきちぎられることは無いだろうと、高を括っていたが現実はそんなに甘くないと実感。

物理的な対策を考えます。

以上

No response to 4 echo-requests

法人様ハウス内でテスト開始してから丸2カ月。

初めてデータロスが発生した。

syslogを調べてみると
###########################################################################
Feb 15 01:06:04 pppd[8416]: No response to 4 echo-requests
Feb 15 01:06:04 pppd[8416]: Serial link appears to be disconnected.
Feb 15 01:06:04 pppd[8416]: Connect time 1298.1 minutes.
Feb 15 01:06:04 pppd[8416]: Sent 299553 bytes, received 403732 bytes.
Feb 15 01:06:10 pppd[8416]: Connection terminated.
Feb 15 01:06:11 pppd[8416]: Modem hangup
Feb 15 01:06:11 pppd[8416]: Exit.
###########################################################################

PPPのLCPエコーリクエストが4回失敗して、モデムがハングアップ。
2ヵ月動作させて初めての症状なのだが、その時間帯でキャリアのメンテが実施されているのでその影響なのか。

ともあれ、PPPが不安定だったとしても、これで停止するようでは話にならない。
リクエスト回数を増やすか、その他処理を講じることとする。

以上

VPNがはれなくなる(CRL has expired)

リモートからテスト環境に接続できなくってしまった。
その時の対応策を記載しておく。

ハード:Raspberry-pi3
ソフト:OpenVPN-2.4
openvpnサービス状態:active

/var/log/openvpn.log の状態を確認。
==================================================================================================
54975 TLS: Initial packet from [AF_INET]134.180.4.40:54975, sid=5163289a 123c2f95
54975 VERIFY ERROR: depth=0, error=CRL has expired: CN=client
54975 OpenSSL: error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed
54975 TLS_ERROR: BIO read tls_read_plaintext error
54975 TLS Error: TLS object -> incoming plaintext read error
54975 TLS Error: TLS handshake failed
54975 SIGUSR1[soft,tls-error] received, client-instance restarting
==================================================================================================
verify error
error=CRL has expired=期限切れ

varsファイルを確認。
日数設定が書かれていない。(デフォルト180日?)

対応策
varsファイルに、日数設定の構文を追加し、crl.pemを再作成することで接続可能になるとのこと。

varsファイルに下記追加。
set_var EASYRSA_CRL_DAYS 3650 (10年)

crl.pem再作成。
/etc/openvpn/easy-rsa/easyrsa gen-crl

openvpn再起動。
/etc/init.d/openvpn restart

クライアントから接続確認。

以上

【第二弾】ハウス内のIoTセンシング開始

別ハウス内のセンシングを開始しました。
今回は、気温・湿度・気圧、地温、さらに日照度をセンシングします。
第一弾との大きな違いは、インターネットへの抜け方をモバイルルータからUSB型SIMドングルへの変更したこと。
前回より、安定したセンシングができることを期待し、本日から3ヵ月を目安に実施します。

関係者の皆様、どうぞよろしくお願いします。

【第一弾】ハウス内のセンシングテスト終了

活動メンバーのハウス内で9月下旬から11月下旬まで、IoTによるセンシングテストが終了しました。

結論からすると、納得できる状況ではない。

見える化した項目は、気温・湿度・気圧・地温。

また、指定した閾値を超えた場合に特定メールへ連絡。

接続イメージ:Raspi—(Wi-Fi)–MobileRouter(SIM)—(3G/LTE)—AWS

Raspi自体はエラーなく動作していたが、MobileRouterの方で不具合が多発した。

ISPに確認を取ったところ、本体が不安定になっているのではとのことで、機器交換を実施。

結局、不安定になる原因はよくわからなかったが、機器交換で症状は出なくなったことは確かである。

MobileRouterの長時間連続稼働は、ちょっと厳しいかな。

 

第二弾の設置テストは、12月17日から別ハウスにて実施。

それまでに、機器の接続構成を下記のように変更し、再トライします。

接続イメージ:Raspi-USBドングル(SIM)—(3G/LTE)—AWS

関係の皆様、引き続きよろしくお願いいたします。

 

ESP8266乾電池稼働の調査結果

こんにちは、ミウラネットワークスの三浦です。

10月より実施していたESP8266とBME280センサを使用した環境データの測定を屋内のDeep Sleepモードで実施してきましたが、乾電池の寿命となりました。

連続可動日数は70日でした。(当社調べ)

成果の評価としては、DeepSleepモードで、3か月くらいを希望として考えていたのですが、少し及びませんでした。実用レベルかといえば、ちょっと厳しいと感じました。

電池の種類を変える、電池の本数を増やす(供給電圧を上げる)とかの工夫で延命はできるかもしれませんが、本番環境で電池駆動が必須になった場合に改めて考えます。
デバイス、設置環境と通信方式の組み合わせで適材適所で考えていくしかなさそうです。

他のモードとの比較結果は以下のグラフの通りです。

Wi-Fi環境での乾電池稼働日数(当社調べ)

Wi-Fi環境での乾電池稼働日数(当社調べ)

ではまた。

SORACOM Technology Camp 出席してきました

久しぶりの東京出張でした。

SORACOM_Tech_Camp_2018

SORACOM_Tech_Camp_2018

雰囲気を味わいたくて、遠路参加してしました。
SORACOMのサービスを体系的に知る良い機会でした。いくつかPoCの参考になる情報もありましたので早速実践したいと思います。
買ったままの「SORACOM LTE-M Button」も早く実験してみたい、

けど時間がない、でも大丈夫?

AWS IoT 1-click届きました

SORACOM LTE-M Button powered by AWS 届きました。

SORACOM_LTE-M_Button

SORACOM_LTE-M_Button

限定価格の先行予約で2個注文していました。
日本初の「AWS IoT 1-Click」に対応したボタン型デバイスです。
ボタンとメールやSNSの利用を想定しています。農業IoTというより
見守り系などで使えそうな気がします。どう使うかはアイデア勝負な
ところはあると思います。
先ずはともあれ、いろいろ試してみたいと思います。

農業IoTの難しさ(電源編)

農業分野のIoTに取り組むにあたって技術面でハードルになるのが、

・電源の確保
・ネットワークの接続性
・安定的な計測
・セキュリティ・盗難対策、などです。

そのうち、今回は「電源の確保」について書きたいと思います。

電源の確保
当たり前ですが、圃場の真ん中に電源はありません。
ハウスであれば、照明や外気取り込みなど電源を要する設備があり、そこから電源を確保することも可能ですが、少なくとも水耕田にはありません。
従って電源を確保するために、
・乾電池
・スマホ用充電バッテリー
・太陽光パネル
・電源工事を行いを電源を引っ張ってくる

乾電池駆動
小規模施設で現実なのは、乾電池もしくは充電バッテリであり、現在これを想定した耐久試験を行っています。
ここで考えなければいけないのが、デバイスの消費電力です。Wi-Fiで通信すると結構な電力を消費します。

例えば、Raspberry-Pi-3B+が、400mA(2.0W)、Raspberry-Pi-Zeroでも、120mA(0.7W)というデータ(*1)があります。
ESP32でも、送信時240mA)、「一般的な」受信待機時(96~100mA)というデータ(*2)があります。

(*1)参考 http://www.pidramble.com/wiki/benchmarks/power-consumption
(*2)参考 https://www.espressif.com/sites/default/files/documentation/esp32_datasheet_en.pdf

プロトタイプの試験でも、単三電池3個で電源供給した場合の気象データ測定で2,3日しか電池がもちませんでした。
これでは実用にならないということで、デバイス(ESP32,ESP8266)で「Deep Sleep」モードにプログラムを変更し、待機時の電力を抑える試験を行っています。

現在ほぼ3週間を経過し、引き続き稼働中です。がんばれー!
一方で、Wi-Fiの消費電力が大きいのであれば、他の通信方式、BlueTooth(BLE)やLoRaWANも考えられますね。
これらについてもいろいろ試していきたいので、次の機会でレポートしたいと思います。

乾電池駆動のESP8266

ではまた。