easy-floorplan: a drag-and-drop floorplan card for Home Assistant

What easy-floorplan solves, and who it is actually for

Home Assistant dashboards are grids of entity cards. A floorplan card is the other idea: draw the house, then put the entities where they physically are. The problem is that most floorplan setups separate the drawing from the binding. You draw in one tool, export an image, and then hand-place transparent icons over it in YAML, guessing pixel coordinates. Move a wall and every coordinate is wrong.

easy-floorplan puts the editor in the card. The README describes it as "A Home Assistant Lovelace card for building an interactive floorplan, with a visual drag-and-drop editor", and the feature list is the editor: draw walls, drop doors and windows that snap onto them, drag, nudge with arrow keys, multi-select, copy/paste, undo/redo, zoom. Devices are bound to entities and drawn as icons, ripples or live state. Because the geometry and the bindings live in the same card configuration, editing the plan does not invalidate the entity positions.

The intended user is a Home Assistant owner with a Lovelace dashboard and a house worth drawing. It is not for someone who wants a floorplan image for a listing, a permit or a renovation quote. The furniture set makes the boundary clear: 28 gray line-art diagrams, each a plain JSON file of numbers, each bindable to an entity. That is a diagram library for a control surface, not a drafting library.

How the card works: geometry, bindings and conditional styling

The repository is a TypeScript project built with Vite (vite.config.ts, tsconfig.json, package.json with lit and custom-card-helpers as the only runtime dependencies). The card is a Lit element, which is the standard shape for a Lovelace custom card, and the build output is what HACS serves.

The data model is a plan, not an image. Walls are drawn elements; doors and windows snap onto walls; furniture, text and device badges are placed elements. Entities attach to placed elements, and the README lists what a binding can drive: tap to toggle or open more-info, a live state or attribute label, a custom icon, size and rotation. Conditional rules restyle an element from what its entity reads, and the README says the same rules drive furniture and rooms, so a room polygon can color from an entity rather than from a fixed fill.

Some behavior is derived rather than drawn. Dead spaces are the regions the walls seal off that no door or window reaches; the README states nothing has to be drawn for them because "the regions come from the walls and openings themselves", and cutting a doorway into one stops it being dead as soon as the door is placed. Follow the sun dims the plan through dusk and brightens it through dawn from the Home Assistant instance's sun elevation, and any light casting light holds the dark back around itself out to some radius. Cast light pools a light's own color and brightness onto the plan, and overlapping pools mix.

One detail worth noting for anyone evaluating the file format: furniture is JSON, not SVG, and the README gives the reason directly, "so nothing you paste can run anything". That is a deliberate constraint on the editor's paste box, and it also means you can copy a furniture definition out of the repository, edit the numbers and paste it back.

Installing easy-floorplan and drawing a first room

The repository ships hacs.json, so the intended install path is HACS as a custom frontend repository. The README does not spell out the manual resource step in the extracted text, so treat the HACS flow as the documented one and add the resource manually only if you know your Lovelace setup requires it.

For local development the package scripts are explicit. `npm run build` produces the bundle, and `npm run ha` builds, prepares a Docker environment and starts Home Assistant:

npm install
npm run ha

The script chain is `npm run build && node docker/prepare.mjs && docker compose -f docker/docker-compose.yml up`, so the Docker setup in docker/ is a real Home Assistant instance with the card preloaded, not a static preview. `npm run ha:logs` follows the Home Assistant log, `npm run ha:down` stops it, and `npm run ha:reset` removes the volumes and reruns docker/reset.mjs.

Once the card is available, the README describes the editing loop rather than a config schema: open the editor, draw walls, drop doors and windows that snap onto them, then place devices. The Apply button saves the plan to the dashboard without closing the editor, which the README says exists so you can judge a change on the real card in a second tab or by collapsing the editor, instead of in the small preview beside it. The README states Apply needs Home Assistant 2025.3 or newer, and that on anything older the button says so and Save still works. That is the first thing to check before you plan a workflow around it.

Where easy-floorplan stops being the right tool

The card is a rendering surface for Home Assistant state. Anything that is not an entity in your instance is decoration, and decoration is not what the feature list is built around. If your goal is a floorplan to hand to a contractor, this is the wrong tool: there is no dimension annotation, no scale export, no print layout, and the furniture is 28 line-art diagrams in a searchable picker.

There is a second boundary that is easy to miss. The editor is a Lovelace card, so the plan lives in the dashboard configuration. The README does not document rollback, versioning of the plan, or a way to diff two plans, so recovery from a bad edit rests on Home Assistant's own configuration backups rather than on anything the card provides. Undo and redo exist inside the editor session; they are not a history of the saved plan.

Complexity also has a cost. The card supports presence ripples, cast light with mixing pools, skylight sun patches, top-hinged windows, per-leaf sensor bindings, conditional text and icon rules, live position trackers from one or two distance sensors, and dead-space hatching. Each of those is a thing you can turn on. A dense floor with every minor sensor visible is exactly the case the README addresses with devices that appear only when their room is zoomed into, which is a recognition that the straightforward approach stops working at scale.

easy-floorplan against a generic floorplan drawing tool

The real alternative for most people searching for a floorplan maker is a drawing application: a browser tool where you drag walls and furniture onto a canvas, export a PNG or PDF, and are done. Those tools are better at the drawing itself. They have dimension tools, larger furniture libraries, print output and no dependency on a smart home platform. If you want a picture, use one of them.

The difference in approach is what happens after the drawing. In a drawing tool the output is a static file, and any live state has to be layered on separately, usually as a Home Assistant picture-elements card with hand-tuned coordinates. In easy-floorplan the plan and the entity bindings are one artifact, so a badge knows which entity it represents and an opening knows which contact sensor drives it. The README's example of that coupling is the animated openings: bind a contact binary_sensor, cover or lock and openings swing, slide or roll with their real state, partial positions included, and a lock reads unlocked as open so a door with no contact sensor still animates.

The trade is that you cannot take the result anywhere. There is no export path described in the README. The plan is a Home Assistant card, and its value is proportional to how much of your home is already in Home Assistant.

Maintenance, versioning and the MIT licence

The repository is not archived, and the last push was on 2026-09-16. Releases are frequent and small: v1.8.0 on 2026-09-07, v1.8.1 on 2026-09-09, v1.9.0 on 2026-09-15, with release notes naming ambient daylight, furniture actions, a movable floor switcher, balcony walls and shutter icons. That cadence tells you two things. Fixes arrive quickly, and the configuration surface is still moving, so a plan built today may gain options that did not exist when you wrote it.

Upgrade cost is the usual HACS frontend cost: pull the new version, reload, and check that your plan still renders. The repository does not describe a migration guide or a config version field, so there is nothing to consult before upgrading beyond the release notes. The package version in package.json is 0.7.2 while the releases are at v1.9.0, which suggests the npm version field is not the release identifier; use the GitHub release tag when you report a problem.

The licence is MIT, which is permissive and, as with any frontend card, means you are free to fork it and ship your own build. That is not legal advice; read the LICENSE file in the repository for the actual terms. The practical implication for a Home Assistant user is that there is no paid tier or licence key involved, and the README links to a Buy Me A Coffee page rather than to a commercial offering.

Editorial conclusion

Adopt easy-floorplan if your home is already in Home Assistant and you want a plan that reacts to entity state, not a picture with icons glued on top: the editor, the entity bindings and the conditional styling all live in the card. Do not adopt it as a general floorplan drawing tool, and do not expect it to produce construction documents; the furniture set is line art bound to entities, not a CAD library. Before committing, check your Home Assistant version, because the README states the Apply button needs 2025.3 or newer and older instances fall back to Save, and open the docs/ files for behavior, appearance and lighting, since the README links out to them for the details on skylights, top-hinged windows and colors for on and off.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nicosandller/easy-floorplan on GitHub
4. README
5. Releases