リーフレタス植え付け

  今日は土が乾いてきたので、残り半分の畝つくりから植え付けまでを行います。
 今日はスピードアップのため根っこの除去レベルをさらに変更、根っこをカテゴリ分けして対処方法を設定します。木の根っこは見える範囲を除去し、深く追わないことにします。地下茎については追えるところまで追ってとことん除去します。
 細かい根っこは無視して、気になる根っこだけを除去することにします。地下茎の主なものはスギナです。地下茎の先を追い始めると50cmより深いところまで垂直に伸びているものもあります。スギナさえなければ作業がはかどります。
 前述のレギュレーションを設定後すぐにスギナの巣を発見しました。レベルを変更したらスギナの巣にぶち当たるのがジンクスな感じがしましたが、この巣も5,60cmくらいまで追っかけて除去しました。
 さて、このレベルでどの程度で雑草が生え始めるのか確認していきます。ちなみに、上下ひっくり返しただけで根っこを 除去しなかったら1か月ぐらいで雑草が生え始めています。一番生えてきているのはスギナです。そのほかの雑草も生えていますが、 スギナの比ではないので、スギナ中心の除去対処でよかったのかもしれません。ひっくり返す際に地下茎を細かく切断して地表近くにもってきたが発見できていないものがどのくらい残っているかが今後の手間を左右しそうです。今回以上に対処は、すべての土を篩いにかけるくらいしかないと思います。

何か月か、今回作った畝の状況を確認していきます。

脆弱性情報の収集

脆弱性関連情報を「定期的に自動チェックしてメール通知するとか、検討してみよう。」ということで、とりあえずクラウドサーバ上にpythonコードを移行し、定期実行の手順を検証します。
 phpから呼び出したところで、エラー。このクラウド環境は、Python2が動いていて、python3には対応していない。いまどきのクラウド環境ならPython3に対応しているのだろう。つぎの引っ越し先はPython3にも対応していることを条件に入れよう。その選定作業は別途行うことにします。※
Python2用にコードを書き換えて、チェック対象のコンテンツをダウンロードできることを確認できました。

つぎに、クラウド環境のコントロールパネルで定期実行タスクを設定します。
定期実行で、「with open(saveFilePath, ‘wb’) as saveFile:
IOError: [Errno 13] Permission denied: 」のエラーメールが送られてくる。
phpから呼び出した時とは実行ユーザが異なることが原因だろう。
ということで、パス指定を修正して、定期実行によりチェック対象のコンテンツをダウンロードできることを確認できました。
 
次は、脆弱性関連情報をチェックするPythonコードを用意します。

久しぶりの晴れ、キャベツは順調

雨の後のため地面は湿っているので今日はほかの作業をすることにした。先日植えたキャベツは順調そう。2つのレベルで根っこを除去したので、この後それぞれどの程度、スギナなどが出てくるのかチェックする。

パワコン?謎の消費電力増加 その3

先に「昼と夜の消費電力の差は、時刻によって切り替わっているだけと判断できます。このような動作が想定されるのはパワコンです。次回以降パワコン観点で検討を行います」と書きましたが、今回はこの点について確認してみます。
 まず、なぜパワコンに着目したかですが、このサイト2では、1台の”KP55M-J4-SS”(パワコン)を使用しています。このパワコンの仕様として「 消費電力(夜間(交流側)) 0.5W、11.5VA(Typ.)」の記載があります。
http://www.solar-frontier.com/jpn/residential/products/pdf/discontinued/KP55M-J4-SS-A_KP44M-J4-SS-A.pdf
また、パワコン自体の表示器が、昼間は発電量が表示されているが、夜間は表示が滅灯し明らかに昼と夜で動作状態が切り替わり 消費電力量も変わっていることがわかります。
つぎの情報を見ると、パワコンの機種は違いますが、表示を滅灯したときより点灯したときの消費電力が大きいこともわかります。
http://www.faq.energy-innovation.omron.co.jp/print/faq/9

このグラフから、夜間の消費電力は0.26kW、昼間の消費電力は0.17kWで、その差は0.09kWつまり、90Wの差があることがわかります。
パワコンの使用に書かれた消費電力とは2桁ほど違っているので、本当にこれがパワコンの消費電力なのかは疑問です。 そこで、昼間から夜間の消費電力に切り替わる時刻がどのように推移するかを確認するために日ごとの18.19,20,21時それぞれの消費電力量をプロットしました。


この結果から、昼間から夜間の消費電力に切り替わる時刻は日々徐々に一定に変化しており、日没時刻から算出したと推測します。このような挙動をするのはパワコンなど太陽光発電システムくらいしか思いつきません。 パワコンの消費電力は0.5Wなのか、90Wなのか、パワコン以外に夜間電力消費が発生するものがあるのか確認してみます

ここまでの状況から、電力量が大きいかどうかの確認は必要だが、パネルが故障するなど、長期間発電量がゼロの場合、パワコンが無駄に電力消費するということがわかりました。発電システムの故障を検出したら、放置せずにすぐに修理するとか接続を切るとか処置をするべきでしょう。放置や変な処置をすると、淡路の風力発電のような事故につながるかもしれないので故障を早期に気付ける仕組みも重要そうです。

パワコン?謎の消費電力増加 その2

サイト2の夏の冬の消費電力で夕方は日照時間の影響が見えるが、朝方はずれがないように見えています。データの整理ミスの可能性が一番高いと思い再点検しましたがここでの間違いはなさそうです、これについても原因確認していきます」と前に書きましたが、今回はこの点について確認してみます。まず、考えられる原因について検討してみます。
①どこかの時点でデータ収集する時刻がずれた。集計ミスではなく機器の設定の問題を想定しています。
②天候の影響で、たまたま6月の該当日は早朝の日照がなかった。
③ ①、②のいずれでもない。パワコンなどの負荷側の挙動で発生している。

①の確認のため、別の日のデータをプロットしなおしました。6月、12月のデータは2013年分で、6月の2としたものは2014年4月分です。


2014年4月分でも夕方の消費電力の増加時刻の差が確認できますが、朝方の減少時刻には変わりがありません。このデータの日の気象庁データは快晴で、天候による朝方の減少時刻への影響はありません。念押しで、12月のかなり強い雨日のデータに変えてプロットしなおしました。


意外に朝方の減少時刻だけでなく、夕方の増加時刻にも影響はありませんでした。この結果からサイト2には日照により点灯・滅灯する機器の影響ではないという結論にたどり着きます。つまり、①、②ではないということです。昼と夜の消費電力の差は、時刻によって切り替わっているだけと判断できます。このような動作が想定されるのは③のパワコンや太陽光発電システムです。次回以降パワコンなど太陽光発電システム観点で検討を行います。

パワコン?謎の消費電力増加

データ集計の過程で、サイト3の消費電力が多めであること気が付きました。サイト3は街路灯のLED化の変更をした以外は変更がなく、消費電力が増える予定はありませんでした。
時系列で消費電力をチェックしました。同時にプロットしたサイト2の消費電力も
同様にほぼ一定で、増えるような変更はしていません。

まず、サイト2、サイト3について月ごとの総消費電力をプロットしました。太陽光発電として 気になるのは自己消費電力なのですが、自己消費電力量は、消費電力量と太陽光発電での発電量の 両方に依存するので、ここでは総消費電力のみを分析します。

総消費電力量の推移

  サイト2はほぼ一定です。多少冬場の電力消費量が多めな感じです。サイト3は夏と冬の電力消費量の変動が明確です。さらに、2016年以降に消費電力量が増加しています。現在は通常?の状態に戻っています。この謎の消費電力増加の 原因分析、調査を行います。
そこで、考えられる理由を挙げてみました。
①誰かが電気器具を接続して消費している。
②新たに導入した設備が電力を消費している。
③何らかの理由で、既存設備(太陽光発電以外の設備)の消費電力が増加している。
④何らかの理由で、太陽光発電システムの消費電力が増加している。

①が原因として一番怪しいが、消費電力が多い状態のとき、現地の確認を行い特に電気製品が使われている気配がないことを確認しました。
②に関しては、2013年以降の設備変更はなく原因ではありません。
③、④の根本原因は、設備が”故障している”か”動作状態が変わった”ことで消費電力量が増加していることと想定されます。

現地の外観や状況からは決め手となる原因は見つかっていません。これについての分析は置いておいて、 夏と冬の消費電力量の差について分析してみます。 夏至・冬至付近の晴天の日の1時間ごとの消費電力量を プロットしました。

夏と冬の消費電力

昼間より夜間の消費電力が大きい。これは街路灯の電気消費に依存します。それぞれのサイトには、街路灯と常時省電力を消費する設備があります。 街路灯の消費電力は、サイト2が0.8kW、サイト3が4.6kW程度で、常時消費される電力はサイト2が1.6kW、サイト3が1.4kW程度です。 夏と冬で明るい時間が朝と夕方とそれぞれで2時間程度違うため、その分、街路灯が消費する電力量が変わります。 ただ、サイト3については日照の影響以外にベースの消費電力が違うように見えるので、冬のデータから0.05kWを引いたデータでプロットしなおしてみました。


検証のため0.05kW分シフトして再プロットしたグラフ

想定される絵柄になりました。夏と冬の差が日照時間の2時間分の差だけで他に差がないように見える絵柄です。ということは、夏と冬で 0.05kWの消費電力の差が何らかの理由で発生しているということです。言い換えると前述の”動作状態が変わった”に該当する事象が発生しているということです。
今日はここまでです。今後、”動作状態が変わった”原因が何かを分析していきます。※ サイト2の夏の冬の消費電力で夕方は日照時間の影響が見えるが、朝方はずれがないように見えています。データの整理ミスの可能性が一番高いと思い再点検しましたがここでの間違いはなさそうです、これについても原因確認していきます。 また、上記の④の中にタイトルに記載したパワコンがあります。これについても分析していきます。

電力と電力量の表記ゆれがあるように見えますが、1時間分の消費電力量を断り書きせずに電力に換算しています。ほかの箇所もこの断り書きなしの菅さんをして書きます。

目標の半分だけど、キュウリとキャベツの植え付け完了

昨日の続き、耕すと同時に根っこの除去作業です。昨日同様あまり進まず。気が付くと16:00です。
1m幅で、2m進む間に根っこでバケットがいっぱいになりました。ちなみに1m分でこの量です。

このままでは、今日の予定分が終わらないのでペースアップ、細かい根っこは無視して目についた 大きいものだけを取るように除去レベルを変更、と変更した矢先、次々太い根っこが出てきて、…。厳しいがとりあえず上から見つけたものだけを除去して、予定の半分の畝を立てる作業を完了しました。

2週間くらいおいて、苗を植え付けたかったのですが、苗のほうが来週目以降には持たなさそうなので、即植え付け作業をしました。キュウリとキャベツは今日予定していた分の植え付けを完了しました。

今日も、まだ植え付けできず

今日こそキャベツの苗を植え付けするつもりで、作業開始しました。
予定していた雑草の絨毯を積み重ねる作業(積み重ねるのが目的ではなく 雑草を取りたいだけなのですが)、何とか半分まで終わった状態が つぎです。

雑草絨毯の山

・半分は土なので、後日焼却処分して、剥がしたところに、戻す予定です。
 といっても今は早く植え付けしたい。
この時点で、日没まで時間がない。なんとか雑草を剥がす作業は完了し、
畝を作る前の耕す作業を始めましたが、周辺から侵入してきた木の根や、スギナの地下茎が大量に 出てきて思うように進まず、4分の1の根っこ除去したところでタイムアップとなりました。
それでも前回の進捗を思えばかなり進んだ感はあります。
月曜日は雨が降りそうなので、明日には植え付けまで完了させたい。

太陽光発電システムの故障判断アルゴリズム(その1)

 前回「この判定アルゴリズムを組み込んだアラートメールと、定期的にアラートメール自体の稼働監視用のメール通知をするシステムを構築しました。」と紹介しました。今回は、この 判定アルゴリズムと判定精度について紹介します。
 つぎが判定アルゴリズムでの解析後のデータのプロットです。 故障をかなりきれいに検出しています。

故障検出用のデータプロット


グラフの一番左が、発電開始日で、日ごとのデータをプロットしていて、一番右側が導入後6ヶ月あたりです。
太陽光発電システムは3つあり、サイト1、2、3としています。順番に構築したので、サイト2、3の発電開始日は 2、3週間とそれぞれ遅くなっています。 サイト1、2、3のそれぞれの500m程度です。距離が500m程度だと、瞬間に日照は雲のかかり具合で差が生じますが、1日の発電量に影響するような長時間片側のシステムだけ雲が覆い隠すようなことは 起こりません。要するに近場だと、天気による発電量への影響はほとんど同じになる。この特性を利用します。つぎが具体的な判定アルゴリズムです。
P1=「サイト1の1日の発電量」/「想定発電量」
P2=「サイト2の1日の発電量」/「想定発電量」
P3=「サイト3の1日の発電量」/「想定発電量」
MaxP=max(P1,P2,P3)
S1=P1/MaxP
S2=P2/MaxP
S3=P3/MaxP

このS1、S2、S3をプロットしたものが上のグラフです。
すこしばらつきがありますが、その原因は悪天候です。発電量が小さい場合はばらつきが大きくなる傾向があります。
また、太陽光パネルの配置が2か所は南向き1面なのに対して1か所は東西で振り分け(均等ではない)であるため、 午前と午後で天気が変わった場合にばらつきがすこし大きくなります。また、悪天候の日の発電量が想定発電量に対して、いずれの設備も30%以下と極端に小さい場合は、その日のデータを無視する仕掛けを入れて 判定しています。 そして判定結果をメールで通知しています。
これまでのところ工事停電など特殊な事情がなければメールも来ず、監視はうまくいっています。

 ここでは、複数の設備の比較での判定を紹介しました。1システムしかないケースがほとんどなので、 次回は、1システムしかない場合でも判定できるアルゴリズムを紹介します。

そういえば脆弱性

WordPressの初期設定をしたばっかりだが、そういえばWordPress関連の脆弱性は結構な数があったような気がする。
とうことで、その他のアプリケーションも含めて、チェックしてみました。

まず、WordPress:
開発元の情報だと5.1.1が最新で、5.1以前は脆弱性ありということ。
https://wordpress.org/news/2019/03/wordpress-5-1-1-security-and-maintenance-release/
https://wpvulndb.com/vulnerabilities/9230
 → これに関しては対処済みで問題なし。

https://wordpress.org/news/category/releases/
 → 2019/4/24時点のリリース状況だと、近く5.2が出そうだが、脆弱性的にはどうかは不明。ただし、バージョン番号のつけかたからすると、
つぎのSecurity Releaseは、5.1.2か、5.2.1だろう。

プラグイン:WordPress関連ではプラグインの脆弱性が多数報告されている。
https://jvndb.jvn.jp/search/index.php?mode=_vulnerability_search_IA_VulnSearch&lang=ja&useSynonym=1&keyword=WordPress
https://nvd.nist.gov/vuln/search/results?form_type=Basic&results_type=overview&query=WordPress&search_type=all
→インストールしたプラグインも一通り確認して対処済みであることを確認した。

何度も見て回るのは面倒なので、定期的に自動チェックしてメール通知するとか、検討してみよう。

とりあえずチェックするサイトはつぎや開発元サイトにする。
https://nvd.nist.gov/vuln/search
https://jvndb.jvn.jp/index.html