Repository navigation
Evohome: fails with an unrecognized model_type: 'Saratoga' #179414
Description
Activity
Hi @
please restore and make use of the issue template.
thx 👍Still failing on 2026.9.3 (evohome-async 2.1.0). The body above follows the issue template as requested.
The error wording has changed since the original report, but the root cause is the same:
response failed validation: not a valid value: 'saratoga' is not a valid TcsModelType at '[0].gateways[0].temperature_control_systems[0].model_type'TccTcsModelTypeon evohome-asyncmainanddevstill has only EvoTouch / FocusProWifiRetail / Sydney / VisionProWifiRetail. The fix belongs in the library, so I've filed it there: zxdavb/evohome-async#145I'm sorry, I've only just noticed this issue (I wonder if that was because the problem template was altered?).
We should be able to get a fix for you. To ensure any fix fits, and stays fixed, I'd appreciate a copy of your installation JSON, so that I can create a fixture from it.
What I need is a copy of your system's JSON - this is easy to get into the logs by turning on debug logging for evohome in the configuration.yaml file:
logger: logs: homeassistant.components.evohome: debug
... and then restart HA.
Note that the JSON is automatically anonymized (but do check it contains no data you wouldn't want posted on the internet).
I ask you not to change any of the identifier numbers, unless you absolutely insist.
If you are happy to do that, please post the JSON here & I can use it to address this issue.
You can look in the homeassistant.log file for
ConfigandStatusandSchedule.Just further information...
The reason why I'm needing the entire JSON is that it is possible there's a subsequent bug which won't show until we fix this proximal bug...
Experience has shown me that it's easier just to get the whole JSON and to sort it out in one go, becuase edge cases have a tendency to cluster.
@webbtechaust Thanks for reporting this issue!
Before we dive in, please make sure this isn't a duplicate by searching through existing issues. Also check recently closed issues, as your problem might already be fixed but not yet released.
https://github.com/home-assistant/core/issues?q=%20label%3A%22integration%3A%20evohome%22%20
(message by IssueContext)
evohome documentation
evohome source
(message by IssueLinks)- changed the title
[-]evohome: integration fails to set up entirely when a temperature_control_system reports an unrecognized model_type ('Saratoga')[/-][+]evohome: fails with an unrecognized `model_type`: 'Saratoga'[/+]on Sep 27, 2026 - Thanks @zxdavb. Attached is the raw installationInfo JSON (installation_info.sanitized.json). It's the GET location/installationInfo?...&includeTemperatureControlSystems=True response logged by evohomeasync2.auth, captured on HA 2026.9.3 / evohome-async 2.1.0. As requested, I have left the identifier numbers unchanged. In addition to the library's anonymisation, I've manually redacted my street/city and first/last name. Nothing structural has been altered. Unfortunately I can't provide Config, Status or Schedule from the homeassistant.components.evohome logger yet. Setup fails during the initial client.update() because the installationInfo response fails validation on 'saratoga'. The HA Config logging, status fetch and schedule fetches occur after that point, so they are never reached. I therefore enabled the library debug logger for one restart to capture the underlying installationInfo response. I'm happy to capture Status and Schedule once a fix allows setup to proceed beyond this point. Two details that may be relevant when creating the fixture: this is a single-zone Saratoga system where `zoneId == systemId`, and the zone reports `allowedFanModes`. Thanks for looking into this. <<SNIP>>
Nope.
Paste it in a code block?
Are you able to edit your instance of HA - with (e.g.) VS Code?
So you can try the new client? Would have to edit components/evohome/manifest.json at the minimum?
(there's something about your comments, sent by email, that are causing markdown to format incorrectly - very odd)
installationInfo JSON
[ { "locationInfo": { "locationId": "5508661", "name": "My*****", "streetAddress": "********", "city": "********", "country": "Australia", "postcode": "", "locationType": "Residential", "useDaylightSaveSwitching": false, "timeZone": { "timeZoneId": "AUSEasternStandardTime", "displayName": "(U*************************************", "offsetMinutes": 600, "currentOffsetMinutes": 600, "supportsDaylightSaving": true }, "locationOwner": { "userId": "4578816", "username": "***@***.***", "firstname": "********", "lastname": "********" } }, "gateways": [ { "gatewayInfo": { "gatewayId": "5231562", "mac": "************", "crc": "****", "isWiFi": true }, "temperatureControlSystems": [ { "systemId": "7171354", "modelType": "Saratoga", "zones": [ { "zoneId": "7171354", "modelType": "Saratoga", "setpointCapabilities": { "vacationHoldCapabilities": { "isChangeable": false, "isCancelable": true }, "maxHeatSetpoint": 30.0, "minHeatSetpoint": 4.5, "valueResolution": 0.5, "canControlHeat": true, "canControlCool": false, "allowedSetpointModes": [ "PermanentOverride", "FollowSchedule", "TemporaryOverride", "VacationHold" ], "maxDuration": "1.00:00:00", "timingResolution": "00:15:00" }, "scheduleCapabilities": { "maxSwitchpointsPerDay": 4, "minSwitchpointsPerDay": 0, "timingResolution": "00:15:00", "setpointValueResolution": 0.5 }, "name": "TH********", "zoneType": "Thermostat", "allowedFanModes": [ { "fanMode": "Auto" }, { "fanMode": "Circulate" }, { "fanMode": "On" } ] } ], "allowedSystemModes": [ { "systemMode": "Off", "canBePermanent": true, "canBeTemporary": false }, { "systemMode": "Heat", "canBePermanent": true, "canBeTemporary": false } ] } ] } ] } ]Thanks @zxdavb — I tested PR #146 at
dac3c33on HA 2026.9.3, as acustom_components/evohomeoverride (an unmodified copy of the 2026.9.3 integration, withmanifest.jsonrequirements pointed at the commit zip).Good news: PR #146 fixes the original Saratoga problem. The integration loaded, and both the controller and zone entities came up with correct live data.
Next bug (as you predicted): schedules fail validation, because the zone schedule switchpoints include a
fanModekey:GET temperatureZone/7171354/schedule: response failed validation: not a valid option at 'daily_schedules[0].switchpoints[0].fan_mode'It looks like
SCH_GET_SWITCHPOINT_ZONEisPREVENT_EXTRA, with nofanMode. That's more than cosmetic: the exception is aBadApiSchemaError, and_update_v2_schedules()only catchesInvalidScheduleError. So every coordinator refresh after the first fails ("Unexpected error fetching evohome_coordinator data"), and the entities become unavailable ~5 minutes after startup.(Minor:
minHeatSetpointis 4.5 in the config, but the switchpoint schema'sheatSetpointrange starts at 5. My schedule doesn't go below that, so it's not an issue for me.)I've rolled the test back successfully to stock HA 2026.9.3 / evohome-async 2.1.0.
JSON below. All IDs are unchanged.
- Status: as returned, except that I've removed two zone
activeFaultsentries unrelated to this issue. - Schedule: the times and setpoints are substituted privacy-safe values. The structure, IDs and
fanModefields are exactly as returned (7 days × 4 switchpoints, each with"fanMode": "Auto").
Status — GET location/5508661/status?includeTemperatureControlSystems=True
{ "locationId": "5508661", "gateways": [ { "gatewayId": "5231562", "temperatureControlSystems": [ { "systemId": "7171354", "zones": [ { "zoneId": "7171354", "temperatureStatus": {"temperature": 21.5, "isAvailable": true}, "activeFaults": [], "setpointStatus": {"targetHeatTemperature": 4.5, "setpointMode": "PermanentOverride"}, "name": "TH********", "fanStatus": {"fanMode": "Auto", "canBeChanged": true} } ], "activeFaults": [], "systemModeStatus": {"mode": "Off", "isPermanent": true} } ], "activeFaults": [] } ] }Schedule (substituted times/setpoints; structure and fanMode as returned) — GET temperatureZone/7171354/schedule
{ "dailySchedules": [ {"dayOfWeek": "Monday", "switchpoints": [ {"heatSetpoint": 19.0, "fanMode": "Auto", "timeOfDay": "06:30:00"}, {"heatSetpoint": 15.0, "fanMode": "Auto", "timeOfDay": "09:00:00"}, {"heatSetpoint": 20.0, "fanMode": "Auto", "timeOfDay": "17:30:00"}, {"heatSetpoint": 15.0, "fanMode": "Auto", "timeOfDay": "22:00:00"}]}, {"dayOfWeek": "Tuesday", "switchpoints": [ {"heatSetpoint": 19.0, "fanMode": "Auto", "timeOfDay": "06:30:00"}, {"heatSetpoint": 15.0, "fanMode": "Auto", "timeOfDay": "09:00:00"}, {"heatSetpoint": 20.0, "fanMode": "Auto", "timeOfDay": "17:30:00"}, {"heatSetpoint": 15.0, "fanMode": "Auto", "timeOfDay": "22:00:00"}]}, {"dayOfWeek": "Wednesday", "switchpoints": [ {"heatSetpoint": 19.0, "fanMode": "Auto", "timeOfDay": "06:30:00"}, {"heatSetpoint": 15.0, "fanMode": "Auto", "timeOfDay": "09:00:00"}, {"heatSetpoint": 20.0, "fanMode": "Auto", "timeOfDay": "17:30:00"}, {"heatSetpoint": 15.0, "fanMode": "Auto", "timeOfDay": "22:00:00"}]}, {"dayOfWeek": "Thursday", "switchpoints": [ {"heatSetpoint": 19.0, "fanMode": "Auto", "timeOfDay": "06:30:00"}, {"heatSetpoint": 15.0, "fanMode": "Auto", "timeOfDay": "09:00:00"}, {"heatSetpoint": 20.0, "fanMode": "Auto", "timeOfDay": "17:30:00"}, {"heatSetpoint": 15.0, "fanMode": "Auto", "timeOfDay": "22:00:00"}]}, {"dayOfWeek": "Friday", "switchpoints": [ {"heatSetpoint": 19.0, "fanMode": "Auto", "timeOfDay": "06:30:00"}, {"heatSetpoint": 15.0, "fanMode": "Auto", "timeOfDay": "09:00:00"}, {"heatSetpoint": 20.0, "fanMode": "Auto", "timeOfDay": "17:30:00"}, {"heatSetpoint": 15.0, "fanMode": "Auto", "timeOfDay": "22:00:00"}]}, {"dayOfWeek": "Saturday", "switchpoints": [ {"heatSetpoint": 19.0, "fanMode": "Auto", "timeOfDay": "06:30:00"}, {"heatSetpoint": 15.0, "fanMode": "Auto", "timeOfDay": "09:00:00"}, {"heatSetpoint": 20.0, "fanMode": "Auto", "timeOfDay": "17:30:00"}, {"heatSetpoint": 15.0, "fanMode": "Auto", "timeOfDay": "22:00:00"}]}, {"dayOfWeek": "Sunday", "switchpoints": [ {"heatSetpoint": 19.0, "fanMode": "Auto", "timeOfDay": "06:30:00"}, {"heatSetpoint": 15.0, "fanMode": "Auto", "timeOfDay": "09:00:00"}, {"heatSetpoint": 20.0, "fanMode": "Auto", "timeOfDay": "17:30:00"}, {"heatSetpoint": 15.0, "fanMode": "Auto", "timeOfDay": "22:00:00"}]} ] }HA's
Config = …debug line matched theinstallationInfoI posted above (minus the location owner/address block). Happy to test the next commit the same way.- Status: as returned, except that I've removed two zone
Next bug (as you predicted): schedules fail validation, because the zone schedule switchpoints include a fanMode key:
Yes - the code was written for Evohome, but support for edge cases like Saratoga can be supported. Your JSON will ensure that.
My apoligies about this... The library switched to being fully snake_case (and other Pythonic best-practices), and voluptuous schemas are being used to coerce JSON values... A side-effectis this behaviour (that I should have thought through more).
Please try the latest commit, and let me know.
Please dont remove the Active Faults from the JSON - could I have them?
- changed the title
[-]evohome: fails with an unrecognized `model_type`: 'Saratoga'[/-][+]Evohome: fails with an unrecognized `model_type`: 'Saratoga'[/+]on Sep 28, 2026 @zxdavb — tested the latest commit on PR #146,
566b65d("fix: allow a schedule heatSetpoint down to 4.5, as for minHeatSetpoint"), on HA 2026.9.3, using the samecustom_components/evohomeoverride method (an unmodified 2026.9.3 integration, withmanifest.jsonrequirements pinned to the566b65dcommit zip).Result: it works.
- Saratoga loads. The controller and zone entities populate with correct live data (system
Offpermanent; zonePermanentOverrideat 4.5; current temperature 21.5). - The real schedule, with
fanModeon every switchpoint, now validates.Schedule['THERMOSTAT']is populated at startup, and the zone'sthis_sp_*/next_sp_*setpoints are derived from it correctly. - I watched three scheduled coordinator refreshes (at +5, +10 and +15 minutes). Each re-fetched status and schedule, and each finished with
success: True. The entities stayed available throughout. - No evohome / evohome-async warnings or errors, other than HA's standard "custom integration" notice.
My real schedule is structurally identical to the neutralised one I posted earlier: 7 days × 4 switchpoints, each with
heatSetpoint,fanMode: "Auto"andtimeOfDay, and allheatSetpointvalues ≥ 7.0.Here's the status again, this time with the Active Faults exactly as returned (IDs unchanged;
nameis as masked by the library's debug logging):Status — GET location/5508661/status?includeTemperatureControlSystems=True
{ "locationId": "5508661", "gateways": [ { "gatewayId": "5231562", "temperatureControlSystems": [ { "systemId": "7171354", "zones": [ { "zoneId": "7171354", "temperatureStatus": { "temperature": 21.5, "isAvailable": true }, "activeFaults": [ { "faultType": "NeedToRegisterOnline", "since": "2022-06-11T02:42:04.1252794" }, { "faultType": "ReminderTimerHumPad", "since": "2026-08-16T14:00:01" } ], "setpointStatus": { "targetHeatTemperature": 4.5, "setpointMode": "PermanentOverride" }, "name": "TH********", "fanStatus": { "fanMode": "Auto", "canBeChanged": true } } ], "activeFaults": [], "systemModeStatus": { "mode": "Off", "isPermanent": true } } ], "activeFaults": [] } ] }Note that the first fault's
sincehas 7 fractional digits and neithersincehas a UTC offset. The library parsed both without complaint (they showed up in HA as2022-06-11T02:42:04.125279+10:00and2026-08-16T14:00:01+10:00).Thanks for the quick turnaround. Is there anything else you'd like me to check before this is released?
- Saratoga loads. The controller and zone entities populate with correct live data (system
That's helpful, and good to know the status/schedule updates are working.
Three question before I publish release with your fix:
Logs: with those two active fault types, the library should log two warnings (Active fault: … (unknown, please report it …)). Can you see them? let me know.
Fault times: the since dtms have no UTC offset, and the library currently treats them as local time. Your
ReminderTimerHumPadis 2026-08-16T14:00:01. If that's UTC instead, it's one second past midnight on 17 August your time. Does the thermostat or the TCC app show that reminder as starting at midnight on 16/17 August, or at 2 pm on 16 August?Re-test: could you repeat your test with the latest dev? It has new changes.
@zxdavb — answers to your three questions, from one test run on HA 2026.9.4, using the same
custom_components/evohomeoverride method (an unmodified copy of the 2026.9.4 evohome integration, withmanifest.jsonrequirements pinned to the dev commit zip).1. Active fault warnings — yes, both are logged.
My HA config normally sets theevohomeasync2logger toerror, which is why I hadn't seen them before. With it atwarning, both appear at startup, exactly once each:WARNING (MainThread) [evohomeasync2] Zone(id='7171354'): Active fault: 2022-06-11T02:42:04.125279+10:00 need_to_register_online (is unknown, please report it at https://github.com/zxdavb/evohome-async/issues) WARNING (MainThread) [evohomeasync2] Zone(id='7171354'): Active fault: 2026-08-16T14:00:01+10:00 reminder_timer_hum_pad (is unknown, please report it at https://github.com/zxdavb/evohome-async/issues)2.
sincetimestamps — local or UTC: unable to determine.
I looked for anything Honeywell shows about these faults, to avoid simply guessing from the numbers:- TCC International web portal (the account lives there): the location, location-system and zone data show
AllActiveFaultsas[]/null,AlertCount: 0and every zone alert flagfalse. So the portal doesn't show these two faults, or any time for them. - v1 API (
api/locations?userId=…&allData=True): no faults or fault timestamps, only the (inactive)alertSettings. - NA portal: the account doesn't exist there.
So the v2 status is the only place these values appear, and they have no UTC offset. I have no evidence either way yet. If I can find the reminder's time on the thermostat itself or in the TCC app, I'll post it here.
3. Latest dev —
62ff3a8(dev head / PR #156): passed.- Saratoga loads.
climate.my_homeandclimate.thermostatpopulate with correct live data. - The real schedule (with
fanModeon every switchpoint) validates at startup. The zone'sthis_sp_*/next_sp_*setpoints match the actual schedule. - Three scheduled coordinator refreshes (+5, +10, +15 min) each fetched v2 status, v1 locations (high-res temps) and the zone schedule, and each finished with
success: True. The entities stayed available throughout. - No other evohome / evohome-async warnings or errors, beyond the two Active fault lines above and HA's standard "custom integration" notice.
One detail relevant to your last
thermostatModelTypechange on dev: in the v1locationsresponse this device reports"thermostatModelType": "SARATOGA"(a string) with"deviceType": 48, and it validated fine.I've rolled back to stock 2026.9.4 / evohome-async 2.1.0 until the release lands. Thanks again!
- TCC International web portal (the account lives there): the location, location-system and zone data show
@webbtechaust It woudl be gret if you could test #185694
@zxdavb — tested #185694 (head
40ca498) on my Saratoga system, on HA 2026.10.1 (HAOS). Result: it works.Method. I couldn't use the PR-head files as they are: the PR is based on
dev, which already has #184820 (native temperature properties), and 2026.10.1'sClimateEntitydoesn't support that. So I used acustom_components/evohomeoverride that is:- the unmodified 2026.10.1
homeassistant/components/evohome/, - plus this PR's diff to
climate.py,coordinator.py,entity.pyandmanifest.json, exactly as in the PR (it applied cleanly), - plus the
"version"key that custom integrations require.
The only other differences from the PR head are the unrelated
devchanges (#184820 and #183811).evohome-async==3.0.0was installed from PyPI. No other code changes were made.Results:
- Setup: succeeds. There is no
TcsModelTypeerror, and bothclimateentities and both reset buttons are created. The system isOff(permanent); the zone isPermanentOverrideat 4.5 °C, with a current temperature of 22.5 °C. - Schedule: the real schedule (with
fanMode: "Auto"on every switchpoint) validates. The zone'sthis_sp_*/next_sp_*values match the actual schedule for today. There was no invalid/missing-schedule warning. - Active faults: both are logged once at startup, as before:
WARNING [evohomeasync2] Zone(id='7171354'): Active fault: 2022-06-11T02:42:04.125279+10:00 need_to_register_online (is unknown, please report it at https://github.com/zxdavb/evohome-async/issues) WARNING [evohomeasync2] Zone(id='7171354'): Active fault: 2026-08-16T14:00:01+10:00 reminder_timer_hum_pad (is unknown, please report it at https://github.com/zxdavb/evohome-async/issues) - Refreshes: I watched three consecutive scheduled coordinator refreshes, at +5, +10 and +15 minutes (300 s apart). Both entities were updated each time and stayed available throughout.
- Logs: the only other evohome log line was HA's standard "custom integration" notice. There were no errors, and nothing from the coordinator. The deployed code uses none of the names that v3 deprecated or removed (
update(),ApiRequestFailedError,InvalidSystemModeError, and so on). I checked that by reading the code; I didn't capture anyDeprecationWarnings at runtime. - Other integrations: no regressions. The component and unavailable-entity lists matched the pre-test baseline, apart from the evohome entities.
The test was read-only, so I didn't exercise any set-mode or setpoint paths.
I've rolled back to stock 2026.10.1 (evohome-async 2.1.0), which is back to the original
'saratoga'error, until this is released. Thanks!- the unmodified 2026.10.1
The problem
Since the
2026.8.0update (evohome-async bumped to v2.0.1, #174335), the evohome integration hard-fails setup entirely if anytemperature_control_systems[].model_typeisn't in the library's accepted list. My controller reportsmodel_type: 'Saratoga', which isn't recognized. Prior to2026.8.0this same controller worked fine — the older evohome-async was more permissive about unrecognized model types.What version of Home Assistant Core has the issue?
core-2026.8.2
What was the last working version of Home Assistant Core?
core-2026.7.x (last known-good before the 2026.8.0 bump)
What type of installation are you running?
Home Assistant OS
Integration causing the issue
evohome
Link to integration documentation on our website
https://www.home-assistant.io/integrations/evohome/
Diagnostics information
N/A — evohome is a YAML-configured integration (no config entry), so there's no diagnostics download available for it.
Example YAML snippet
Anything in the logs that might be useful for us?
Additional information
Still reproducing identically on 2026.8.0, 2026.8.1, and 2026.8.2 — confirmed via live log check on each. Happy to enable debug logging and provide the raw upstream API payload if useful.