GeezerVison

Adds support for the KE100/KE110 thermostat schedule, which was asked for in #1601, along with a few other components these thermostats and the T310/T315 sensors report but python-kasa didn't support yet.

New modules

The request names and parameters (get_sc_schedule_info, get_sc_schedule_rules, edit_sc_schedule_rule, set_sc_schedule_info, get/set_temperature_correction, get_temperature_records) come from the Kasa Android app, and I checked them against real devices.

Device behaviour worth knowing

• Only the active mode's schedules can be edited. edit_sc_schedule_rule for another mode returns -1001. The same edit succeeds once that mode is active, so set_schedule() rejects ids from other modes with a hint to call set_mode() first.
• The schedules come back in pages (start_index/sum). _ChildProtocolWrapper doesn't iterate list pages, so the module pages through them itself and keeps schedule_mode on each request. (SmartProtocol._get_list_request would also drop schedule_mode on later pages.)
• Slots aren't returned in time order, so they're sorted. A day must be covered without gaps, with at most day_segment slots (6 on the KE100).
• Hub children only refresh module queries every 24h. The record modules override this to 15 minutes, which matches the device's own interval. The schedule and temperature correction setters update the cached state straight away.

Fix: hub child module data lost on partial updates

SmartChildDevice._update replaced _last_update with only the responses for the modules queried in that cycle, so modules that weren't due lost their data and raised You need to call update() prior accessing module data. This didn't show before because all child modules refreshed on the same daily cycle. With the 15 minute record modules it happened 15 minutes in. It now merges the responses, as SmartDevice already does. The regression test is in test_childdevice.py. It uses hub fixtures because standalone child fixtures load as plain SmartDevices, which is how this got past the existing tests.

Fixtures and tooling

• New KE100(EU) and KE100(UK) 2.6.0 fixtures with responses for the new components.
• dump_devinfo now queries the new components, and scrubs temp_sensor_device_id by mapping it to the scrubbed child id (it can point at another child). It's also added to the log redactors.
• FIXTURE_MISSING_MAP defaults for the older KE100/KE110/T315 fixtures, and a fake handler for edit_sc_schedule_rule that, like the device, only accepts edits to the active mode.

Testing

• The full test suite and ruff pass, and mypy reports no issues in the new modules.
• On hardware: KH100(UK) hub (fw 1.8.0) with four KE100s (fw 2.6.0, EU and UK). I read every valve's schedule, temperature source and history, edited one schedule and confirmed the change in the Kasa app, and checked the active-mode restriction.
• The hub needs the TPAP transport from TPAP Implementation #1592, so I tested on a branch that combines both. This PR doesn't depend on TPAP Implementation #1592 and has no TPAP changes.
• The T310 module is tested against the existing T310/T315 fixtures. I haven't yet tested set_external_sensor() with a real T310; I'll report back once mine arrive.

Not included: the T310's comfort temperature/humidity settings (get/set_comfort_temp_config, get/set_comfort_humidity_config) and the KE100's other settings (window open detection, night mode, shutdown mode, early start). The request names are known, and I can follow up once I have real responses for the sensor ones.

🤖 Generated with Claude Code