Feature area
Dashboard UI/template
Problem or use case
With pref_use_label_grouping: true, each label group's heading renders with a hardcoded mdi:label. Home Assistant labels already carry an icon and a color, set in Settings → Areas, labels & zones, but neither reaches the card. That makes every label group look identical, and the visual identity already configured in Home Assistant is discarded. Once a card has more than one label group, the headings are distinguishable only by their text.
Proposed solution
Carry icon (and potentially color) alongside the label name in the chore row's label payload, then use it when building label groups, falling back to today's behavior.
Relevant spots:
helpers/entity_helpers.py → get_friendly_label() looks up the registry entry and returns label_entry.name, discarding .icon and .color.- Chore sensors currently expose labels as a list of friendly-name strings.
templates/shared/chore_engine/prepare_groups_v1.yaml already handles labels as mappings with id/name, so a mapping carrying icon/color needs no shape change. The group build would become roughly 'icon': label.icon | default('mdi:label', true) in place of the literal.group_render_v1.yaml already styles the heading's styles.icon and styles.name, so a label color could feed those.
Fully backward compatible: string labels keep working and the fallback preserves current output.
Given #124 ("state attributes exceed maximum size"), adding fields to every chore row has a size cost. It may be better to send label metadata once per card rather than repeated on each row.
Expected outcome
Label groups become distinguishable at a glance, which matters most on kids' dashboards where scanning speed is the point. It also honors the icon and color already chosen in Home Assistant, instead of requiring a hand edit to the generated card which is lost on every dashboard regeneration.
Alternatives considered
- Hardcoding the icon in the inlined
prepare_groups_v1 fragment. Works, but it's per-card, doesn't scale past one label, and has to be reapplied after every regeneration.
- A label-name → icon lookup dict in the card. Same drawback, slightly more scalable.
- A template-side lookup. Tested in Tools → Template:
label_icon is undefined as both function and filter. Only labels(), label_id(), and label_name() are available, so there's no workaround from Jinja.
Additional context
My use case is a "Side Quests" bonus card holding shared_first chores with no due date, no recurrence, and manual reset, isolated onto its own card with pref_include_label_list plus label grouping. I'd like the label icon and color to better reflect the difficulty of the quest. Related: #145, #269, #154.
Claude Code helped with some details for this submission. Please be gentle if I got anything wrong!
Feature area
Dashboard UI/template
Problem or use case
With
pref_use_label_grouping: true, each label group's heading renders with a hardcodedmdi:label. Home Assistant labels already carry an icon and a color, set in Settings → Areas, labels & zones, but neither reaches the card. That makes every label group look identical, and the visual identity already configured in Home Assistant is discarded. Once a card has more than one label group, the headings are distinguishable only by their text.Proposed solution
Carry icon (and potentially color) alongside the label name in the chore row's label payload, then use it when building label groups, falling back to today's behavior.
Relevant spots:
helpers/entity_helpers.py→get_friendly_label()looks up the registry entry and returnslabel_entry.name, discarding.iconand.color.templates/shared/chore_engine/prepare_groups_v1.yamlalready handles labels as mappings withid/name, so a mapping carryingicon/colorneeds no shape change. The group build would become roughly'icon': label.icon | default('mdi:label', true)in place of the literal.group_render_v1.yamlalready styles the heading'sstyles.iconandstyles.name, so a label color could feed those.Fully backward compatible: string labels keep working and the fallback preserves current output.
Given #124 ("state attributes exceed maximum size"), adding fields to every chore row has a size cost. It may be better to send label metadata once per card rather than repeated on each row.
Expected outcome
Label groups become distinguishable at a glance, which matters most on kids' dashboards where scanning speed is the point. It also honors the icon and color already chosen in Home Assistant, instead of requiring a hand edit to the generated card which is lost on every dashboard regeneration.
Alternatives considered
prepare_groups_v1fragment. Works, but it's per-card, doesn't scale past one label, and has to be reapplied after every regeneration.label_iconis undefined as both function and filter. Onlylabels(),label_id(), andlabel_name()are available, so there's no workaround from Jinja.Additional context
My use case is a "Side Quests" bonus card holding
shared_firstchores with no due date, no recurrence, and manual reset, isolated onto its own card withpref_include_label_listplus label grouping. I'd like the label icon and color to better reflect the difficulty of the quest. Related: #145, #269, #154.Claude Code helped with some details for this submission. Please be gentle if I got anything wrong!