
My heat pump is a Kronoterm: Hydro S indoor unit, Adapt 0416 outdoor unit, TERMOTRONIC 3000 controller. Good hardware. The software situation is that the only official way to see or change anything remotely is the Kronoterm cloud app, which looks and behaves like a side project from 2012, because it is one. Slow, missing half the interesting registers, and every command round-trips through Elektrina's servers to reach a box two meters from my router.

I wanted full local control in Home Assistant. The existing community integrations all wrap the same cloud API, so they inherit its limits. The other option was to remove the cloud from the equation entirely. That's what I did, with Kimi K3 running inside the pi coding agent doing most of the work: we reverse-engineered the module's protocol, impersonated the cloud endpoint, and finished with a proper local integration. Here's how it went.

## Recon

The TTEH-WEB module sits on the LAN with exactly one open port: 80. The web UI ships with admin:admin (yes, really) and offers no local automation API. So the interesting question is what it talks to. Watching DNS: a persistent WebSocket over TLS to wd.elektrina.si.

Then it gets good. The handshake negotiates SSLv3 with RC4-MD5. In 2026. The certificate is 1024-bit RSA issued by a private Elektrina CA. And the module does not pin that CA. No pinning means the module will happily do its ancient handshake with anyone presenting a plausible certificate, which means I can be the cloud.

## The interception box

Two constraints: nothing persistent may change on the heat pump itself, and the intercept has to be always-on. I have a UniFi network and the UniFi Cloud Gateway is Debian with root over SSH and already sits in the path, so the first version went there: an alias IP on the LAN bridge, one iptables REDIRECT rule, one dnsmasq line pointing the cloud hostname at it.

That later moved to a tiny Proxmox LXC, and the dnsmasq hack was replaced by a proper UniFi static DNS record created through the Network API. I gave my UniFi credentials to the agent and it configured it unassisted. The gateway is now back to completely stock config.

## Talking 1998

Python's ssl module hasn't spoken SSLv3 in years, so the agent vendored tlslite-ng (still does) plus its dependencies; tlslite needs Python 3.11 or older because it builds on asyncore. Two more quirks: the module rejects 2048-bit certificates and insists on 1024, and the WebSocket runs a binary subprotocol called ttehweb_bin.

Phase one was a relay: terminate the module's connection locally, open a second one upstream to the real cloud, log everything. That captured full config syncs and steady-state traffic.

## The protocol

Frames come in a handful of types: 0x28 status updates, 0x29 bulk dumps, 0x0b and 0x1f config pushes. The fun bug is that endianness is mixed: 0x28 and 0x0b are big-endian, the 0x29 dumps are little-endian. This is exactly the kind of detail that eats an afternoon when you're decoding by hand. The agent ground through the captures, formed hypotheses, and tested them against live values (compressor on, 800 W electrical in, 5 kW thermal out, COP around 6, hot water at 49 C) until everything lined up.

The register map came from merging three sources: an official Kronoterm BMS/Modbus document, community register maps, and what we observed on the wire. 1140 registers total, about 180 documented, 67 writable.

Phase two replaced the relay with a full local emulator. The module connects, does its sync, and can't tell the difference. The official app now shows my heat pump as offline. That is not a bug; that is the goal. However, if I want the heat pump to start talking to Kronoterm again we can set up the upstream connection again.

## Home Assistant

On top of the emulator's small HTTP API, the agent wrote a real integration: config flow, polling coordinator, 42 entities. Climate entity for the floor loop, water heater for hot water, electrical power, thermal capacity, COP, SCOP, pressure, energy counters, switches for system/vacation/disinfection, heating curve points, the works. Published as a HACS-installable repo: [github.com/jernejstrasner/ha-kronoterm](https://github.com/jernejstrasner/ha-kronoterm).

![The Home Assistant dashboard on the local integration: status, efficiency, 24-hour graphs for temperatures, power, COP and energy](/images/2026-09-06/ha-dashboard.png)

The end result on my dashboard. Everything on it comes from the local integration; none of it touches Elektrina's servers.

Best detective moment: the documented energy counter registers read zero on my firmware. The real lifetime counters turned out to be two undocumented registers, confirmed because their ratio is 4.18, exactly the unit's reported SCOP. 10,751 kWh electrical in, 44,958 kWh thermal out over its life so far.

## Rollback

Nothing was ever written to the heat pump's own configuration. Full rollback is deleting one DNS record and rebooting the module; it re-registers with the real cloud within a minute. That property mattered to me more than any single feature. I definitely want to avoid any serviceablity issues down the line. It's my house's heating we're talking about.

## What the agent was actually good at

The grinding. Frame decoding, endianness hypotheses, register cross-referencing, writing a full HA integration with correct entity semantics, driving the UniFi and Home Assistant APIs directly instead of asking me to click through interfaces. Long captures went in, structured analysis came out, and it held the whole project state (register maps, frame formats, which services run where) without losing track. It also made classic mistakes: it pkilled its own shell once (the pattern matched its own command line), and Home Assistant's module caching made one "reload" look like my fix didn't work when it just wasn't loaded. Both got diagnosed and fixed without me touching the keyboard.

Cost and behavior, since people ask about both: the whole session ran about $20 in tokens. The same volume of work on Claude would cost roughly 4x that, at lower speed. And there was no refusal theater: this project is literally impersonating a vendor's cloud endpoint and intercepting its TLS traffic, and the model just did the work on my own hardware without a lecture. Anyone who has had an Anthropic model explain why it can't possibly help them modify their own equipment knows the difference.

The honest summary: a weekend-plus project compressed into an afternoon, and I spent that afternoon steering and reviewing instead of reading protocol documents. None of this is hard in the intellectual sense; it's tedious. Tedious is what agents are for.

Repo: [github.com/jernejstrasner/ha-kronoterm](https://github.com/jernejstrasner/ha-kronoterm) (the actual proxy service is closed-source for now)

If you've done the same with a Modbus-only unit, or you think MITM-ing your own appliances is a step too far, I want to hear it.

---

A note on the tooling, since it matters for how you read the above: I'm a founder at sference, where we host Kimi K3 ($3 / $15 / $0.45 per million tokens, [app.sference.com](https://app.sference.com)), and the agent doing the work was pi. I picked K3 for this because long-horizon grunt work is where it earns its keep: multi-hundred-line binary captures in, patient hypothesis testing, no drama. This post is the dogfood report.


Jernej Štrasner

My heat pump's cloud app was stuck in 2012, so I reverse-engineered the protocol and cut it out