Version
2026.2
What type of installation are you using?
Home Assistant Add-on
Browser
all of them
What happened?
RFC / Proposal: Tags or Folders for ESPHome Dashboard Devices (Filtering + Scoped Actions)
Hi ESPHome team 👋
First off: thank you for ESPHome and the dashboard — it’s been rock-solid for me across a fairly large homelab and production setup.
I wanted to start a conversation (and potentially a PR) around organizing devices in the ESPHome dashboard, because I’ve hit a scaling pain point that I know other users have been asking about for a while.
The Problem (from real usage)
I currently run a mix of:
- production devices (things that should basically never break),
- sandbox / testing devices,
- and various experiments / retired devices that may be offline for long periods.
Once you cross ~15–20 devices, the dashboard becomes:
- visually noisy,
- harder to scan for “what actually matters right now”,
- and slightly dangerous operationally (e.g. “Update all” is no longer something I trust myself to click).
Here’s what my dashboard looks like today (production + sandbox all mixed together):
(screenshot omitted here, but imagine a wall of red OFFLINE cards next to critical prod devices)
I know I’m not alone in this — there are several long-standing feature requests asking for folders, tags, or filtering.
Related Issues / Existing Requests
A few examples (not exhaustive):
These have been open for a while, which makes me think:
- this is clearly useful,
- but also that there may be architectural or UX tradeoffs worth discussing before anyone jumps into code.
Proposal (MVP-first, low risk)
I’d love to propose device tags + filtering, rather than hard filesystem folders, as a first step.
Why tags (instead of folders)?
- No need to move YAML files around.
- Backward-compatible with existing setups.
- Covers the common cases (prod / sandbox / lab / testing).
- Can later evolve into folder-like “views” if desired.
What this would look like (MVP)
- Devices can have 0..n tags (e.g.
prod, sandbox, lab, hvac).
- Tags are shown as small chips on each device card.
- The dashboard top bar gets a tag filter (multi-select).
- Filters persist across reloads (local storage is fine initially).
- When a filter is active, bulk actions apply only to the filtered set
(e.g. “Update filtered” instead of blindly “Update all”).
Nothing fancy, just enough to:
- keep production devices front-and-center,
- hide noisy offline experiments by default,
- and make bulk operations safer.
Storage / Implementation (very open to guidance)
One possible approach (but very open to maintainer input):
- Store tags in a dashboard metadata file (e.g.
.esphome/dashboard.json) keyed by device name or filename.
- Expose tags through the existing dashboard API.
- Keep ESPHome YAML itself untouched.
Alternative approaches (tags in YAML comments, etc.) could also work — I’m not opinionated here and would love guidance on what fits best with the project’s direction.
What I’m Asking
Before I sink time into a PR, I wanted to ask the maintainers directly:
-
Would you be open to accepting a PR that adds device tags + filtering to the ESPHome dashboard?
-
Are there any known pitfalls, architectural constraints, or UX concerns we should be aware of up front?
- Dashboard state storage?
- Device identity / renames?
- Home Assistant add-on constraints?
-
Is there a preferred direction between:
- tags vs folders,
- frontend-only state vs backend-persisted metadata?
Happy to start with a small, conservative MVP and iterate from there.
Motivation (why now)
For me personally, ESPHome has crossed from “DIY fun” into production infrastructure. The dashboard is now something I rely on operationally, not just configurationally. Organization and scoped actions would meaningfully reduce mistakes and mental overhead.
Judging by the number and age of the linked issues, I suspect this would help a lot of other power users as well.
Thanks for reading — and thanks again for all the work you put into ESPHome.
If this sounds reasonable, I’m happy to draft a design PR or start hacking on an implementation.
— Ivan
How to reproduce
N/A, had to use this template to land in this repo. Thanks for understanding!
Expected behavior
N/A, had to use this template to land in this repo. Thanks for understanding!
Relevant log output
Screenshots
No response
Version
2026.2
What type of installation are you using?
Home Assistant Add-on
Browser
all of them
What happened?
RFC / Proposal: Tags or Folders for ESPHome Dashboard Devices (Filtering + Scoped Actions)
Hi ESPHome team 👋
First off: thank you for ESPHome and the dashboard — it’s been rock-solid for me across a fairly large homelab and production setup.
I wanted to start a conversation (and potentially a PR) around organizing devices in the ESPHome dashboard, because I’ve hit a scaling pain point that I know other users have been asking about for a while.
The Problem (from real usage)
I currently run a mix of:
Once you cross ~15–20 devices, the dashboard becomes:
Here’s what my dashboard looks like today (production + sandbox all mixed together):
I know I’m not alone in this — there are several long-standing feature requests asking for folders, tags, or filtering.
Related Issues / Existing Requests
A few examples (not exhaustive):
Organize devices in the web UI with tags or folders
Organize devices in the webUI with tags or folders feature-requests#3160
(explicitly mentions persistent filters and separating prod vs non-prod)
Organise devices in Folders
Dashboard: Organise devices in Folders feature-requests#867
(also calls out updating subsets instead of everything)
Dashboard filtering / sorting (offline, etc.)
Device filter feature-requests#1728
These have been open for a while, which makes me think:
Proposal (MVP-first, low risk)
I’d love to propose device tags + filtering, rather than hard filesystem folders, as a first step.
Why tags (instead of folders)?
What this would look like (MVP)
prod,sandbox,lab,hvac).(e.g. “Update filtered” instead of blindly “Update all”).
Nothing fancy, just enough to:
Storage / Implementation (very open to guidance)
One possible approach (but very open to maintainer input):
.esphome/dashboard.json) keyed by device name or filename.Alternative approaches (tags in YAML comments, etc.) could also work — I’m not opinionated here and would love guidance on what fits best with the project’s direction.
What I’m Asking
Before I sink time into a PR, I wanted to ask the maintainers directly:
Would you be open to accepting a PR that adds device tags + filtering to the ESPHome dashboard?
Are there any known pitfalls, architectural constraints, or UX concerns we should be aware of up front?
Is there a preferred direction between:
Happy to start with a small, conservative MVP and iterate from there.
Motivation (why now)
For me personally, ESPHome has crossed from “DIY fun” into production infrastructure. The dashboard is now something I rely on operationally, not just configurationally. Organization and scoped actions would meaningfully reduce mistakes and mental overhead.
Judging by the number and age of the linked issues, I suspect this would help a lot of other power users as well.
Thanks for reading — and thanks again for all the work you put into ESPHome.
If this sounds reasonable, I’m happy to draft a design PR or start hacking on an implementation.
— Ivan
How to reproduce
N/A, had to use this template to land in this repo. Thanks for understanding!
Expected behavior
N/A, had to use this template to land in this repo. Thanks for understanding!
Relevant log output
Screenshots
No response