ESPHome Designer: drag a dashboard, export the ESPHome code that draws it

What it does: design on a canvas, export code for the device

ESPHome Designer is a visual drag-and-drop editor for smart displays, supporting ESPHome, OpenEpaperLink and OpenDisplay, and running either as a Home Assistant integration or as a standalone web app. The pitch line is the clearest statement of the problem it addresses, no more hand-coding ESPHome display lambdas. The workflow is to design a layout in the browser, watch your actual Home Assistant entities update live on the canvas, and then export that design as code the device can run. The feature list also covers flexible data sources, connecting widgets to Home Assistant entities or to MQTT topics directly, a multi-page world view where all project pages sit on one unified stage with artboard-style rendering, 55 or more independent widget modules, conditional visibility based on entity state, time-based page scheduling, and a device integration that exposes buttons, a buzzer, and temperature and humidity sensors back to Home Assistant for automations.

Three platforms, three output formats, and why that distinction matters

The supported platforms table is the core of the design. ESPHome produces a C++ lambda or LVGL YAML, for ESP32 devices with direct display control. OpenEpaperLink produces a Home Assistant service call in JSON, for wireless e-paper price tags over the OEPL access point. OpenDisplay produces JSON actions, for HTTP-driven e-paper displays. The distinction is not cosmetic, because the same visual design has to be expressed in three different protocols, and the exporter has to know which semantic model it is targeting. For ESPHome you get generated code, and the README says the normal workflow is still to design in the editor, copy the generated snippet, paste or merge it into your device YAML, and then compile and flash from ESPHome. For the other two you get a payload the platform already knows how to consume. A multi-page world view across a display that can only show one page at a time is also where the scheduling feature earns its place, showing a weather page in the morning, a sensor dashboard during the day and an alert page when the doorbell rings.

Three ways in, and the one that needs no installation

The Quick Start offers three installation routes and the choice is a real decision. The live web version needs nothing installed: you open the hosted designer, go to Editor Settings through the gear icon, enter your Home Assistant URL and a Long-Lived Access Token from your HA profile, and add the designer URL to your HA cors_allowed_origins. The HACS route is described as recommended: add the repository as a custom repository in the Home Assistant Community Store, search for ESPHome Designer, install it, restart Home Assistant, then add it under Settings, Devices and Services, Add Integration. The manual route is the third, where you download the custom_components/esphome_designer folder from the repository, copy it into your Home Assistant config/custom_components/ directory, restart, and add the integration. The web version is the fastest to try and the one to start with, since it is also the only one that does not require a Home Assistant restart to try at all.

Where the data lives, including the legacy migration

The section on where Home Assistant stores your data is the most useful operational detail in the README. Layouts and editor state go in the .storage/esphome_designer file under the config directory, custom layouts you create in the editor are saved inside that same file as separate layout entries, and manual edits made in the YAML snippet box are saved as part of the layout state rather than as a standalone ESPHome device YAML file. Uploaded custom hardware profiles go to a separate directory of YAML files. And there is a legacy note, that installs of 0.8.6.2 and older may still have data in a differently named storage file, which the integration can read and migrate on a later save. That last point matters for anyone upgrading from the earlier version of this project, because it says the migration is lazy rather than automatic.

Saving does not touch your device configuration, and the README admits it

How Saving and YAML Import Work is unusually honest for a tool of this kind, and the first line sets the expectation. Save Layout saves the current canvas, the layout settings and any persisted manual YAML override to the active layout in Home Assistant storage, and it does not automatically overwrite your real ESPHome device YAML file. Save Hardware Profile is a separate action for reusable hardware recipes and writes a YAML profile to its own directory. The generated ESPHome YAML in the snippet box is meant to be copied into your actual device configuration, and the normal workflow is still design, copy, paste or merge, then compile and flash. Import YAML back to canvas, also called Update Layout from YAML, does the reverse and parses supported YAML back into the pages structure. That round trip is the feature that makes the tool usable iteratively, since it is what lets you edit generated YAML by hand and bring the change back into the visual editor.

Round-trip editing, the AI assistant and conditional logic

Round-trip editing is listed as a first-class feature, importing existing ESPHome configs, OEPL YAML arrays or ODP JSON payloads back into the editor. There is an AI-powered dashboard assistant that generates entire layouts or individual widgets from text prompts, which sits oddly beside a tool whose selling point is that the output is deterministic code you own, and it is worth asking whether the generated code is reviewable. Conditional visibility is the other substantial feature, showing or hiding any widget based on Home Assistant entity state with binary, numeric, text and range conditions. The use case the README gives is a display that shows a weather page when you wake up, switches to a sensor dashboard during the day, and shows an alert page when the doorbell rings, which is a good description of what a small e-paper dashboard on a wall is actually for.

The toolchain in the manifest, and a lot of verify scripts

The package manifest is for the front end only, named esphome-designer-frontend at version 1.0.0-rc.47, and the scripts are the clearest description of the project's engineering process. The front end is Vite and Vitest, the build runs a node build script, and the test script runs Vitest and then a schema hash check, so the widget schema has a committed hash that is verified on every test run. There are separate typecheck targets for a base configuration and a strict one, and the repository holds ts_strict_errors.txt as evidence of that being tracked. Then there is the verification layer, with verify:ha, verify:dist, verify:pre-push, a quality gate with a proof directory, a baseline governance check and a baseline update mode, and a workflow benchmark with its own baseline. The pre-push and release scripts each have a skip-hassfest variant, which is the Home Assistant integration validation tool. The Python side is run through node scripts and tested with unittest discovery over a tests_python directory. This is a lot of machinery for a project with one author, and it is a fair proxy for how much the release process has been industrialised.

Where the project stands, and the release candidate caveat

The releases are v1.0.0-rc.45 on 2026-09-20, v1.0.0-rc.46 on 2026-10-03 and v1.0.0-rc.47 on 2026-10-10, with the last push to the repository on 2026-10-17, so the project is on its forty-seventh release candidate and has not cut a 1.0.0 yet. The licence is GPL-3.0, and the primary language is JavaScript. The repository layout shows a custom_components/ directory for the Home Assistant integration, an hacs.json for the community store, a font_ttf/ directory for embedded fonts, a scripts/ directory holding the build and verification scripts, a.devcontainer/ for development, and a start_editor.bat for Windows. The author is funded through GitHub Sponsors and Buy Me a Coffee, and the project also publishes a live demo at the GitHub Pages address and a feature walkthrough video. For an evaluator, the release candidate line is the thing to watch, since the storage format and the migration behaviour are still moving.

Editorial conclusion

ESPHome Designer suits a home automation user with an ESP32 e-paper or LCD panel who has been hand-writing display lambdas, or a developer who wants a visual layout and then the generated code in their own ESPHome configuration. It is the wrong choice if you want the designer to own your device configuration, because the README is explicit that saving a layout does not overwrite the device YAML, the generated snippet still has to be copied and merged by hand, and a poor fit if your display is not one of the three supported platforms. Before adopting it, decide which of the three output formats you need, because the exporter differs per platform, and note that the project is still on release candidates, so the storage paths and the migration of legacy data are worth reading before you build a layout you care about.

Frequently asked questions

Official sources

1. Issues
2. koosoli/ESPHomeDesigner on GitHub
3. License: GPL-3.0
4. README
5. Releases