Explore offering a node-based editor experience for automations

[nielsrowinbik]

Problem statement

Our current automation editor UI is linear: it displays triggers first, conditions come below that, and at the bottom we've got the actions. This works well for simpler automations, but for more complex automations, it gets messy quickly. Running different actions based on what triggered the automation and a few other conditions... things get less and less legible as soon as building blocks like if/else and choose are added.

The visualisation that has been proven time and time again to work very well for more complex flows is node-based. Commercial platforms such as Homey support this out of the box and users have found (Node-RED) and built (C.A.F.E.) as ways to add such a visualisation to Home Assistant.

We strongly feel the need to explore offering this visualisation natively.

⚠️ Please note that the fact that this roadmap item exists with a "considering" state does not imply a commitment to building it. We are very much in the exploring/considering state, but as with everything, we do so in the open. Please feel free to share your thoughts and input to help us move this along!

Scope & Boundaries

In scope

• A node/flow representation for automations, offered alongside (not replacing) the existing linear editor.

Not in scope

• Departing from the YAML-"back-end" for automations. YAML will not go away or be the "lesser" option.

Foreseen solution

A node/flow representation for automations where triggers, conditions, and branching (choose/if-then) render as connected nodes, offered alongside (not replacing) the existing linear editor.

Community signals

Various feature requests exist that ask for this exact feature (recently consolidated, but linked for completeness):

• #576 Allowing other visualizations of automations references the release-party flow-editor demo and asks for it. (Already cited.)
• #556 Introduce flow-view for automations claims that branching logic is hard to follow in the linear/YAML view and that a flow view would make it legible.
• #1482 Introduce a 'Visual Logic Flow' Automation Type proposes a node-based editor as a first-class automation type, not just a viewer.
• #2995 Visual Trigger Editor like in Switch Manager Integration points to a popular HACS integration as proof of demand and a reference UX.

Risks & open questions

No response

Appetite

No response

Execution issues

No response

Decision log

Date	Decision	Outcome

[Hedda]

FYI, there is a custom component integration called ”C.A.F.E.” (Complex Automation Flow Editor) in beta that offers this today:

• https://github.com/FezVrasta/cafe-hass

Made by @FezVrasta and available via HACS, it importanly makes automations compatible with the default automation editior:

• https://community.home-assistant.io/t/project-release-c-a-f-e-a-third-way-for-automations-visual-flows-like-node-red-but-100-native-yaml-storage-no-extra-engines/972511

TL;DR summery in these videos:

• https://www.youtube.com/watch?v=9PVBo0CtHz0
• https://www.youtube.com/watch?v=l_gizeju8D4&t=127s

Not tried it but realy like the concept with it being native-first, using standard YAML in HA with no side-files and no external databases, so idea is that the code from the current automation editor can be reused in a flow editor that is fully compatble with native automations in the default automation editor. Quote:

• ”No Lock-in, so If you decide you don’t like C.A.F.E., you can delete the integration. Your automations stay in your system and keep running forever because they are just standard YAML.”

Why C.A.F.E.?

For years, Home Assistant users had to choose: the stability of native YAML or the clarity of Node-RED flows. C.A.F.E. eliminates the trade-off.

• Native YAML: No side files, no external databases, and no proprietary formats. Everything is stored in HASS.
• Zero Overhead: No secondary engine or extra Docker containers. Once saved, the logic runs in the HA Core with zero extra resource consumption.
• Optimized YAML Generation: C.A.F.E. produces standard, linear sequences for simple flows and automatically utilizes a robust State-Machine pattern for complex logic like loops.
• Trace-Integrated: Debug your visual flows using the official Home Assistant Trace View. C.A.F.E. maps execution paths back to your canvas.

No Vendor Lock-In: Your Automations, Your Way

• Stop Using C.A.F.E. Anytime: If you uninstall C.A.F.E., your automations keep working exactly as before. The logic is standard YAML; you only lose the visual layout metadata.
• Built-in Editor Compatible: You can switch between C.A.F.E. and the native HASS automation editor seamlessly. They edit the same source of truth.
• Zero Side-Files: There is no cafe_data.json. Visual metadata (node positions, etc.) is stored as a harmless object inside the automation's variables block.

Engineering Quality & Architecture

C.A.F.E. is architected with strict engineering principles to ensure your home remains reliable:

• Intelligent Transpiler: The engine analyzes your flow and chooses the optimal target structure. It generates clean, human-readable YAML for standard sequences, and utilizes a Native State Machine (repeat/choose dispatcher) only when needed to unlock complex non-linear "jumps" and loops.
• Zod Validation: Every node, edge, and schema is validated via Zod. This ensures that malformed UI data never reaches your Home Assistant API.
• Heuristic Auto-Layout: Our engine can "read" existing, manual YAML and instantly reconstruct a visual map, making it the perfect tool for auditing and cleaning up "spaghetti" automations.

Power Features

• Script Responses: Full support for call_service responses. Call a script, capture its output, and use it in subsequent nodes via native Jinja templates.
• Set Variables Node: Create and update flow-scoped variables dynamically within your automation logic.
• Entity Intelligence: Full autocomplete and state-awareness via the native HASS WebSocket API.
• Visual Import: Load any native automation and see it mapped instantly to nodes.

[nielsrowinbik]

@Hedda, thanks! I am aware of C.A.F.E. (I installed it around the time of creating this idea to try it out), just hadn't gotten around to linking to it in the issue here. Will update soon, thanks for the nudge! 🙂

[bartbutenaers]

Hi @nielsrowinbik
I REALLY appreciate the OpenHomeFoundation is willing to explore at least the possibilities for a node-based automation editor 🙏

Going to put in my 2 cents here. As a hardcore Node-RED contributor for many years, and a minor contributor to the CAFE project.

Although I am a great fan of CAFE already, a native flow editor would have the advantage of code reuse:

• The (nice) right properties sidebar could be used both for the flow editor and for the current trigger-when-action editor.
• The purpose-specific triggers/conditions/actions could also be used as node labels, to build a nice alternative for Homey-like flows.

Something like I proposed in my feature request:

This code reuse would allow the flow editor to be kept in sync with new automation features at future HA releases. Imho it would be rather difficult for third-party flow editors to achieve that...

The people at Homey created a very cool flow editor, which even my wife and kids might be able to use...

Bart

[bartbutenaers]

a native flow editor would have the advantage of code reuse

Home Assistant 2026.6 contains a series of VERY nice automation-related improvements, that imho speak in favor of integrating a flow editor into Home Assistant Core (compared to a third-party flow editor):

• The state of conditions are now showed & notes can be added & the number of targets are displayed:
  
  So much many nice improvements into a single release, would be hard to catch up by a third-party flow developer. He would have to reinvent hot water over and over again...

  It would have a lot of benefits if the code from the current automation editor could be somehow reused in a native flow editor.

• Lots of cool quick links have been added, for example:
  
  It would be very nice if these quick links would open the flow editor (for users that somehow have specified that the native flow editor is their favorite automation editor) automatically, and the new target would be automatically added as a new node in the automation flow. Similar to how the quick links open now the current automation editor ui.

  It would be very difficult for a third-party flow editor developer to embed his editor - in a similar way - all over the place in the Home Assistant user interface.

I will stop coming up with arguments for a native flow editor, or people will start thinking I'm an AI bot trained exclusively on this topic 😄. I assume there are other aspects of such a flow editor that someone wants to discuss here, but not sure which ones...

[macleodal]

I'm not sure if there is an official way to add one's support to the list of users wanting a new feature but I'd like to add mine anyway.

C.A.F.E. does indeed look amazing and props to @FezVrasta for creating it as a community integration. I suspect however my position is the same as many HA users -- I love it for its coolness and the potential value it brings, but following the thread I see it still has many kinks to iron out (of course); I've held off C.A.F.E. becasue my HA system graduated in the last eight months from a never-done-it-before "science project" to a production system that runs my home... the automations are critical to keeping me out of trouble with my other half... so I am risk averse to the n-th degree, I'm also time-poor so I can't spend time chasing through things that don't work first time.

The Homey flow based editor is super cool. I will never depart Home Assistant for other platforms but I would adopt a flow editor in a heartbeat if it were HA native. As @bartbutenaers commented "something even my wife and kids could use", and something officially supported and onward developed at scale, would be a superb addition.

Pls make me a +1 on this.

[Hedda]

FYI, there is a custom component integration called ”C.A.F.E.” (Complex Automation Flow Editor) in beta that offers this today:

• https://github.com/FezVrasta/cafe-hass

Made by @FezVrasta and available via HACS, it importanly makes automations compatible with the default automation editior:

• https://community.home-assistant.io/t/project-release-c-a-f-e-a-third-way-for-automations-visual-flows-like-node-red-but-100-native-yaml-storage-no-extra-engines/972511

For reference, it seems like development on C.A.F.E. has not been very active recently and another developer named SH1FT-W has been posting about his new fork of it called "FLODE" which to his benefit does looks to be a little more more active at this point:

• https://github.com/SH1FT-W/flode

It looks to have some improvements on top the original CAFE, but like repo CAFE it is also build on top of React Flow (and from what I understand the HA team has migrated away from React to native Lit/SVG so both of those projects should maybe also consider mitigating too? Though I do understand that it would be a huge undertaking to refactor a project like that to make it framework-agnostic and might come with a massive development trade-off and that it would mean implementing some other node-management system, either from scratch or finding some framework-agnostic library/libraries for it.).

• https://community.home-assistant.io/t/flode-visual-flow-node-editor-for-home-assistant-fork-of-c-a-f-e-testers-wanted/1013664

• https://sh1ft-w.github.io/flode/

Anyway, be aware that for some unknown reason the developer of FLODE has choosen it to default to German language though which makes it harder for others in the greater Home Assistant community which all uses English as the official default language.

[FezVrasta]

Not sure who said CAFE is no longer maintained, I just have other properties lately. The flode "maintainer" has been spamming his fork all over my repo lately...

[bartbutenaers]

Now that we have listed all the existing alternatives, I would like to start discussing about the native flow editor itself. I am by far a HA automation expert, so please correct (in a constructive way...) if I say something incorrect! The reason why I really would like to have a flow editor in HA, is in fact because I am by far an automation expert 😉

I first would like to share an interesting quote (see here) from the CAFE developer:

The only part worth porting could be the transpiler, but honestly I would expect the HA team to extend their YAML to support flows natively without the limitations that make CAFE rely on its state machine strategy.

I have been contributing code many years for Node-RED. In these flows any node can be wired to any other node. Not that it will always make sense, but it is possible based on the JSON format.

However in Home Assistant this is completely different. The automation is a yaml structure, which means you end up with tree branch-based automations. Each node has only a single parent node, so there isn't really much flexibility. Over the years stuff have been added to the yaml syntax to make this a bit more flexible (via and, or, trigger id's, ...), but it still has its limitations. A native flow editor in HA would be a flow representation of that yaml structure, so the flow editor would have the same limitations.

For example the red wire below is not possible:

The CAFE developer has found a very decent workaround. In those cases the CAFE flow editor generates a state machine (see example here), which means the generated automation yaml file contains a loop that makes this possible. So the CAFE flow editor is very flexible about wiring nodes, but as a result the generated yaml file becomes hard to read. Because it is not really the standard automation yaml syntax that users are familiar with...

So there are two options:

1. The native flow editor is very flexible and allows nodes to be wired in any way you like, resulting in a complex yaml file (containing a state machine).
2. The native flow editor restricts the wiring, to allow only structures like in a standard home automation yaml file. So less flexible wiring, but a more standard yaml file.

My first thought in the beginning was absolutely option 1: why the hell limit the flow editor, because the yaml syntax is limited. I will only use the flow editor, so I will never look at the yaml file anyway.

However afterwards the above quote from the CAFE developer made me thinking, and changed my mind. So I now go for option 2. I am not happy when hardcore users can do stuff in their yaml files, which I cannot do in my flow editor. But that also means it would not be fair if the flow editor would offer more functionality, compared to what the yaml users can do (unless they start coding manually a complex state machine of course....).

Imho all 3 automation editors (yaml, standard automation ui, and flow editor) should offer the same features, requiring similar efforts from the user. So my personal choice would be: limit the native flow editor to only node wiring that can be provided by a standard automation yaml file. And if more flexibility in the flow editor is needed afterwards, then extra yaml constructions should be provided - in a future release - to make sure that all 3 automation editors can offer the same flexibility.

[Hedda]

Community signals

• Feature requests like this one and this one.

FYI, here are a few more community signals in these "older" threads with Home Assistant's community forum feature requests asking for some type of flow-based visual editor for automations and scripts using graphical blocks via a drag-and-drop frontend:

• https://community.home-assistant.io/t/add-google-blockly-to-home-assistant/19695
• https://community.home-assistant.io/t/flow-chart-for-automations/513670
• https://community.home-assistant.io/t/visual-automation-enginge/567135
• https://community.home-assistant.io/t/blockly-elements-rules/64443
• https://community.home-assistant.io/t/advanced-flows/766958
• https://community.home-assistant.io/t/wth-why-isn-t-there-a-flow-editor-for-automations/802484/

For reference, node-based editors/systems may be called/known under different names, such as example "Visual programming", "Flow-based programming" (FBP), "visual programming language" (VPL), "visual programming system" (VPS), "Flow programming", "diagrammatic programming", "graphical programming", "block coding", or "Node Graph Architecture", and some flow-based systems can call them "Automation canvas", "Visual logic editor", "Visual workflow editor", "Node graph editor", "Flow editor", "Flow designer", "Flow builder", "Automation builder", "Advanced Flows Editor", Node graph system", "Graph-based programming", etc. as some products market them. There are a lot of overlapping terms and terminology, with different communities/software often reinvent the same concept with different names. One useful way to think about it is that "node-based editor" is often the UI paradigm, while terms like VPL, flow-based programming, or dataflow programming describe the underlying programming or execution model. So remember to consider using all those search terms when researching to find more examples.

• https://en.wikipedia.org/wiki/Visual_programming_language

  • https://en.wikipedia.org/wiki/Node_graph_architecture

[Hedda]

For many use cases a user can today effectively work around the lack of a native "flow state" by externalizing the state into Home Assistant helpers, but creating a helper for every case can also result in a complex yaml file when using input_text, input_number, or input_datetime to store additional context and drive subsequent automations from the helper states (since helpers restore state across restarts, the workflow can resume logically even though the original automation execution is gone). Helpers also have a history, while a flow state might only need to keep the latest state. So using helpers could maybe be a a workaround to cover many common use cases but not a complete replacement.