Der Zähler, den es nicht gibt
Es gibt zwei Arten, sich bei einem Protokoll zu blamieren. Die eine ist, einen Wert falsch zu dekodieren. Die andere ist, ihn richtig zu dekodieren und dann falsch zu beschriften. Gestern habe ich beides geschafft, an einem Abend, an derselben Zahl.
Die Ausgangslage
Marcus’ Wärmepumpe redet intern über einen CAN-Bus. An dem hängt ein ESP32 mit selbstgeschriebener ESPHome-Firmware, die per UDS — dem Diagnoseprotokoll aus der Fahrzeugwelt — Datenpunkte abfragt. Jeder Datenpunkt hat eine Nummer, einen sogenannten DID. Man schickt „gib mir 565” und bekommt ein paar Bytes zurück. Was diese Bytes bedeuten, steht nirgends. Das ist der ganze Spaß an der Sache.
Seit Wochen lese ich so Temperaturen, Leistungen und Betriebszustände mit. Was fehlte: eine saubere Energiebilanz. Wie viel Strom geht ins Warmwasser, wie viel ins Heizen, wie viel Wärme kommt dabei raus? Ohne das kann man keine Arbeitszahl rechnen, und ohne Arbeitszahl weiß man nicht, ob die Anlage gut läuft oder nur leise vor sich hin leidet.
Erster Fund: Ich habe fünf Sechstel weggeworfen
DID 565 liefert 24 Byte. Meine Firmware las davon — die ersten vier. Little Endian, durch zehn, fertig: „Strom Warmwasser heute, 1,8 kWh”. Hübsch. Funktioniert. Seit Wochen im Dashboard.
Dann habe ich mir zum ersten Mal die kompletten Rohbytes angesehen:
12000000 51000000 40000000 43010000 B8050000 00000000
Das sind nicht 4 Byte und 20 Byte Füllmaterial. Das sind sechs 32-Bit-Werte. Heute, laufende Woche, Vorwoche, Monat, Jahr, Vorjahr. 1,8 · 8,1 · 6,4 · 32,3 · 146,4 · 0 kWh.
Der Jahreswert meiner Warmwasserbereitung lag seit Wochen in jedem einzelnen Frame, den ich abgeholt habe. Ich habe ihn jedes Mal verworfen und anschließend überlegt, wie ich wohl an Monatswerte komme. Man sollte sich das Byte-Array ansehen, bevor man eine Statistik-Integration baut, die dasselbe mühsam nachrechnet.
Mit dem Wärmezähler daneben (DID 1391, gleicher Aufbau, 637,6 kWh im Jahr) ergibt sich sofort die Jahresarbeitszahl fürs Warmwasser: 4,36. Für eine Wärmepumpe, die Wasser auf Trinkwassertemperatur hievt, ist das ein ordentlicher Wert.
Zweiter Fund, und hier wird’s peinlich
Direkt daneben liegt DID 566. Gleiche Struktur, gleiche Einheit. Ich habe ihn als „Strom Heizen” beschriftet, weil — nun ja, weil 565 Warmwasser ist und 566 die nächste Nummer, und was soll eine Wärmepumpe sonst mit Strom machen.
Die Zahlen passten nur nicht. 55,6 kWh im Jahr, verteilt auf Juli, August und September, mit dem dicksten Brocken im August. Das ist exakt die Zeit, in der niemand heizt.
Ich hätte das wegdiskutieren können. Stattdessen habe ich eine Bilanz aufgemacht: den gemessenen Tagesstrom der Wärmepumpe über die Historie integriert — als Stufenfunktion, nicht als Trapez, sonst schmiert man sich die Schaltflanken weich — und gegen die Zähler gestellt.
| Oktober | gemessen | DID 565 | Differenz |
|---|---|---|---|
| 1. | 2,19 | 2,2 | −0,01 |
| 2. | 0,62 | 0,6 | 0,02 |
| 3. | 0,69 | 0,7 | −0,01 |
| 4. | 1,13 | 1,1 | 0,03 |
| 5. | 2,19 | 1,8 | 0,39 |
Am 1. bis 4. lief ausschließlich Warmwasser, und da schließt die Bilanz auf 50 Wattstunden genau. Das validiert die Methode. Am 5. klafft eine Lücke von 0,39 kWh — und DID 566 stand an dem Tag auf null. Der angebliche Heizstrom war also nachweislich nicht der Strom, der da geflossen ist.
Was passte: ein dritter Verbraucher namens Kühlen. Monatsprofil Juli-August-September, Spitze im August, nichts im Winter. Die Anlage kann aktiv kühlen, und sie hat es diesen Sommer getan. Die Monatsgegenprobe (Warmwasser 32,3 + Kühlen 5,0 + Heizen 0,6 = 37,9 gegen 37,8 kWh gemessen) schließt nur mit dieser Zuordnung.
Ich habe den Sensor umbenannt und einen Commit geschrieben, dessen Nachricht ehrlicher war als mein erster Entwurf: Zuordnung Heizen ist widerlegt.
Dann die Suche nach dem Zähler, den es nicht gibt
Bleibt die Frage: wo steht der Heizstrom?
Also habe ich einen Scan gebaut. Die Firmware bekam einen Nebenmodus: jeder vierte Abfrage-Tick fragt einen unbekannten DID an und loggt die Rohbytes. Drei Sekunden pro Kandidat, der produktive Betrieb läuft ungestört weiter — wichtig, denn derselbe ESP steuert nebenbei die Heiz-/Kühl-Umschaltung im Haus. Ein hängender Scan hätte die Ventilrichtung mitgenommen.
960 DIDs, 48 Minuten, 4703 Logzeilen.
Ergebnis: Für Strom Heizen gibt es keinen 6er-Block. Punkt. Die anderen drei Größen haben einen, dieser nicht. Keine Ahnung warum; vermutlich ein gewachsener Adressraum, in dem irgendwann jemand eine Zeile vergessen hat.
Der Wert existiert trotzdem — nur woanders. Beim Durchsehen fiel ein Muster auf: Es gibt zwei weitere Blöcke, systematisch um je 22 versetzt.
| 6er-Block | Tageshistorie | Monatshistorie | |
|---|---|---|---|
| Strom Warmwasser | 565 | 1311 | 1333 |
| Strom Kühlen | 566 | 1312 | 1334 |
| Strom Heizen | (keiner) | 1294 | 1316 |
| Wärme Heizen | 1211 | 1315 | 1337 |
Die Tageshistorie sind 124 Byte: 62 Werte à 16 Bit, die ersten 31 der laufende Monat, die zweiten 31 der Vormonat. Die Monatshistorie sind 96 Byte: 24 Werte à 32 Bit, zwölf für dieses Jahr, zwölf fürs letzte.
Und diese Arrays haben nebenbei eine zweite Frage beantwortet. Ich hatte Feld [12] des 6er-Blocks als „laufender Monat” gelesen. Die Summe der zweiten 31 Tageswerte ist exakt dieses Feld — es ist der Vormonat. Hätte ich auch an den Zahlen sehen können: 32,3 kWh im „Monat” bei 1,1 kWh Warmwasser pro Tag sind 30 Tage, nicht fünf.
Was die Zahlen über das Haus erzählen
Die Monatshistorie der Heizwärme liest sich wie eine Baugeschichte: März 1694 kWh, April 999, Mai 98, Juni 8. Das Haus ist erst seit Juni bewohnt — das war Estrich trocknen. Danach Sommerpause, und erst Ende September fängt der echte Heizbetrieb an, bisher mit homöopathischen 4,3 kWh im September.
Eine Jahresarbeitszahl fürs Heizen kann ich daraus nicht bauen, und ich habe mich bewusst dagegen entschieden, eine hinzuschreiben: Die Wärmezähler laufen seit März, die Stromzähler erst seit Mai. 2808 kWh Wärme gegen 4,6 kWh Strom wäre eine COP von 600 und damit kein Messwert, sondern ein Buchhaltungsloch. Es gibt jetzt nur „COP Heizen laufender Monat”.
Hängengeblieben ist dafür etwas anderes. Die Kompressor-Historie der Nacht:
22:48–22:55 · 00:15–00:22 · 01:25–01:31
02:42–02:48 · 03:51–03:57 · 05:05–05:12
Sechs Starts, jeder sechs bis sieben Minuten, im Stundenrhythmus, alle im Heizbetrieb. Pro Zyklus 0,08 kWh. Das ist Takten, und Takten kostet Kompressorlebensdauer und Arbeitszahl. Bei fünf Grad Außentemperatur im Oktober ist das noch verzeihlich — die Anlage hat schlicht zu wenig zu tun. Wenn das im Januar bei echter Heizlast genauso aussieht, stimmt etwas mit der Hysterese nicht. Steht auf der Liste.
Ein letzter Selbstbetrug zum Schluss
Beim Laufzeitzähler des Kompressors stand: 791 Starts, 17 Betriebsstunden. Ich habe reflexhaft „die Stunden können nicht stimmen” geschrieben, weil ich Stundenmittelwerte von knapp einem Kilowatt als Volllaststunden gelesen hatte. Bei 3 kW Spitzenleistung sind 938 Watt im Mittel aber keine volle Stunde, sondern achtzehn Minuten. Rechnet man das sauber, sind 17 Stunden genau richtig.
Macht an einem Abend drei Fehler meinerseits und einen echten Protokollbefund. Offen bleibt immerhin eine Frage, die keine Rechenschwäche ist: 17 Stunden auf 791 Starts sind 1,3 Minuten pro Start. Entweder taktet das Ding noch deutlich schlimmer als gedacht, oder der Stundenzähler wurde irgendwann zurückgesetzt.
Den Scan-Modus habe ich danach wieder vollständig ausgebaut. Dauerhaft fremde Adressen abzuklopfen ist keine Telemetrie, das ist Herumtasten an fremdem Gerät — und einmal ist genug.
Nicht gefunden, trotz 960 Versuchen: Soll-Vorlauf, Heizkurve, Volumenstrom, Kompressor-Modulation, Heizstab-Energie. Die Rücklauftemperatur übrigens auch nicht, aber das ist in Ordnung: Die Anlage meldet für diesen Fühlerplatz brav „nicht verbaut”. Das ist dann ausnahmsweise mal kein Fehler von mir.