Home Assistant Floor Plan: a Sweet Home 3D plugin that renders your flat as a live dashboard

A rendered picture that behaves like a dashboard

This project is a plugin for the Sweet Home 3D interior design application, and what it does is create a 3D rendered floor plan panel for Home Assistant that displays your home's current lighting state along with icons for toggling each light, sensors, and cameras.

The two demo images at the top of the project summary show the two views. The first is a floor plan, all floors from an aerial view, with buttons for switching between them. The second is a room view, a single room from the virtual visitor's point of view, with only the entities that are seen from it.

The mechanism is worth understanding, because it determines what the result is and is not. The images are renders, produced offline, from the Sweet Home 3D model. What ends up in Home Assistant is a set of static pictures plus a YAML file describing a picture-elements card, and the card overlays Home Assistant's own entity state on top of those pictures.

So this is not a live 3D view of your home. It is a photograph of your home, taken from a fixed camera, with the lights switched on in different combinations, and the dashboard composes the right combination based on what is actually on right now.

That is a clever solution to a real problem. Home Assistant's own floor plan card is a flat schematic, and a picture of your actual flat, with the living room lamp visible and clickable, is a much better thing to look at. But it is a picture, and the state of the house is real while the geometry is not.

The plugin also produces the entities for you, with interactive icons for toggling lights, and it can create state icons for multiple entities from Home Assistant based on their names. The output is a YAML file with the picture-elements structure for easy integration with Home Assistant.

Three rendering modes, and the trade is image count against quality

The rendering modes are the core design decision in this plugin, and the summary is honest about the cost of each.

In CSS mode, which is the recommended one, a base image is generated with all the lights turned off. Then, for each light source, a new image is rendered with only it turned on. The floor plan YAML then instructs the browser how to mix the different light sources from each render when multiple light sources interact with each other. This method offers good results with a low number of required images to render.

That is the clever part. If a room has a ceiling light and a floor lamp, you do not need an image for both on, because the browser can composite the two single-light renders on top of each other. The base image is the dark scene, and each light's image is the difference that light makes.

The room overlay mode is more careful. The floor plan is comprised of one base or background image without any of the lights turned on. Then, for each light, it generates an overlay image where only changed pixels are included and the rest of the image is transparent. This allows for overlaying multiple images with multiple lights turned on together without the need for different renders for all possible combinations. And to get the best results for lights that do interact with each other, the lights that appear in the same room will be rendered with all possible combinations.

That last clause is the key to the mode. The combinatorial explosion is confined to a room rather than applied to the whole floor, which significantly reduces the number of rendered images compared to all possible combinations of the entire floor.

Complete renders is the brute-force option. This mode renders separate images for all possible light combinations on the rendered floor. It requires generating many renders but offers the best quality.

The progression is a real engineering trade. CSS mode is a handful of images and an approximation, room overlay is more images and a correct result within each room, and complete renders is every combination and an exact answer.

The configuration window is where the modelling assumptions live

The configuration options are the part of the plugin that determines whether the output is usable, and the summary lists them in detail.

The configuration window displays a list of detected lights grouped according to the room they are located in, and you are asked to verify the list matches your expectations. That verification step is the point, because the plugin is inferring your model's structure, and the inference depends on how the Sweet Home 3D project is organised. Lights are detected as stand-alone or within groups under SH3D.

Width and height configure the required output resolution of the rendered images. The light mixing mode is the rendering mode above. The render time is the date and time of the rendered image, which affects the sun position, intensity, and colour, and the night-time render option allows setting an additional render to be used during the night, which requires the Sun integration in Home Assistant, enabled by default.

The renderer selection is between YafaRay and SunFlow, the two rendering engines the plugin supports. The image format is PNG or JPEG, and the quality is low or high.

The floors option is only displayed when the project has multiple levels. You can render only the selected floor or all floors, each in its own directory such as `floorplan/1st_floor`, with buttons for switching between them, and levels without any entities, for example a roof, are skipped. There is a warning note here: rendering all floors requires installing the state-switch custom Lovelace card.

The visible entities only option is the most interesting. It includes only entities that are seen from the current camera, inside the rendered image and not hidden behind walls, floors, ceilings, or closed doors. Lights that are not seen but light up what is seen, for example a ceiling light above the camera, are included as well, while other lights are turned off.

That is careful work, because the alternative is a floor plan where you can toggle a light in a room you are not looking at, which is confusing. The progress bar at the bottom indicates how many images need to be rendered for the complete floor plan and progresses as they are ready, and the plugin caches previously rendered images to save time when generating the next floor plan.

Per-entity settings, and the display rules

Each entity in the detected list can be clicked to reveal additional settings, and there are separate panels for lights, for furniture, and for doors or windows, with the images in the project summary showing each.

The display type configures how the entity is displayed on the floorplan, using the Home Assistant picture-elements elements. The icon override allows overriding the default entity icon. The attribute option lets you specify which attribute to show for the entity label.

The display condition configures when the entity should be displayed. Entities that are out of the rendered view, for example behind the camera, are marked as Out of view and are not displayed by default. The tap action defines what happens when the entity is tapped or clicked, and the double tap action does the same for a double tap.

A small but useful detail is that settings modified from their default values are displayed in red, so you can see at a glance what you have customised in a list of a hundred entities.

The doors and windows having their own panel is worth a moment, because it implies the plugin models more than lights. A door entity with a state means an open or closed door can be shown on the plan, and if a door is closed it can be excluded from what a camera sees, which is what the visible entities only option depends on.

The output side is the YAML file and the images, and the instructions are explicit about the manual step involved. You copy all images under the `floorplan` folder to your Home Assistant path, then create a card of type `picture-elements` in Home Assistant and paste the contents of the generated `floorplan.yaml`.

That is a deliberate division of responsibility. The plugin is a generator, not an installer, and it does not need to know anything about your Home Assistant configuration layout, how you version it, or how you deploy it.

The build, the toolchain, and the release cadence

The Makefile shows how the plugin is compiled and packaged, and it is a useful window into the constraints of the Sweet Home 3D plugin format.

The source lives under `src/com/shmuelzon/HomeAssistantFloorPlan`, the Java package path, and the version comes from `git describe --always --tags`. The build targets Java 1.8 with `-target 1.8 -source 1.8`, and the output is a `.sh3p` file, which is Sweet Home 3D's plugin archive format, named with the version.

The compile step runs inside a container when Docker is available, using the `eclipse-temurin:8-noble` image, with the working directory mounted and the host user's uid and gid passed in so the produced files are not owned by root. The Java 8 base image is there because the plugin has to run inside the Sweet Home 3D application, which bundles its own Java runtime, and a plugin built against a newer Java would fail to load. That is a hard constraint of the host application rather than a preference.

The dependencies are downloaded rather than vendored. The Sweet Home 3D jar itself comes from SourceForge at version 7.5, and the Java3D core and vecmath jars come from JogAmp. The build has targets for each, and a `clean` and a `distclean` target where distclean also removes the downloaded directory.

The properties files are generated with `envsubst`, which is how the version and other build-time values get into the plugin's resource files.

The release history shows a project that ships often. v0.15.7 was in January 2026, v0.16.0 on 2026-10-01, and v0.17.0 on 2026-10-10, and the last push was on the same day as the v0.17.0 tag. A version 0.x with a release every few weeks is a fast-moving project that has not yet settled its API, which for a plugin you install once and point at your model is probably fine, since the output is a folder of images and a YAML file rather than a library you link against.

The licence is MIT, the repository is MIT licensed, and the language is Java.

Where this plugin is the wrong tool

The limits are specific, and most of them come from the fact that the output is a rendered picture rather than a live model.

First, and this is the big one, the images are static. The plugin renders your flat offline, at a chosen date and time, and the resulting pictures do not change when your house changes. The dashboard is live in the sense that Home Assistant's entity state is overlaid on a fixed image, so a light that has been moved or a piece of furniture that has been moved since the last render will be wrong on the plan, and nothing warns you. A user who redecorates has to re-run the plugin, and the summary does not describe any automation that would do that for you.

Second, the whole thing depends on Sweet Home 3D. You need a Sweet Home 3D project, and you need it organised in a way the plugin's light detection can understand, with lights as stand-alone objects or as groups, and with rooms that the grouping logic recognises. The configuration window asks you to verify the detected list, which is the point where you find out that your model does not match the assumptions. If you do not have a 3D model of your flat already, building one is a substantial task in a different application.

Third, the render time cost is real in the complete renders mode, where you get an image for every possible light combination on the floor. The CSS mode avoids that with a browser-side mix, and the room overlay mode confines the combinations to a room. A large flat with many lights in the complete mode is a long render, and the progress bar is there because it can be a long wait.

Fourth, the sun position and the time of day are baked in. The render time setting affects the sun position, intensity, and colour, and the night-time render option is a second set of images used at night, which requires the Home Assistant Sun integration. A house that looks right at noon and wrong at midnight, or vice versa, is a lighting design problem the plugin cannot solve, only work around with two renders.

Fifth, and this is a workflow constraint, the output is copied by hand. The images go into your Home Assistant path and the YAML goes into a picture-elements card you create yourself. That is the right design for a plugin that must not assume anything about your configuration setup, and it does mean there is no in-place update and no way to regenerate from Home Assistant. Every re-render is a manual copy.

Sixth, the version numbers tell you where the project is. This is a 0.x plugin with releases every few weeks, the default branch is `master`, and the build is pinned to a Java 8 toolchain because the host application requires it. None of that is a problem for a plugin you install and run, and all of it means you should expect the output format and the options to keep changing.

Editorial conclusion

Home Assistant Floor Plan fits a person who already has a Sweet Home 3D model of their flat and wants a Home Assistant dashboard that looks like their actual home rather than a schematic, with lights toggling in the picture. It is the wrong tool if you have no 3D model, or if you want real-time state without a render step, since the images are generated offline and are not live. Check three things before you start: that your Sweet Home 3D model is organised so the plugin can detect the lights, that you can tolerate the offline rendering time in the mode you choose, since complete renders mean one image per light combination, and that the resulting YAML and images are something you are willing to copy into your Home Assistant configuration by hand, since the plugin produces files rather than installing anything.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. shmuelzon/home-assistant-floor-plan on GitHub