下の写真中央のきゅうりを収穫しました。まわりの葉は白く粉を吹いたようになっています。うどんこ病だとおもわれるのと、となりの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の管理に組み込めば、スマート何とかはさらに進化できるはずです。
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日づつ変化するパワコンのモード切替時刻の影響が見られなくなっています。このパワコンの挙動の変化のタイミングと、消費電力量のベースラインの変化のタイミングが一致しているので、ベースラインの変化の原因がパワコンに依存しているのではないかと想像されます。次回、詳細を確認します。
どこかで、自動アップグレードする設定とかあったのでしょうか？ 更新ボタンも押していないのに「WordPress5.2.2にアップグレードした」とメールが送られてきた。たしかに、WordPress5.2.2 が6/18にリリースされていて、 https://wordpress.org/news/2019/06/wordpress-5-2-2-maintenance-release/ このサイトにも勝手に適用されていた。
”更新”の記載には「最新バージョンの WordPress をお使いです。 今後のセキュリティ更新は自動的に適用されます。」と書かれている。 これを信じるならば、まだ セキュリティ情報は出ていないが 5.2.2で脆弱性の対処が行われたのでしょう。
以前に予想したとおりの状況ですが、勝手に修正を適用されてしまうのは想定外でした。 5.2.1の時みたいにセキュリティ強化した権限設定の影響でサービスダウンしてしまったらどうしてくれるつもりでしょうか。その辺の不満を越える危険をはらんだ問題だというならわからなくはないが、この仕掛けを基盤にして業務用に使用しているところは沢山あります。業務が止まったら大変なことになります。この辺を踏まえて設定で自動適用するかとか自動適用する脆弱性の深刻度レベルを設定できるようにするとか、工夫してほしい。
WordPress5.2.2の修正内容をチェックはまた明日。
監視モニター用の画面が起動しないので、ほかのページを確認すると、Nginxが動作していないと推測される状況でした。プロセスを確認するとNginxのプロセスは確かにいない。手動で、 Nginxを再起動しても、復旧しませんでした。
こんな時は、慌てず原因調査します。nginxのログファイルerror.logには、つぎのとおり出ていました。再起動するたびにこれが出力されます。
[notice] 19828#9876: signal process started
[error] 19828#9876: OpenEvent(“Global\ngx_reload_16096”) failed (2: The system cannot find the file specified)
logsディレクトリには ファイルnginx.pidが存在していて、このファイルには 16096と書かれていました。 上の” ngx_reload_16096 ”と同じ数字です。これはNginxのPIDです。tasklistでこのPIDが存在しないことを確認しました。また nginx.pid ファイルのタイムスタンプは2日前であり、かなり古い日付です。 この状況から、Nginxの終了処理が完了しないうちにOS再起動されてしまい、nginx.pidファイルが残留してしまったことが原因で、Nginxが起動できなくなってしまったと推測されます。
ということで、 nginx.pidファイル を削除して、再起動します。
おや、再起動しない。ログメッセージはちょっと変わりました。
[error] 17420#13516: CreateFile() “XXXX/logs/nginx.pid” failed (2: The system cannot find the file specified)
おっといけません、” nginx.pidファイル を削除して ”いたつもりでしたが、 nginx.pid を開いたエディタを別名で保存した状態で開きっぱなしでした。 nginx.pid ファイルは存在しないけど、このエディタプロセスが nginx.pid のファイルディスクリプタをつかんでいる状態になっていました。
エディタも閉じて、Nginxを再起動して、無事に復旧しました。
ログメッセージをインターネット上で検索してみると、問題対処のためインストールしなおししている人がいました。復旧させるにはその方法もありますが、原因を特定しないと再発防止策の検討もできませんし、復旧に余計な時間がかかるかもしれません。そんなときはサービス停止の影響を最小化しつつ、慌てず原因調査しましょう。
トマトとミニトマトの実がなり始めました。花も順次咲いているので、この調子だと７月上旬からどんどん収穫できそうです。
「トマト・ミニトマトは開花から毎日の平均温度を足していった積算温度で赤くなる日にちが決まります。
トマトだと800～1000℃（品種によって違います）
ミニトマトだと750～850℃（品種によって違います）くらいです。」
ということですので、累積温度800℃として、 平均気温23℃から25℃として 計算すると開花から35日くらいと予想できます。６月1には花が咲いていたので、7月5日くらいには最初の収穫ができそうです。
ミニトマトは摘果を省きますが、トマトのほうは随時摘果していきます。
まだ梅雨入りの発表はありませんが、雨の日も少ないけど何日かあり、キュウリの実も付き始めました。僅かに残っていたスペースにトウモロコシを蒔きました。2か月ほど先行して蒔いたトウモロコシは半数ほどが20センチほどに育ってきています。長期間にわたって収穫することを目指してあと1回くらい時期を分散して蒔く予定です。
各列の奥のほうがトマトで、一番左の列はキャベツ。左から２番目はレタスと虫に食われてなくなったキャベツの跡、３番目は今回追加したトウモロコシ、一番右はぼぼ収穫し終わった大根の跡と先行で植えて生き残ったトウモロコシです。一番右側の列は最初にスギナの処置を全く行わなかった場所で、一番左はある程度スギナの処置を行った場所、この２つは明確な差があります。大根への影響はあまりなかたと思いますが、弱い作物なら育ちや育成中の作業に悪影響はありそうです。どこまで根っこの処置をするかは何を植え付けるかで決めるのもありだと思います。
「免許自主返納後に運転して事故」とか、何年も先の話をしている場合ではないですね。2020年以降販売する車は免許証を差し込んで、運転を許可されている車かどうか認証して、確認できないとエンジンがかからないようにするとかすぐに対策しないとしないとけませんね。
自動運転をすぐに実現するのは厳しいでしょうが、運転免許証を認証するのはすぐにできるはずです。
まず、ICチップを組み込んだ免許証ですが、一番遅い時期に導入された鳥取県でも2010年に導入されています。このため全国で導入されてから8年以上経過しています。運転免許証の有効期間は長い人でも5年ですので、すでにすべての人の免許証はICチップが入ったものに切り替わっています。
また、免許証のICチップには 「氏名」「生年月日」「免許証交付年月日」「有効期間」「免許の種類」「免許証番号」「顔写真」 の情報が入っています。ICチップを読み取る機器はすでにありこれをベースに開発すれば、有効期限内の運転免許があるか、この免許証で運転可能な車かどうか、をチェック可能です。ETC機器と同額程度で実現できるのではないでしょうか。 また、画面に氏名や顔写真を表示することも簡単にできそうで、免許のまた貸しにもある程度の抑止力があるでしょう。さらに、半年くらい開発期間は長くなるかもしれませんが今どきのディープラーニング技術を使って、「顔写真」と運転者が同一人物か顔認証でチェックすることもできるでしょう。
いろんな方面からの対策がありますが、役所関係が本気になれば免許ベースの対策はすぐに現実できそうな感じがします。
「単機能の低額なものと割り切って購入しようかとも思いましたが、とりあえず試したスマホの歩数計のアプリで十分と判明したので、スマホアプリでやってみます。」 のその後です。 回線なしスマホでも十分利用できることが確認できました。当面これを使って測定してみます。
その場の運動だけでもちゃんとカウントしてくれるし、車で移動しても変にカウントしないのでかなり信用してもよさそうです。GPSは使っていたとしても誤カウント防止で、加速度を計測して歩数としているのでしょう。
で、ここまでで気になったのは、普通にウォーキングしている分にはポケットにスマホを入れていても、何も問題がありませんが、しゃがみ込んで作業をするとポケットから飛び出してしまいます。これだけが、困って点です。何かないか探すとサイドポーチだけでなくアームポケットとかいろいろ売られているようです。持ち運びと操作を考えるとアームポケットがよさそう。
