4/28に植え付けしたキャベツを収穫しました。一時は虫に食われて壊滅寸前できたが、農薬のおかげで持ち直して少し前倒しの収穫にまでたどり着きました。直径13cm、重量は920ｇほどです。市販のものは1玉1200g程度ですのでほぼ想定通りです。期間をずらしてできるだけ長期間にわたって収穫したいので、早めに成長したものを前倒しで収穫したのです。
月別: 2019年6月
きゅうり収穫＆追加植え付け
本格的にきゅうりを収穫できそうなところまできました。最初に早取りしたものを除いて初収穫です。長さは23cmほどです。
市販のキュウリの長さは20cm前後なので丁度よいサイズになっています。ここまで大きくなるのに１週間ほどかかっています。今日時点でしたの収穫4日前の程度のサイズの実が４つ以上あるので、来週は4本は収穫できそうです。
上とは別の畝ですが、レタスの収穫が終わったので、その場所にが新たに育ったキュウリの苗を植え付けました。合わせて、キュウリネットも設置しました。
トマトが赤くなり始めました。来週からはいろいろ収穫できそうです。
サーバー移行先検討のページを更新しました。
移行先検討の件です。現在、各サービスについて調査しており、ここまでの結果を移行先の検討のページに反映・更新しました。代替サービスの案内の資料はまだ届いていないので、代替サービスの部分は空欄です。最終的な判断は資料が届いてからにします。ほかによいサービスがあるなどコメントなどあれば情報をくださいお願いします。
また、移行スケジュールは来週決める予定です。
大雨で自動での排水起動頻度が不十分なので音声起動を追加
雨が降り出したら自動排水するようにIFTTTのAplletを追加しましたが、その対処では不十分なくらいに大雨になっています。これまで頻度がそれほどでもなかったので手動で起動していましたが、そうもいっていられないくらいの雨になってきたので、音声で起動で指定するAppletを追加します。
IFTTTのサービスを使って、雨が降り出したら排水ポンプを動かすAppletをGoogle homeとEchoそれぞれについて設定します。まずIFTTTで「New Applet」すると次が表示されます。
「+this」をクリックして実行する条件”トリガー”を設定します。ここでは「Google Assistant」もしくは「Alexa」を使っています。検索枠にサービスの名称の頭から数文字”As”や”Al”を入れると選択肢が表示されます。
” Google Assistant”や”Amazone Alexa” をクリックします。
次に起動ワードを指定します。起動したいだけなので、”Say simple phrase”を選択します。
起動ワードに は「排水」を、指定します。「Create trigger」をクリックします。
「＋that」をクリックして、何を実行するかを指定します。
実行する処理をサービスの中から選択します。ここでは、利用するスマートコンセント”Meross”を指定します。
”Turn on”（電源オン）を選択します。
登録した”排水ポンプ”のスマートコンセントを選択し、「Create action」をクリックします。
設定した内容を任意の名前を指定します。 「Finish」をクリックしIFTTT設定を完了し保存します
以上で、「雨が降りだしたら自動で排水」することができます。排水ポンプを止めるほうはスマートコンセントのスケジュール設定で「1分後にオフ」を登録しているので、1分後に自動的に排水ポンプは停止します。
ついに来た。サービス停止の案内。移行先検討を本格的に開始します。
ようやく明日、梅雨入りとなる見込みで当分水やりの手間ははぶけそうです。
さて、以前に移行先の検討すると書きましたが、ついに2019年12月27日にサービス終了する旨のメールが来ました。後日代替サービスの案内を郵送すると記載されていました。最終的な判断は資料が届いてからにするとして、本格的に情報収集を始めます。
また、これまでに仮決めしていた移行スケジュールは2019年10月に移行先決定でしたが、現行サービス終了から逆算してスケジュールを決めなおすことにします。※ 現在の運用状況だと、1か月並行運用、1か月切り替え期間、1か月予備期間くらいをとらないと余裕を持った作業ができなさそうです。
トマトの収穫時期について
このサイトの情報によると、
「トマト・ミニトマトは開花から毎日の平均温度を足していった積算温度で赤くなる日にちが決まります。
トマトだと800～1000℃（品種によって違います）
ミニトマトだと750～850℃（品種によって違います）くらいです。」ということです。
積算温度で800℃と仮定して計算してみます。
5/21以降の平均気温を積算したグラフです。徐々に気温が上がっているので、短くなってきていますが、現在は36日で800℃に達します。
最初に開花を確認した記録は6/1でしたので、計算では7/6もしくは7/5が収穫見込日です。 昨日開花していた分をマークしました。あと2回ほどマークして大玉トマトとミニトマトそれぞれについて積算温度がどの程度で収穫できるのかを検証してみます。
きゅうり収穫
下の写真中央のきゅうりを収穫しました。まわりの葉は白く粉を吹いたようになっています。うどんこ病だとおもわれるのと、となりの1株が枯れてしまったので、農薬を使って対処しました。農薬は使いたくはないのですが、全滅は避けたいので酢系のものを使いました。
トマトもたくさん実が付いてきました。まだ、緑色のままです。これから雨の日が多くなりそうで、気温は低めに推移することになり来週くらいから収穫できそうな感じはあまりしません。実際に積算温度がどの程度で収穫できるものなのかをマークを付けて検証してみます。
いいね 家電リモコンのセンサー機能
ちょっと前に試しに設定していて忘れていた機能が動作して、やっぱりいいねと思いました。
それは、センサーで取得した明るさの情報をもとに家電を操作する設定です。次のように設定しました。
１）IFTTT連携の設定を行う。
２）IFTTTでつぎのようにAppletを作成する。
2-1)then に RATOC remoconを選択する
2-2) リモコン明暗 (照度) を指定する
2-3) 基準値１（100Lx）より低いを選択する
2-4) Create Triggerを押す
2-5) that に RATOC remoconを選択する
2-6) エアコンの操作を設定する
2-7)エアコンの操作で 停止 を指定する。
2-8)Create Actionを押す
以上で設定は終わりです。
この設定で、電灯を消して部屋が暗くなれば自動的にエアコンが切れるので、エアコンの切り忘れを防げます。 逆にエアコンをつけたままにしておきたければ電灯を点灯したままにしておく必要があります。その場合でも離れたところからオンになっていることを気が付けます。エアコンの消費電力に比べれば電灯のほうはそれほど多くないので、消費電力的にも無視できるでしょう。
RATOCの仕掛けに改善してほしい点を言うとすると、「 基準値よりｘｘ 」という条件だけでなく、「ｘｘｘ以上からｘｘｘ以下に変わった」など、条件をきめ細かくしてほしいところです。 現状の「 基準値１（100Lx）より低い 」の条件だと、電気を消した時点だけでなく、暗い時間帯に複数回”エアコン停止”の操作が行われることになります。エアコンの動作的には何も起こりませんが、リモコン操作がおこなれたのと同じで”ぴっ”という音がします。
そんな感じで、現在の状況に合わせて動作する仕掛けは、うまく使えばなかなか便利です。その点は、Amazon EchoとGoogle homeの音声アシスタントにも当てはまります。今の状態を認識したうえでそれに合わせてより期待に近い動作をさせるというものです。今の時刻、現在の場所、などです。「今日の天気は？」と聞くだけで、現在地の天気を教えてくらますよね。現状はGoogleのほうが状態認識しているものの情報量が多く、的確な動作をしていると感じます。
たとえば、つぎのようなものです。
・テレビがついているかどうか
→ リモコンボタンの電源操作は、ON/OFFどちらも同じ信号が送信されます。このため、テレビの状態を認識できていないと「テレビをつけて」の操作の結果として”テレビを消して”しまうことがあります。
Google home（Chromchast）の場合はリモコン操作でないので機能するのですが…
・誰が操作したか
→ 誰が操作したのかを認識してその人の設定で動作する。
カレンダーなど個人アカウントと紐づいている情報にアクセスして動作します。
・今、何をしているか
ということ、スマートスピーカーは、その機器で認識した5W1H？を条件にして、それについて前置きする音声入力することなく機能するので違和感なく使えます。このレベルまではふた昔前のAIのレベルです。今どきのディプラーニング技術をこの5W1Hの管理に組み込めば、スマート何とかはさらに進化できるはずです。
WordPress 5.2.2の修正内容 と脆弱性
WordPress5.2.2のことを書く前に、以前に書いたWordPress脆弱性で完結できていないものを再確認します。
まず以前に書いたCVE-2017-6514について書きます。JVNのDBには2019/6/6に登録されています。これは私がここに投稿した日より2週間ほど遅い。JVNの情報から修正内容など新たに分かる情報はありませんでした。最近の動きは6/14にある脆弱性チェックツールで検出できるように強化されたことが情報公開されています。このタイミングでの情報公開なのでWordPressの修正コードなどの情報をもとにチェックルールを作成したものと推測されます。まだWordPress側では脆弱性情報が公開されていません。現在関係機関と公開に向けて調整しているのではないかと推測します。
つぎに、WordPress5.2.1の修正情報の再チェックです。前回チェックしたときに内容チェックに終始して、後で更新されることは想定していませんでした。ぱっと見た範囲では、変わっていません。この状況だと更新される可能性がありそうです。
さて、本題のWordPress5.2.2の修正内容についてです。13件のバグ修正とWordPress5.2で追加したサイトヘルス機能をちょっと更新したとリリース情報には記載されています。
＃45094 #46289 #46997 #47227 #47429 #47558 #47475 なし
#46749 4.3
#46881 #46957 #46960 #47070 #47158 5.2
作り込みバージョンの記載がないもの7件、4.3が1件、5.2が5件です。
バージョンの記載がないものの修正内容は次ように、脆弱性に関係しそうな記述はありませんでした。
#45094 ダッシュボードのいくつかのエレメントでフォーカスされない
#46289 メディアモーダルでのナビゲーションアローのリンク先間違い
#46997 テーマの更新でリンクが動作しない
#47227 サイトヘルスタブの文字列修正 → 5.2での強化分の修正
#47429 更新パッケージ
#47558 更新ページのアップデート → 5.2.2で勝手にアップデートした件でしょう
#47475 typoの修正
脆弱性に該当しそうな修正内容の情報はありません。5.2.2は”セキュリティ更新”として更新が自動適用されたり、修正公開の事前情報など脆弱性対処をしたりした状況と推測される状況なので、セキュリティ修正がリポジトリには登録されたソースコードはあるが、公開された修正項目には情報がないという状態だと思われます。
以上の状況から、別途公開済みの5.2.2か5.2.1で修正された脆弱性情報が後日公開されるものと推測されます。
それから、サービス停止を引き起こしかねないアップデートを勝手に適用するというはそれ自体がDOSの脆弱性と言ってしまってもよいのではないでしょうか。サービス停止したことを自動検知して自動リカバリするとかいろいろな対処がありそうです。
太陽光発電システム導入環境での消費電力解析
これまで、太陽光発電のデータ解析について書いてきましたが、そもそもなぜ書き始めたかについて詳しく書いていませんでした。「パワーコンディショナーの消費電力」や「ここまでのまとめ」で、パワーコンディショナーの消費電力についての挙動をあるていど理解できたので、それを踏まえて気になっている点について解析してみます。
解析したかったのは、さきに書いたサイト3における「パワコン？謎の消費電力増加」の総消費電力量の増加の原因です。
問題の期間（2018年5月から2019年2月までの間）について、”パワコンでの解析”のように各時刻ごとの消費電力をプロットしてみます。
「謎の消費電力増加 その4」のデータと同様な絵柄ですが、5回ほど階段状に変化してそれぞれで別の挙動をしているように見えます。そこで、同様に朝と夕方の時間帯分をプロットしなおします。
朝方のデータから全体の階段情報変動はベースライン自体の変動に依存しているように見えます。つまり、太陽光発電システム以外で常に一定の電力を消費している何かが増えたと推測されます。
夕方のデータでは、１日に１分づつ変化するパワコンのモード切替時刻の影響により6/13以前と7/9から9/7あたりは19時台の消費電力が徐々に変化しているのがわかります。
9/14から12/1あたりは激しく変動しています。昼間と夜間の差は同じようにあるのでベースが変動していると推測できます。
12/1以降は5回ほど階段状に増減しています。それぞれの区間での昼間と夜間の消費電力差は同じです。この区間内での変動はベースラインの変動のみと考えてよいのですが、9/7以前にみられた19時、18時台の1日づつ変化するパワコンのモード切替時刻の影響が見られなくなっています。このパワコンの挙動の変化のタイミングと、消費電力量のベースラインの変化のタイミングが一致しているので、ベースラインの変化の原因がパワコンに依存しているのではないかと想像されます。次回、詳細を確認します。