謎の実、インディアンサマー？

庭に大量に出てきたので、一つ食べてみました。


　　　食べられなくなないが、特に味もしないスカスカな感じです。この個体だけかもしれないので、他の実もいくつか試してみます。

個体により多少ばらつきはありますが、総じてほんのり甘酸っぱい薄い味です。そういえば、ケーキの上に載っていたラズベリー？でも薄い味のものと同じ味です。ということで、残りの実も収穫してみましょう。

これらは、これまで雑草の１つとして処理していた蔓系の植物です。ちょっと手を抜くといつの間にか繁茂しているイメージがあります。前述の実は、これまであまり処置できていなかった個所に生えてきたものでした。上の写真のようにいろんな植物の中の１つでした。

出来のよさそうな実だけを選んで収穫しました。意図的に植えているわけではないので、生えている場所によって出来具合はバラバラです。ところで、この実はいったい何ということで 調べてみました。この植物を植えたいきさつを知らないので、何が生えているのかよくわからない状況です。

まず、実の写真から画像で類似するものを検索しました。

「west indian raspberry」と出ました。ほかのサイトの記述などを見るとインディアンサマーのようです。もっと詳しい品種の見分け方はないものだろうか。

トップページ更新

トップページを更新しました。
リンクページに、太陽光発電、MysTilesのアイコンを追加し、ロゴを更新しています。 また、サブページにも太陽光発電、MysTilesを追加しました。MysTilesはタイル型ポータルページであるMyS’Tileのサブセット版です。MyS’Tileは個人ごとのカスタマイズを想定したJavaScriptベースのポータルページです。 phpで書いたものではありません。これを、クラウドサーバに移行して、個別カスタマイズ部分を削除し、一部をphp化しました。何か良いphpで書かれたポータルアプリケーションもあれば、切り替えたいと思います。何か良いものがあればコメントください。

WordPress5.2リリース

以前、脆弱性に関連して取り上げたWordPress5.2が5月8日にリリースされています。

・管理者アカウントでログインすれば新しいバージョンが提供されていることが左上の更新と赤に白抜きの数字で示されます。また、ダッシュボードや更新画面から最新バージョンに更新することができます。更新の前にバックアップするように案内されます。
・投稿者アカウントでログインした場合は、ダッシュボード上部に「WordPress 5.2 が利用可能です。サイト管理者にお知らせください。」と表示されます。
機能強化を行うメジャーバージョンアップやマイナーバージョンアップの場合、不具合が含まれているケースが多々ある。新たに提供されて機能を使いたいなら話は別だが、 必要がない機能しか提供されていないので、バージョンアップは急がなくてもよいでしょう。そこで、1か月程度は保留することにします。あまり放置するとほかの実行基盤のバージョンとの組み合わせで不具合が発生することがあります。そこで、１年以内にはバージョンアップを適用することにします。通常は、１年経過する前にセキュリティパッチが提供されて、セキュリティパッチを適用する必要が発生します。
WordPressの場合、Security Category Archiveのページ
https://wordpress.org/news/category/security/ をチェックしていれば、脆弱性対処を含むパッチが提供されているか確認できる。ざっと見て、2か月に１回程度の頻度で脆弱性対処パッチが提供されていることがわかります。

これにより、WordPressの更新頻度が頻繁であれば、特別な方法で通知されなくても気づくことができます。逆にWordPressの更新頻度が低い場合、脆弱性対策パッチ未適用状態で長期間運用される可能性が高くなりそうです。このパターンは対応できるようにしたほうがよさそうです。

ということで、バージョンアップ情報や脆弱性対処を含むパッチの提供情報をメールで通知する仕掛けを用意しました。今回の公開には間に合わなかったが次回の公開時には、実際に通知されることを確認します。

パワコン？謎の消費電力増加 その4

以前のパワコン消費電力についての解析をもうすこし越し掘り下げてみます。すべての時刻 について”昼間から夜間の消費電力に切り替わる時刻がどのように推移するか”を最新のデータでプロットしなおしてみます。

やはり同じような傾向を示しています。日ごとに一定割合での減少と、2月5日の階段状の増加の２つの変化が見られます。

朝方と夕方のデータそれぞれのデータのみをプロットしなおします。

朝方については、これまでに解析した通り、夜間から昼間の消費電力に切り替わる時刻は変化していません。6時のデータ（6：00から7:00の合計）と前後の時間のデータが比率計算で、ほぼAM6:20に切り替わっていると判断できます。
また、2月5日前後で、昼間の消費電力が変わっていないことから、2月5日に発生した階段状の増加は、夜間の部分にのみ発生していることがわかります。

夕方については、毎日約1分ずつ遅い時間に切り替わるように変化しているように見えます。5月2日時点では19:20ころと推測されます。
5月1日と5月2日の日没時刻はそれぞれ18:52と18:53なので、夜間モードに切り替わるのは妥当な感じの時刻で、、毎日約1分ずつ遅い時間にずれているもの妥当言えます。発電量が下がったからパワコンが買電力から電力消費していると仮説を立てた場合は、パワコンの表示は18:50頃には0.0となっており19:20の時点では真っ暗です。このため、この時刻で発電量起因で切り替わっていることになり、妥当とは言えません。また、サイト2とサイト1のパワコンの動作に大きな差はないと判断して、5月1日の19時ころのサイト1のパワコン表示を確認した結果、”KP44M-J4-SS”は、19:10から19:15の間に、”KP55M-J4-SS”は19:17から19:18の間に、パワコン表示が滅灯することを確認しました。すべてのパワコンが同時に滅灯すると想定していただけに、意外な結果となりましたが、ほぼサイト2の夜間の消費電力増加はパワコンなどの太陽光発電システムに起因すると判断できます。

昨日の降雨量

昨日の雷雨は、実測で5mmの降水量がありました。ここから5km程度離れている気象庁の測定ポイントでのデータは0mmでした。かなり激しい雷雨だったので広範囲に降ったように感じましたが局所的な雨でした。
4月以降の気象庁の降水量のデータは、実測データとほぼ一致していたので気象庁データで十分そうだったのですが、昨日の降水量データの5mmと0mmの違いは大きい。自動化するなどの元データにするには、もう少し正確なデータのほうが良いような気がするがどうだろう。
　　　局地的なデータを取得できる何かいい方法など、コメントをお願いします。

連休中に、予定していた苗の植え替えは完了

残っていたトマトの苗を植え替えました。まだ育ちがいまいちのものはポットへ植え替えました。これで当面、急ぎで植える必要があるものはなくなりました。そして、今日は予想以上に雨が降りました、直近の水の心配も解消です。

トマトの苗を植えるために、いったん移動した土を戻して新たに畝を作りました。その際に、除去したはずのスギナの地下茎が多数見つかりました。先日見つけて除去した分の半分くらいを除去しました。この分だと、先日除去したのと同程度の量の地下茎が残っているものと推測される結果です。今回作った畝の状況も今後確認していきます。

リーフレタス植え付け

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

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

脆弱性情報の収集

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

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

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

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

パワコン？謎の消費電力増加 その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なのか、パワコン以外に夜間電力消費が発生するものがあるのか確認してみます。

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