Names, Icons, Areas, and Labels: Order Before the Dashboard

Before you place a single card on the Home, Office, Admin, or any other view this module builds, every entity you plan to use genuinely deserves a clear name, a sensible icon, and a proper area assignment. This housekeeping lesson feels like a detour from dashboards themselves, but skipping it is exactly why so many real dashboards end up cluttered with switch.shellyplus1pm_a4cf12 instead of a plain, readable "Hallway LED."

Friendly name versus entity_id: two genuinely different things

An entity_id like switch.led_status_hallway is a stable technical identifier that automations, scripts, and YAML reference directly, while a friendly name like "Hallway LED" is purely the label a dashboard card actually displays to a household member. These two genuinely serve different audiences, the entity_id speaks to the system and to you as its builder, the friendly name speaks to whoever is simply glancing at a tile wondering what it controls.

Three genuinely distinct levels: device, entity, name

A single physical device, a Shelly relay, a Zigbee bulb, an ESPHome board, can genuinely expose several entities at once, a switch entity, a power-sensor entity, an uptime-sensor entity, each with its own separate name and its own separate entity_id. Keeping these three levels straight, the device as the physical object, each entity as one measurable or controllable aspect of it, and the name as what a person actually reads, prevents a great deal of the confusion this lesson exists to head off.

What renaming actually changes, and what it never touches

Changing a friendly name in the entity settings panel updates only what's displayed on cards and in the entity list, it never touches the entity_id itself, and any automation or script referencing switch.led_status_hallway keeps working exactly as before, completely undisturbed by the rename. This is genuinely reassuring, it means you can polish every display name freely across this entire lesson without any risk of quietly breaking a single automation built back in Module 11 or 12.

When to rename, and when to actually change the entity_id instead

Rename freely whenever the only problem is what a card displays, that's the vast majority of cases covered in this lesson. Changing the entity_id itself is a considerably bigger, riskier step, genuinely only worth doing early, before you've written dozens of automations referencing the old id, because every single reference across every automation, script, and template needs updating by hand afterward, and missing even one quietly breaks that automation without any obvious warning.

Icons: a small detail that genuinely changes recognition speed

Every entity in Home Assistant carries a default icon based on its domain, a generic bulb for lights, a generic switch shape for switches, but a genuinely well-chosen custom icon, a specific ceiling-light glyph instead of a generic bulb, a fan icon instead of a generic switch shape, lets a household member recognize a tile's purpose almost instantly, before even reading its label. This tiny investment, a few seconds per entity, pays off every single day the dashboard actually gets used.

Areas and labels: two genuinely different organizing tools

An area assigns an entity to one physical place, Hallway, Office, Living Room, and Home Assistant uses that assignment to auto-generate area cards and area-based voice commands. A label is genuinely different, a tag like "diagnostic" or "test-mode" that can cut clean across areas, letting you filter for every diagnostic-flagged entity in the whole house regardless of which room it physically sits in, a capability the rebuilt diagnostic view later in this module leans on directly.

A YAML example: overriding a name at the card level

type: tile
entity: switch.led_status_hallway
name: Hallway LED
icon: mdi:led-outline

Notice this card-level override doesn't touch the entity's actual registered name at all, it simply displays "Hallway LED" and a specific LED icon on this one particular card, while every other card referencing the exact same entity elsewhere keeps showing whatever name is registered globally, unless it too carries its own local override.

A six-question checklist before naming any entity

Before finalizing a name, genuinely ask six quick questions: does it name the thing or the technology, does it read naturally in a sentence, would a guest understand it instantly, does it distinguish this entity from every similar one in the house, is it short enough for a tile's limited space, and does its icon match what it actually controls. An entity passing all six questions rarely ever needs renaming again later.

A real-life example: a household member glancing at Start

Picture a household member glancing at the Start view built later in this module, scanning quickly for whether the hallway light is on. A tile labeled "switch.shellyplus1pm_a4cf12" with a generic default icon forces them to stop and actually think, while a tile labeled "Hallway LED" with a matching light-bulb icon answers the question in well under a second, exactly the difference this entire lesson's housekeeping is genuinely working toward.

Step by step: renaming and re-iconing one entity

Open Settings, then Devices and Entities, and search for the entity in question. Open its entity settings panel, edit the Name field to something genuinely plain and specific, click the icon field and search for a more fitting glyph, and assign an Area if none is set yet. Save, then check any dashboard card already referencing that entity to confirm the new name and icon actually appear as expected.

What not to do when naming entities

Don't rename an entity to describe a temporary state, "Currently Off" becomes wrong the instant it turns on. Don't copy the raw entity_id into the friendly name field verbatim, defeating the entire point of a friendly name. And don't leave every entity in one giant unsorted "No area" bucket, since areas are exactly what let Home Assistant's own auto-generated area cards and voice assistant integration actually function the way they're designed to.

An exercise: clean up five entities right now

Pick five entities you'll actually use across this module's upcoming views, the hallway and office LEDs, the office temperature threshold, the movie-night scene, and one ESPHome sensor, and run each one through the six-question checklist above, fixing its name, icon, and area assignment as needed. Doing this now, before a single card exists, means every view built for the rest of this module starts from genuinely clean, readable material.

Device name versus entity name: which one actually wins

Home Assistant genuinely lets you set a name at the device level and a separate name at the entity level, and by default an entity's displayed name is built by combining the two, "Hallway Shelly Power" for a power-monitoring entity on a device named "Hallway Shelly." Once you give the entity its own explicit name instead, that combination logic is genuinely bypassed entirely, and only your chosen entity name displays, which is exactly why two entities on the very same physical device can end up looking completely unrelated on a dashboard if you're not paying attention to which level you actually edited.

A naming pattern worth adopting: room, then thing

A genuinely simple, consistent pattern, room first, then the thing itself, "Hallway LED," "Office Temperature Threshold," "Office Movie Night," reads naturally in an entities list, sorts sensibly when entities from several rooms sit alphabetically together, and scales cleanly as the house grows to dozens of entities across many more rooms. Adopting one single consistent pattern early, rather than naming each entity however feels convenient in the moment, saves you from a genuinely messy, inconsistent entity list several months into actually using the system daily.

Icons and color: matching visual weight to real importance

Beyond simply picking a fitting glyph, several card types let an icon's color genuinely respond to entity state, a thermostat icon turning warm orange above a threshold, a door-sensor icon turning red while open, giving a household member a color-coded signal before they even read a single word of text. Reserve this coloring for entities where state genuinely matters at a glance, applying it to every single entity indiscriminately dilutes its usefulness back down to visual noise very quickly.

Areas power more than dashboards alone

Assigning entities to areas genuinely does more than tidy up an entities list, it also feeds Home Assistant's built-in area cards, its voice assistant integrations, and its automation area-targeting features, letting you write a single automation that acts on "all lights in the Office" without hand-listing every entity_id involved. This is a genuinely good reason to finish area assignment properly now, well before Module 14 introduces the central control panel that leans on exactly this area structure directly.

Labels as a second, cross-cutting dimension

Where an area answers "where is this," a label genuinely answers a completely different question, "what category does this belong to regardless of location," letting you tag test_mode_hallway, test_mode_office, and every other test-mode helper across the whole house with a single "diagnostic" label even though they sit in entirely different areas. The rebuilt diagnostic dashboard later in this module filters directly on that one label, which is precisely why setting labels up correctly now saves considerable rework later.

What can genuinely go wrong with naming and organizing

Two entities can genuinely end up with the exact same friendly name if you're not careful, "Temperature" appearing on both a hallway sensor and an office sensor, forcing anyone reading a card to guess which one they're actually looking at. Areas can drift out of date as devices get physically moved between rooms without anyone updating their area assignment to match. And icons chosen purely for looking nice, rather than for actually matching an entity's real function, can genuinely mislead a household member into tapping the wrong control entirely.

A quick audit: search your entity list for duplicates

Open the full entities list under Settings and sort by name rather than by entity_id, scanning for any two entities sharing an identical or near-identical friendly name. Each duplicate you genuinely find is worth resolving immediately, prefixing with the room name if nothing else, since a genuinely ambiguous name discovered later, once it's already baked into several dashboard cards, takes considerably longer to track down and fix than catching it here in this single dedicated pass.

Batching the cleanup rather than doing it entity by entity forever

Rather than fixing names one entity at a time whenever you happen to notice a bad one, set aside one genuinely dedicated session, twenty or thirty minutes, and work straight down the full entities list for each room in turn, hallway first, then office, then any shared or whole-house entities last. This batched approach is considerably more efficient than the constant small interruptions of fixing names reactively one at a time, and it means every single view built for the remainder of this module can safely assume the underlying entity list is already genuinely clean and properly organized.

Why this lesson genuinely earns its place before dashboards

It would genuinely be tempting to skip straight from card types to building the Start view, treating names and icons as a minor detail to fix later if it ever becomes a problem. But every view this module still has to build, Start, Office, the rebuilt Diagnostic view, Admin, mobile, and desktop, references the exact same underlying entities, and fixing a sloppy name once here, at the source, is considerably cheaper than fixing it six separate times across six separate cards spread across six separate views.

Keeping a running note as you go

This course has repeatedly recommended a notebook for tracking automations, helpers, and scripts, and naming decisions genuinely deserve the exact same treatment, a short running note of your chosen naming pattern, your label vocabulary, and any exceptions you deliberately made, so that six months from now you're extending an established, documented convention rather than trying to reverse-engineer your own past decisions from a half-remembered dashboard.

A brief note on multilingual or unusual household naming

Some households genuinely prefer entity names in a language other than English, or in a private household shorthand only family members actually recognize, and Home Assistant's friendly name field genuinely accepts any text at all, there's no requirement to use plain generic English terms like the examples throughout this lesson. What actually matters is consistency within your own household's chosen convention, not which specific language or shorthand you settle on, since the whole real point of this entire lesson is genuinely straightforward readability for the actual people who will honestly be looking at these dashboards every single day for years to come.

This lesson's real payoff shows up gradually, not today

None of this housekeeping produces a single visible dashboard today, and that can genuinely make it feel like the least rewarding lesson in the entire module, but its actual real payoff genuinely arrives gradually over time, every single card in the Start view reading cleanly the very first time it appears, no awkward mid-project renaming ever disrupting a nearly finished Office view, and a full diagnostic dashboard whose labels already do exactly what's genuinely needed the moment it gets rebuilt later in this module. Treat this entire lesson as deliberately front-loaded, genuinely necessary work that the rest of the whole module ultimately depends on directly.

Key takeaways

What's next

With every entity genuinely named, iconed, and placed in its area, the next lesson turns to charts, when a history graph genuinely earns its space on a dashboard, and when it's simply clutter dressed up as information.