Claude Code transcript

Here's the landscape. Short version: everything you described is not only possible, it's a well-trodden path — and the best approach doesn't need any cloud API at all.

1. Controlling the KP400 — you have a clean local option

The key discovery: there's a mature open-source library, python-kasa, that talks to Kasa devices directly over your local network — no internet, no TP-Link cloud, no reverse-engineered web login. The KP400 is explicitly supported, including its two independently-switchable outlets (each of your outlets shows up as a child you can toggle separately). This is exactly what powers the Home Assistant Kasa integration.

Why local is the right choice here: - Reliability — an ice-protection system shouldn't depend on TP-Link's cloud being up, your account not getting rate-limited, or a firmware change breaking an unofficial web API. It just needs your LAN. - Speed & simplicity — kasa --host 192.168.1.x on --index 0 from a shell, or a few lines of Python. - No account fragility — TP-Link has no official public developer API; the cloud methods people use are reverse-engineered from the Kasa app, and TP-Link periodically changes them (they've been migrating newer devices to an encrypted "KLAP" transport). Your KP400 uses the older, stable, well-supported local protocol.

One caveat to plan around: give the KP400s static/reserved IPs (DHCP reservation in your router) so the controller always knows where to find them.

Cloud alternatives exist (tplink-cloud-api and similar) and would let you control the switches from outside your home network — but for a device sitting on your own roof controlled by a program on your own network, that's added fragility for no benefit. I'd only reach for cloud control if the controller can't be on the same LAN as the switches.

2. Weather data — free and ideal for your location

Since you're in Montana (US), the National Weather Service API (api.weather.gov) is the natural fit: - Completely free, no API key, ~5,000 requests/hour — you'll use a handful per hour. - Just requires a User-Agent header identifying your app + a contact email. - Flow: hit /points/{lat},{lon} once to get your gridpoint, which gives you URLs for hourly forecast and current observations (temperature, precipitation, etc.).

The main limitation is US-only, which doesn't affect you. If you ever want richer data (snow depth, freezing rain probability, historical) you could supplement with a keyed service like OpenWeatherMap, but NWS alone is plenty to start.

3. The actual logic — inferring "icing conditions"

This is the interesting part, and worth getting right so you're not just burning electricity all winter. Ice dams form from a melt-refreeze cycle: snow on the roof melts (from attic heat or sun), water runs to the cold eaves, and refreezes. So the danger zone isn't "very cold" — it's near and just below freezing, with snow present.

A reasonable first heuristic: - Turn ON when: there is snow on the roof (recent snowfall or snow on ground) AND temperature is in roughly the 15°F–38°F band (cold enough to refreeze at the eaves, warm enough for melt to occur). - Turn OFF when: well above freezing for a sustained period (snow sheds on its own) or no snowpack present. - Add hysteresis / minimum on-time (e.g., don't flip states more than every 30–60 min) so a temperature hovering at the threshold doesn't rapid-cycle the relays.

You can refine over your first season — some people simply run cables whenever there's snowpack and temps are below ~40°F, accepting some extra energy use for safety margin. Because the KP400 has two outlets, you could even zone it (e.g., north-facing eaves vs. south).

4. How to run it — a few architectures

For a focused, single-purpose system like this, I'd lean toward the standalone script on a small always-on device at home — it's the least moving parts, and a Raspberry Pi (or any machine that's always on) sitting on your LAN can reach the switches directly. Home Assistant is the better pick if you anticipate this being the first of several automations.

Important safety layer regardless of approach: the automation should fail safe. Think about what happens if the controller crashes, the network drops, or the NWS API is down during a storm — you likely want a "when in doubt during winter, turn them ON" bias, plus the ability to manually override via the Kasa app (which keeps working independently). The KP400's own schedule/manual control remains as a fallback.

A sensible path forward: 1. Confirm you can reach a KP400 locally — install python-kasa and run kasa discover on your home network to see the switches and their two outlets. 2. Pull a live forecast from api.weather.gov for your coordinates. 3. Write the decision logic + a scheduler, starting conservative on the "on" conditions.

If you'd like, I can help you build this — e.g., start by scaffolding a small Python project that discovers your KP400s and pulls your local NWS forecast, so we can verify both halves work before writing the icing logic. Want me to go ahead and set that up?

Sources: python-kasa · python-kasa docs · KP400 product page · NWS API docs · NWS API FAQ · tplink-cloud-api

Empty repo, Python 3.12, venv available. I'll build a proper installable package. Here's the structure I'm creating:

• heatwires/ — package with weather (NWS), switches (python-kasa), decision logic, state, controller, and a CLI
• config.example.yaml — all tunables (location, switch IPs, icing thresholds, fail-safe)
• pyproject.toml, .gitignore, updated README.md

Let me write it all.

All 12 pass. Now a live end-to-end smoke test of the real NWS integration (the part unit tests can't cover). I'll make a real config.yaml and run status — weather should come back live; the switch at the placeholder IP should fail gracefully (it's not on this machine's LAN), which also verifies the error handling.

Done. Built a working, installable Python package and verified it end-to-end.

What's there

heatwires/
  weather.py     NWS client → temperature + snow/ice signal (keyless api.weather.gov)
  logic.py       the icing decision: band + snow + hysteresis
  switches.py    Kasa control over the LAN via python-kasa (KP400 dual-outlet aware)
  controller.py  one cycle: weather → decision → switches → state
  state.py       run-to-run state (last state, dwell timing)
  config.py      YAML load/validate
  cli.py         discover / status / run / loop
config.example.yaml   pyproject.toml   .gitignore   tests/   README.md

The decision matches what we discussed: cables run when the temp is in a 15–38 °F band and frozen precip is present, with hysteresis (no flapping), a minimum dwell time, a winter fail-safe (default ON if weather can't be fetched), and graceful per-switch failure so one unreachable plug doesn't abort the run.

How it was verified

• 12 unit tests pass — the decision logic (band edges, hysteresis, snow-required, fail-through) and the NWS response parsing (observation vs. forecast fallback, °C conversion, unavailable handling), using a mocked HTTP session.
• Live end-to-end: heatwires status pulled real Bozeman weather (88°F, no snow signal — Mostly Clear), correctly decided OFF ("snow sheds naturally"), and the placeholder switch IP failed cleanly rather than crashing.
• I confirmed the code matches the installed python-kasa 0.10.2 API (checked discover_single/discover/turn_on/children signatures directly).

What you need to do to run it for real

1. On a machine on the same LAN as the switches (e.g. a Raspberry Pi): pip install -e .
2. heatwires discover to find your KP400s' IPs, then put them (and reserve those IPs in your router) into config.yaml.
3. Double-check the location coordinates — I seeded config.yaml with default Bozeman coords and your email for the NWS contact; adjust the lat/long to your actual roof.
4. heatwires -c config.yaml status to sanity-check, then deploy via cron or the systemd unit (both in the README).

Note: config.yaml and state.json are git-ignored as host-specific. I have not committed anything — want me to make an initial commit on a branch?

One tuning caveat for your first winter: the snow signal is inferred from NWS text (keywords like "snow"/"freezing"), not actual roof snowpack — so watch the first few storms and adjust the band or require_snow to taste.

It works against the real hardware. The KP400 responded to unicast discovery straight through WSL2, and we can read it live:

192.168.1.64 (Switch #5):
  [0] Shop gutter heat wire = off
  [1] Shop deck mat = off

So the full read path is verified end-to-end against your actual switch — device identification, both named outlets, and current state. Note the outlet names came straight from the device: outlet 0 = "Shop gutter heat wire", outlet 1 = "Shop deck mat". That's useful — you may eventually want different logic per outlet (a deck mat and a gutter wire don't necessarily want the same rules).

The one thing still unverified is the write path (turn_on/turn_off) — and that actually energizes real heating equipment. Since it's 88°F and these control a gutter heat wire and a deck heat mat, I don't want to actuate them without your say-so.

The safe way to prove the write path: flip one outlet on, read back that it reports on, then immediately flip it back off — a couple seconds of relay actuation, fully restored. How would you like to proceed?

Write path verified against the real hardware:

target: outlet[0] = 'Shop gutter heat wire'
1. before        : off
2. after turn_on : on
3. after turn_off: off
   outlet[1] 'Shop deck mat' untouched: off
OK: write path verified, outlet 0 restored to off

Outlet 0 energized, reported on, then restored to off — outlet 1 never touched. The equipment is back exactly as it was.

The whole system is now proven end-to-end against your actual switch: live NWS weather → decision logic → device read → device write, plus graceful handling and clean restore. Nothing left mocked.

Let me record the hardware details so future sessions don't have to rediscover them.

Everything's verified against your real hardware and the project is complete. Summary of where things stand:

Proven live: weather fetch (real Bozeman NWS data) → icing decision → device discovery/read → device write (on + restore), plus the graceful-failure path. 12 offline unit tests pass for the logic and NWS parsing.

Ready to deploy: your real switch IP is in config.yaml (git-ignored), and the README has both cron and systemd recipes. To go live, run it on an always-on box on that LAN.

Two things worth your attention before winter: - Two different loads. Outlet 0 is a gutter heat wire, outlet 1 is a deck mat — currently both follow the same icing rule (outlets: all). If you want them governed differently, we can split them into separate switch entries with their own thresholds (the config already supports per-outlet selection like outlets: [0]). - Snow signal is text-inferred from NWS conditions, not actual roof snowpack — worth watching over the first few storms and tuning the band or require_snow.

I haven't committed anything. Want me to make an initial commit on a branch? And if so, should I split the gutter wire and deck mat into independent rules first, or leave that for when you've decided how they should differ?

Done. config.yaml now has outlets: [0], so heatwires only ever touches the gutter heat wire — the deck mat stays entirely under your manual control and the automation will never flip it.

That's the last functional change. The project is verified end-to-end against your real switch and ready to deploy. Note that config.yaml is git-ignored (it's host-specific with your switch IP), so your commit will ship config.example.yaml as the template — which is the intended design. Thanks, and enjoy the ice-free eaves this winter.