# C.A.F.E. compiles Home Assistant flow diagrams back into native YAML > FezVrasta/cafe-hass is a visual flow editor for Home Assistant that transpiles your diagrams into native automation YAML stored in Home Assistant itself, rather than running its own execution engine like Node-RED. The project is still marked beta, and the README asks you to back up your automations before editing them. **FezVrasta/cafe-hass** — The "Third Way" for Home Assistant Automations. - Repository: https://github.com/FezVrasta/cafe-hass - Website: https://fezvrasta.github.io/cafe - Stars: 1,733 · Forks: 38 - Language: TypeScript - License: MIT - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/fezvrasta-cafe-hass ## It is a compiler, not a second automation engine The framing the project uses is a trade-off it claims to eliminate. Home Assistant users are described as having had to choose between the stability of native YAML and the clarity of Node-RED flows, and C.A.F.E. presents itself as removing that choice. The mechanism is a transpiler. You draw a diagram, and on save the flow is compiled into 100% compliant native Home Assistant logic stored directly in the core system. There is no secondary engine and no extra container. The FAQ is blunt about what that means at runtime: it is not an execution engine, it is a specialized compiler, and once you hit Save the resulting logic is pure native Home Assistant code consuming zero background CPU or RAM. That single design choice cascades into the rest of the feature set, and it is the reason to care about this project if you already run Home Assistant. There are no side files. The README is explicit that there is no `cafe_data.json`. Visual metadata such as node positions is stored as an object inside the automation's own `variables` block, which is harmless to the engine. Uninstall the integration and your automations keep running; you lose the box positions and nothing else. The built-in Home Assistant editor and C.A.F.E. are described as two lenses on the same data, editing the same source of truth, and changes made in either are picked up by the other. That is a genuinely different posture from Node-RED, and it is also the whole value proposition. If you are comfortable running a sidecar container that holds your automation state, you have other options. If you are not, this is one. It is installed through HACS as a custom repository, requires Home Assistant 2024.1 or later, and is MIT licensed. The newest release is v0.10.1 on 2026-09-25, with the last push the same day. ## The transpiler picks linear or state machine for you This is the part that most affects how your automations look in YAML afterwards, and the README has a dedicated FAQ entry for it. For linear flows, C.A.F.E. generates standard YAML sequences. For complex flows, specifically ones with loops or jumps, it generates what the README calls a native state machine, described as a repeat/choose dispatcher. The engine analyzes the flow and chooses the target structure itself. The generated YAML therefore depends on whether the transpiler detects a linear flow or a complex flow requiring loops or jumps. The consequence for you is that you should not predict the YAML from the picture. Read it. That is also what the visual import feature is for: the heuristic auto-layout claims to read existing manual YAML and reconstruct a visual map instantly, which the README positions as a tool for auditing and cleaning up existing automation sprawl. Two decisions about safety sit around the transpiler. Every node, edge and schema is validated with Zod, so malformed data from the UI never reaches the Home Assistant API. And the debug story uses a feature you already have: the official Home Assistant Trace View, with execution paths mapped back to your canvas rather than requiring a separate debugger. The beta warning sits at the very top of the README and is not soft: the project is still in beta, and although it is designed to be non-destructive, the README asks you to back up your automations before editing them with C.A.F.E. That is the correct posture for a compiler whose whole point is rewriting files you care about. ## Script responses and flow-scoped variables through Jinja The features that push beyond simple trigger-and-action are the ones that make complex automations expressible in a diagram. Script responses are supported in full for `call_service`. You call a script, capture its output and use it in later nodes, which means a node is not limited to a boolean or a state change. The wiring is via `response_variable`: set one, for example `weather_data`, and the values become available to every subsequent node in the flow. You read them with ordinary Home Assistant Jinja in any text field: ``` The temperature is {{ weather_data.temp }} degrees. ``` There is also a Set Variables node for creating and updating flow-scoped variables dynamically inside the automation's logic, which is how you accumulate state across nodes without writing Jinja assignment expressions by hand. Entity awareness comes from the native Home Assistant WebSocket API, giving autocomplete and state awareness in the editor rather than a list you maintain. A Visual Import feature loads any native automation and maps it to nodes immediately. One thing to keep in mind when reading these features: they work because the output is native Home Assistant, so they inherit the semantics of the native system rather than adding new semantics. A `response_variable` behaves exactly as it does in hand-written YAML, which is both the strength and the constraint. The companion project is worth a mention because it addresses a gap C.A.F.E. does not. The README points readers looking for role-based access control in Home Assistant to ha-rbac, described as now available. The repository is a TypeScript monorepo on Yarn 4 with workspaces under `packages/*`, orchestrated by turbo, tested with vitest and linted by Biome. The HACS custom component lives under `custom_components/cafe/`, and the scripts include a dedicated `build:ha` target that rebuilds and copies into `custom_components/cafe/www/`, plus a `test:cli` script that runs the transpiler CLI. ## Against Node-RED and against hand-written YAML The comparison everyone will ask about is Node-RED, and the difference is architectural rather than a matter of features. C.A.F.E. is not an execution engine. It provides Node-RED-style visual flows that compile into native Home Assistant logic. C.A.F.E. uses Home Assistant's native Trace View, with execution paths mapped back to the visual canvas. The central trade is that C.A.F.E. keeps the generated logic inside Home Assistant and does not run a secondary execution engine. Against hand-written YAML, the comparison is about review and maintenance rather than about capability. The output of C.A.F.E. is YAML, so nothing it produces is better than what you could write. What it changes is the editing surface: a diagram you can point at, auto-layout that reconstructs a map from existing configuration, and trace output mapped back to a canvas. Against writing automations in the built-in editor, the difference is smaller than the marketing suggests. Both edit the same source of truth, and the README says plainly you can switch between them. The gain is visual structure for large flows; the cost is a beta dependency in your front door controller. For a house with a handful of automations, the built-in editor is enough and this is unnecessary complexity. The case for C.A.F.E. starts when the number of automations makes the YAML list hard to hold in your head. ## Conclusion C.A.F.E. fits an existing Home Assistant installation whose automations have grown into spaghetti and that someone finds hard to review in raw YAML, because the visual editor writes back the same native data the built-in editor uses. Do not adopt it while it is beta on a house you cannot afford to debug at 2am, since the README itself says to back up your automations first, and do not adopt it expecting a Node-RED runtime, since the whole design is to have no runtime. Verify first that your Home Assistant is 2024.1 or newer as the badge requires, that you have a working backup of your automations directory before the first save, and how the transpiler chooses between a linear sequence and a state machine on a flow of your own, because the generated YAML will not always look like what you drew. ## FAQ ### How do I install C.A.F.E. in Home Assistant? Through HACS: install HACS if needed, go to HACS then Integrations, open the menu and choose Custom repositories, add `https://github.com/FezVrasta/cafe-hass` as an Integration, install C.A.F.E. and restart Home Assistant. Then add it from Settings, Devices & Services, Add Integration. The badge states Home Assistant 2024.1 or later is required. ### Does C.A.F.E. slow down Home Assistant? The README states it does not, because C.A.F.E. is a compiler rather than an execution engine. Once you save, the logic is native Home Assistant code running inside HA Core, consuming no background CPU or RAM, and there is no secondary engine or extra container. ### What happens to my automations if I uninstall C.A.F.E.? They keep working. Everything is stored as native YAML with visual metadata inside the automation's `variables` block, and there is no `cafe_data.json`. You lose the visual layout, the positions of the boxes, and the logic remains intact and editable as YAML. ### How do I use script responses and variables in C.A.F.E.? Call a script and set a `response_variable`, for example `weather_data`, and those values become available to all subsequent nodes in the flow. You read them with standard Home Assistant Jinja in any text field, such as `The temperature is {{ weather_data.temp }} degrees.` ### Why does the YAML C.A.F.E. generates not always look like my diagram? The transpiler analyzes the flow and chooses the target structure. Linear flows compile to standard YAML sequences, while flows with loops or jumps compile to a native state machine built as a repeat/choose dispatcher. ### Is C.A.F.E. safe to use on my Home Assistant instance? The README marks the project as still in beta, says it is designed to be non-destructive, and explicitly asks you to back up your automations before editing them with C.A.F.E. ## Sources - [FezVrasta/cafe-hass on GitHub](https://github.com/FezVrasta/cafe-hass) - [License: MIT](https://github.com/FezVrasta/cafe-hass/blob/main/LICENSE) - [Project website](https://fezvrasta.github.io/cafe) - [README](https://github.com/FezVrasta/cafe-hass/blob/main/README.md) - [Releases](https://github.com/FezVrasta/cafe-hass/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fezvrasta-cafe-hass