Concurrent use of infinite and per schedule holds

[jack-rann]

I know about the integration's Holds are infinite, when off holds are until next scheduled activity configuration option. When checked, this causes calls to climate.set_temperature or climate.set_preset_mode to result in an infinite hold. However, when this is checked, is it possible to set a temperature or preset hold that is only active until the next schedule period?

For example, I have an automation that sets the system to away mode until some future date. With Holds are infinite option checked, this works fine. However, I have another automation that wants to set the system to sleep mode (ahead of its normally scheduled time) when a specific light is turned off. This automation needs to set a hold that will expire when the next scheduled change occurs.

[jack-rann]

After further investigation, I've raised issue #335 to fix what appears to be a bug in how the hold_activity and hold_until attributes are set. It also proposes to add a new next_activity_time attribute into the mix that would allow automations running in Home Assistant to both indefinite and temporary holds.

A prerequisite is to configure the ha_carrier integration with Holds are infinite, when off holds are until next scheduled activity enabled (i.e., checked). This implies that all holds placed with climate.set_preset_mode are indefinite.

To accomplish a temporary hold (i.e., "Per schedule" within the Carrier SmartHome app or via the thermostat itself), a new next_activity_time attribute could be exposed by the integration. This would indicate the next time that the thermostat schedule will change. In other words, the time that the temporary hold should be released.

With this in place, it allows me to create a new template sensor that converts next activity time to a timestamp using the following template:

{{ today_at(state_attr('climate.home_zone_1', 'next_activity_time')) }}

Create a new toggle / binary_sensor helper that is used to indicate whether a hold is to be released at that next activity time.

Finally, create an automation that triggers on the timestamp stored in the template sensor. This must also have a condition to require the toggle / binary_sensor be "on". Actions performed by the automation would resume the normal schedule (e.g., call climate.set_preset_mode(preset=resume) and then turn off the toggle / binary_sensor (to prevent it from firing again).

To set a temporary hold (until the next schedule time), call climate.set_temperature or climate.set_preset_mode (which will set an indefinite hold given that Holds are infinite is enabled), then turn on the toggle / binary_sensor which will cause the above automation to fire.

This approach seems to allow permanent holds to be set (the default behavior), but also allow a relatively easy way to effect a temporary hold (until the next scheduled time).