太陽光パワーコンディショナからのデータを見える化してみた（売買電力量と発電量の見える化2）

　前回からずいぶん空いてしまいましたが、ハードウェアは2月から一度も失敗することなく順調に動いています。（ちょっと安心、、、）

　今度は、1日の売買電のグラフから、Google Spreadsheetにためたデータを使って更にGoogleのBIツールLookerStudio（Microsoftで言うところのPowerBI）を使ってトレンドが見えるようにしました。

　当初、Google Spreadsheetへデータを取り込むのに、グラフ化制御しやすいようにと表の一番上に新たなデータを入れるように作り込んでいました。しかし、レコード数が増えて来ると、1レコード分のInsertといえど処理が重くなってきて、1分毎のInsert処理が連続してできない状態になる事が増え、午前0時の切り替え処理ができない事も何度か起きてしまいました。（6月の頭の頃）

　仕方ないので重い腰を上げて、最終行にレコードを追加する処理に改造し、それ以降は現状順調に動くようになりました。（多分またレコード数がMaxに近くなると今度はDataFullとかで止まっちゃうんだと思います、、、。）

　左下は1日のトレンドグラフ、青が売買電、赤が太陽光発電量です。（前の投稿とほぼ同じ）

　右下は約一週間分の日々の買電量（青）、太陽光発電量（緑）、売電量（赤）です。

上は、さらに過去の買電量、太陽光発電量、売電量（右下と同じ）に加えて、

　太陽光発電利用率[％]＝（太陽光発電量ー売電量）／太陽光発電量

つまり発電した電力をどれだけ使ったかの割合をオレンジのグラフで示しています。要は、この数値が大きい（100%）と発電したものがすべて家の中で消費されている、売電の余力がない、つまり天気が悪いという事になります。

（6月の頭にオレンジ色のグラフが無い部分（実際には上記の午前0時の切り替えができずに数値がマイナスになっている）がありますが、無視してください）

このグラフは、→X軸が1日の太陽光発電量、↑Y軸が太陽光発電利用率です。

なんとなく、1日の発電量が4kWhのあたりで、分かれているようにも見えます。4kWh以上は晴天、それ以下は曇天、太陽光発電利用率が100％のあたりは多分大雨で暗い1日、なんだろうな、と思えます。（だからどうしたという話ではありませんが、、、）

　昨年置き換えたパワコンの費用回収を考えると、上のトレンドグラフから太陽光発電利用率が100％に近い日の買電量を見ると10kWh超、そうでない日を見ると5kWh程度に読めますので、多分１日5kWh程度は太陽光発電によって補填されているように見えます。我が家は東電家電上手ですが、2024/4からの料金を見ると、日中の夏季は43.93円/kWh、それ以外は40.44円/kWh出そうなので、月に発電できない雨の日が5日あるとして5kWh×25日→5491円/月＠夏季、ざっくり年間5～6万円位補填されていると考えると、6年くらいでパワコン交換が回収できる、と見積もれます。パワコンは10年補償だから最悪でも4年分はプラスになりそうな勘定になりますか。

　本当はこの余剰電力を蓄電すれば、20年落ちの太陽光パネルでも、多分ほぼ買電しなくても電力が賄えちゃうのでしょうけれど、メーカ物を備えると絶対にPayしないんだろうなぁ、と思ってそこには手を出さないようにしています。

　とりあえず、そういうことか、と言う事がわかったので、次はエコキュートの制御（昼間の余剰電力でお湯を沸かす、、）をしたいなと思っていて、まずはスマホでの遠隔制御で動作を確認するのですが、早朝の湯沸かしが制御できず、どうしたもんかと悩んでおります、、、、。

　どなたかエコキュート（ダイキンですが）の制御の相談に乗ってくださる方はいらっしゃらないでしょうか、、、。

　ということでまだまだ暇つぶしは続くのでした、、。

太陽光パワーコンディショナからのデータを見える化してみた（売買電力量と発電量の見える化）

［2024/2/25 10:00追記あり］

　とりあえず自作アダプタ経由で太陽光発電電力量のモニタができるようになったので、電力会社への売買電力量と一緒に見ることができるようにしてみました。上記はその概念図です。

　電力会社との売買電力量は、電力計に備わっているいわゆるBルート、というやつを使って、NatureさんのRemo E lite経由でNatureさんのサーバへデータが送られて溜まっています。このデータは通常、専用のスマホのアプリ経由で見ることができます。

　太陽光発電電力量は、今回作成した自作のアダプタ経由でAmbientさんのサーバへ送られ、作成したグラフをWEB経由で見ることができます。

　で、今回この両者のデータを一緒に見るために、Googleさんの力を借りました。両者はどちらもWEB経由でデータがやり取りできるAPIを用意してくれていて、そんなに手をかけずにデータを抜いてくることができました。また両者はそれぞれデータを蓄積してくれていて、今回は売買電力と発電電力の状況を見たいだけなので、データをDBに入れるとか、きちんと確保することは考えないことしました。

　GASでの仕組みの概要は、GASのタイマ起動機能を使って1分間隔で両者から最新データを取ってきて、Google Spreadsheetへ書き込み、それをグラフにして公開、という流れです。気をつけることはGoogle Spreadsheetは最大書き込みセル数（1000万セルだったか、、）があって、それを超過するとエラーになります。以前、Nature Remo E liteのデータを入れていたら、それに引っかかってエラーが山程（1分に1回やっていたので、それなりに、、、）来てびっくりしました。それも考慮する必要があります。

　現在は、午前0時に列を追加するようにしていて、それをグラフ化しています。つまり、午前0時から23時59分までのグラフを見えるようにしてあります。

　この状態が出来上がってから天気が良くないので、今度良い日（発電が十分されている日）のデータがあったらここに貼りたいと思っています。

青は、売買電力量（プラスが買電、マイナスが売電）、赤は太陽光発電量（発電方向がマイナス）です。青は、発電量を相殺、差し引いたデータのグラフになります。

さて、今度はEchoNetでも調べてみますかね。

<以下、2024/2/25に追記>

　昨日久しぶりに晴れたので一日分を貼りました。青が買電力（＋）、赤が太陽光発電電力のそれぞれ瞬時値です。我が家での実際の家電製品等での合計消費電力は青線と赤線の差分となります。

　0時から4時くらいまでの1kW位の二山（後ろは良くわからないですが、それくらいしかない、、）は多分エコキュートです。4時すぎの500W位の凸凹は多分洗濯機。6時半前に太陽光発電を始めています。8時前のピークは、200V系エアコンと調理器具の消費ですね。ちなみ我が家はオール電化です。

　青線をたどると8時位に売電（マイナス）に切り替わって、10時から13時位まで買電量が下がっているのは、エコキュートの「昼間シフト」機能で追加で沸き上がっています。朝の湯量を見てみましたが、350Lとなっていたので、昼間に沸き上げる制御なのでしょうね。100％を昼間に沸き上げる制御ではない（天気を信用していない、、、）という感じでしょうか。ちなみに昼間はでかけていたので昼食に関わる電力消費はないです。14時位にも買電量が下がっていますが、これは私がエコキュートの追加での沸き上げをしたものです。沸き上げ指示をした時点で湯量は500Lと表示されていました。23時からの1.5kW位はこれも多分エコキュートだと思います。エコキュートは低電力（多分1kW）での沸き上げ設定をしているのですが、多分それじゃ朝までに沸き上がらないと判断して1.5kWにしたのだと思います。1.5kWでの運転は私は初めて見ました。ちなみに今日は朝から雨予想だったので「昼間シフト」設定は解除してました。

　この数日寒い（と言っても最低は＋ですが）のと、娘が子供を連れて遊びに来ているので消費人数が多い状態なので、エコキュートも結構稼働しているようです。

　現在は、前夜に明日の天気予報や日射量予測を見て「昼間シフト」の設定をマニュアルで設定していますが、究極は自動運用をしたいと思っています。（いくつの会社からこの手のサービスが始まってますね、、、）

ということで、まだやることあります、、。まぁ、暇つぶしと趣味の延長なので悩みながら、楽しみながら進めて行こうと思っています。

太陽光パワーコンディショナからのデータを見える化してみた（毎朝のESP32の起動制御改）

（2024/1/22 7:50追記修正）

以前、毎朝のPowerConの起動で、立ち上がりの時にPowerConからの12V電源がOn/Offを繰り返す（いくつかパタンがあるようで0.5秒毎、1秒毎に点滅をとか）、という話でCRによる遅延回路でESP32のENpin制御でうまく動いている、と書きましたが、あれだめでした。思ったように動かない（うまく起動しない、プログラムが消えちゃう等のことはなくなったんですが、計算上の時定数と動作が全然合わないので気になっていました、、）ので色々とESP32について調べると、ENpinは、Resetボタンと同じ（パラ？）ようで、CRの遅延制御ではそもそも動かないですね。「電源」がOn/Offを繰り返すのでESP32じゃ制御できないので、CRのパッシブな回路でうまくゆくかな、と思ったのですがそれがだめ、、、。

で、じゃぁ外付け回路（アクティブな回路、、）でやる？PIC、となりました。

PICであれば、PICに電源印加、即動作（限界はありますが）してくれるので、印加電圧が加わっていれば、そこからタイマをかけてタイムアウトするまでENをlowにしてやれば良い、多分ENpinをトランジスタなりで制御してやればよいので、電源印加でOnにして継続して電源が入っていればその間タイマで監視して、タイム・アウトしたらOff（→トランジスタがOff→ENpinがhigh→ESP32が動作）してやれば良さそうです。

で、早速やってみました。電源が入ってENをOff（low）、電源が継続して約10秒間OnであればENがOn（high）になるようにプログラムを書いて、ENpinに接続。実際には後段にトランジスタを入れたのでこれの負論理にしてあります。これで思ったように制御できるようになりました。めでたしめでたし。PICの電源は、ESP32の3.3V出力（後段にトランジスタを入れたのでESP32入力の5Vでも良かったですかね）をもらってきています。

追加したものは、8pinの12F675と、ジャンク箱に転がっていたUsedな2SC372（なんでもよかったのですが、流石に古すぎますかね、、ハット版！）、10kΩの抵抗一本と、あとはモニタ用にLEDと電流制御用の抵抗一本を追加。

上の写真だと、ESP32のお腹の下に見えるのがPIC 12F675です。その下に起動時のENの停止を示すLED（赤）が見えます。トランジスタは奥の方にあるので見にくいです。

%ESP32のUSBコネクタが、MicroBからCに変わっているのは気にしないでください。単にいじっていて壊しちゃっただけです（なんで壊れたのかは不明ですが、EN制御で色々とやっているうちに壊れちゃいました、、）。再度大陸からお取り寄せしました。（円安のせいで高くなっちゃってましたが、、）

朝の起動時に丁度？立ち会えたのでPanaさんのモニタと比べてみましたが、連続電源印加10秒程度でLCDに表示が出てきて、次のデータ転送で発電量の表示が出ます。この連続値はPanaさんのを参考にしたわけでもありませんが、ほぼ同じだったのはちょっとびっくりしました。とりあえず完了。

太陽光パワーコンディショナからのデータを見える化してみた（起動時の様子編）

起動時の様子です。下の図の紫線の07:00近辺の0と200の行ったり来たりは、200が前回サーバにデータを正常にあげられた事を示していて、0は前回再起動した事を示しています。なので、ENを制御して、継続して数秒間12Vが検出できると起動していますが、データを送信したけれど、やはり12Vが安定せず断になってまた再起動した、ということを示しています。

上の図は当日の発電量（起動時=0として）を示していますが、07:10頃から発電量が検出できる状態になった、多分連携を始めているのではないかと思います。

毎朝、心配？で覗きにゆくのですが、EN対処後は一度も起動失敗することも止まることなく順調に動いています。　→次の記事で改造しました。

太陽光パワーコンディショナからのデータを見える化してみた（サーバへの転送時Errorの話）

　先のソフトウェア周りの話のところ書きましたが、今回、CircuitPythonでambientへ書き込み時にCircutPythonの先の深いところでエラーが起きてアプリが落ちる事がありました。

　Error自体は、Repeated socket failuresとでてadafruit_requests.pyの中で落ちているようです。色々調べて海外でのやり取りを見つけましたが、どうやらadafruit_requests.pyの先で落ちているようで、そのやり取りも途中状態でまだFixされていないような感じです。

太陽光パワーコンディショナからのデータを見える化してみた（ソフトとか編）

未だ根本解決はしていないようですが、今回はPythonのtry/exceptで救える事がわかったのでその対処をしていて、どのくらいの頻度で落ちているのかを知るために失敗した次の成功した転送でその状態をサーバに送るようにしていました。

　上の3枚のグラフは、2023/12/6、12/7、12/8の横軸時刻、縦軸が緑が転送にかかった時間（sec）、紫がサーバからのresponce値（失敗した場合は1000を足しているので急に立ち上がっているところが前回失敗しているところ）です。転送に要した時間は、プログラムの中で8秒でタイムアウトするように設定しているので、実際にはもっとかかっているものもありますが所望の動作です。

　問題の紫のグラフですが、真ん中の12/7のお昼ころを境に明らかに挙動（頻度）が変わっています。もちろんESP32側のソフトウェア環境は継続して動作しているので変わっていません。この後も一日数回から10回程度のエラーは起きていますが頻度は以前と明らかに違います。途中経路のNetwork側の設定が変わったのか、サーバ側の設定が変わったのか、どちらにしてもESP32/CircuitPythonの外部の要因がきっかけでこのエラーの発生頻度が大きく変わる、ということはわかりました。

　今回はtry/exceptでアプリ側で救えているので良いですが、複数のシステムが絡んでいるとこういうところは難しいです。