工作と競馬2

電子工作、プログラミング、木工といった工作の記録記事、競馬に関する考察記事を掲載するブログ

IFTTTが有料化するので、Webhooks/LINE Notify連携レシピの代替をAWSで検討する

概要


IFTTTのWebhook+LINE Notify連携の代替として、AWS API Gateway + Lambdaの動作を確認した。



背景と目的


IFTTTが2020年10月6日に有料化するらしい。無料枠が少しだけあるのだが、私の場合そこに収まり切らないので、代替が難しそうなレシピを無料枠に充て、他のものはIFTTTより安く実現できる代替手段を検討している。

最近作成した自動水やり器では、

Webhookチャンネルでデータを受けて、LINEチャンネルでLINEのトークルームに結果通知するレシピ

を使っているが、AWSAPI Gateway+Lambdaに変更できそうに思えるので、ちょっと試しにやってみる。この組み合わせだと、使用規模次第で無料枠に収まる。Microsoft Flowも当然候補だが、すでにAWS使っちゃってるので優先で。


詳細


1. LINE NotifyのAPI

ちょっと調べただけで、

qiita.com

など、たくさんの情報が出てきた。Notifyでトークルームに送信できるAPIが用意されているらしい。とりあえず、上記の例はNode.jsだが、ここではPythonスクリプトを書いて試す。

1.1 トークンの取得

LINE NotifyのAPIをたたくには、LINE NotifyのWebサイトにログインして、トークンの取得が必要。トークルームごとにトークンを取得する必要があるようだ。というわけで、以下のボタンを押して表示されたものをメモ。なお、トークンごとに識別名を任意に与えられるらしく、送信時にメッセージの先頭につくらしい。

f:id:dekuo-03:20201003214709p:plain


2 試しに送信

以下を作成。tokenとmessageは外から与える想定。下の方に、試しに動かすコード。

# coding: utf-8

import requests
import json

def post_LINE_Notify(token, params):

    URL = "https://notify-api.line.me/api/notify"
    headers = {
        "Content-Type": "application/x-www-form-urlencoded",
        "Authorization": "Bearer %s" % token
    }
    response = requests.post(URL, data=params, headers=headers)
    ret = {
        "response": json.loads(response.text)
    }
    
    return ret


if __name__ == "__main__":

    token = "取得したトークン"
    params = {
        "message": "これはテストです。" # paramsの中身は、https://notify-bot.line.me/doc/ja/ 参照
    }
    ret = post_LINE_Notify(token, params)
    print(ret)

printした結果は、以下の通り。ステータスコード200が返ってきた。

{'response': {'status': 200, 'message': 'ok'}}

一方、LINEの画面は以下の通り。ちゃんと受信している。 園芸IoTという部分は、トークンを取得する際に、識別名として与えたもの。(自動水やり器の通知用トークルームに送信するのでこんな名前)

f:id:dekuo-03:20201003215907p:plain


3. APIGateway + Lambda

3.1 APIGateway

IFTTTと同じ感じにするため、APIのリソースに、{event}というパスパラメータを用意。 リクエスト統合のapplication/jsonマッピングテンプレートでメソッドリクエストのパススルーを使った場合、Lambdaのevent引数のevent.path.eventに入ってくれる。 (AWSでやるなら、別に互換性持たせずむしろもっといろいろできる仕様にした方がいいかもしれないが)

f:id:dekuo-03:20201003230840p:plain f:id:dekuo-03:20201003230836p:plain


3.2 Lambda

IFTTTでは、本文のJSONでvalue1,2,3を受け取り、パスパラメータでevent名を受け取って、LINE Notify本文を構成する。ここではテストなので、とりあえずパラメータを全部流す。

def lambda_handler(event, context):
    
    token = "取得したトークン"
    params = {
        "message": "event=%s\nvalue1=%s\nvalue2=%s\nvalue3=%s" % \
            (event["params"]["path"]["event"], 
            event["body-json"]["value1"],
            event["body-json"]["value2"],
            event["body-json"]["value3"])
    }
    # 送信
    ret = post_LINE_Notify(token, params)
    
    return ret


3.3 試し実行

f:id:dekuo-03:20201003223843p:plain

LINEの方も、正しく受信できた。

f:id:dekuo-03:20201003230205p:plain

というわけで、一応、API GatewayとLambdaで置き換えできそう。ノンプログラミング環境からの乗り換えにはなるが、発展性があるのでよしとする。


まとめと今後の課題


IFTTTのWebhook+LINE Notify連携の代替として、AWS API Gateway + Lambdaの動作を確認できた。こちらに置き換えようと思う。


リモート水位センサ筐体内温度の上昇を抑えるカバーの効果を検証、2年目稼働状況のまとめ

概要

リモート水位センサ筐体内温度の上昇を抑えるカバーの効果を検証し、期待通りの効果があったことを確認できた。


背景と目的

今年もいよいよ稲刈りの時期が来て、田んぼに水がなくなったため、リモート水位センサも出番が終わった。2年目のシーズンも故障なく無事稼働してくれた。そこで、今年のまとめとして、真夏の筐体内温度上昇を抑えるためのカバー装着効果を検証しておく。


詳細

1. 条件

  • 筐体内温度
    • リモート水位センサシステム内蔵温度計
    • 2019年のデータ
      • 2019/06/28~2019/09/05
    • 2020年のデータ
      • 2020/06/28~2020/09/05
  • 筐体内温度と気温を比較(気象庁データのうち、水位センサ所在地から最も近い地点の温度を使用)


2. 結果

以下の通り、2019年に比べて2020年は温度上昇が抑えられている。特に、日照時間割合が高い、つまり日が照っている状態での温度上昇が抑えられている。なお、日照時間割合が1の場合の平均的な温度は、

  • 2019年: 48℃
  • 2020年: 43℃

と5℃の差となった。事前検証で5~10℃くらいが期待できると書いたが、ほぼその通りになった。

2019年

50℃を頻繁に超えている。

f:id:dekuo-03:20200909233332p:plain

2020年

50℃を超えたのは1度だけ。

f:id:dekuo-03:20200909233336p:plain

比較

すべての日照時間割合のパターンで比較。特に、気温が高いときに、温度上昇が抑えられている。

f:id:dekuo-03:20200909233339p:plain


3. 2年目のまとめ

こちらで、今シーズン開始前にメンテナンスをした内容に沿って書く。

  • 電池容量アップ
    • 使用したエネループが別件でダメージを受けていたらしく、今シーズン開始後早々にくたばってしまった。そのため、通常の乾電池を使用したのだが、その乾電池も怪しいメーカーのものだったらしくあまり持たなかった。再度交換した乾電池は、問題ない。ソーラー発電+リチウムイオン電池蓄電も稼働実績が上がってきているので、来年はソーラーで駆動したい。
  • 水位の分解能調整
    • これは、あまりメリットがなかった。まあ、水位の変化が頻繁に起こるので、わかりやすいといえばわかりやすいが、干上がるか、そうでないかというレベルの判断にはいらなかった。もし、次のモデルを作るようなら、大雑把でいいと思う。
  • 温度上昇を防ぐカバーの装着
    • 上記の通り。十分効果があった。来年もカバー装着する。


まとめと今後の課題

平均的に5℃程度上昇を抑えられ、ほぼ狙い通りの効果が得られたと思う。来年も、装着することにする。


気づいたら、LINEの通話呼び出し(音またはバイブレーション)がされなくなっていたので直した

概要

LINEの通話呼び出しがされなくなっていたので直した。


背景と目的

最近、自分や周りの人のスマホで、LINEの通話がかかってきたときに音もバイブレーションもなく気づけないというトラブルが起きていた。メッセージよりも即時性が求められる通話の呼び出しがされないのは不便なので、ちゃんと呼び出しされるように直す。


詳細

1. 環境

f:id:dekuo-03:20200906214919p:plain


2. 調べる

Web上に何かしら情報はあるだろうと探してみた。以下を見てどうにかなりそうなので、参考にした。

appllio.com


3. 直す

結論から言うと、LINEアプリ内の通知に関する設定を直せばOKだった。 LINEのホーム > 設定 > 通知 と進むと、下の方に通話に関する通知設定がある。私の場合、以下のように音声なしとなっていた。

f:id:dekuo-03:20200906214938p:plain

なので、

  • "アラートを受け取る"を選ぶ
  • "ポップアップ"を有効にする

という2つを行った。

f:id:dekuo-03:20200906215125p:plain

試しに、通話呼び出しをしてみたところ、ちゃんと呼び出されるようになった。(私の場合、呼び出し音はなくしているのでバイブレーションのみ)AQUOSフォン(私のモデルとは違う)を使っている周りの人も同じ設定変更で、ちゃんと呼び出しされるようになった。


4. 呼び出しされなくなった原因

はっきり言って、よくわからない。とはいえ、自分でいじった記憶もないし、周りの人も同じ反応であることを考えると、機種固有機能やソフトウェアアップデートによって、何らかの影響を受けているのではないかという気がしてならない。2であげた参考サイトに、AQUOSフォンでは高度なマナーモードという機能があって、それの影響をほのめかす記述があるのも気になる。とはいえ、LINE内の設定自体が影響を受けるのも考えにくいので、こちらはLINEのアップデートのせいかも?いずれにしろ、原因ははっきりしない。


まとめと今後の課題

LINEの通話呼び出しがされるようになった。とはいえ、もともと設定を変えた記憶がないので、もし本当に勝手に変わっていたとすると、納得がいかないなあ。


ソーラー発電式自動水やり器を作る(5) --- 無動作時消費電力の低減 ---

概要

自動水やり器の無動作時消費電力を低減させるための回路の変更を行い、無駄な消費が減ったことを確認した。


背景と目的

前回完成した自動水やり器だが、陽が落ちてソーラー発電がなくなると、意外と電池の電圧が下がるのが速いことに気づいた。そこで、消費電力を低減させるための回路の変更を行う。


詳細

1. 現状

以下が、ある日の電池電圧の低下の様子。日中よく晴れていたにもかかわらず、明け方には、最大値から0.4V程度下がってしまう。これだと、天候不順が続くと心配だ。

f:id:dekuo-03:20200831215922p:plain


2. 原因

現在の回路構成を調べたところ、

  • 土壌水分センサが無動作時も約5mA消費している
  • ポンプを駆動するリレーモジュールの一次側についているLEDが無動作時も点灯しており、約3mA消費している

ことがわかった。まあ、作っている最中からなんとなく気になっていはいたが、やっぱりそうだった。


3. 変更

3.1 土壌水分センサの電源供給をマイコンのGPIOでON/OFFする

以下が変更後の回路。トランジスタQ2,Q3によるスイッチを構成し、ESP32のIO12をHIGHにしたときだけ出力PWR_MOISTから土壌水分センサに電流が供給されるようにした。これにより、マイコンスリープ中は消費電力はほぼ0。ただ、マイコンでONしてから安定動作するまでのタイムラグを考慮して、ONから計測までの間に少しディレイを入れるように、マイコンのプログラムを変更しておいた。ちゃんと動作している。

f:id:dekuo-03:20200831214119p:plain


3.2 LEDを削除する

LEDは箱に入れてしまえば見えないので、ついていても付いていなくても変わらない。そこで、物理的に削除することにした。


4. 動作確認

変更後は、明らかに夜間でも電池の電圧が下がりにくくなっている。効果は十分あったといえる。※2ポイントだけやけに低い電圧値があるが、これは変更前の日のデータが混ざってしまった編集ミス。

f:id:dekuo-03:20200831215905p:plain


まとめと今後の課題

自動水やり器の無動作時消費電力を低減させることができた。これで悪天候が続いても安心だ。


ソーラー発電式自動水やり器を作る(4) --- マイコンソフトの製作、完成 ---

概要

前回に引き続き、マイコンソフトの製作を行い、システム全体が完成した。


背景と目的

前回に引き続き、マイコンソフトの製作を行い、完成させる。


詳細

1.主な仕様

やりたいことは以下。

  • 一定時間ごとに起動し、それ以外の時間はできるだけ消費電力を下げるためスリープする
  • 土壌水分センサ、BME280、水瓶の水位センサでそれぞれ計測を行う
  • 土壌水分センサの値が一定値を上回る=乾燥している場合、ポンプを動かす
  • ポンプを動かした場合には、IFTTTを使ってLINEに通知する
  • 水位センサで水瓶の水切れを検出した場合は、IFTTTを使って通知する
  • 起動ごとに、センサの計測値をIFTTTを使ってGoogleスプレッドシートに記録する


2.実装

具体的なコードは割愛するが、方法を大まかにメモ。

2.1 一定時間ごとに起動、動作完了後スリープ

この動きは、過去に作ったリモート水位センサと同じなのでそれに倣って、一定期間のディープスリープをすればOK。

dekuo-03.hatenablog.jp


2.2 土壌水分センサ、BME280、水位センサの計測

土壌水分センサはアナログ入力、BME280はI2C、水位センサはGPIOを読み取ればよい。BME280だけちょっと困ったのは、BME280があまりにもいろいろなところで使われているせいか、Arduino用のライブラリだけでやたらと数があること。何が決め手ということもないが、今回はスイッチサイエンスが公開しているものを使用した。

github.com

基本的に、サンプルコードと同じ流れなので特に変わった部分はないが、最初ちょっと違うサンプルを見ていてうまく動かず躓いた。I2Cをbeginして、bme280の初期設定をして、readTrimメソッドを呼ぶという手順を忘れない。

  // BME280初期化
  Wire.begin();
  bme280.setMode(
    BME280_ADDRESS, //I2C Address
    1, //Temperature oversampling x 1
    1, //Pressure oversampling x 1
    1, //Humidity oversampling x 1
    3, //Normal mode
    5, //Tstandby 1000ms
    0, //Filter off
    0  //3-wire SPI Disable
  );
  bme280.readTrim();


2.3 土壌水分センサの値が一定値を上回る=乾燥している場合、ポンプを動かす

アナログ入力の値を読み取って、基準よりも大きければ乾燥している。その基準をどこにするかだが、以下が販売元が公開している空気中と水中での値で校正する方法。まあ、とはいえ毎回校正できるわけではないので、生の値で適当に1つ基準を決めた。その値より大きい値であれば乾燥していると判断して、ポンプを動かす。ポンプは、GPIO出力を一定時間HIGHにするだけ。

wiki.dfrobot.com


2.4 ポンプを動かした場合には、IFTTTを使ってLINEに通知する

給水したら、LINEで通知を受ければちゃんと IFTTTを使ってLINEに通知するには、thisにWebhookチャンネルのRecieve a web requestトリガー、thatにLINEのsend a messageアクションを選択。ESP32からは、JSONボディを作ってWebhooksチャンネルのエンドポイントに投げればよい。WiFiだとか、HTTPSリクエストについては、Arduino-esp32のWiFiClientSecureライブラリのサンプルの通りやればよい。 通知内容は、

f:id:dekuo-03:20200828000317p:plain


2.5 水位センサで水瓶の水切れを検出した場合は、IFTTTを使って通知する

水切れについても、同様に通知すれば水瓶自体に給水するタイミングを知ることができて便利。 やり方は、2.4と同じ。

f:id:dekuo-03:20200828000332p:plain


2.6 起動ごとに、センサの計測値、電池電圧などをIFTTTを使ってGoogleスプレッドシートに記録する

電池電圧は、アナログ入力を読む。AD変換値と電圧の対応は回路構成から決まる。 これもIFTTTを使って、thisにWebhooksチャンネルのRecieve a web requestトリガー、thatにGoogleスプレッドシートチャンネルのAdd row to spreadsheetアクション。IFTTT連携の注意点として、Googleドライブ内のパスに日本語が入っているとうまくいかないので、日本語の入らないパスにシートを置く。シート名も日本語が入らないように。

以下のような感じで溜まっていく。センサ値がたくさんあるが、IFTTTのWebhooksチャンネルは一度に3種類までしか送れないので、センサ計測値、水やり実施有無、電池電圧に分けて記録。

f:id:dekuo-03:20200828000800p:plain


ここまでで全体が完成した。ソーラー充電を含めてちゃんと動くか、しばらく試運転していこうと思う。


まとめと今後の課題

自動水やり器が完成した。


ソーラー発電式自動水やり器を作る(3) --- 筐体の設計、製作 ---

概要

前回に続き、回路基板を入れる筐体と水瓶を製作した。


背景と目的

前回に続き、回路基板を入れる筐体と水瓶を設計、製作する。


詳細

1.回路基板を収納する筐体

1.1 満たすべき要件


1.2 物の調達

やはり100均のプラスチックケースなどがちょうどいいだろうと思い、探してみた結果、セリアでちょうどよさそうなものが見つかった。ただし、防水構造ではないので、適宜防水加工をする。それと、材質的にも屋外使用はちょっと厳しいかも?と思うのでできるだけ日陰になるように設置する。

f:id:dekuo-03:20200827230429j:plain


1.3 製作

ベースボードをねじで固定し、蓋と本体の隙間はエプトシーラーで埋めたが、ちょっと不安はある。使い始めてからしばらく様子を見る必要はありそう。本体裏面のネジ穴から水の侵入が考えられるので、エプトシーラーを使った実績のある方法を用いて、穴をふさいだ。(写真撮り忘れた) なお、筐体の外に設置される土壌水分センサ、ポンプ、水位センサなどの配線は、筐体下側に穴をあけて通してあるので、水が上からかかる分には大きな問題はない。

f:id:dekuo-03:20200827230712j:plain


2.水瓶

2.1 満たすべき要件

  • 2L程度の水が入ること
  • 水位センサとポンプ装着のための加工がしやすいこと
  • お金をかけずに


2.2 調達

これまた100均の力を借りた。こちらはダイソーのいわゆる麦茶用ボトルのようなもの。バケツみたいなものもあったが、四角いほうが筐体とドッキングしやすいのでこちらを選んだ。

f:id:dekuo-03:20200827231320j:plain


2.3 製作

ボトル内を撮影したためちょっとわかりにくいが、ボトル内に水位センサとポンプをねじで固定。これもネジ穴からの水漏れを防止するため、エプトシーラーを使用。水を満タンに入れて放っておいたが全く漏れる気配がないのでOK。

f:id:dekuo-03:20200827231547j:plain


3.全体

最後に筐体とボトルを合体させて完了。これでハードウェアは完成。

f:id:dekuo-03:20200827232125j:plain


まとめと今後の課題

筐体と水瓶を設計、製作することができた。次回は、マイコンのソフトを作って完成にこぎつけたい。


ソーラーパネルで発電してリチウムイオン電池を充電する

概要

ソーラーパネルで発電してリチウムイオン電池を充電するための回路を作成し、動作を確認した。


背景と目的

最近作成している自動水やり器は、ソーラーパネルで発電した電力を電源として利用すること考えている。そこで、ソーラーパネルで発電し、それを一時的にリチウムイオン電池にためて、利用するところまでの一連の回路を組んでみる。


詳細

1.構成

ソーラーパネルで発電した電力をそのまま使用しようとすると、日照状態によって電圧が変動するのは言うまでもないので、一時的に電池に貯めてそれを取り出す形にしたい。

以前、ソーラーパネル+エネループのシステムでとしてまさにそのようなシステムを試したのだが、残念ながら比較的短い期間(1か月くらい?)でメモリ効果のようなもの?が発生し、充電できなくなってしまった。これは、満充電でも空でもない中途半端な状態を行ったり来たりする毎日の充放電が、ニッケル水素電池の特性に合わない使い方だったということだ。手持ち品のエネループが生かせると思って電池材料費をケチったのが失敗の元だった。

そこで、今回は中途半端な繰り返しの充放電でも問題が起きにくいリチウムイオン電池を用いることにする。ただし、リチウムイオン電池はよく言われるように使い方を間違えると、ニッケル水素電池よりも危険であるため、注意が必要だ。


2.電池の選定

電池は、自動水やり器で想定される消費電力は大雑把に見積もって2,3mAhなので、(数時間に一度、30秒間程度起動して水やりする、という動作を繰り返す)1日放置してもせいぜい60mAh。5日晴れなかったとして300mAなので、その程度があれば十分だろう。いろいろ探したところ、千石電商で、400mAhという手ごろなものが見つかったので、使用することにした。

www.sengoku.co.jp


2.リチウムイオン電池充電制御IC

リチウムイオン電池は過充電してしまうと危険なため、ここでは迷わず専用の充電制御ICを使用する。秋月電子で50円と非常に手ごろなものがあった。マニュアルをざっと読むと、最大電流値は外付け抵抗で決めることができ、リチウムイオン電池の電圧を高精度にモニタして満充電状態を検出し、充電を自動で止めてくれるとのことだ。ネット上にもたくさんの使用例があるので、安心だ。

akizukidenshi.com


3.回路の製作

3.1 MCP73831周りの実装

MCP73831を使った回路をさっそく製作した。ICのマニュアルに従って各定数を設定。PROG端子についている抵抗10kΩは、充電電流を最大100mAに制限するための設定。STATにつないであるLEDは充電中に点灯して知らせてくれる。入力側のENELOOP+/ENELOOP-は、エネループとは関係なく、3.2の回路の出力を繋ぐ関係でこういう名前になっている。

f:id:dekuo-03:20200827003323p:plain

f:id:dekuo-03:20200827003706j:plain


3.2 ソーラーパネルからの供給部

今回使用するソーラーパネルは、以前の記事で使用しているものを流用するのだが、

  • 最大出力時電圧/電流 約9V/約340mA

というスペックなので、上記のMCP73831の最大入力電圧よりも高く、直接つなげない。そのため、以前作成したエネループ充電用の回路がちょうど使えそうなので使う。充電用回路といっても一定以上の電圧/電流が出力されないようにしているだけ。この回路は約5.6V/約100mAに制限しているので、3.1の回路につなぐことができる電圧で、しかも必要な電流が供給できる。回路図は以下。負荷としてエネループではなく、3.1で作成した回路を接続することになる。

f:id:dekuo-03:20190915213343p:plain


4.動作確認

4.1 通常の電源でテスト

ソーラーパネルを繋がず、通常の直流安定化電源を使用して充電してみたところ、最大100mAに制限されて充電された。リチウムイオン電池の電圧が4.2V程度に近づくと徐々に電流が減ってきて、約4.2Vを超えることはなかった。動きが理解できた。

4.2 ソーラーパネルを繋いでテスト

晴れた日に接続してみた。4.1と同様にしばらくはずっと充電ステータスLEDが点灯し、リチウムイオン電池の電圧が4.2V程度になるとLEDが消灯した。ソーラーパネルからでも問題なく充電できている。


まとめと今後の課題

ソーラーパネルで発電してリチウムイオン電池を充電するための回路を作成し、動作を確認できた。自動水やり器の電源として使用できそうだ。