auto-create groups from HA areas

[awhitwam]

New "Create from Area" button that lets users select Home Assistant areas and automatically create groups populated with their climate entities. Adds backend service create_groups_from_areas that queries area/entity/device registries, and a frontend modal with area checkboxes showing entity counts. Areas with existing matching groups are shown as disabled.

[kneave]

Great idea! I'll review it and see if I can get it in the next release :)

[kneave]

Sorry for the delay with this, I've had a hectic month or so and got a little behind schedule. Planning on spending some time getting back up to speed this weekend.

[kneave]

Sorry I've not been able to look at this yet, it looks like you've added a lot more functionality here than just the area creation though. Could you let me know more about the things you've added to I can properly review them please?

[awhitwam]

Hi Keegan, I believe the only change in the original pull request was the ability to add thermostats by their Home Assistant area (details in item 1 below). However, I have since made several additional tweaks on my own fork. These are fairly specific to my requirements, so you may not want to merge them, but I’ve listed them below for info. I also attached a few screenshots for reference. The integration is working very well in my setup, especially with a large number of thermostats. Thank you for all your hard work on this 1. Create Groups from Home Assistant Areas *New feature* — A "Create from Area" button on the main page lets you auto-create thermostat groups based on HA areas. Each area containing climate entities becomes a group with those entities pre-assigned. - New backend service create_groups_from_areas in services.py - Frontend modal with area picker (select all/none), in panel.js and app.js - New HA API methods: getAreas(), getEntityRegistry(), getDeviceRegistry(), createGroupsFromAreas() in ha-api.js - Filters out the integration's own climate entities to avoid self-reference - Skips areas that already have a matching group name

…

------------------------------ 2. Group Header Temperature Display *New feature* — Show live current temperatures for selected entities directly in the group header row (collapsed view), so you can monitor temps without expanding the group. - Per-entity "S" (show) toggle button in the group members table - Entities flagged as "show" display as Name: 18.5° in the header, with orange highlighting when actively heating - Shared target temperature shown as a prefix arrow (20.0° ←) - Custom display names per entity (edit with ✎ button), persisted via group_header_temps in settings - Auto-refreshes every 30 seconds - Settings migrate cleanly if group is renamed

------------------------------ 3. Graph Y-Axis Range Override *New feature* — Separate "Graph Min" and "Graph Max" settings allow you to zoom the graph's Y-axis independently of the thermostat min/max temperature limits. - New settings inputs in the Settings panel (graph_min_temp, graph_max_temp) - Falls back to min/max temp if not set - Useful for seeing detail when your temperatures only vary within a narrow range (e.g. 17–22°C)

------------------------------ 4. Running State Visualisation on Graphs *New feature* — Temperature history lines now visually indicate when the thermostat is actively heating vs idle. - Fetches sensor.{name}_running_state history alongside climate history - *Line thickness varies*: thick (3.5px) when heating, thin (1px) when idle, default (2px) if no sensor - *Data point dots turn red* (larger, 3px radius, 0.8 opacity) when heating; normal colour when idle - Gracefully handles entities without a running_state sensor (no errors, default rendering) - Works for both single-entity and group graphs

------------------------------ 5. Thermostat Update Delay Setting *New feature* — Configurable delay (in seconds) between successive thermostat commands during coordinator update cycles. - New "Thermostat Update Delay" setting in the Settings panel - Prevents overwhelming integrations (e.g. Zigbee) that struggle with rapid successive commands - Delay only applies after actual entity updates, not skipped entities - Skipped during initial startup to avoid slow boot

------------------------------ 6. Background Initial Sync *Improvement* — The integration's initial sync (loading schedules and applying temperatures) now runs in a background task instead of blocking HA startup. - 5-second delay before first sync to let climate entities finish loading - Prevents "unavailable" states caused by the integration trying to update entities that aren't ready yet - _initial_setup flag tracks startup phase (used to skip update delay during boot)

------------------------------ 7. Coordinator Logging Cleanup *Improvement* — Reduced log noise by downgrading most coordinator messages from _LOGGER.info to _LOGGER.debug. - Normal operation no longer floods the HA log - Error/warning messages remain at their original level - Added a summary line at the end of each update cycle: "Update cycle complete: X updated, Y skipped, Z total entities"

------------------------------ Files Modified File Changes __init__.py Background initial sync, new service registration coordinator.py Update delay, background sync flag, log level cleanup, update cycle summary services.py create_groups_from_areas service frontend/app.js Group header temps, area modal, running state parsing, graph range settings, update delay UI frontend/graph.js Segmented line rendering (running state), red heating dots frontend/ha-api.js Area/entity/device registry API methods frontend/panel.js Area modal, graph range inputs, update delay input frontend/styles.css Minor styling manifest.json Version bump frontend/.version Version bump

On Wed, 18 Mar 2026 at 22:20, Keegan Neave ***@***.***> wrote: *kneave* left a comment (kneave/climate-scheduler#155) <#155 (comment)> Sorry I've not been able to look at this yet, it looks like you've added a lot more functionality here than just the area creation though. Could you let me know more about the things you've added to I can properly review them please? — Reply to this email directly, view it on GitHub <#155 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGVVVB6HXX73ZMZPSVJRYW34RMOLHAVCNFSM6AAAAACVNGP6P2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAOBVHEZDSMJTGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Andy Whitwam