パワコン？謎の消費電力増加
データ集計の過程で、サイト3の消費電力が多めであること気が付きました。サイト3は街路灯のLED化の変更をした以外は変更がなく、消費電力が増える予定はありませんでした。
時系列で消費電力をチェックしました。同時にプロットしたサイト2の消費電力も
同様にほぼ一定で、増えるような変更はしていません。
まず、サイト2、サイト3について月ごとの総消費電力をプロットしました。太陽光発電として 気になるのは自己消費電力なのですが、自己消費電力量は、消費電力量と太陽光発電での発電量の 両方に依存するので、ここでは総消費電力のみを分析します。
サイト2はほぼ一定です。多少冬場の電力消費量が多めな感じです。サイト3は夏と冬の電力消費量の変動が明確です。さらに、2016年以降に消費電力量が増加しています。現在は通常？の状態に戻っています。この謎の消費電力増加の 原因分析、調査を行います。
そこで、考えられる理由を挙げてみました。
①誰かが電気器具を接続して消費している。
②新たに導入した設備が電力を消費している。
③何らかの理由で、既存設備（太陽光発電以外の設備）の消費電力が増加している。
④何らかの理由で、太陽光発電システムの消費電力が増加している。
①が原因として一番怪しいが、消費電力が多い状態のとき、現地の確認を行い特に電気製品が使われている気配がないことを確認しました。
②に関しては、2013年以降の設備変更はなく原因ではありません。
③、④の根本原因は、設備が”故障している”か”動作状態が変わった”ことで消費電力量が増加していることと想定されます。
現地の外観や状況からは決め手となる原因は見つかっていません。これについての分析は置いておいて、 夏と冬の消費電力量の差について分析してみます。 夏至・冬至付近の晴天の日の1時間ごとの消費電力量を プロットしました。
昼間より夜間の消費電力が大きい。これは街路灯の電気消費に依存します。それぞれのサイトには、街路灯と常時省電力を消費する設備があります。 街路灯の消費電力は、サイト２が0.8ｋW、サイト３が4.6ｋW程度で、常時消費される電力はサイト２が1.6ｋW、サイト3が1.4ｋW程度です。 夏と冬で明るい時間が朝と夕方とそれぞれで２時間程度違うため、その分、街路灯が消費する電力量が変わります。 ただ、サイト3については日照の影響以外にベースの消費電力が違うように見えるので、冬のデータから0.05ｋWを引いたデータでプロットしなおしてみました。
検証のため0.05kW分シフトして再プロットしたグラフ
想定される絵柄になりました。夏と冬の差が日照時間の２時間分の差だけで他に差がないように見える絵柄です。ということは、夏と冬で 0.05ｋWの消費電力の差が何らかの理由で発生しているということです。言い換えると前述の”動作状態が変わった”に該当する事象が発生しているということです。
今日はここまでです。今後、”動作状態が変わった”原因が何かを分析していきます。※ サイト2の夏の冬の消費電力で夕方は日照時間の影響が見えるが、朝方はずれがないように見えています。データの整理ミスの可能性が一番高いと思い再点検しましたがここでの間違いはなさそうです、これについても原因確認していきます。 また、上記の④の中にタイトルに記載したパワコンがあります。これについても分析していきます。
電力と電力量の表記ゆれがあるように見えますが、１時間分の消費電力量を断り書きせずに電力に換算しています。ほかの箇所もこの断り書きなしの菅さんをして書きます。
初スパム
運用開始して10日目で、スパムコメントが入りました。
以前のサイトで運用していたフォーラムシステムでは、最初のスパム投稿が発生したのは 運用から１年以上経過した後でした。そのフォーラムにはスパムを自動判定できる仕掛けは、 なかったので、気が付いた時にはごみ投稿の山ができていたこともありました。
この感じだと、スパムコメントも大量にある感じがします。でもスパムをブロックする 仕掛けで、検出できていました。スパム検出が機能していることは、とりあえず一安心です。
つぎは、検出精度と処置の手間がどの程度低減できるのか注目です。
目標の半分だけど、キュウリとキャベツの植え付け完了
昨日の続き、耕すと同時に根っこの除去作業です。昨日同様あまり進まず。気が付くと16:00です。
1m幅で、2m進む間に根っこでバケットがいっぱいになりました。ちなみに1m分でこの量です。
このままでは、今日の予定分が終わらないのでペースアップ、細かい根っこは無視して目についた 大きいものだけを取るように除去レベルを変更、と変更した矢先、次々太い根っこが出てきて、…。厳しいがとりあえず上から見つけたものだけを除去して、予定の半分の畝を立てる作業を完了しました。
2週間くらいおいて、苗を植え付けたかったのですが、苗のほうが来週目以降には持たなさそうなので、即植え付け作業をしました。キュウリとキャベツは今日予定していた分の植え付けを完了しました。
今日も、まだ植え付けできず
今日こそキャベツの苗を植え付けするつもりで、作業開始しました。
予定していた雑草の絨毯を積み重ねる作業（積み重ねるのが目的ではなく 雑草を取りたいだけなのですが）、何とか半分まで終わった状態が つぎです。
・半分は土なので、後日焼却処分して、剥がしたところに、戻す予定です。
といっても今は早く植え付けしたい。
この時点で、日没まで時間がない。なんとか雑草を剥がす作業は完了し、
畝を作る前の耕す作業を始めましたが、周辺から侵入してきた木の根や、スギナの地下茎が大量に 出てきて思うように進まず、4分の1の根っこ除去したところでタイムアップとなりました。
それでも前回の進捗を思えばかなり進んだ感はあります。
月曜日は雨が降りそうなので、明日には植え付けまで完了させたい。
太陽光発電システムの故障判断アルゴリズム（その１）
前回「この判定アルゴリズムを組み込んだアラートメールと、定期的にアラートメール自体の稼働監視用のメール通知をするシステムを構築しました。」と紹介しました。今回は、この 判定アルゴリズムと判定精度について紹介します。
つぎが判定アルゴリズムでの解析後のデータのプロットです。 故障をかなりきれいに検出しています。
グラフの一番左が、発電開始日で、日ごとのデータをプロットしていて、一番右側が導入後6ヶ月あたりです。
太陽光発電システムは３つあり、サイト1、2、3としています。順番に構築したので、サイト2、3の発電開始日は 2、３週間とそれぞれ遅くなっています。 サイト１、2、3のそれぞれの500m程度です。距離が500m程度だと、瞬間に日照は雲のかかり具合で差が生じますが、１日の発電量に影響するような長時間片側のシステムだけ雲が覆い隠すようなことは 起こりません。要するに近場だと、天気による発電量への影響はほとんど同じになる。この特性を利用します。つぎが具体的な判定アルゴリズムです。
P1＝「サイト1の１日の発電量」/「想定発電量」
P2＝「サイト2の１日の発電量」/「想定発電量」
P3＝「サイト3の１日の発電量」/「想定発電量」
MaxP＝max(P1,P2,P3)
S1＝P1/MaxP
S2＝P2/MaxP
S3＝P3/MaxP
このS1、S2、S3をプロットしたものが上のグラフです。
すこしばらつきがありますが、その原因は悪天候です。発電量が小さい場合はばらつきが大きくなる傾向があります。
また、太陽光パネルの配置が２か所は南向き１面なのに対して１か所は東西で振り分け（均等ではない）であるため、 午前と午後で天気が変わった場合にばらつきがすこし大きくなります。また、悪天候の日の発電量が想定発電量に対して、いずれの設備も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
太陽光発電について
2013年に導入した太陽光発電システムについて書きます。最近の話の前にこれまでの運用状況です。
一言でいうとおおむね順調です。導入当初に設定した6年で投資額を回収する計画をほぼ予定通り 達成しています。 導入システム選定はこの投資回収期間の最小化を指標として機器選択をしています。
この投資金額は補助金等を考慮した実質の投資金額で算出しています。買電単価は42円/kWhでした、最近は 買電単価や太陽光発電システムの価格が下がってきているので、投資回収期間がどれくらいなのか わかりませんが、現時点で投資回収期間を6年くらいにするのは難しいと思います。
これまでの、太陽光発電システムのトラブルは、導入後3か月で発生したパワコンの故障が一番大きいものでした。
たまたま見たモニタの発電量の数値が小さめであったことで気が付きました。4.4kWと5.5kWの２台のパワコンがありこのうち4.4kWのほうが故障していました。
このため、モニタ上の発電量は”0”になるのではなく通常の60%くらいの数値でした。もちろん発電量は天候によって 変化するので最大値の60%程度の発電量しかないことも普通にあるので、発見できたのは運が良かったかもしれません。
といっても、過去データを解析すると(ロスした期間はしたのとおり)、実際に故障してから発見するまで2週間経過していました。そして修理（パワコン交換）まで１週間ほどかかりました。
この復旧までの期間を短くするため、この判定アルゴリズムを組み込んだアラートメールと、定期的にアラートメール自体の 稼働監視用のメール通知をするシステムを構築しました。
そして、上のトラブル以降は、パワコンの故障は発生することなく現在に至っております。
パワコンの故障以外に気になる事象（別の機会に書きます）が発生しており、アラートの仕組みの再構築を検討中です。
6月7日 100%
6月8日 57%
6月9日 62%
6月10日 57%
6月11日 68%
6月12日 67%
6月13日 66%
6月14日 61%
6月15日 72%
6月16日 71%
6月17日 68%
6月18日 61%
6月19日 56%
6月20日 54%
6月21日 59%
6月22日 80%
6月23日 64%
6月24日 65%
6月25日 61%
6月26日 91%
6月27日 100%
6月28日 100%
6月29日 100%
phpからpython起動
ローカルマシン上で動かしているpythonのコードを、サーバー上に移行することを検討中です。 現在、Jupyter Notebook（iPython Notebook）を使っていて、この環境向けに書いたコードを定期的に起動して、データ収集と解析を行っています。現状は、実行するときは手動でJupyterを起動して、操作しています。 この手間を何とかしたいわけです。
まず、pythonコードをPHPから呼び出す方法を確認。 いくつかのサイトに記載があり、つぎの２つの動作確認はすぐにできました。
「phpからpythonを呼び出し、実行結果を取得、表示」
「サーバー側でPythonスクリプトを動かし、結果をクライアント側に表示する」
ただ、numpyをインポートする単純なコードだと、phpではpythonの出力文字列を拾えない状態になった。上の２つ目のコードに順に追加していくと問題なく動作し、前の問題を再現できていない。
1つめのコードに１行ずつ追加して問題発生有無をチェックしていくと、２バイト文字を含む行を追加した時点で問題が発生することが判明した。 そして、２つ目のpythonコードと比べて、
２つ目のpythonコード の1行目「#-*– coding: utf-8 -＊-」が効いていた。 これを1つめのコードに反映して問題が解決した。 この行の記述のとおり２バイト文字はここで指定した文字コードで保存しないと文字化けする。
↑そもそもPHPでエラー出力を拾えるように細工しておけば、原因はすぐに分かったはずだが、 久しぶりに触ると.やはりだいぶ忘れてます。
つぎはJupyter Notebookのコードを移植していきます。
あっという間にディスクフル
そんなに大きなファイルを保存したはずもないのにディスクフルになることはないですか？
上は空き確保の対処後の状態ですが、まだまだ改善の余地なりの状態です。 ポイントは、保存したファイルの総サイズが255GBなのに対して、ディスク上のサイズは595GBという点です。実利用率は42％ほどにとどまっています。つまり、60％もの領域が使えない状況なのです。
この事象を発見した当時は、” 保存したファイルの総サイズが5GB程度なのに、4TBのHDDを使い切っていました。ディスクの実利用率は0.1％とひどい状況でした。原因はHDDの1ブロックのサイズが128MBと大きいのに、細かいサイズのファイルを大量にxcopyでバックアップしていたからでした。昔は512Byteとか4kByteだったので、何の問題もなかったのだが…。
バックアップの仕方を、圧縮したファイルを転送するようにバッチを変更しました。 ただ、たまに古いバッチが動いているようだ……。探して処置しないと…
それから、Windowsのイメージバックアップが１つのファイルで、1.6TBもある、OSなどバックアップ対象にしたファイルサイズはこんなに大きいはずはないのに。 バックアップの範囲内に、外部へのシンボリックリンクがあるような気もする… これも再確認が必要だ.