ドコモのスマホへの移行の勧誘が頻繁になってきた感じがする。これまでにもいくつかのサービスが終了する前の移行勧誘を経験してきましたが、それらと同じような状況になっています。以下は、2019年5月時点で ドコモ窓口の人から聞いた話です。これらは、たぶん対応マニュアルとかに書かれているのだと思います。まず、「imodeサービス」のキーワードが出ています。 「imodeサービス」 から新しいサービスに移行を進めようとしているのでしょう。「imodeサービスの終了がいつになるかはまだ決まっていない」、「終了時期の2か月前にはメール（メッセージRかメッセージF）で案内する」ということでした。多分、案内はメッセージRのほうでしょう。
過去に次のような報道もありますが、終了時期は状況によって変わるでしょう。
第３世代移動通信システム（３Ｇ）の終了時期について「２０２５―３０年」
どのタイミングで更新するのか悩みどころです。車は買い替える気はなく、車が対応しているモバイル端末の機種拡大もされそうもないので、当面ガラケーで行くしかなさそうなのですが….。
日本語では名称が”ふわっ”としていることがある。コンセントとプラグ、どっちがどっちか良くわからず使われていることはないですか？刺される方と刺すほう、どっちがどっちなのかという点です。プラグは刺すほうです。コトバンクの記載では”差込プラグ”とまで書かれています。冗長な表現なのですがこういう言葉が出てくること自体が、日本語では意味をちゃんと定義せずに使われていることを感じさせます。
英語（米）では、プラグはPlugですが、コンセントはoutletです。outletのほうが直接的な表現のように思います。
それはさておき、スマートコンセント、スマートプラグの名前の商品はどういうものでしょう。刺すほうなのか、刺されるほうなのか、どっちに着目したのかで命名されている感じがします。形状にあう名称にするなら”電源タップ”が妥当かも知れません。
最近、多い自動車事故について統計データを分析、解析してみようかとデータを探してみました。”交通事故総合分析センター”のサイトから入手できそうですが無料で入手できるのは統計解析後の情報だけでした。有料ならどこまで生データを入手できるのかよくわかりませんでした。無料で入手した統計データでは確認したい情報はありませんでした。以下に、何を確認したかったのかなどを書きます。
事故件数は報道されている件数よりも遥に多いはず。ということは、報道は一部を報道しているだけなので、そこには報道関係者などのベクトルがかかっている。そのベクトルは妥当なのか、報道されている統計後の情報は、意図的に元データを操作するなどデータ自体にもベクトルがかかっていたりしないかを確認したかったのです。
まず、ぱっと思いつく疑問を挙げてみました。
・高齢者の事故が多いとされているが、何か傾向はあるのか？
・報道写真を見ていると、特定車種をよく見る。車依存の事故が多いのでは？
・今どきの分析での成果はなにかあるか？
とりあえずこの辺についてコメントします。
■”高齢者”に関する分析
・ 「運転者年齢層別の事故件数」や「 高齢者の事故 」の統計データがありました。 計数データはほかの年齢と比較しないと、あまり意味がないでしょう。事故を起こしたのが高齢者かどうか、資料での記述”第1当事者”の年齢別のデータについては、人口統計の補正はしているようですが、運転者人口とか運転時間（人・時）を母数とした情報にはなっていません。この辺の考慮や、運転時間別の比率つまり普段運転していない人のほうが多いとか、自動車を乗り換えてからの期間が短いつまり操作性が異なる車に慣れないうちに起こす事後が多いとか、組み合わせてみるとより顕著な結果が得られるように思います。
■”車種別”の分析
車の台数が多いから、よく報道に登場するのかどうかとか車種別のデータがありません。気が付いている人も多いので、統計データを公開しないのは何か意図的に隠ぺいしているように見えますよね。明らかに何かあるのなら情報を公開して、みんなで議論しつつ対策を進めるべきでしょう。逆に何もないなら公表しない理由は何のでしょうが、少なくとも何かる車種があるので公開できない状態なのでしょうか？よくあるパターンは、気にしているところは何もないが、思わぬ車種に特異なデータがあったりしますね。
■” 今どき”の分析
今どきの分析ならもっと面白い結果が出てきてもよさそうですが、その辺が何もない感じです。これだけ大量のデータがあるのだからちょっと何かすれば改善できるネタは出てくるはずなのですが。
↑感覚的にはそうかもしれないが、分析的なアプローチがない感じです。また、プリウスをじっくり乗りこなしたうえでも感じる違和感には到達していないと思われ、深堀りした内容にはなっていない感じがします。
↑ 最近のブレーキとアクセルの踏み間違いとみられている件に触れているが、その件についての原因周りの話はなく、 ギア周りの話に終始していて分析不足の感がある。
↑ギア周りの話は、同感です。 最近のブレーキとアクセルの踏み間違いとみられている件には触れていない。
↑全体的に同感ですが、身振り手振り付きの喋りながらの運転は危険運転とまではいかないが、いまいちです。さて、直近の事故は、事故ごとに特性は違うので、それぞれの事故ごとに分析が必要でしょう。
最近の車には、一昔前のフライトレコーダと同レベルの情報は残っているのでしょうからデータ解析すれば何かわかるでしょう。入力信号の混線や人為的なデータ破壊とかまで考えるとデータ矛盾のチェックなど大変な作業かも知れません。
できるだけ早く、完全自動運転で何とかしてほしいです。そのレベルに辿り着く途中の車のデザインは現状と変えないほうようにするとか、新しいデザインの車は一定基準を満たした人だけ運転できるとか、いろんな角度からの対策も必要そうですね。
これまでにパワコンなどの消費電力について確認した情報を整理します。
1a) 夜間と昼間で電力消費の状態が変化する。
1b) 昼間は発電した電力を消費し、消費電力は変換効率内の扱いとなり表面上は見えない。
1c) 機種によっては充電する機能（UPS）を持っている。
2a) ”1a)”の状態が切り替わる時間は（日照時間）時期によって変わる。
2b) 夜間に消費される電力は変わることがある。
3a) 夜間に消費される電力は仕様に記載されている消費電力より大きくなることがある。
3b) パワコン等のファームウェアのバージョン（コード内容）や設定などにより消費電力が変化する。
3c) 昼間は、発電した電力や充電した電力を消費することで動作している。雨天等で長時間発電がない場合、充電した電力も使い切るために外部の電力を消費する可能性がある。
過去の写真データを参照したくなって、古い媒体を整理しました。様々なタイプの媒体やバックアップしたデータも出てきました。中身をチェックしようとしてドライブ入れてみたが、読めないものもあります。今すぐには不要だが、バックアップしたものが必要となったとき読めるかどうかを整理しまします。
下表内の記号の意味
◎：読み書きを確認済み
〇：読めることを確認済み
無印：未確認
| ドライブ型番 | HL-DT-ST DVDRAM GH24NS90 | HL-DT-ST DVDRAM GH24NSD1 | 備考 |
| メディアタイプ | |||
| DVD | 〇 | ||
| DVD-R | × | ◎ | |
| DVD＋RW | × | ||
| DVD-RAM | × | 〇 | |
| CD | |||
| CD-R | 〇 | ||
| CD-RW | 〇 | ||
ドライブ自体が手に入らなくケースとか高額になってしまうなどの問題が発生するので、どの媒体が生き残りそうなのか、見極めたうえでバックアップ媒体をどうするのか考えたほうが良いですね。
消費電力ほぼゼロのはずの電気代が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コードをクラウドサーバー上への移行で、本来不要であってほしい手間が発生しています。これも関連して、別のクラウド環境への移行を検討します。この検討状況を公開する固定ページを作成していく予定です。
上述の”本来、不要であってほしい手間”とは環境移行の手間です。この環境は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度温度が下がってしまうため、あまりに時間が経つと追い焚きしなければなりません。 また、お風呂の保温機能はできるだけ使わないのがベターです。」
ということで、あとなんとか節約できるとしたら、追い炊き分なのでしょう。
つまり、「続けて入る」ようにするとかなり削減できそうです。
庭に大量に出てきたので、一つ食べてみました。
食べられなくなないが、特に味もしないスカスカな感じです。この個体だけかもしれないので、他の実もいくつか試してみます。
個体により多少ばらつきはありますが、総じてほんのり甘酸っぱい薄い味です。そういえば、ケーキの上に載っていたラズベリー？でも薄い味のものと同じ味です。ということで、残りの実も収穫してみましょう。
これらは、これまで雑草の１つとして処理していた蔓系の植物です。ちょっと手を抜くといつの間にか繁茂しているイメージがあります。前述の実は、これまであまり処置できていなかった個所に生えてきたものでした。上の写真のようにいろんな植物の中の１つでした。
出来のよさそうな実だけを選んで収穫しました。意図的に植えているわけではないので、生えている場所によって出来具合はバラバラです。ところで、この実はいったい何ということで 調べてみました。この植物を植えたいきさつを知らないので、何が生えているのかよくわからない状況です。
「west indian raspberry」と出ました。ほかのサイトの記述などを見るとインディアンサマーのようです。もっと詳しい品種の見分け方はないものだろうか。
トップページを更新しました。
リンクページに、太陽光発電、MysTilesのアイコンを追加し、ロゴを更新しています。 また、サブページにも太陽光発電、MysTilesを追加しました。MysTilesはタイル型ポータルページであるMyS’Tileのサブセット版です。MyS’Tileは個人ごとのカスタマイズを想定したJavaScriptベースのポータルページです。 phpで書いたものではありません。これを、クラウドサーバに移行して、個別カスタマイズ部分を削除し、一部をphp化しました。何か良いphpで書かれたポータルアプリケーションもあれば、切り替えたいと思います。何か良いものがあればコメントください。
