Skip to content

fix(areas): return area-controls in canonical order, not entity-iteration order (closes #201)#249

Open
TheDave94 wants to merge 1 commit into
TheRealSimon42:mainfrom
TheDave94:fix/area-controls-order
Open

fix(areas): return area-controls in canonical order, not entity-iteration order (closes #201)#249
TheDave94 wants to merge 1 commit into
TheRealSimon42:mainfrom
TheDave94:fix/area-controls-order

Conversation

@TheDave94
Copy link
Copy Markdown

Summary

Closes #201 — area card shortcut icons (light, cover-shutter, etc.) could appear in a different order between rooms with the same control mix. The reporter saw "light then shutter" in most rooms but "shutter then light" in one specific room, with no obvious reason.

Root cause

`getAreaControls` populated a `Set` while iterating `Registry.getVisibleEntitiesForArea(...)` and returned `[...found]`. JS `Set` preserves insertion order, and the entity registry returns entities in registration order, which differs across areas (depending on when each device was added to HA). So:

  • Room A registered the light first, then the cover → set is light, cover-shutter → renders "light, shutter"
  • Room B registered the cover first → set is cover-shutter, light → renders "shutter, light"

Fix

Replace [...found] with CONTROL_DOMAINS.filter((d) => found.has(d)), which uses the canonical declaration order of CONTROL_DOMAINS (light → fan → switch → cover-shutter → ... → cover-damper). Rooms whose icons happened to be in that order are unchanged; rooms with reversed order now align with the rest.

Test plan

  • Two rooms with the same control mix render shortcut icons in the same order
  • Rooms with different mixes still only show the icons that apply
  • TypeScript clean

AI-drafted under human supervision by @TheDave94. Tested live on Home Assistant — fully when the relevant hardware is available, otherwise only along the code paths that don't require an actual sensor of that type.

…mon42#201)

getAreaControls used Set insertion order to determine the order of
shortcut icons on area cards. The Set was populated by iterating the
entity registry, which returns entities in registration order — that
order varies between areas, so two rooms with the same control mix
(e.g. light + cover) could end up with the icons in different orders
on the area card.

Fix: filter CONTROL_DOMAINS by what was found, so the output order is
always canonical (light → fan → switch → cover-* in the order declared
in the constant). No behaviour change for areas where Set insertion
happened to match the canonical order; rooms with reversed order now
align with the rest.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@codacy-production
Copy link
Copy Markdown

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · 0 duplication

Metric Results
Complexity 0
Duplication 0

View in Codacy

NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.

@TheDave94 TheDave94 closed this May 20, 2026
@TheDave94 TheDave94 deleted the fix/area-controls-order branch May 20, 2026 22:44
@TheDave94 TheDave94 restored the fix/area-controls-order branch May 21, 2026 09:17
@TheDave94 TheDave94 reopened this May 21, 2026
@TheDave94 TheDave94 closed this May 22, 2026
@TheDave94 TheDave94 deleted the fix/area-controls-order branch May 22, 2026 05:55
@TheDave94 TheDave94 restored the fix/area-controls-order branch May 23, 2026 20:43
@TheDave94 TheDave94 reopened this May 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Reihenfolge Shortcut Icon in Raum vertauscht

1 participant