esphome / esphome/feature-requests

Thermostat climate control component should expose more of itself to external C++

Open
#2,265 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
No language data
Stars
450
Forks
29
PR merge metrics
No merged PRs in 30d

Description

**Describe the problem you have/What new integration you would like**

I'd like to be able to have `lambda`s in my YAML access `const` views of at least `supplemental_action_`, to display more about the thermostat's current state.

I'd also like a trigger when someone takes the configuration off a preset (that is, changes something without changing the preset). The existing `target_temperature_change_action` works for the temperature endpoints, and there's `change_preset` for switching _between_ presets, but AFAICT there is no corresponding call for when any of the {climate mode, fan mode, swing mode} are changed without changing the preset. Moreover, there's no ability to tell whether the current settings match those of the current preset, because there's no way to get at the thermostat's preset (or custom preset) mappings and/or the `ThermostatClimateTargetTempConfig` object associated with the current preset.

**Please describe your use case for this integration and alternatives you've tried:**

The first point is just to have a more detailed display on the thermostat. I could approximate it by reading the actual outputs and the current action and then divining whether the supplemental cooling action had been called, but it would be nicer to hear it directly from the horse's mouth, as they say.

For the second, I have written some `cron` logic that changes the thermostat preset at scripted times of the day, and I want that logic to fire only if nobody has altered the settings otherwise. Towards that end, my YAML currently has
```
target_temperature_change_action:
then:
# Take us off preset when someone changes the temperature

# TODO: We can't do this when someone takes us off the default mode or fan_mode
# for lack of a trigger. That's sad, and it's why our cron jobs above have to
# test for the mode and fan mode.
- lambda: |
auto cc = id(climate_control);
cc->preset.reset();
cc->custom_preset.reset();
```
and the alluded to check is this mess:
```
- id: climate_conditional_preset
parameters:
preset_from: int
preset_to: int
then:
- if:
condition:
# TODO: This shouldn't hardcode the tests on ->mode and ->fan_mode, but should
# look inside cc's understanding of the preset. Unfortunately, that map is not
# public and there are no accessors.
lambda: |
auto cc = id(climate_control);
return (cc->preset == preset_from)
&& (cc->mode == CLIMATE_MODE_HEAT_COOL)
&& (cc->fan_mode.value_or(CLIMATE_FAN_OFF) == CLIMATE_FAN_AUTO);
then:
- lambda: |
auto call = id(climate_control).make_call();
call.set_preset(static_cast(preset_to));
call.perform();
```
As the comment says, that test is only so good of an approximation of the behavior I think I want.

**Additional context**

Thoughts welcome.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.