* Raise errors for all the now deprecated options
* Fix CONF_DEFAULT_PRESET detection
* Stop attempting to set the non-existent normal_config
* Add support for default presets
* Fix correct detection of Two Point temperature mode
* Fix lint issues
* Fix tests
* Generate correct yaml for equivalent configurations
* Remove debug code
* Only set default preset if the thermostat does not have state to restore
* Add restore_default_preset_on_boot option
If set to True then the default_preset will be applied on every boot. If False (Default) state will be restored from memory as per prior versions
* Apply lint suggestions
* Switch from restore_default_preset_on_boot to an enum for startup_behavior
This gives better self-documentation as well as the option for extending to other options down the track
* Lint fixes
* Rename startup_behavior to on_boot_restore_from
This removes any issues with different English locales
* Fix comparable_preset yaml output alignment
* Add dump of on_boot_restore_from setting
Co-authored-by: Keith Burzinski <kbx81x@gmail.com>
* 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
Sebastian Rasor