* Expose `send_local_time()` as public, for use in lambdas.
This will send the current time configured in `time_id`.
* Add a new `set_clock()` public method, separate from time_id.
This allows setting the clock manually, without syncing from a Time
Component. Again this can only be called from ESPHome; i.e.,
generally from a lambda.
* Rework HOME/AWAY support to being driven via a map of ClimatePreset/ThermostatClimateTargetTempConfig
This opens up to theoretically being able to support other presets (ECO, SLEEP, etc)
* Add support for additional presets
Configuration takes the form;
```
climate:
platform: preset
...
preset:
[eco | away | boost | comfort | home | sleep | activity]:
default_target_temperature_low: 20
default_target_temperature_high: 24
```
These will be available in the Home Assistant UI and, like the existing Home/Away config will reset the temperature in line with these defaults when selected. The existing away_config/home_config is still respected (although preset->home/preset->away will be applied after them and override them if both styles are specified)
* Add support for specifying MODE, FAN_MODE and SWING_MODE on a preset
When switching presets these will implicitly flow through to the controller. However calls to climate.control which specify any of these will take precedence even when changing the mode (think of the preset version as the default for that preset)
* Add `preset_change` mode trigger
When defined this trigger will fire when the preset for the thermostat has been changed. The intent of this is similar to `auto_mode` - it's not intended to be used to control the preset's state (eg. communicate with the physical thermostat) but instead might be used to update a visual indicator, for instance.
* Apply lint, clang-format, and clang-tidy fixes
* Additional clang-format fixes
* Wrap log related strings in LOG_STR_ARG
* Add support for custom presets
This also changes the configuration syntax to;
```yaml
preset:
# Standard preset
- name: [eco | away | boost | comfort | home | sleep | activity]
default_target_temperature_low: 20
...
# Custom preset
- name: My custom preset
default_target_temperature_low: 18
```
For the end user there is no difference between a custom and built in preset. For developers custom presets are set via `climate.control` `custom_preset` property instead of the `preset`
* Lint/clang-format/clang-tidy fixes
* Additional lint/clang-format/clang-tidy fixes
* Clang-tidy changes
* Sort imports
* Improve configuration validation for presets
- Unify temperature validation across default, away, and preset configuration
- Validate modes for presets have the required actions
* Trigger a refresh after changing internals of the thermostat
* Apply formatting fixes
* Validate mode, fan_mode, and swing_mode on presets
* Add preset temperature validation against visual min/max configuration
* Apply code formatting fixes
* Fix preset temperature validation
Nicholas Peters