2025年のHome Assistant活用法
(vpetersson.com)- 7年間にわたるHome Assistant運用の経験は、Raspberry PiとSQLite中心の小規模な自動化から、ホームサーバーVM、MySQL、InfluxDBベースで100台以上のデバイスを構成する環境へと拡大した
- 新しい家では部屋と照明が増え、ほぼすべての電球がHome Assistantに接続され、スマート照明はすべてIKEA製品で統一された
- 照明の自動化はFluxからHACSのAdaptive Lightingへ移行し、時間帯ごとの色温度と明るさをより細かく制御しているが、各light entityを個別に列挙しなければならない設定上の負担は残っている
- Cursorは、Home Assistant APIから照明機能を分析するカスタムパーサーとYAML生成を支援し、反復的な設定作業とデバッグ時間を減らしている
- 次の段階は、ZigbeeベースのスマートTRVをラジエーターに取り付け、Nestの温度データを活用して部屋ごとの暖房をHome Assistantで制御することだ
小さなアパートの自動化からホームサーバーVMへ拡張
- Home Assistantの利用は、小さなアパートでIKEA Smart Hubを使って照明をまとめる程度の構成から始まった
- 自動化に慣れてからは、温度・湿度センサーのようなカスタムハードウェアも自作し始めた
- デバイスと自動化が増えるにつれて、Raspberry Piベースの運用は限界に近づいた
- 標準データベースのSQLiteが大量のセンサーデータを扱う際のボトルネックになった
- Home Assistant専用ハードウェアは使ったことがないため評価はしていない
- 現在の構成はホームサーバー上のVMへ移行している
- Home AssistantのメインデータベースはMySQLへ移行した
- 長期メトリクスと履歴データ用にInfluxDBサーバーを別途用意している
- ホームサーバー構成は別記事にまとめられている
新居で100台以上のデバイスへ拡大
- 家へ引っ越してから、部屋、照明、全体のデバイス数が大きく増えた
- 現在はHome Assistantに100台以上のデバイスが接続されている
- スマート照明はすべてIKEA製で、家のほぼすべての電球がHome Assistantに統合されている
FluxからAdaptive Lightingへ移行
- 照明自動化の中核機能はAdaptive Lightingだ
- 以前は、時間帯に合わせて照明を同期する古い方式のFluxを使っていた
- 関連設定はHome Assistant, Flux, sensorsガイドにまとめられている
- 現在はHACS（Home Assistant Community Store）経由で提供されるAdaptive Lighting統合へ移行した
- 新しい統合は、1日の中で色温度と明るさをより精密に制御する
- 設定で最も面倒なのは、FluxもAdaptive Lightingもlight groupを対象に指定できないことだ
- 一緒に管理したい照明が数十個あっても、設定ファイルに各light entityを明記しなければならない
- 1つのグループを指定すれば、その中の照明を自動処理できる方式のほうが便利だったはずだ
- すべての電球がIKEA製でも、対応機能はそれぞれ異なる
- Adaptive Lightingを正しく動作させるには、電球カテゴリごとに別設定が必要になる
- 目標は、朝と夕方には暖かい黄色、日中はより冷たい白や青へとなめらかに切り替わる色温度の自動切り替えだ
CursorでYAML設定作業を短縮
- 今年の大きな変化は、Cursorを使ってHome AssistantのYAML設定における反復的で煩雑な作業を処理したことだ
- Home AssistantのDSLや設定ファイルの細部をすべて習得する時間がなかったため、AIコーディング支援ツールを設定作業に活用した
- 最初に作ったのは、すべての照明をパースして電球の種類と機能を分析し、デバッグ情報を出力するカスタムスクリプトだった
- このスクリプトはHome Assistant APIに接続して、照明を機能別に分類する
light.で始まるentityを収集する- 現在の状態、明るさ、色温度、対応色モード、対応機能を確認する
- Adaptive Lightingの設定と照明機能が一致しないときに警告を出力する
- 点灯中の照明の最小・最大・平均明るさと、照明タイプ別の一覧を出力する
- 作業フローは3段階に整理できる
- Home Assistant環境でカスタムパーサーを実行し、電球と機能の一覧を生成する
- 出力結果と既存設定をCursorのagent modeまたは類似モードに入力する
- Cursorが新しいAdaptive Lightingシステム用のYAMLを生成する
- 問題が起きた場合は、Home AssistantのログをCursorに入力してエラー修正を依頼する形で、デバッグ支援も受けている
IKEA電球ごとのAdaptive Lighting設定
- 広範なテストの後、IKEA電球のタイプごとにAdaptive Lighting設定を最適化した
-
Dimmable white spectrum
- 対象は LED bulb GU10 345 lumen, smart/wireless dimmable white spectrum 電球
- 設定例では
min_brightness: 50,max_brightness: 100,min_color_temp: 2202,max_color_temp: 4000を使う sleep_brightness: 1,sleep_color_temp: 2202,transition: 45,interval: 90,initial_transition: 1,prefer_rgb_color: falseが含まれる
-
Dimmable color and white spectrum
- 対象は LED bulb E27 806 lumen, wireless dimmable color and white spectrum/globe opal white 電球
- 設定例では
min_brightness: 70,max_brightness: 100,min_color_temp: 2000,max_color_temp: 6535を使う sleep_brightness: 1,sleep_color_temp: 2000,transition: 45,interval: 90,initial_transition: 1,prefer_rgb_color: falseが含まれる
-
Dimmable warm white
- 対象は標準的な LED bulb GU10 345 lumen, smart/wireless dimmable warm white 電球
- 色温度設定なしで、明るさ中心に
min_brightness: 50,max_brightness: 100,sleep_brightness: 1を使う transition: 45,interval: 90,initial_transition: 1が含まれる
次の段階: ZigbeeスマートTRV
- 照明自動化が安定して動作した後の次のプロジェクトは、すべてのラジエーターをZigbeeベースのスマートTRVへアップグレードすることだ
- 目標は、中央のNestサーモスタットの温度データを読み取り、各部屋が適切な温度を維持できるようにすることだ
- 古いイギリスの住宅は温度制御が細かくないため、ラジエーターごとの調整は快適性と効率を高められる
- すでにTRVは購入しているが、まだ設定していない
- 計画している構成は次のとおり
- TRVをZigbeeネットワークにペアリングする
- Nestサーモスタットから温度データを取得する
- 各部屋の目標温度に応じてラジエーターバルブを開閉するHome Assistant自動化を作成する
- 期待している結果は、一部の部屋は暑すぎて、別の部屋は十分に暖まらないという、イギリスの住宅でよくある問題を和らげることだ
1件のコメント
Hacker Newsの意見
Home Assistantの創業者です。プロジェクトや Open Home Foundation について気になることがあれば質問してもらって構いません
現在はOpen Home FoundationがHome AssistantやESPHomeなどを所有しています
月次リリースは良いのですが、毎回破壊的変更があると負担が大きくなります。破壊的変更を年1回か2回に制限すれば、ユーザーが追従しやすくなると思います
毎回、破壊的変更の一覧を読もうとはしていますが、数カ月間HAに触らないこともあります。その後ログインし直すと、確認すべき変更が大量にたまっていてアップグレードを先送りしてしまい、問題がさらに大きくなります。破壊的変更のないアップグレードが明確に分かれば、最新状態を保ちやすくなるはずです
そうしたデータ収集大企業はこの技術を好まないでしょうが、実際に停止命令書のような圧力や、防御を迫られた事例がどれくらいあったのか気になります
新しいデバイスを追加して位置と役割を説明すると、HAが既存の自動化に自動で統合したり、ほかのセンサーと組み合わせたりしてくれるとよさそうです。ここに LLM を活用することもできそうです
例えば、新しい漏水センサーをランドリールームに設置したと言えば、漏水時の通知自動化を作ってくれて、リビングの温度センサーを追加すれば、ほかのセンサーと合わせてリビングの平均温度を更新してくれるとよいと思います
Bermuda[0]というプロジェクトはBluetoothデバイスを基に、人がエリアに入ったり出たりするイベントを発生させますが、Shellyスイッチで追跡されるスマートフォンのテストではうまく動作しています。ただ、そのイベントで実際の動作をさせる方法を見つけるのが難しいです
エリアごとの自動化を一つひとつ作るのではなく、「日没後に誰かが入ってきたら、そのエリアの照明を20%で点ける」のように言えると、もっとよさそうです
[0] https://github.com/agittins/bermuda
約10年前に KNXベースの家 を作り、今でもかなり満足しています
スマートフォンに照明スイッチを入れたからといって賢くなるわけではなく、たいていは複雑になるだけです
最も価値があった自動化は、自動ブラインド、暗いときに動きがあると点く部屋ごとの照明、ナイトモードです。ブラインドは日差しが強すぎると下がり、外が暗いと下がり、風が強すぎると上がります。おかげで出勤後に過熱したリビングへ帰る心配がなく、エアコンも不要でしたが、冬と春には直射日光を自動で取り込めます
おもちゃのような自動化もあります。空き部屋ではブラインドを完全に閉め、人がいると半分ほど傾け、太陽の角度に合わせて直射日光なしに自然光を最大化します。テレビを点けると反射が出る背面のブラインドが下がり、テラスのドアを開けるとブラインドを開け、室内灯を消して蚊を引き寄せにくくします。シャワールームのモーションセンサーは換気を強め、一部のコンセントはクリスマスライト用にオン・オフし、家電・水・換気・暖房のログも残します
KNXの低レベル機能が中央ハブなしで動作する点は気に入っていますが、高レベル機能には追加の知能が必要なので、今年Home Assistantへ移行する予定です
単体のシンプルなモーションセンサーだけでも、より低コストでWi-Fi依存なしに、スマートホームのかなりの部分を実現できそうに思えます
Home Assistantは本当に好きですが、とても楽しい 趣味 に近いと思います
メンテナンス、ダッシュボード設定、無線ローカルネットワーク標準の統合をしていると、あっという間に技術的な作業になります。それでも使っているうちに、オープンな管理プラットフォームを持つ家庭用機器を好むようになりました
ちょうどよいオタク向け機器を買いさえすれば、スマートホームをクラウドの外に置いたまま、優れた自動化を作れるのではないかという感覚がずっとあります
HAとそのエコシステムの本当の目的は、オープンな管理プラットフォームを後押しすることにあると思います。Matterがマイクロコントローラー側のIPv6採用を推し進めているのと似ています
毎年年末にAliExpressで安い機器を買って分解していますが、2024年にはメーカーがGPIOピンのラベルやプログラミングインターフェースの露出を、ほとんど自慢しているのを初めて見ました。望めば独自ファームウェアを載せられ、WLEDを標準サポートすると宣伝しています。自由なオープンソース、DIY、「あなたのクラウドではなく、家に自分のクラウドがある」運動に、メーカーが実際に歩み寄り始めたのは新しいことです
今では数百台のデバイスが接続されていますが、使っているクラウド統合は明白な理由でSpotifyだけです。スマートデバイスを買うときは完全にオフラインかどうかを注意深く見て、スマートではあってもオフライン専用でなければ「賢くない」家電に限定します
例えば、新しい食器洗い機にはWi-Fi接続時のスマート機能がありましたが、メンテナンスメニューを見つけてネットワークインターフェースを完全に切り、今では普通の食器洗い機としてだけ使っています。それが気に入っています
そのおかげでSiriと自然に統合され、非技術者でも簡単に制御できると同時に、より強力な自動化も使えます
例えば在宅検知機能は、実際にはHAから公開したバイナリセンサーを反転させるHomeKit自動化として動作しています
最も重要な原則は、「スマートさ」を追加機能として位置づけ、家とやり取りする通常の方法は変えないこと
配偶者に受け入れてもらいやすくし、訪問客、とくに両親のような年配者を戸惑わせないため
具体的には、照明スイッチは期待どおりに動作すべきで、TRVで温度を調整できるべきであり、HAインスタンスが落ちても基本機能は動き続けるべき
そのため一部の部屋にはモーションセンサーを置き、深夜0時以降はメイン照明や小さなランプを点けるが、照明スイッチは常にメイン照明をオン/オフする。X分間動きがなければすべての照明が消える
母が夜に寒いと感じたら、これまで一生やってきたようにダイヤルを回すだけでいい。アプリも、TRVのタッチボタンも、「hey Google……いや、ソリ？ Siri？ 息子よ助けて！」も不要。スマートさは全体のスケジュールと、手動調整後15分間動きがなければTRVを再びスケジュールに戻すモーションセンサーにある
そのためスマート電球ではなく照明スイッチの中にリレーを入れ、分離モードにはしない。TRVにはダイヤルがあるので、当然この方式が可能
電源が戻ると最後の状態に復帰するものもあれば、基本的な普通の照明状態で点灯するものもある。こうしたオプションや、電源復帰時に消灯状態を維持する設定などを簡単に変えられるので、より高価なスマート電球を買い続けてしまう。たとえば寝室の照明が夜中の停電後に「パッ」と点いて起こされることを避けられる
電球がきちんと対応していなくても、ハブが照明がネットワークから消えて戻ってきたことを検知すれば、ソフトウェアで有用なデフォルト状態をある程度まねできる
家ではこの程度の自動化を減らしているところ
多くても、主な生活空間全体のシンプルな非スマートLED電球をオン/オフし、明るさを調整するスマートパネル程度だけを考えている
今は当時高価だったGU10 LIFX電球が14個あるが、もう入手しにくく、Wi-Fi設定が変わった後は壁スイッチでオン/オフする形でまともに運用されていない。電球を手動で初期化して取り外し、その後ゆっくり苦痛を伴いながらWi-Fiに再登録するのが面倒だったからだ。そもそもこのインフラ専用に変更しないSSIDを使っていればよかったので、自分で招いた苦労も大きい
スマート電球がただの電球になっている間、実際に明るさを下げたり色を変えたりスマート機能を使ったりする必要はほとんどなかった。結局、良いアイデアのように見えるが、「明かりを点ける」という単純なことを考えすぎたのだと思う
たとえばスマート電球は、家の中で最も明白で正しい制御手段である照明スイッチを台無しにするので愚かだ。スマートスイッチのほうがはるかに良い発想であり、ほとんどの場合、部屋に入るときにスイッチを押して照明を点けるのが最良のタイミングだという現実を認めている
モニタリングは本当に有用になり得るし、控えめな予約制御も良いが、人々はあまりにも愚かにやりすぎている
else条件は欲しくないし、自分がxやyをしたときに照明が点くのも望んでいない。センサーはAliExpressで安く豊富に手に入り、esp32-s3のようなものがあればよい
スマートホームは事前定義された条件どおりに動作するのではなく、自分の必要を動的に予測すべきであり、「リビングを赤にして」以上のものであるべき
そうすれば既存の2.4GHzがIoT用になる
明かりを点けるために、中国のサーバーであれ自分のLANの外のどこかにあるサーバーであれ、必ず通信するよう求める「スマート」機器が多すぎるのは残念
Home Assistantの99ドルのハードウェアは非常によく動作する
一部の機器はおしゃべりだが、初期設定の2行で大半をフィルタリングでき、有用な機能を失うこともない
リビングで生成されるデータがeMMC上のSQLiteを圧倒するなら驚きだ
Home Assistantは、最近の製品の中でセットアップ過程が楽しいと感じた数少ないものの一つ。ネットワーク上で見つけた妙な機器の数は印象的で、複数のクラウドベンダーがロックをかけ始めたことで、そのうちいくつかが消えていく数はさらに印象的だった。今後の購入判断にも確実に影響し、構成をシンプルにするきっかけにもなった
SQLiteが本当に耐えられないのか疑問。問題はデータベース自体というより、設定やコード側にあるように思う
古いRaspberryでも毎秒数千件の書き込みは処理できるはず
この用途なら、センサー種別ごとに独自の書き込みキューを作り、まとめて挿入してもよい可能性が高い
単一の家庭がSQLite[0]を圧倒するほどだとは想像しにくい。同時に書き込もうとする機器が何千台もあり、キューで順番待ちできない場合でなければ、そうはならないはず
[0] https://sqlite.org/whentouse.html
当時はPi 3で、今なら改善しているかもしれず、SQLiteの性能改善もあったことは知っている。ただ自分の場合、時系列データはInfluxへ、データベースはMySQLへ移したら解決した
そしてどれほど良いSDカードでも、これだけ大量に書き込めば最終的には壊れる
おそらくデータベースが非常に遅いmicroSDカード上にあったことが問題だったのかもしれない
Home Assistant がどれほど優れていて、さらに良くなっていくとしても、結局はアップデートを受け取れてネットワークにつながっているデバイスを10台、20台、50台以上管理することになる
Wi-Fi であれ Zigbee であれ、それぞれ問題があり、互いに干渉したり、単に故障したりもする
可能性は魅力的で、時には安心感もあり、人に見せるにも良いが、個人インフラがどれもそうであるように、サンクコストとともに、だんだん気持ち悪さと後悔が大きくなっていく
WebAssembly は、継続的なメンテナンスを必要としないプラグインを作るうえで、かなり妥当な可能性に見える
HA には興味があるが、今は HomeKit と Homebridge を使っており、デバイスの追加や再設定の間はほとんど触らない
原文の筆者とほぼ同じ段階を数年前にたどり、同じ結論に到達しているのを見ると良い気分
VM 方式の代わりに専用ハードウェアを買った。重要ではない作業を動かすホームサーバーから完全に独立させたかったため。Minisforum のミニ PC を買い、HA には性能・RAM・ストレージが過剰なほどだが、もともとそういうもの
100台を超えるデバイスを使いながら MariaDB と Influx に切り替え、暖房も数年前に解決した。家のすべての部屋に BLE 温度センサー Switchbot Meter Plus を置き、各ラジエーターには Z-Wave TRV を取り付けた。値を上階と下階に昼/夜基準でまとめ、ホームオフィスの例外を設けたうえで、一種の平均温度を計算している
ヒステリシスを作るスクリプトで、平均温度が設定温度 -0.2°C より低ければ暖房全体をオンにし、設定温度 +0.3°C より高ければオフにする。各部屋には個別の設定温度があり、室温が設定値を超えると TRV をオフにし、下がると再びオンにする。ここにも弱いヒステリシスを入れている
状況に応じて異なる設定温度と部屋ごとのオン/オフを適用する、昼/夜/外出モードの自動化もある
照明には Circadian Lighting を使っており、照明グループをサポートしているので、yaml にグループだけ指定すればグループ全体を処理してくれる。Adaptive Lighting プラグインの一部機能は足りないかもしれないが、電球の種類の違いを気にする必要はなく、Hue が80%で、IKEA の白色・カラー電球が混在している
なぜかは分からないし、正直あまり時間はかけていない。暖房のアイデアは良さそうなので見てみるつもり
制限が多かったり出来の悪かったりするスマートホームアプリから抜け出す用途だけに HA を使うつもりだったが、家で約6か月いくつかの用途に使ってみて、とても気に入っている
今年はスイッチやセンサーなどで本格的に拡張することになりそう
いちばん深く取り組むプロジェクトは、ゲーム機、電圧変換器、モデム、ルーター、HA マシン、レーザープリンターなどの技術機器が入っている IKEA の収納棚の中に、温度感応型の PWM ファンを配線して過熱を防ぐこと。始めるのが楽しみ
そのほかには、ワイヤレスの植物用水分センサー、ブラインド・カーテン管理、微粒子・VOC・CO2 に基づく換気管理といった計画がある
スマートロックやドアホンカメラ、一般的なカメラにはあまり惹かれない。少し不気味だが、魅力は理解できる
ドアホンカメラは、ドアの近くまで来てベルを押す前から何人が近づいているかを TTS で知らせるように設定した。ベルを押さずに玄関前へ荷物を置いていく配達員にも良いし、全体的なセキュリティにも役立つ