CODEX Session Transcript

Yes—this is quite feasible. The KP400 can be controlled programmatically over your local network, even though TP-Link does not appear to offer a documented public Kasa API intended for this purpose. My preferred solution would be: > An always-on Home Assistant system controls the KP400 locally, using online weather data initially and optional roof sensors later.

Control options

1. Home Assistant — best overall choice Home Assistant has a maintained TP-Link integration that controls Kasa devices locally. Its underlying library explicitly supports the KP400 and its two independently controlled outlets. Home Assistant can combine this with weather forecasts, physical sensors, timers, manual overrides, alerts, and operating-history dashboards. [Home Assistant TP-Link integration](https://www.home-assistant.io/integrations/tplink/) and [supported python-kasa devices](https://python-kasa.readthedocs.io/en/stable/SUPPORTED.html). It can run on: • A Raspberry Pi • A small mini-PC • A NAS or existing home server • A virtual machine This requires relatively little custom programming and will be easier to monitor and modify than a standalone script. 2. A custom Python service — most flexible The community-maintained [python-kasa](https://github.com/python-kasa/python-kasa) library supports KP400 control. A Python program could: • Read current conditions and hourly forecasts • Maintain an estimate of whether snow remains on the roof • Turn each KP400 outlet on or off • Verify that the command succeeded • Record decisions in a log • Send an alert if the switch or weather service is unreachable • Provide manual override and maximum-runtime safeguards It could run every 5–15 minutes under systemd, Docker, or a scheduled task. This is local device communication, so ordinary switching would not depend on TP-Link’s cloud remaining available. Some firmware versions may require your TP-Link credentials for local authentication. This is an unofficial, reverse-engineered interface rather than a contractual TP-Link API, so firmware compatibility is a consideration. 3. Cloud automation platforms Alexa, Google, Samsung SmartThings, and possibly third-party automation services can control the KP400, but weather logic and reliability tend to be more limited. They also introduce additional cloud dependencies. I would not choose this for unattended roof protection unless convenience matters more than robustness. 4. Dedicated snow/moisture controller — most reliable sensing Commercial roof and gutter de-icing controls use a local temperature sensor plus a moisture or precipitation sensor. That is materially better than inferring roof conditions from a weather station several miles away. For example, nVent offers roof/gutter control equipment using moisture and temperature sensing. [Example sensor module](https://www.nvent.com/sites/default/files/acquiadam/assets/RAYCHEM-EU2356-DS-ACS30ELEXANT650CSMDIMOD-EN.pdf). A particularly good design would use a dedicated sensor/controller for the primary decision and Home Assistant/Kasa for monitoring, notifications, scheduling, or an authorized override.

The weather logic is the harder part

“Below freezing” alone is not a good trigger. Ice dams form when snow is present and part of the roof is warm enough to melt it while the eaves remain cold enough to refreeze it. Building heat loss, insulation, roof geometry, sun, wind, and existing snow cover all matter. The Department of Energy describes precisely this roof-temperature mismatch. [DOE ice-dam guidance](https://www.energy.gov/cmei/buildings/articles/building-america-best-practices-series-volume-12-energy-renovations). A reasonable first-generation algorithm could maintain a snow_on_roof state and switch the cables on when either: • Freezing rain or freezing drizzle is occurring or imminent; or • Snow is believed to remain on the roof and temperatures are in a configurable freeze/thaw risk band. It should also include: • Starting before forecast precipitation, if the cable manufacturer recommends it • Continuing for a configurable time after precipitation ends • Hysteresis so it does not switch repeatedly near a threshold • Minimum on/off periods • A maximum continuous runtime • Conservative behavior when weather data becomes unavailable • Manual ON, OFF, and AUTO modes • Alerts when commands fail • Periodic confirmation of the actual outlet state For a US location, the National Weather Service provides free forecasts, alerts, and observations through its API. [NWS API documentation](https://www.weather.gov/documentation/services-web-api). Elsewhere, an equivalent national service or a commercial weather API could be used. I would begin conservatively and tune the thresholds from observations. A local outdoor temperature sensor is an inexpensive improvement; roof-surface temperature and moisture/snow sensing are much better.

Important electrical considerations

The KP400 is rated for a maximum 15 A total across both outlets at 125 V, with a stated maximum of 1,875 W. TP-Link also says it must plug into a GFCI receptacle when used outdoors or in a wet location. [KP400 datasheet](https://static.tp-link.com/2021/202104/20210407/KP400%28US%293.0%263.8_Datasheet.pdf). Before making this unattended: • Add up the actual wattage/current of all connected heating cable. • Confirm whether the manufacturer classifies the load as continuous and what switching device it permits. • Confirm that the receptacle, branch circuit, GFCI protection, cords, connectors, and smart plug are suitable. • Check the heating-cable instructions for required thermostats, ground-fault equipment, preheating, and shutdown behavior. • Have an electrician verify the arrangement if the load is substantial. For a large or critical installation, I would generally have a properly rated contactor/control panel switch the heating load and let the automation operate only its low-current control input. That avoids making a consumer smart plug the sole high-current safety component. Also note that TP-Link now lists the KP400 as end-of-life, although it remains supported by current community software. [TP-Link KP400 page](https://www.tp-link.com/us/home-networking/smart-plug/kp400/v1/).

Recommended progression

1. Install Home Assistant and confirm reliable local control of both KP400 outlets. 2. Add current conditions and hourly forecast data. 3. Run the decision logic in “observe only” mode for several storms, logging what it would do. 4. Compare those decisions with actual roof conditions. 5. Enable automatic operation with notifications and manual override. 6. Add local temperature and moisture/snow sensing if false positives or missed conditions matter. 7. Eventually address attic air sealing and insulation if practical—the cables manage symptoms, while reducing roof heat loss addresses the principal cause of ice dams. A custom Python implementation is also entirely viable, but Home Assistant provides most of the operational machinery—device state, automations, dashboards, logs, alerts, and overrides—without having to build it all from scratch.

Yes. Local control through Home Assistant or python-kasa normally coexists with the Kasa cloud and mobile app. You do not have to choose one or re-pair the KP400. The normal arrangement is: • The KP400 remains registered to your TP-Link/Kasa account. • The Kasa app communicates through TP-Link’s cloud when you are away. • Home Assistant or your Python program communicates directly with the KP400 over your home LAN. • Either one can change the outlet state; effectively, the most recent command wins. Home Assistant explicitly instructs users to provision devices in the official Kasa/Tapo app before adding them to its TP-Link integration. Newer firmware may require your TP-Link account credentials to authenticate local access, but the actual switching remains local. [Home Assistant TP-Link integration](https://www.home-assistant.io/integrations/tplink/) A few practical interactions are worth designing around: • Manual changes should take priority. If you turn an outlet off in Kasa, a naïve automation might turn it back on five minutes later. Use explicit AUTO, FORCE ON, and FORCE OFF modes—or a temporary manual-override period. • Synchronize before deciding. Each automation run should read the current outlet state before issuing a command. • Avoid competing schedules. Existing schedules stored through Kasa can remain active, but simultaneous Kasa schedules and your weather automation can produce confusing “last command wins” behavior. • The app should reflect local changes. The device reports its new state to TP-Link while cloud-connected, although the app display may occasionally need a refresh. • Internet isolation changes this. If you later block the KP400 from reaching TP-Link, local automation may continue working, but remote control through the Kasa cloud will not. • Use fixed local addresses. DHCP reservations for the KP400 devices make direct control more dependable. Given your clarified objective, I would make the automation deliberately asymmetric: 1. Humans can turn the wires on whenever direct observation indicates risk. 2. Automation is conservative about turning them on during vacations. 3. Automation turns them off only after conditions have been comfortably outside the plausible icing range for a sustained period. 4. A manual-on action suppresses automatic shutdown for a generous interval—or until explicitly returned to AUTO. For example, automatic shutdown might require both: • No relevant precipitation or recent snowmelt risk for 12–24 hours, and • Temperature comfortably above freezing for several hours, or sufficiently cold that melting is implausible. The precise criteria can be conservative because wasted electricity is preferable to a missed ice-dam event. I would also have it send a notification such as “automatic shutdown proposed/executed,” leaving you able to reverse the decision through Kasa. This backup-oriented design is considerably easier and safer than attempting authoritative roof-condition detection.

Implemented the initial custom Python controller. Key features: • Local KP400 control using python-kasa • Kasa cloud/app pairing remains intact • Conservative default off_only policy • Optional vacation mode for automatic startup • NWS hourly weather forecasts • Manual Kasa changes trigger a configurable override period • Dry-run commissioning mode • Fail-safe behavior: errors and incomplete forecasts leave the outlet unchanged • Persistent state, structured logging, and command verification Start with [README.md](/home/david/projects/play/heatwires-gpt/README.md), then copy and edit [config.example.toml](/home/david/projects/play/heatwires-gpt/config.example.toml). Validation completed: • All 7 policy tests pass • Python compilation passes • Example configuration loads successfully • Diff formatting checks pass pytest was not installed in the current environment, so I executed the test functions directly. Testing against the physical KP400 and live NWS service will require your location, device address, and local-network access.

Your coordinates are now configured in [config.toml](/home/david/projects/play/heatwires-gpt/config.toml). It remains in conservative off_only mode. The next required value is the KP400’s local IP address; 192.168.1.50 is currently a placeholder. A DHCP reservation is recommended so that address remains stable.

The KP400 isn’t visible from this environment’s neighbor table; only its container gateway appears. This workspace likely lacks direct access to your home LAN. To find its IP, use one of these: • Check your router’s DHCP/client list for MAC 3C:84:6A:1F:80:FC. • Look for an IP address under the Kasa device’s information/details screen. • Run kasa discover from a computer connected to the same LAN after installing this project. Once found, send me the address and I’ll update config.toml. You should also create a DHCP reservation for that MAC so the IP remains stable.

Updated [config.toml](/home/david/projects/play/heatwires-gpt/config.toml) with the KP400 address 192.168.1.64. Configuration validation passes.

From the project directory, create the environment and install the controller:

cd /home/david/projects/play/heatwires-gpt
python3 -m venv .venv
source .venv/bin/activate
python -m pip install -e .

Then query the KP400 without changing its state:

kasa --host 192.168.1.64 state

If it reports an authentication error, set your Kasa account credentials and retry:

export KASA_USERNAME='your-kasa-email@example.com'
export KASA_PASSWORD='your-kasa-password'
kasa --host 192.168.1.64 state

A successful response should identify the KP400 and show both child outlets, their names, and their current on/off states. After that, test the complete controller without allowing it to switch anything:

heatwires --config config.toml --once --dry-run --verbose

That checks contact with both the KP400 and NWS weather service while only logging the action it would take. Avoid running turn-on or turn-off commands until we confirm which child outlet—index 0 or 1—controls the intended heating wires.