C.A.F.E.（Complex Automation Flow Editor）は、Home Assistantに“流れ”のビジュアルエディタを追加する統合で、Node-REDの精神に少し似ていますが、大きな違いがあります：C.A.F.E.は実行エンジンではありません。Home Assistantのみが自動化を実行します。C.A.F.E.は、あなたのビジュアルスキームを100%準拠のYAMLに変換し、Home Assistantシステム内に直接保存するだけです。
つまり、ブロックを矢印でつなげてロジックを描画し、その後保存…すると、Home Assistantが通常通り実行します。追加するDockerコンテナは不要、維持管理しなければならないデータベースもなく、Node-REDのように弱点になるアドオンはありません。これは、プロジェクトが強調している“ゼロオーバーヘッド”の約束です。
Home Assistantにとっての興味深い点
YAMLが好きなら、すでに理由を知っています：それは堅牢で、ネイティブで、予測可能です…しかし、自動化が大きくなると、すぐにテキストの壁にぶつかります。C.A.F.E.はまさに“スパゲッティ皿”になる瞬間を狙っています。既存の自動化を読み取り、ビジュアルマップを再構築することができ、監査や理解、整理するのに非常に便利です。
Node-REDから来た場合、安心できる点は別にあります：ノードのロジックが再現されますが、Home Assistantの実行をスイッチすることはありません。C.A.F.E.はインターフェイスを変更するだけで、エンジンは変更しませんし、いつでもネイティブエディタに戻ることができます。
さらに、多くの人が気に入る“ボーナス”が2つあります：
- C.A.F.E.は、ビジュアルインタフェース側の変数の概念をより適切に扱いますが、Home Assistantのネイティブビジュアルエディタでは、この種のことに関してYAMLをいじることを強いられることがよくあります。
- C.A.F.E.はHome Assistantのトレースと統合します：目的は公式ツールでデバッグを維持し、平行な宇宙を発明しないことです。
賢い“トリック”：ロックなし、エキゾチックなフォーマットなし
おそらく最も安心できる主張です：C.A.F.E.をアンインストールしても、自動化はそのまま機能します。視覚的なレイアウト（ブロックの位置）を失うだけで、ロジックは残ります。なぜなら、それは標準的なYAMLだからです。
そして、このレイアウトを維持するために、C.A.F.E.はメタデータ（ノードの位置など）を自動化のvariablesブロックの中に“無害”のオブジェクトとして保存します。Home Assistant内で自動化を変更し、その後C.A.F.E.で再度開くことができます：どちらも同じソースを編集します。
Home AssistantにC.A.F.E.をインストールする方法（HACS経由）
推奨される方法はHACSを介して、カスタムリポジトリを追加することです。公式のREADMEには手順が示されています：HACSで、Integrationsセクション、3つの点メニュー、“カスタムリポジトリ”を選択し、https://github.com/FezVrasta/cafe-hassを統合として追加します。
次に、HACS内でC.A.F.E.を見つけて、インストールします（ダウンロードします）。
Home Assistantを再起動し、設定 → デバイスとサービス → 統合を追加を通じてC.A.F.E.統合を追加します。
一度設置されると、C.A.F.E.はHome Assistantのサイドバーにパネルとして表示されます。これは“Lovelace”のダッシュボードではなく、サイドバーのエントリです。
インストールせずにテストしたいですか？
C.A.F.E.を何もインストールせずに試すことができます。ウェブインターフェース経由で、Home Assistantへのリモートアクセスがあれば可能です。
実際、Home Assistantをインターネットに公開する場合は、適切に行う必要があります（Nabu Casa、リバースプロキシ、認証など）。これは可能ですが、スマートホームのために“yolo”モードは避けます。
Home Assistantへのアクセスを与えたくない場合（これは全く理解できます）、私はあなたのためにC.A.F.E.を最近数週間提供しているHome Assistantテストサーバーにインストールしました。これにより、自宅で全てを壊すことなく、リモートアクセスを提供せずにテストが可能です；-）
使い方：日常的にどのように使うのか
C.A.F.E.に入ると、インターフェイスは非常に“フローエディタ”です：左側にはノードのパレット（トリガー、条件、アクション、遅延、待機…）、中央にはブロックを置く大きなキャンバス、右側には各ノードを設定するためのプロパティパネルがあります。ズームイン、移動、複雑な自動化のナビゲーションのためにミニマップを使用できます。
典型的なシナリオは次のようになります：トリガーを配置（たとえば“動きが検出された”）、条件を追加（たとえば“夜である”）、次にアクションを追加（たとえば“廊下のライトを点灯”）し、すべてを接続します。その後、各ノードを開いてエンティティやサービスを選択します。C.A.F.E.はHome Assistantのエンティティのインテリジェンスに依存して（オートコンプリート、API経由の状態の知識）、手動で識別子を入力する必要を回避します。
非常に便利なポイント：既存の自動化を開くと、それがキャンバスに“置かれ”、ブロックを動かして見えやすくし、変更してからHome Assistantに保存します。編集、保存、そしてネイティブエディタで自動化を見つけると、レイアウトメタデータに豊かにされたYAMLが得られます！
インポート、エクスポート、デバッグ
C.A.F.E.は既存の自動化をインポートでき、YAMLまたはJSONもインポートでき、その後フローをJSONでエクスポートできます。これは“スキーム”を共有したり、やや繊細なロジックをリファクタリングする前のバージョンをアーカイブするのに役立ちます。
デバッグの側面では、アイデアは簡単です：実行の明確な読み取りを保持します。“ステップ実行”インディケーターと条件結果をシミュレートするオプションを持つデバッグモードがあります。これにより、自動化で取った道筋を視覚化できます。
プロジェクトの面では、Home Assistantのトレースビューとの統合は発表された強みの一部です：起こったことを分析するために公式ツールの中に留まります。
C.A.F.E.が本当に違いを生む具体的な例
<p“夜の照明”自動化の例を見てみましょう。トリガー：日没の直前。条件：特定の時間前のみ（そうでないと、遅すぎて無駄です）。アクション：特定のランプを点灯させますが、時間帯に応じて異なる明るさで。YAMLでは、しばしば入れ子になった“choose”が発生し、条件が交差します。C.A.F.E.では、この種のロジックが道路地図のようになり、分岐が見え、道が見え、息をつくことができます。そして、これは転写で示された例のまさにそのタイプです。もう一つ非常に明確なケース：変数を用いたシナリオ。シンプルな例：スクリプトを呼び出し、それが情報（温度、料金、合成状態）を返し、応答を変数に保存し、次のアクションでその変数を再利用します。READMEには“スクリプトレスポンス”（response_variable）の機構と、次のノードでのJinjaにおける使用{{ variable.champ }}が説明されています。
そして、インストーラーや高度なユーザーにとって：ループ、戻り、非線形のロジックについて話すと、C.A.F.E.は必要に応じて“最適化された”コンパイルをアナウンスし、状態遷移のような構造を生成できますが、Home Assistantと100%互換のままでいます。
限界と注意事項（はい、これはベータです）
プロジェクトは“非破壊的”とされていますが、まだベータの段階であり、頻繁な修正があります。第一のルール：重要な変更を行う前に、自動化のバックアップを取ってください。
第二のルール：クリティカルな自動化（警報、暖房、安全）については、徐々に進めてください。まずはシンプルな自動化でテストし、YAMLを事前/事後で比較し、トレースを確認し、複雑さを増していきます。これは、家を改装する際にすべての壁を一気に壊さないというスタイルです（そして、将来のリラックスも感謝してくれるでしょう！）。
第三のルール：オートレイアウトと視覚再構成が非常にアーティザナルなYAMLでは100%完璧ではないということを受け入れてください。プロジェクトもこれを認めています：複雑な手動YAMLのインポートには差異があるかもしれません。
今すぐ採用するべきか？
ネイティブエディタに慣れていて、自動化がシンプルであれば、C.A.F.E.は“必須”ではありません。一方、複雑なシナリオがあり、Wi-Fiがない日のように長いYAMLを読み返すことが嫌いで、Node-REDの視覚的な快適さが好きだが、2つ目のエンジンを求めていない場合、C.A.F.E.は多くの要件を満たします：視覚的、ネイティブ、オーバーヘッドなし、そして長期的な罠がないので、標準のHome Assistant自動化に留まります。ここでは、すでに採用されています！
