Unified climate entity per room

[snazzybean]

Description

Replace the current scattered per-room entities (sensors, switches, override climate entity) with a single, full climate entity per room. This is the HA-native way to represent climate control and was suggested by @c2who in #91.

Current state (per room)

• sensor.roommind_{area}_target_temp
• sensor.roommind_{area}_mode
• climate.roommind_{area}_override
• switch.roommind_{area}_climate_control

Proposed

One climate.roommind_{area} entity that covers everything:

Climate feature	Maps to
HVAC mode (heat/cool/heat_cool/off)	Room mode + enable/disable (replaces switch.*_climate_control)
Presets (eco/boost/comfort)	Override mechanism (replaces climate.*_override)
Target temperature slider	Direct target temp control (replaces sensor.*_target_temp)
hvac_action (heating/cooling/idle)	Current state (replaces sensor.*_mode)

Benefits

• One entity instead of four per room
• Works natively with HA dashboards, automations, voice assistants (Google Home, Alexa)
• Standard HA UX. No RoomMind-specific entity knowledge needed.

Considerations

• Breaking change for users with automations targeting current entities. Needs migration path or transition period.
• RoomMind's target resolution (override > vacation > presence > schedule > comfort/eco) must map cleanly to the climate entity model.
• The existing climate.*_override entity can serve as the starting point and be expanded.

References

• Toggle control for each room individually #91 (original discussion by @c2who)

[hecktech27]

might be a good chance to add support for #83 ;)

[Psykar]

I've vibed the heck out of something here, which actually works decently. It address most of what is mentioned here, but still has some sharp edges around updating the climate entity when the schedule changes targets.

I haven't reviewed the code at all yet so I'm hestiant to make an MR here, but it's here Psykar#2

In terms of thoughts on how it handles things though:

• Roommind's side dash is the source of truth
• Climate entity does optimistic updates async and then updates its own values after the response from roommind
• Presets were made for (comfort/eco/override/schedule) - didn't make one for vacation/presence, but I think presets work fine here.
• Schedule is self explanatory, if the temp is changed it moves to the override preset (but doesn't do a timeout)
• If one of the other presets is chosen manually it also doesn't timeout, but now altering the temperature changes the preset (this is handy IMO, but maybe should be gated behind a config toggle on roommind's side, and instead have the same behavior as schedule - that changing the temp changes it to override

TODO:

• Maybe expose the timeout on mode overrides to be exposed as an entity so you can put it on a dash beside the climate entity
• Fix up the climate entity not updating its temps when the roommind schedule changes modes

If this is going in the right direction I'll review it properly and actually get it into a sane state to do a PR, or someone else can grab it if they want to do so - as I might take a while to get that cleanup done.

[Psykar]

Oh I believe it did deal with #83 but I'm not sure if it's done it well 😇

But, I am using this and have been for over a week now :)

[snazzybean]

Love that you built something and have been running it for a week, that's the best kind of signal. Before you invest more cleanup time, a few things worth thinking through, since they shape the API surface:

RoomMind's target chain is override > vacation > presence > schedule > comfort/eco. HA only gives you one slider and one preset, so when a schedule is on comfort/schedule and the user drags the slider, something has to give. Your "schedule → override, other presets → mutate in place" split is reasonable but it's a real design call.

For auto mode with the dual-slider, the thing to watch is preset switching keeping both sides in sync, since rooms with climate_mode: auto carry separate heat/cool comfort and eco temps.

Managed Mode (no external temp sensor) is worth a second look, since the device self-regulates there and RoomMind only forwards. Not obvious what hvac_action should report in that case.

Vacation and presence you skipped, which I get, they're system-driven. But the entity still has to reflect them somehow or automations and voice get a stale picture.

And migration: keeping old entities alongside is fine for a transition but shouldn't be permanent. A Repairs flow with deprecation is the cleaner path long-term.

None of this is a blocker. Just wanted to flag before you put more time in it.
Thanks for you work so far!

[Psykar]

Thanks. I backflipped on the sliders updating the presets, instead going with changing the slides immediately changes to an override (and added an entity for the default override time, which can be set before moving it)

The target chain is a little tricky conceptually to line up, yes. I think I missed that schedule is ahead of comfort/eco, but I guess on the existing UI clicking comfort/eco is effectively applying an override.

The dual slider seems to be sync'd fine.

Managed Mode (no external temp sensor) is worth a second look, since the device self-regulates there and RoomMind only forwards. Not obvious what hvac_action should report in that case.

Hmm. Might have to see about making a fake climate device to test this. I don't want to mess too much with our actual heating system, and the whole reason I'm here is our reverse cycle heat pump has atrocious self regulation.

Vacation and presence you skipped, which I get, they're system-driven. But the entity still has to reflect them somehow or automations and voice get a stale picture.

Yeah, not sure on best approach there yet, just showing them in the preset list might work, so that selecting them toggles them in RoomMind. Should work I think.

And migration: keeping old entities alongside is fine for a transition but shouldn't be permanent. A Repairs flow with deprecation is the cleaner path long-term.

What's the preference for managing this? My approach was going to be keep them around, but ensure they only are wrapping the new ones, so that deleting them in a later MR has no functional change?

An aside is I was going to include UI changes to the sidebar/dash that shows target ranges instead of single values in a few place (see screenshot) but perhaps those are better in a separate MR.

[dfischer0]

Any update on this? This would be really useful to avoid having to resort to the full RoomMind page for overrides.

[Psykar]

There has been an override climate entity merged in the latest release.
#313