最新のブログ

Home Assistantの変更により、リロード、再検出、状態の再適用、レジストリの更新、Recorderへの書き込みが発生し、短時間だけ通常の定常状態を超える処理負荷がかかることがあります。

信頼性の高いローカル制御の速度は、Home Assistant CoreやCPU使用率だけでなく、トリガーからデバイスまでの経路に必要なコンポーネントのうち最も遅いものによって決まります。

インターネット接続が失われてもローカル制御は機能し続ける一方で、クラウド呼び出しの失敗によってタイムアウト、再試行、キュー、復旧処理が変化することがあります。

ローカルのHome Assistantオートメーションなら、家全体の制御を、デバイス入力、状態、ルール評価、サービス呼び出し、フィードバックという、テスト可能な一連のイベントフローにできます。

サービスを追加して共有状態、キュー、デバイス、更新サイクル、または障害ドメインが増えると、単にコンテナが増えるだけでなく、Home Assistantのアーキテクチャが変わります。

ウォーム状態での結果は、容量ではなく再利用を示します。コールドスタート、ウォーム時の定常状態、繰り返し負荷、テールレイテンシ、そして最初に飽和するリソースを測定してください。

家全体の自動化の多くは、重複実行数に上限を設けるだけで十分です。実行時間×トリガー発生率で同時実行数を見積もり、その後、下流システムが安全に処理できる容量を上限にします。

同じCoreでも、描画性能、キャッシュの状態、経路、ライブ更新のコストはサーバー処理の後段にあるため、クライアントによって動作が遅く感じられることがあります。