Home Assistantのデータパスとは何か、そしていつ重要になるのか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

What Is the Home Assistant Data Path, and When Does It Matter? - Zima Store Online

Home Assistantのデータパスとは、デバイス情報がリアルタイムの状態、オートメーションの判断、保存履歴、クライアント画面、そして外部への制御へと変わっていく順序のことです。

これは単一のデータベースパイプラインではなく、すべてのアクションですべての段階が実行されるわけでもありません。Recorderが履歴を確定する前に、現在の状態やイベントを使ってリアルタイム制御を行うことができます。一方、ダッシュボードはリアルタイムのWebSocket更新と履歴クエリを組み合わせる場合があります。システムが遅く感じられるときに別々のパスとして考えることが重要なのは、同じエンティティに関係していても、遅延したグラフ、遅いオートメーション、反応の遅い物理デバイスが、それぞれ異なる層に起因する可能性があるためです。

リアルタイムパスはデータベースではなくインテグレーションから始まる

インテグレーションはデバイスやサービスから情報を受け取り、それをエンティティ、状態更新、イベント、アクションとしてHome Assistantに公開します。Coreは、こうしたリアルタイムの変化にすぐ反応できます。データベースは、現在のセンサー値を取得するためにオートメーションが毎回クエリしなければならない権威データ源ではありません。そのため、データベースの遅延とリアルタイム制御の遅延は、初めから同一のものとして扱うべきではありません。

ソフトウェアアーキテクチャに関する研究では、Home Assistantをイベントバス、状態機械、サービスレジストリを中心に説明しています。この構造がリアルタイムパスを説明します。入力はイベントまたは状態になり、オートメーションがそれを監視し、サービス呼び出しは長期履歴を経由するラウンドトリップを必要とせず、インテグレーションを通じて外部へ送られます。

この違いは、ハードウェアを議論する際の最初のアンチマーケティング原則です。「より高速なデータベース」が自動的に「より速い照明スイッチ」を意味するわけではありません。遅延している処理が実際にRecorder、履歴クエリ、起動時の復旧、共有ストレージの競合に依存している場合には効果があります。しかし、遅い無線、ブロックされたイベントループ、クラウド経由のデバイスを置き換えるものではありません。

現在の状態と履歴状態は異なる役割を担う

Home Assistantでは、ダッシュボードやオートメーションが現在の状態を把握できるよう、現在の状態をメモリ上で保持する必要があります。Recorderは、履歴、アクティビティ、統計、分析のために変化を時系列で保存します。そのため、同じセンサー更新が両方のパスに影響することはありますが、リアルタイム状態と永続化された行では、遅延と耐久性に対する要件が異なります。

データベースに焦点を当てたHome Assistantガイドでは、Recorderストレージは1つのサブシステムであると説明されており、その媒体、保持期間、データベースエンジンが履歴とI/Oの挙動に影響します。また、データベースの変更をプラットフォーム全体に対する万能な高速化策として扱わないよう明確に警告しています。

トラブルシューティングでは、この境界が重要になります。ダッシュボードの現在値がすぐに変わるのに履歴グラフの読み込みが遅い場合は、履歴パスを調べてください。グラフを開く前から物理デバイスの反応が遅い場合、データベースは関係ない可能性があります。大量の書き込み中に両方が遅くなるなら、共有ストレージやホストの競合によって、間接的にパス同士が影響し合っている可能性があります。

クライアントは別個のシリアライズおよびレンダリングパスを追加する

ブラウザやコンパニオンアプリは、サーバーの状態、設定、ダッシュボード定義、アイコン、カスタムカード、継続的な更新を受け取り、それぞれのCPU、メモリ、ブラウザエンジン、キャッシュ、画面レイアウトを使って描画します。そのため、Home Assistant Coreが同じタイミングで同じ状態を生成していても、2つのクライアントの体感は異なる場合があります。

ダッシュボードのパフォーマンスに関する議論では、クライアント側のテンプレートやカスタムカードの処理と、サーバー側のエンティティ計算を区別しており、同じHome Assistantサーバーがすべてのデバイスにデータを提供していても、フロントエンドの処理はクライアント固有のままになり得ることを示しています。そのため、Coreがすでに更新を配信した後は、クライアントが最も遅い段階になることがあります。

キャッシュが曖昧な理由もここにあります。ブラウザのキャッシュが温まっていれば初期リソースの読み込みを高速化できますが、古いフロントエンドアセットは誤った動作を引き起こす可能性があります。また、データベースのページキャッシュが温まっていれば履歴クエリを高速化できますが、物理デバイスの制御速度は変わりません。測定対象のキャッシュとパスを必ず明確にしてください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

データパスを使って適切なパフォーマンス指標を選ぶ

測定する前に、ユーザーの操作をマッピングしてください。モーション照明では、センサーから状態への反映、トリガーからサービス呼び出しまで、サービス呼び出しからデバイス確認までを追跡します。履歴では、クエリ開始から最初の結果が返るまでの時間とストレージ遅延を測定します。ダッシュボードの起動では、接続、サーバーの応答、WebSocketによる状態配信、クライアントのレンダリングを加えます。Home Assistantの高度なデバッグ手順がトレースと範囲を絞ったログを使うのも同じ理由です。エンドツーエンドの1つの数値は、内部の各段階が分かって初めて役立ちます。

ZimaSpaceは、スマートホームのセンサー保持で、このモデルのストレージ側を示しています。そこでは、サンプル頻度、インデックス、保持期間、バックアップによって履歴ストレージの負荷が決まり、1つのセンサー値の瞬間的なサイズでは決まりません。

データパスのモデルは、提案された対策が実際の遅延の上流または下流にあるコンポーネントを対象としている場合に重要です。症状とともにストレージの処理時間が変化するならストレージを変更し、サーバーの応答がすでに速いならクライアント設計を変更し、現在の状態の到着が遅いならインテグレーションまたはネットワークを変更します。このパスによって、「Home Assistantが遅い」という表現を、範囲を限定した技術的な説明へと変えられます。