雨が降りだしたら自動で排水　

消費電力ほぼゼロのはずの電気代が1か月で5500円とか、9500円に増えていることに気がつきました。調べると排水ポンプが稼働しっぱなしになっており、常に「ジョロジョロ」と排水されていることが原因と判明しました。普通は、「ドバー」っと一気に排水されて水がなくなると自動で止まります。これは排水ポンプのフロースイッチが効かなくなっていることが問題原因なので、本来は排水ポンプを修理もしくは交換するところです。しかし、費用も抑えたいし、コンセント側で電源をON/OFFしてやれば同じ動作ということで、余っていたスマートコンセントを付けてみました。そして指定した時刻に定期的に排水するように設定しました。この変更で、電気代は１か月で390円に激減しました。これは意図した通りなのですが、故障する前の電気代は1か月あたり1100円程度だったので、期待以上の削減です。ポンプの待機電力より、スマートコンセントの消費電力のほうが小さいとは思えないので、以前は現状のポンプの稼働頻度よりも高頻度でポンプが稼働していたと推測されます。

短時間に多量の雨が降った場合、自動では排水されず、水が溢れるかも知れないので、少し工夫してみます。
IFTTTのサービスを使って、雨が降り出したら排水ポンプを動かすAppletの設定をします。まずIFTTTで「New Applet」すると次が表示されます。

「+this」をクリックして実行する条件”トリガー”を設定します。ここでは「Weather Underground」を使っています。検索枠にサービスの名称” Weather Underground ”の頭から数文字を入れると選択肢が表示されます。
” Weather Underground ” をクリックします。

次に実行条件を選択します。雨が降ったら起動したいので、”Current condition change to ….”（現在の天候がｘｘｘに変わったら）を選択します。

”Current condition” は「Rain」（雨）を、Locationをマップで指定します。「Create trigger」をクリックします。

「＋that」をクリックして、何を実行するかを指定します。

”実行条件”と同様に、実行する処理をサービスの中から選択します。ここでは、利用するスマートコンセント”Meross”を指定します。

”Turn on”（電源オン）を選択します。

登録した”排水ポンプ”のスマートコンセントを選択し、「Create action」をクリックします。

設定した内容を任意の名前を指定します。　「Finish」をクリックしIFTTT設定を完了し保存します

以上で、「雨が降りだしたら自動で排水」することができます。排水ポンプを止めるほうはスマートコンセントのスケジュール設定で「1分後にオフ」を登録しているので、1分後に自動的に排水ポンプは停止します。

他のサービスやWebRequest、Webhook、独自実装を組み合わせて排水量制御とか、排水の代わりに灌水の制御をするようにして、雨の状況を予測して灌水するかどうかを制御するとかいろいろできますね。

Pythonで日本語メール送信

定期実行タスクの機能を使ってメール送信していましたが、content-typeを次のようにcharsetを指定したいのに、

Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US

つぎのように指定されています。
Content-Type: text/plain; charset=ANSI_X3.4-1968

このcharset指定のメールでは、日本語の文面が文字化けしてしまいます。受信したメーラーで明示的に文字コードを指定することで文字化けは解消しますが、いちいち指定する手間が大変です。そこで定期実行タスクのメール送信機能は使わずに、Pythonから直接送信するように変更します。

Python2.6で使用するので、 Uchida さんのコードを参考にさせていただきました。

参考のための補足情報：

・デバック方法
smtp = smtplib.SMTP(c[‘host’], c[‘port’])
の次の行に 「 smtp.set_debuglevel(True) 」を追加することで、メールサーバとの通信内容を確認できます。

・ユーザー名、パスワードの指定にはダブルクオーテーションでくくるのはNGです。ダブルクオーテーションもユーザー名、パスワードとして送信されます。

user = <アカウント名>
password = <パスワード>

このPython実装でのメールでは、charsetは次のように設定されます。

Content-Type: text/plain; charset="iso-2022-jp"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

以上の設定により 、メールの日本語文面を文字化けせずに参照することができます。 これをベースに、脆弱性情報の通知メールに送信機能を組み込みます。

脆弱性情報の通知メールの仕掛けの更新

結構、動的に更新されるのか、頻繁に脆弱性ページが更新されています。
このため、先に作成した（5/9）、バージョンアップ情報や脆弱性対処を含むパッチの提供情報の通知メールが2,3日おきに飛んできます。WordPress5.3の作業も始まって、この更新分もあります。デイリーなのか更新頻度がどの程度なのかで、チェック方法を検討しなおします。
とりあえずメール文面を強化して簡単に更新内容をチェックできるようにしました。
今後、Webページの更新内容自体が、動的更新によるものかどうかを自動チェックして、通知するかどうかを切り分けるように強化します。※

次期クラウドサーバーの選定準備

　Pythonコードをクラウドサーバー上への移行で、本来不要であってほしい手間が発生しています。これも関連して、別のクラウド環境への移行を検討します。この検討状況を公開する固定ページを作成していく予定です。
　上述の”本来、不要であってほしい手間”とは環境移行の手間です。この環境はPythonのバージョンが古く、Python 2.6は使えるが、Python3が使えません。このため、ローカルで実装しているPythonコードを移行するとエラーが発生することがあります。原因はPythonのバージョンの際のほかライブラリがないなどの環境の差です。OSが異なることが原因もこともあります。
今後の移行時の参考のために、この移行時に発生したエラーと、その原因、対処をまとめたページを作成しました。

概略は次の通りです。
・Pythonのバージョンが古くPython3が使えないため、requestなどのコードをPython2.6用に書き換える必要がある。
・BeautifulSoupがない？など、 使いたいライブラリがないので、どうするか対処が必要。

費用削減の検討

「ちょっとガス代が高いのではないか？」ということで、ちょっと調べてみました。
実際のデータと、いろんなサイトの情報を並べたものです。

データ内容 実際のデータ 他サイトでのデータ
人数 3人 1人 3,4人
年間平均 6800円、12㎥ 4505円、5㎥ 12350円、20㎥
冬季 10500円、19㎥ 5551円、7㎥ 16534円、28㎥
夏季 3700円、5㎥ 3459円、3㎥ 9735円、15㎥

この情報からは、相場から見れば”高い”というのはあてはまらいようです。
ちなみに、enepi https://enepi.jp/のサイトで確認したところ、今使っている業者が最安ということでした。

どの業者を選択するかは問題なしとして、使用量は妥当か検討してみます。
3、4人の一般的な使用料と比較すると少ない数値です。他サイトの同じ人数より夏季が極端に少ないのは太陽熱温水器を使っているからです。
夏場の晴れた日は、太陽熱で50度程度まで上がっているようで、水で薄めて浴槽に入ります。このへんの温度調整はスカイブレンダーと給湯器が 自動でやってくれるので、太陽熱温水器で実際に何度くらいまで温度が上がっているのかは知りません。 このため、40年以上前に使っていた太陽熱温水器の経験から推測した数値を使います。

まず、夏季について、計算してみます。
お風呂の分
http://lpg-c.netで使っている次の数値と実際のデータもほぼ同じなので同じ条件として計算します。
「浴槽一杯分、250l（リットル）の水を42度で入れた場合の使用量を計算していきます。」
太陽熱温水器を使っているので、晴・曇・雨に分けて、初期水温の条件を設定します。
晴れの日は先に書いた通り50度として、曇りは32度、雨は25度とします。昨年の８月の天候は太陽光発電のデータで見て 晴れは24日間、曇りは6日間、雨は1日間として計算します。つまり、
晴れの日：　0kcal
曇りの日：　250ℓｘ（42-32）＝2500kcal　0.13㎥　ｘ6回
雨の日： 　250ℓｘ（42-25）＝4250kcal　0.22㎥　ｘ1回
　　　　　　＝　1.00㎥

また、追い炊きする時点で水温が30度に下がっているとして
　250ℓｘ（42-32）＝2500kcal　0.13㎥　ｘ31回
　　　　　　＝　4.03㎥
合計　5.03㎥
　　→数値合せしてしまいましたが、こんな感じでしょうか。
　　　調理にもそれなりに使っているはずですが、ほとんどはお風呂分ですね。
　　　3ℓｘ（100-25）＝225kcal　0.01㎥　ｘ31回

同じように冬季分を計算します。
冬季は太陽熱温水器の効果はほぼないので、一律で10度とします。
　250ℓｘ（42-10）＝8000kcal　0.42㎥　ｘ1回
　　　　　　＝13.44㎥

また、追い炊きする時点で水温が10度に下がっているとして
　250ℓｘ（42-20）＝5500kcal　0.29㎥　ｘ31回
　　　　　　＝　8.99㎥
合計　22.43㎥

　晴天の場合、冬場でもある程度暖かく感じる日もあったので、10度は厳しめの数値です。
　　　同様に調理分です
　　　3ℓｘ（100-10）＝270kcal　0.01㎥　ｘ31回

いずれも、追い炊き分が大きいです。
http://lpg-c.netのサイトにも記述がありますが、「お風呂はこまめにふたをして続けて入るのが節約のコツ！ お風呂もふたをしていないとどんどん熱が逃げてしまいます。こまめにふたをし、お風呂を沸かしたらすぐに入るようにする事が節約のコツです。 ふたをしていても1時間に約1度温度が下がってしまうため、あまりに時間が経つと追い焚きしなければなりません。 また、お風呂の保温機能はできるだけ使わないのがベターです。」

ということで、あとなんとか節約できるとしたら、追い炊き分なのでしょう。
つまり、「続けて入る」ようにするとかなり削減できそうです。

期待していない植物もいっきに成長

期待していない植物もいっきに成長しています。

野菜を気に掛けてばかりでしたが、気にかけていないうちに雑草や樹木が伸びてきています。2週間ほどで1mほど伸びた草もあります。ということで、今日の作業は雑草取りと、剪定です。
先日重ねた”雑草の絨毯”も成長しています。これの処置は当面できそうにありません。

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

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


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

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

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

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

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

「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の更新頻度が低い場合、脆弱性対策パッチ未適用状態で長期間運用される可能性が高くなりそうです。このパターンは対応できるようにしたほうがよさそうです。

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