はじめ@Blog

function foo() {
  let x = 10;
  var z = 30;
  if (true) {
    let y = 20;
    var z = 40;
    console.log(x); // Output: 10
    console.log(y); // Output: 20
    console.log(z); // Output: 40
  }
  console.log(x); // Output: 10
//  console.log(y); // Uncaught ReferenceError: y is not defined
  console.log(z); // Output: 40
}

foo();

ChatGPTが吐き出したコードに少し手を加えたものだが、これ(変数z)を見てわかるように、var は入れ子で宣言できるくせに、関数スコープなので、内側ブロックでは上書き宣言になってしまう。こんなこと許されてよいのか？と思う人もいると思うが、関数スコープならその関数内で複数の宣言があったらエラーになって欲しいし、複数宣言できるならブロックスコープにして欲しい。ということから、let が追加された。

ざっくりと言えば、var の直感的ではないおかしな挙動をしないようにしたものがlet だとも言える。

なので、これからは、どう考えても let を使うべきで、var で無ければならない理由が見当たらない。のだが、まだ、var 派の開発者が少なからず居る。私はというと、let 派ではあるのだが、ついつい、癖でvar と書いてしまうヘボプログラマといったところだ。特に既存の var だらけの他人のプログラムをメンテナンスする時は、下手に let に変えたら、動かなくなるのではないかという恐怖心がわくこともある。動かなかったらほぼ元バグなのだが、めちゃくちゃ複雑怪奇なものだと、バグ取りをするのも面倒なので、var で逃げてしまうこともある。

大した使い分け的意味もなく、var と let が混在する状況も、あまりよくないとは思うということも、var を使いがちになる要因と言える。

太陽光発電＋蓄電池のシステムで、AI制御というのが、出てきているが、AIで何を制御して、どうなるのかが、今ひとつわからなかったので、想像してみる。

私の蓄電池はAIは無いのだけど、私はLOOOPでんきのスマートタイムONEという仕組みを使って、少しでも買電時の単価を抑えようと目論んでいる。今のシステムだと発電から消費に変わるタイミング（時刻）で、80%くらい（最近は日が長くなってきたので、70%）蓄電されていれば、翌日の発電までバッテリーがもつことがわかってきたので、3月後半からは特に何もしなくても、バッテリー切れの買電は発生していないのだけど、天気の悪い日が続いたり、夜の長い冬や、発電量が下がる時期は、前の日に100%まで蓄電できたとしても、朝までもたない可能性があるので、その時の買電のタイミングを、電気の単価のなるべく安い時間帯にずらそうと考えている。大雑把に言えば、自宅の発電量とLOOOPでんきの単価（30分ごとに変わる）は同期しているので、発電しない時は、単価も高いのだが、天気は地域ごとに違うので、自宅で発電していなくても、どこかで発電していれば単価が最低レベルであったりもするので、調整できる可能性がある。

しかし、蓄電池のAIシステムは、LOOOPでんきのように市場価格を考慮するわけでは無いようです。私としては、この市場連動型プランのようなものほど、AIの力を必要とすると思うのですが、電力会社次第なので、汎用的なバッテリーシステムとしては作りづらいのかもしれませんね。

だとしたら、AIのメリットは何か？ということなのですが、どうやら、このAI蓄電池は、毎日買電する事を前提にしているようです。特に深夜電力の活用が前提になっているようです。

基本的には、発電の余剰電力を蓄電して、それを発電終了後から次の発電までに使うのですが、それが足りなくなりそうな場合に、深夜電力の時間帯に買電して蓄電するということのようです。蓄電池は、充電と放電を同時に行う事は構造的にできませんから、買電するタイミングでは、自家消費と蓄電を合わせた電力を買電することになります。買電した電力を蓄電しながら、自家消費は蓄電池の電力を使うなんてことはできないです。これは太陽光発電時も同じですが。ただし、買電した電力を自家消費のみにして、蓄電池への充電を止めることはできますので、昼間の単価が高い間は、0%で、発電もしていない状態であっても充電せず、深夜電力の時間帯になったら、充電を開始するというような制御をして、なるべく高い単価の電力を買わないようにするようですが、これだけだと以前からある蓄電池のタイマー設定とあまりかわらず、AIは必要なさそうです。ただし、深夜電力で蓄電池が100%になった場合、自家消費分は買電を止めて蓄電池から電力を使うか、深夜電力を使うかは、うまく調整してやると効果があるかもしれません。蓄電池に蓄えられている電力の多くが昼間発電した分であり、かつ翌日には夜に使った分を補うだけの十分な発電量が見込める場合は、買電をストップして、蓄電池の電池を消費した方が、夜間電力の買電量が減りますから、メリットがあります。しかし、翌日期待しただけの発電が無かった場合は、夜間電力より高い昼間の電力を買電することになるかもしれませんから、そこは、天気予報と連動したAIが必要になってくるということなのでしょう。それと、翌日の発電が見込める場合には、深夜電力で100%まで充電せず、発電開始までに十分な残量だけ確保するというような事もするそうです。それやらないとせっかく発電しても、蓄電池は直ぐに100%になって、安い売電にまわってしまいますからね。（FITが高い頃はそれで良かったのでAI無かったし、蓄電池あっても容量は少しで良かったのですけど）

というわけで、その家の電力消費パターンと、翌日の発電予測から、夜間の蓄電池の残量をどうするか（使うか、チャージするか）を判断するのがAIの役目ではないかと思われます。AIと呼んでいる以上、予めパターンが標準的な登録されているかもしれませんが、日々、その家の電力消費パターンと、蓄電池の残りかたなどを学習しながら、少しでも節電できるほうへ調整されていくのでしょう。なので、生活パターンが安定しないお宅には向かないですし、曜日による偏りくらいまでは考慮してくれそうですが、月の中、あるいは季節によって電力使用量に偏りがある場合まで対応されているのかは疑問がありますね。様々なケースで対応してしまうと、それはもうパターンではないということになりますから。私の想像では、基本は曜日別学習で、月末は忙しくなるとか、季節の変わり目は、その状況に応じた調整が完了するまで不安定になるような気がしますが、どうなのでしょうね。

そう考えると、AIは、日々安定した生活パターンを持っているお宅には効果的でも、そうでないお宅には思ったほどの効果は無いようにも思われます。そして、安定したパターンを持っているお宅の場合は、AIというより、多少賢いタイマー設定に天気予報をもとにした発電予測が反映できるものといったものになるかと思います。個人的にはなんでもかんでもAIと呼ぶ今の風潮には少々嫌気が差しています。

AI＝詳しくは説明しないけど、なんとなくうまくやる（はずの）システム

で、実際にどのようにやるかの説明と、うまくできなかった時の責任を回避しているようにも思えるのですよね。

AIと呼ぶのであれば、過去数年分の天気予測、発電予測、実際の発電量と電力消費と蓄電池の状態のデータを蓄積して、そのデータをもとに、NG的な事も含めて様々なパターンをシミュレートして最適解を見つけて、その中から、現在の状況に似ている状況を探してその最適化を適用するようになっていて欲しいのですが、そこまでは期待できそうに無いなぁと思っています。

Grails は、Asset Pipeline というので js / css などのアセットを管理しているけど、例えば、 bootstrap.bundle.js を入れると、設定にもよるが、ビルド時（デバッグ実行時でも）に、自動でminify（難読化）してくれるようで、bootstrap.bundle.min.js とかも同時に入れていても、それではなく自前で難読化されたものを使うらしい。

のだが、この難読化に失敗すると、どういうわけか、bootstrap.bundle.unminified.jsが無いというエラーになってしまう。 bootstrap.bundle.unminified.jsを開発用の bootstrap5 のソースから入れても見てくれない。それどころか、その js を読み込む asset の設定ファイルまで、unminified が無いというエラーになって、収拾つかなくなる。

なんでエラーになるのだろう？

function bootstrapDelegationHandler(element, selector, fn) {
return function handler(event) {
const domElements = element.querySelectorAll(selector);

for (let {
target
} = event; target && target !== this; target = target.parentNode) {

問題は、ここにありました。 let { target } = event; という見慣れない代入がありますが、これは分割代入というもので、 let target = event.target; と似たようなものです。 event が Object の場合に、その、代入先変数名と同じ要素を代入するみたいな処理で、　let { type, target} = event; みたいに{} の中が、複数の場合は便利ですが、一つの場合は、変人コードにしか見えませんので、素直に、let target = event.target;と書けば良いのにと思ってしまいます。

この分割代入が、 for() の中にあると、どうやら、minifier がエラーを起こすようですね。

      let {target} = event;
      for (; target && target !== this; target = target.parentNode) {

の様に、外に追い出したら、一連のエラーもなく、無事 grails prod war できるようになりました。

bootstrapは、5.0から、ずっとこの書き方みたいで、関数が関数なので、今後も変わりそうにありません。 Asset Pipeline プラグインがアップデートすればそのまま使えるようになると思いますが、それまでは、ソースを修正して使うしかないのかもしれません。

使われていなかったポーチライト

新築した時に、明暗センサーを南側の壁に設置する形で、自動点灯のポーチライトを付けてもらいました。ピアノ教室をやっていることと、防犯の為に付け忘れ・消し忘れが怖かったので、そうしたのですが、何年かしてからは、省エネという要素も加わっています。明暗センサーは室内に押しスイッチがあって、それを長押しすると消したり、点けたり（暗いときのみ）ができるようになっているのですが、何年かして明暗センサーが調子悪くなり、取り替えてもらってから、そのスイッチが効かなくなりました。最初の頃は省エネは考えていなかったので、押すことも無かったのですが、ある時から省エネの為に夜中は消そうと思って押しても消えません。新築のときは試しに押して消えたのに変だなと思ったのですが、まさか極めて似たような型番（後ろに1があるかないかの違いしかない）で押しスイッチ非対応の製品があるとは、電気屋も思わなかったのか、先日確認したら、しっかり非対応でした。実は壊れていると思って自分で取り替えようとAmazonで買って気づいたのですが、もう20年くらい気づかず、ツイン蛍光管だったので、家をLED化したときに、LED化することもできず、勿体ないので、蛍光管を外してしまって使っていませんでした。スイッチは無いので、蛍光管を外すしかありません。代わりに、バッテリー式の人感センサーライトを付けていたのですが、ソーラーパネルもついていて充電するので、バッテリーの充電はひと月に1回くらいで済んでいました。

重い腰を上げた

センサーライトは、この手の製品にしては結構丈夫で長持ちで、かれこれ10年以上使っていますが、今でも使えています。それでもだんだん面倒になってきたと、バッテリー切れに気づかずに、暗いままだったりすることもあり、明暗センサーを変えて、ポーチライトも新しくしようと決意して、Amazonで明暗センサーを買いました。ここで、ようやく、明暗センサーが押しスイッチ非対応だったということに気づいたのですが、いずれにしても、今どき蛍光灯ってどうなのよと思ったので、新しいポーチライトを物色していました。パナのがデザイン的に良かったのですが、センサーが付いていて切り替えが壁スイッチの連打みたいなやつなので、壁スイッチが無い我が家は使えず、今のポーチライトの蛍光灯をもぎ取って、代わりにE26ソケットでも付けてやろうかと考えていました。ライトの筐体自体は気に入っていたので。

変換ソケットを発見

発見といっても、我が家のシーリングライトは全部こんなのに変えたのですが、ポーチライトの入れ物が狭いので駄目かなと思っていて、このコンパクトのを発見したので、試しに買ってみた感じです。今日入れ替えてみましたが、無事LED電球が入りました。ラッキーなことに、グローランプ式だったので、グロー外すだけで工事不要でした。（安定期はつながったままなので勿体ないのですけど….）

そして、スマート電球化

ここで、先日自分の部屋のシーリングライト用に買った、SwitchBotのスマート電球を思い出しました。これつければ、ボタンおさなくても、タイマーで自動消灯できるじゃん！ってことで、取り付けてみたところ、ポーチなのでWiFiもつながって、タイマーセットもできました。これで、明暗センサーで自動点灯・消灯する上に、夜中はタイマーで自動的に明るさを落としたり、消したりできるようになりました。

人の出入りがあるときは、明るいほうが良いのですが、夜中はあまり明るいと近所迷惑かもしれないので、多少暗くしてから、消灯で良いかなと思いました。

この電球は、点灯・消灯時に、即時だけでなく、数秒から1時間かけて徐々にという設定ができます。（まぁ、徐々にといっても、LEDなので、あんまり線形ではないのですが）。そんなわけでとりあえず、17時になったら、60分かけて、徐々に明るくして最大まで、21時になったら60分かけて消灯という設定にしてみました。