Schedule Hold not populating in preset_modes

[cmgrayb]

Describe the bug
"Schedule Hold" is returned by the S30 any time the fan or temperature is changed from the default, in property preset_mode. This causes an error to pop up in the thermostat card on load, such as:
Preset mode is not valid. Valid preset modes are: schedule IQ, Summer, Winter, Fall/Early Spring, Default, away, cancel hold, cancel away mode, none.
The above list of modes is populated in property preset_modes (note plural)

To Reproduce
Steps to reproduce the behavior: create a thermostat card tied to the HVAC zone, change either the fan or temperature setting

Expected behavior
Schedule Hold should be a member of the list in preset_modes to prevent the above error

Screenshots/Logs

Version

• Home Assistant: 2024.6.*
• This Integration: 2024.6.0

**Integration Configuration **

• Cloud or Local Connection: Local
• Inverter or Sensor Diagnostics Enabled: Sensor

Additional context
N/A

[PeteRager]

Thanks for reporting. Should be fixable.

Couple of potential approaches.

a) if the thermostat is in Schedule Hold, Schedule Hold will be added to the valid list of presets
b) if the thermostat is not in Schedule Hold, Schedule Hold will not be in the valid list of presets
c) any attempt to set the preset to "Schedule Hold" will generate an error.

Alternate approach

a) always have schedule hold in the list of presets
b) any attempt to set the preset to "Schedule Hold" will generate an error.

Thoughts?

[cmgrayb]

Personally, I would probably approach it the same as cancel hold, since that is not an actual preset. Barring that, it would appear that Schedule Hold should be available on every unit, so probably statically add it to the list?

Edit: I reread your comment and I see the issue. Since it is not an actual preset and also does not map to a function like cancel hold, it will appear in the list but be unusable and thus throw a different error. I don't suppose we can tell what preset we're coming from to trap the error and set the preset back to a valid one?

[cmgrayb]

In further thought, the first approach makes more sense and it appears you are already headed that direction in the PR.

[PeteRager]

. I don't suppose we can tell what preset we're coming from to trap the error and set the preset back to a valid one?

I think we can. Lennox uses numerical ids for the schedules. So 1-16 are the user presets. If you are on schedule id 3 and override it, they add 32, so that becomes schedule id 35. When we cancel it, it goes back to 3. How would you see this working?

[cmgrayb]

That sounds promising

[PeteRager]

So it turns out that we can't add that preset in sometimes. So we are going with

a) always have schedule hold in the list of presets
b) any attempt to set the preset to "Schedule Hold" will generate an error.

Note, when attempting to do B in the climate card and error is reported to the UI; however the climate cards "optimistic" mode will show schedule hold temporarily until it's timer expires or the card is reloaded.

[PeteRager]

This should be fixed in

https://github.com/PeteRager/lennoxs30/releases/tag/2024.6.1

Please give it a try; let me know if it fixes.