Describe the problem you have/What new integration you would like
I'd like to be able to have lambdas 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<esphome::climate::ClimatePreset>(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.
Describe the problem you have/What new integration you would like
I'd like to be able to have
lambdas in my YAML accessconstviews of at leastsupplemental_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_actionworks for the temperature endpoints, and there'schange_presetfor 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 theThermostatClimateTargetTempConfigobject 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
cronlogic 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 hasand the alluded to check is this mess:
As the comment says, that test is only so good of an approximation of the behavior I think I want.
Additional context
Thoughts welcome.