はじめ@Blog

スマートホームが流行りで、Switchbot などの遠隔操作可能なデバイスを使って、自動・手動で家電をコントロールできるようになってきました。

最初スマートコンセントが売り出された時には、「今どきの家電でコンセントの抜き差しでコントロールできるものなんてそうそう無いよ」と思っていましたし、今でもそうなのですが、指ロボットとか、赤外線リモコンの代わりになるデバイスが出てきて、ボタンを押す系のデバイスや、リモコンが使えるデバイスがコントロールできるようになってきて、既存の家電でも操作できるようになってきました。それでも、私はあまり気が進まなかったのですが、電気代（現時点では蓄電池の残量）節約の為に、冬のセントラルヒーティングのボイラーと、ウオシュレットの電源と、給湯ボイラーの電源と、ポーチライトのOFFなど、いくつか自動化したいものがあって、GW中に試してみました。その結果、いくつかわかったことをまとめておきます。

そのデバイスの対応は必要ですか？

まず、最初に考えるべきは、「ほんとにそれ必要？」ということです。スマートホーム化というと家中のデバイスをスマホからコントロールするとか自動化するとかの「夢」を持ちますが、そもそも、今の家電はそれ自体タイマーを持っていたり、節電機能を持っていたり、リモコンが使えたり、bluetoothで専用アプリからコントロールできたりと結構便利なのです。それを、全部まとめる必要はありますか？　例えば、テレビをつけるのに、リモコンのスイッチを押す代わりに、「OK Google テレビをつけて」とわざわざ言わなければならないシチュエーションってどのくらいあるのでしょうか？　朝起きたら、カーテンが開いて、コーヒーメーカーのスイッチが自動で入って、テレビがニュースを流して、家を出る時には、自動で消灯してとか、それって本当に必要でしょうか？　まして一人暮らしでなかったらどうなりますか？　夫が「行ってきます」と出かけたら、まだ妻が家にいるのに、カーテンは閉まり、電灯は消えて、クーラーも止まってなんてなったら怖いことになります。妻が先に家を出るときもあるだろうし、同時のときもあります。家に誰かがいる場合と居ない場合で条件を変えて動作を切り替えられればまだ使いようがあるかもしれませんが、そんな条件は設定できません。つまり「自動で○○したら便利だろうな」には、大きな罠があって、24時間365日便利な一律動作なんてほとんど存在しないのです。そのようなデバイスを自動化したところで、結局何も設定できなくて、せいぜいスマホでスイッチを入れるか、「OK Google」というだけですが、これが、かなり面倒で、その場所に行ったり、自分でリモコンで操作する、今までの操作の方がずっと便利だったりします。朝カーテンが自動で開いて陽の光で起きたいという宣伝文句ですが、ベッドから出て、カーテンを開けるという動作が朝の目覚ましの動作になっている人は、逆に眩しいと思いながら寝続けるかもしれません。太陽と共に暮らしたいなら、カーテンなんて無い方が良いかもしれません。

ハブは必要ですか？

Switchbot を購入する時に最初の疑問は、ハブって必要？ということでした。結論から言うと、買うべきだと思います。特に、温度計と明暗センサーが内蔵されているハブ2は有ったほうが良いです。 スマート電球とか、スマートプラグ（コンセント）などいくつかの Switchbotデバイスは、それ自体、WiFi機能を持っていますが、指ロボットや各種センサーは、Blouetooth接続です。Bluetooth は、かなり到達距離が長くて、我が家の場合玄関ドアの開閉センサーは微妙ですが、他は、トイレの中でもユーティリティでも私の部屋から Bluetoothで状態を把握できます。Bluetoothだけでも、例えば、人感センサーの状態をトリガーにして、ウオシュレットの電源を入れるというくらいはできますが、3つほど困ったことがあります。1つは、反応がめちゃくちゃ遅いです。もう一つは、「シーン」設定が出来ないので、出来ることが限られているということです。3つ目は、通知が来ないということです。最初私はハブを買いませんでしたが、ハブ無しでも結構なんとかなっていたからで、ハブを買った理由は、上記３つの困ったことではなくて、セントラルヒーティングのボイラーをリビングの部屋の温度で、入・切したかったためです。で、温度センサーだけ買おうかなと思ったのですが、セントラルヒーターのボイラーは、ボイラー自体の電源にスマートプラグを入れて、ボイラーのスイッチに指ボットを取り付けたのですが、ハブが無いと、シーンが作れないし、Google Homeなどからもコントロールできないので、どちらかしか操作できません。電源のスイッチを入れてから、指ロボットでスイッチを押すという連続動作ができないのです。ハブがあれば、Switchbotのアプリの「シーン」設定でも、あるいは、Google Home のルーティン設定でもそれが出来ます。（「シーン」設定には、AをしてBをする間に「待機」ができないので、この場合は、ルーティン設定のほうが良いかもしれません）

ですので、結論から言えば、ハブは必要で、どうせ買うなら、ハブ2をお勧めします。ただし、ハブは高いです。

TVや、エアコン、照明機器など確実にOFFできないものがある

リモンコンを見て、OFFというスイッチが無い場合は要注意です。「電源」というスイッチしかない場合、そのスイッチを押した時に、ONになるのか、OFFになるのかがわかりません。TVの前に居ればわかることでも、自動化したり、リモート（外出先）から操作しようとしたときには、今の状態がわからないので、結局使えないです。つまり今のこの手のデバイスでは、TVの電源をOFFにすることすら、できないのです。私がボイラーに設置した指ロボットも同じで、ボタンを押すという操作なので、1回でも失敗したらONとOFFが逆になります。それでも自分でアプリでON・OFFする場合は、スマートプラグが電力使用量を計測してアプリで把握できるので、電力使用量からON/OFFの状態を推測することはできます。スマートプラグが測定できないような電力使用量であれば、常にONでも良いくらいですから、これは使えます。が、「シーン」の設定では、それを条件にできませんから、自動化する場合は、毎回間違わずに指ロボットが働いてくれると信じるしかありません。ONにするときに「1回押す」、OFFにする時に「1回押す」が毎回正確に行われることが条件になりますし、途中で人が指で操作しないようにもしなければなりません。ただし、家の照明のスイッチがトグルタイプのスイッチであれば、指ロボットは「押す」動作ではなく「スイッチ」動作になるので、この場合はON・OFFが明確に把握できます。一般家庭のリビングで、TVもエアコンも照明機器も、確実にON/OFFできないとしたら、全然意味ありませんよね。

照度計の罠

ハブは各デバイスとBluetoothで接続されるので、家の中心に置いたほうが良く、我が家ではリビングに置いています。家の中ならどこでもだいたい同じですが、この状態で、ハブの照度計を使って、シーリングライトのON/OFFができるかというと、出来ません。なぜなら、暗くなったライトをON、明るくなったらOFFと設定すると、暗くなった＝＞ライトがON＝＞明るくなった＝＞ライトがOFF　と無限ループになるからです。照度計を屋外に設置すればコントロールできるかもしれませんが、そんな照度計はありませんし、屋外の明暗ではなく、部屋の明るさでコントロールしたいので、必ずしもそれが一致するとは限りません。加えてその部屋に別の照明があったら、それをつけた途端にOFFになりかねません。LDKの場合Lのライトを自動にしたくても、DやKのライトでオフになってしまったりして、使えないということになります。

家族の存在

自分の生活パターンはだいたい安定していても、それが家族の生活パターンと100%一致しているということは稀です。○時になったらTVをオフとかしたくてもできません。「OKGoogleおやすみ」と言っても、まだ家族が起きているなら自動でどうこうできない場合がほとんどです。すっごい大きな家に一人で住んでて、あれこれやらなければならず、それが大変だという人には便利かもしれませんが、日本の一般家庭で便利だという状況はほとんど無いような気がします。

電源ON/OFFでは、心配な機器が結構ある

例えば、TVは、リモコンにOFFがなくて、電源ON/OFFができないなら、コンセント引っこ抜けば良いじゃんと思う人はどれだけいるでしょうか？　もしかしたら、録画中かもしれないし、そうでなくても、HDDが回転している状態でコンセント引っこ抜いたら、なんか悪い事が起きそうな気がします。ボイラーなどでも、電源OFFからしばらくファンが回っていたりのクーリングアクションがあってから電源が切れるタイプのものは少なくありません。我が家のボイラーもそうです。それがあって、私はボイラーに指ロボットを使うようにしたのですが、指ロボットを使っても、Switchbotの「シーン」には待機が無いので、オフ動作では、プラグをOFFにできません。なのでオンでは、プラグをONにして指ロボットでボタンを押すという設定、オフでは、指ロボットでボタンを押すという設定にして、プラグの方は、気が向いたらスマホで電力使用量をチェックしてOFFになっていそうなら自分でOFFにするしかありません。因みに我が家のボイラーは、OFFでも数ワットの待機電力を消費するので、本当はスイッチOFFならコンセントを抜きたいところですが、スイッチONに比べるとたいした消費電力ではないので、そこまでこだわる意味もないかなとは思います。

要するに、確実にコントロールすることが難しいものが、多々あるということで、どこかで妥協しなければならないため、妥協できないなら、そもそも自動化すべきではないという事も考えられます。

状態がわからない

例えば、玄関から人が入ってきたら在宅で、出ていったら外出かというと、そういう事はなくて、家族全員が外出なのか、誰かが家に居るのか、また、我が家の様にピアノ教室になっている場合は、私でも妻でもなく、生徒さんが出入りするので、結局玄関ドアの開閉だけでは、家の中に誰がいるのかがわかりません。そんな状態で一体何がコントロールできるのでしょうか？　最低でも、私のスマホと妻のスマホの両方が家の中にない場合は、留守だと判断するくらいのアルゴリズムは欲しいところですが、それすらありません。人感センサーが使えるかといえば、Switchbotの人感センサーは、熱検知ではなく動体検知です。熱検知のセンサーでも似たようなものですが、TVの前でじっとしている人、布団に入って寝ている人がいる場合に、「人が居ます」と検知することは稀です。私はトイレに人感センサーを設置してウォシュレットのON/OFFを設定しましたが、座って用を足している時は、数秒で「居ない」になります。そのタイミングで、ウォシュレットがOFFになったら、結局使えません。幸い我が家の２Fのトイレには窓がないので、明るくなったらON、暗くなったらOFFとしましたが、それってもやは人感センサーではなく、明暗センサーということです。玄関に顔認識機能付きのカメラを設置して、出入りを常に把握して、リアルタイムに誰が家にいるのかを把握できるようなデバイスでも出て来ない限り、「シーン」設定は難しいものが非常に多いです。

シーン設定の貧弱さ

Google Homeでは、センサーをトリガーにできませんから、センサーをトリガーにする場合には、Switchbotアプリのシーンを使うしかないのですが、そうなると、このシーン設定の貧弱さがかなりネックになります。待機が無いというのも最悪ですが、状態を保持できない、条件にできないというのも問題です。例えば、状態については、自分で、全員家に居るとか、一人だけ外出中とかを、スマートタグとかを使ってシステム（ハブ経由でクラウド）に知らせることができたとしても、シーンの条件にそれが指定できないのであれば、シーンの自動化はできません。家に誰かいるときは、夜になったらリビングの灯りをつける。の、「家に誰か居る時は」が指定できません。

壁コンセント用の節電スイッチで十分では？

省エネタップ というのものがあります。例えばウォシュレットの場合、座ってから自分でスイッチをONにしても、結構水があたたまるので、十分だと言えます。流石にコンセントの抜き差しを毎回するのは大変だったのですが、このスイッチを取り付けてからは、それでもいいかなと思えるほどで、実際、現在１Fトイレはこれです。と言っても、教室がある時は生徒さんに自分で操作してとは言えないので、基本、外出時にOFFにするだけですが…

我が家の場合

それでも、我が家ではSwitchbot を導入しました。いろいろ諦めた結果、それでも使えそうなところがあったので、そこだけは使おうと思いました。それが次のようなところです。

• 寝室兼仕事部屋のシーリングライト（というか裸電球）をスマート電球に交換（これが最初）
• 玄関のポーチライトをスマート電球に交換　※もともと光センサーでON/OFFするようになっていたが、電気屋がセンサーを間違えて取り付けていて、手動消すスイッチが使えず、朝まで消せなくなっていたので交換（ついでに蛍光灯＝＞LED化）
• 玄関から誰かが入ったら通知　（防犯の為）　※通知だけで何も連動しません。
• リビングの部屋の温度と湿度をスマホで把握　※特に外出先でわかるのは便利です。
• リビングの部屋の温度が 20度を下回ったら、セントラルヒーティングをON
• リビングの部屋の温度が、21度を越えたら、セントラルヒーティングをOFF
• セントラルヒーティングのボイラーの電力消費量をリアルタイムで把握
• ２Fのトイレが明るくなったらウォシュレットをON
• ２Fのトイレが暗くなったらウォシュレットをOFF

これだけです。玄関ドアは、夫婦で外出中に侵入者があった場合だけ、通知の意味があります。ただし、通知があったとしても、警察に通報するなんてできるほどの信頼性はありませんから、電話をかけるとか、シーリングライトをONにするとかして、家に誰かいるように見せたりして撃退するしかありませんが… 基本はASAPで家に帰るということくらいでしょうか。

トイレは、１Fのトイレには窓があって、明暗センサーでコントロールできないので、１Fのウォシュレットは電源入れっぱなしです。GWなど長期で教室がお休みのときや泊まりで外出流の時は、スイッチをOFFにします。ウォシュレット自体には節電モードがありますが、あれはまったく使い物になりません。1日24Hのうち、ウォシュレットを使う時間なんて、30分にも満たないのに、そのために、ずっと水の温度をキープしているのですから、まったくの無駄です。

一応、ハブをリビングにおいているので、「OK　Google　電気をつけて」とか「OK Google TVをつけて」とかの操作は出来るようにしましたが、正直リモコンのほうが便利です。

ライト関係を忘れていたので追記しましたが、もともとは、寝室兼仕事部屋のシーリングライトをスマートバルブに交換したのが最初でした。スマートである必要はなかったのですが、40Wを使っていて、ちょっと暗かったので交換しようと思っていたところスマートバルブが安かったので交換。色も変えられるし、時間指定でON・OFFできるので、目覚ましとか何かの合図代わりにもよさそうだし、時間で消せるのも良いかなと思って。ポーチライトは、明暗センサーがだめになったと思って、何年も使っていなくて充電式のライトを使っていたのですが、めんどうになった為、センサーを替えようと買った時に電気屋が間違った型番のセンサーをつけたので、強制OFFができなくなっていたのでした。新しいセンサーは届きましたが、明暗センサー自体は動いているし、新しいセンサーに変えたところで毎日自分でオフにするのもめんどうだなと思って、センサー交換はせず、蛍光管をソケットかましてスマートバルブに交換しました。ある時間までは 20%、そこから100%、レッスンが終わる時間頃からまた20% としました。明暗センサーは機能しているので、20% -> 100% -> 20% -> OFF となります。スマートバルブにとっては、毎日停電している状態になるので、停電警告が来るのが煩わしいですが、期待通りに動いています。

人感センサー付きLEDバルブ

実は、もう10年以上前から、我が家の廊下とユーティリティは、センサー付きLEDバルブになっています。廊下は、玄関からユーティリティまで３つのバルブがあるのですが、壁スイッチを入れると、玄関側は常時点灯、後の２つは人感センサー付き、ユーティリティも人感センサー付きです。流石に玄関側を人感センサー付きにすると、玄関入った時点で点灯しなかったり、人が通るたびに付いたり消えたりしては、レッスンのじゃまになるので、これは常時点灯にしたのですが、廊下の奥とユーティリティは人感センサーで正解でした。妻のレッスンでは、生徒は外から入ってきたら、まずユーティリティに行って、手を洗ってから教室に入るルールなのですが、常時ついている必要が無いのと、順に点灯するのである種誘導灯的な役割にもなっています。ネットにつながっているわけでも操作でいるわけでもありませんが、これだって、スマート？ホームと言えなくもなく、案外こんなので事足りてしまうことも多いです。

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 プラグインがアップデートすればそのまま使えるようになると思いますが、それまでは、ソースを修正して使うしかないのかもしれません。