投稿

Home Assistantで気付いたこと・分かったこと（Windows 11のスリープには2種類ある）

-
Windows 11のスリープには2種類ある―Modern Standby（S0）ではPing判定に注意 はじめに Home Assistantでは、Ping（ICMP）を利用してPCの起動・停止を判定する方法がよく紹介されています。 私もその方法を試したところ、期待どおり動作しませんでした。 原因を調べると、Windows 11には2種類のスリープ方式があることが分かりました。 Windowsには2種類のスリープがある Windowsのスリープには S3（従来のスリープ） S0（Modern Standby） があります。 項目 S3 S0（Modern Standby） CPU 停止 必要に応じて動作 ネットワーク 停止 一時的に通信することがある Ping 応答しない 応答することがある 自分のPCはどちら？ コマンドプロンプトで powercfg /a を実行すると確認できます。 私のPCでは スタンバイ (S0 低電力アイドル) と表示されました。 つまり、Modern Standby対応PCでした。 Pingでは思ったように判定できなかった Pingを監視すると、 PCがスリープしているにもかかわらず、 接続 ↓ 切断 ↓ 接続 ↓ 切断 を繰り返していました。 そのため、 「スリープした」 ことを正しく判定できませんでした。 HASS.AgentのSessionStateを試した そこで、 HASS.Agentの SessionState を利用してみました。 取得できた状態は Unlocked Locked unavailable でした。 SessionStateは安定していた 気付いたこと 気付いたこと SessionStateを確認すると、 Pingのような 接続 ↓ 切断 ↓ 接続 という繰り返しは発生しませんでした。 スリープ中は安定して状態を維持し、 Pingよりも安定してPCの状態を取得できることが分かりました。 気付いたこと 今回分かったことは次のとおりです。 WindowsにはS3とS0（Modern Standby）の2種類のスリープがある。 Modern Standbyではスリープ中でもネッ...
コメントを投稿
続きを読む

Home Assistantで気付いたこと・分かったこと（開発者ツールや履歴の状態表示と、オートメーションの状態候補は一致しないことがある）

-
イメージ
  開発者ツールや履歴の状態表示と、オートメーションの状態候補は一致しないことがある はじめに Home Assistantでオートメーションを作成するとき、状態トリガーを利用することがよくあります。 今回、状態トリガーを設定している中で、開発者ツールや履歴に表示される状態と、オートメーションの状態候補が必ずしも一致しないことに気付きました。 最初は設定方法を間違えたのかと思いましたが、確認を進めるうちに、表示方法に違いがあることが分かりました。 状態は3か所で表示される 今回の検証では、状態は少なくとも次の3か所で確認できました。 開発者ツールの状態 off 、 unavailable 、 Unlocked など、英語の状態値が表示されます。 履歴 状態の変化を確認できます。 英語のまま表示されるものもあれば、「切断」「接続済み」など日本語表示になるものもあります。 オートメーションの状態候補 状態トリガーで選択する候補です。 一部は日本語表示されていますが、すべての状態が表示されるわけではありません。 この3か所の表示は、必ずしも一致しませんでした。         開発者ツール（状態の例） off    unavailable    on    Unlocked    …       （英語の状態値）                  ↓                  ↓            履歴（表示例） off    切断    接続済み    Unlocked    …  （英語と日本語が混在）               ...
コメントを投稿
続きを読む

SwitchBotロックの解錠をHome Assistantで自動化してみた

-
イメージ
はじめに 我が家では、玄関の鍵としてSwitchBotロックUltraを使用しています。 以前から、Home Assistantと連携して玄関の解錠をオートメーション化したいと考えていました。 しかし、SwitchBotアプリでは施錠はオートメーションに設定できますが、 解錠はオートメーションの対象外 となっています。 これは、意図しない解錠による防犯上のリスクを考慮した仕様だと考えられます。実際、解錠を自動化すると、センサーの誤検知や設定ミスなどにより、意図せず玄関の鍵が開いてしまう可能性があります。 一方、Home Assistantでは、SwitchBot Cloud APIを利用することで、SwitchBotロックの**「アンロック」**をオートメーションのアクションとして利用できます。そのため、SwitchBotアプリでは実現できない解錠の自動化が可能になります。 ただし、これはSwitchBotが安全性を考慮して設けている制限を利用者自身の判断で回避することになります。 そのため、 便利だからという理由だけで導入するのではなく、どのような条件で解錠するのか、誤動作が起きた場合にどのような影響があるのかを十分に検討したうえで運用することが重要 です。 私自身も、この方法が「安全」だとは考えておらず、現在も運用しながら条件の見直しを続けています。 この記事では、私が実際に構築・運用している環境を例に、 SwitchBotロックの解錠をHome Assistantでオートメーション化する方法 を紹介します。 Home Assistantの導入方法については、以前公開した記事をご覧ください。 Windows 11 Hyper-VでHome Assistantを動かす方法（2026年版） この記事では、SwitchBot Cloud APIの設定からHome Assistantとの連携、解錠オートメーションの作成まで、実際の画面を使って順番に説明します。 動作環境 今回使用した環境は次のとおりです。 Home Assistant SwitchBot Hub Mini SwitchBotロックUltra（2台） SwitchBot Motion Sensor FA SwitchBot Cloud API ...
コメントを投稿
続きを読む

Home AssistantでTapo P105をオートメーションから操作する方法

-
イメージ
はじめに 私のデスクトップPCにはLogicool Z407スピーカーを接続しています。 普段は問題なく使えていますが、PCがスリープすると、スピーカーから「ボッ、ボッ」という音が一定間隔で鳴ることがありました。スピーカーの電源を切ると音は止まるため、PCの起動時は電源を入れ、スリープ時は自動で切る方法を考えました。 そこで利用したのが、TP-Linkのスマートプラグ「Tapo P105」です。 Home Assistantからオートメーションで制御できれば、PCの状態に合わせて自動でON/OFFできます。 この記事では、その設定方法を紹介します。 動作環境 Home Assistant TP-Link Tapo P105 Tapoアプリで初期設定済み Home AssistantとP105が同じネットワークに接続されていること 最初に知っておきたいこと インターネットで調べると、PythonライブラリやPowerShellなどを利用してTapo P105を操作する方法が紹介されています。 しかし、 現在はそのような方法を利用する必要はありません。 Home Assistant標準の TP-Link Tapo 統合を利用すれば、オートメーションから簡単にON/OFFできます。 TP-Link Tapoを追加する Home Assistantで 設定 → デバイスとサービス を開きます。 **［統合を追加］**をクリックし、 TP-Link Tapo を検索して追加します。 TP-Link ID（Tapoアプリで使用しているメールアドレス）とパスワードを入力すると、P105が自動的に検出されます。 P105が追加されたことを確認する 追加が完了すると、P105がデバイスとして表示されます。 この画面では、 スイッチの状態 ファームウェア Wi-Fiの電波強度 関連するオートメーション などを確認できます。 今回の例では、「スピーカーの電源」という名前で登録しています。 オートメーションを作成する 新しいオートメーションを作成します。 アクション で デバイス を選択します。 続いて、 デバイス： スピーカーの電源 アクション： オンにする を選...
コメントを投稿
続きを読む

Home Assistantで気付いたこと・分かったこと（スリープ中でもPingセンサーは一瞬だけ反応することがある）

-
スリープ中でもPingセンサーは一瞬だけ反応することがある はじめに PCのスリープと起動に合わせて、スピーカーの電源を自動でON・OFFするオートメーションを作成しています。 トリガーにはPingセンサーを使用しています。 動作はほぼ期待どおりでしたが、ログを確認していると気になる現象がありました。 スリープ中なのに接続済みになる PCをスリープすると、Pingセンサーは off になります。 ところが、そのままログを見ていると、スリープ中にもかかわらず、一瞬だけ on になることがありました。 もちろん、その直後には再び off に戻ります。 毎回発生するわけではなく、間隔も一定ではありませんでした。 最初に考えた方法 最初は、この一瞬の on を無視するため、 「offが30秒続いたらスピーカーをOFFにする」 という設定にしました。 これでも問題なく動作します。 ログを見直して気付いたこと その後、何度もログを確認していると、もう一つ気付いたことがありました。 スリープ中には一瞬だけ on になることがあります。 しかし、 起動したときに、一瞬だけoffになることはありません。 つまり、誤判定が起こるのは ON側だけ でした。 現在の設定 そこで、オートメーションを次のように変更しました。 PCがスリープしたら、すぐにスピーカーをOFF Pingセンサーが on の状態で5秒続いたらスピーカーをON この設定にしてからは、誤ってスピーカーがONになることはなくなりました。 しかも、起動時の反応も速くなりました。 おわりに オートメーションを作るときは、「何秒待つか」を先に考えてしまいがちです。 しかし、実際にログを確認すると、どちらの状態で誤判定が起きているのかが見えてきます。 今回もログを見直したことで、待ち時間を入れる場所を変更し、よりシンプルなオートメーションにすることができました。
コメントを投稿
続きを読む

Home Assistantで気付いたこと・分かったこと（PCのスリープ検知にはPingセンサーが向いていた）

-
  PCのスリープ検知にはPingセンサーが向いていた はじめに Lenovo PCがスリープしたらスピーカーの電源を切り、起動したら再び電源を入れるオートメーションを作っています。 以前は正常に動いていましたが、設定を見直す中でPCの状態を device_tracker で判定するよう変更しました。 ところが、PCをスリープしてもスピーカーの電源が切れません。 アクションは正常だった 最初にオートメーションの「アクションの実行」を試してみました。 スピーカーの電源は正常にON・OFFします。 つまり、問題はアクションではなく、トリガーにあることが分かりました。 device_tracker を確認する 開発者ツールで device_tracker の状態を表示したままPCをスリープさせました。 2分以上待っても状態は home のままで変化しません。 これではオートメーションは実行されません。 Pingセンサーを確認する 以前使用していたPingセンサー（ binary_sensor ）も確認してみました。 こちらはPCをスリープすると約30秒で off になり、起動すると on に戻ります。 そこでオートメーションのトリガーをPingセンサーへ変更したところ、以前と同じように動作するようになりました。 もう一つ分かったこと ログを見ていると、PCがスリープしている間でも、Pingセンサーが一瞬だけ on になることがありました。 そのため最初は、 「offが30秒続いたらスピーカーをOFFにする」 という設定にしました。 しかし、さらにログを確認すると、 スリープ中に一瞬だけ on になることはある。 起動時に一瞬だけ off になることはない。 ということが分かりました。 そこで現在は、 スリープしたらすぐスピーカーをOFF onが5秒続いたら スピーカーをON という設定にしています。 こちらの方が反応も速く、安定して動作しています。 おわりに 同じPCの状態を表すエンティティでも、今回の環境では動作に違いがありました。 実際に状態を確認しながら比較した結果、PCのスリープや復帰を検知する目的には、Pingセンサーの方が期待どおりの動作になりました。
コメントを投稿
続きを読む

Home Assistantで気付いたこと・分かったこと（Hyper-Vで「別のプロセスが使用中です」の原因）

-
Hyper-Vで「別のプロセスが使用中です」の原因 はじめに Home AssistantをVirtualBoxからHyper-Vへ変更することにしました。 仮想マシンの作成は順調に進み、最後に起動ボタンを押したところ、 別のプロセスが使用中です というエラーが表示されました。 Hyper-Vを使い始めて最初に遭遇したトラブルです。 最初はHyper-Vの設定を疑った エラーメッセージを見ると、「仮想マシンの設定が間違っているのだろう」と考えるのが普通だと思います。 私も、 Secure Bootの設定 自動チェックポイント VHDXファイルの指定 仮想マシンの作り直し など、Hyper-Vの設定ばかり確認していました。 しかし、何をやっても状況は変わりません。 エラーメッセージをもう一度考えてみる ここで一度立ち止まり、エラーメッセージをそのまま読んでみました。 「別のプロセスが使用中です」 Hyper-Vの設定が間違っているのであれば、「設定が不正です」や「起動できません」といったメッセージになるはずです。 しかし、このメッセージは**「誰かが使っている」**と言っています。 それなら、Hyper-V以外の何かがVHDXファイルを開いている可能性があるのではないかと考えました。 Windowsが使っていた そこで、PowerShellでVHDXの状態を調べてみました。 Get-DiskImage "C:\Hyper-V\HomeAssistant\haos_ova-18.1.vhdx" すると、 Attached : True と表示されました。 つまり、WindowsがVHDXをディスクとしてマウントしていたのです。 Hyper-Vも同じファイルを使おうとしていたため、 別のプロセスが使用中です というエラーになっていました。 解決方法 WindowsからVHDXを切り離します。 Dismount-DiskImage -ImagePath "C:\Hyper-V\HomeAssistant\haos_ova-18.1.vhdx" 再度確認すると、 Attached : False になりました。 この状態でHyper-Vを起動すると、Home Assistantは問題なく起動しました。 今回の気付き 今回、一番印象に残っ...
コメントを投稿
続きを読む