!Hand dreht am Thermostatkopf eines Heizkörpers
Am 16. November 2024 eröffnete der Entwickler von Versatile Thermostat im eigenen GitHub-Repository ein Issue, das mit einem Eingeständnis begann. Der Titel: „Add native support of Sonoff TRVZB valve in VTherm". Im Text schlug jmcollin78 vor, eine Regel zu brechen, die er selbst aufgestellt hatte. Die „ungeschriebene Regel", schrieb er, laute: Die Integration solle generisch sein und sich nicht an eine Marke oder ein Modell binden. Beim Sonoff TRVZB mache er eine Ausnahme, weil das Gerät billig, gut und eines der wenigen sei, bei dem sich die Ventilöffnung überhaupt direkt ansteuern lasse.
Das Issue wuchs auf 219 Kommentare und wurde am 7. Dezember 2024 geschlossen. Ein Nutzer wollte den Offset lieber auf die gemessene als auf die Zieltemperatur anwenden, wie Better Thermostat es tut. Ein anderer bot an, die Lösung allgemeiner zu bauen, mit einer frei wählbaren Climate-Entität, einer Offset-Entität und einem Paar aus Öffnungs- und Schließgrad. Der Maintainer antwortete knapp, genau das habe er vor, es gebe ohnehin keine andere Wahl. Heute steht das Ergebnis in der Doku, und es erklärt ziemlich gut, was diese Integration im Kern ist: eine Regelschleife für Heizkörper, die sich nicht auf die Eigenintelligenz der Thermostate verlässt.
Dieser Artikel zeigt, wie Versatile Thermostat (kurz VTherm) arbeitet, welcher der drei Typen zu Ihrer Hardware passt und wo die Fallen liegen. Stand ist der 19. Oktober 2026. Die aktuelle Version ist 10.6.1 vom 18. Oktober, das Repository gibt es seit dem 27. Dezember 2022 und es hat 1209 Sterne.
Was VTherm anders macht
Ein normales Heizkörperthermostat hat einen Fühler, der direkt am Heizkörper sitzt. Der misst die Wärme des Heizkörpers statt die Temperatur im Raum, und das ist der Grund, warum Räume mit smarten Thermostaten oft schwanken. VTherm legt eine eigene Regelung über das Gerät. Sie nimmt einen Raumsensor Ihrer Wahl, optional einen Außentemperatursensor, und berechnet daraus selbst, wie viel Wärme nötig ist.
Installiert wird die Integration über HACS: im Store „Versatile Thermostat" suchen, installieren, Home Assistant neu starten, dann unter Einstellungen und Integrationen so viele Thermostate anlegen, wie Sie Heizkörper oder Heizkreise haben. Laut hacs.json braucht die aktuelle Version Home Assistant 2026.3.1 oder neuer. Eingerichtet wird alles über die Oberfläche, es gibt keine YAML-Pflicht.
Was die Integration über den reinen Regler hinaus bietet, zählt die Doku selbst auf: Presets, Fenster- und Türerkennung mit Verzögerung, Anwesenheitssteuerung, Bewegungsmelder, Lastabwurf bei zu hohem Gesamtverbrauch, zentrale Steuerung aller Thermostate und die Ansteuerung eines zentralen Heizkessels. Für einen einzelnen Raum ist das meiste davon Überbau.
Der TPI-Algorithmus: Prozent statt Schalter
Das Herz der Integration ist TPI, „Time Proportional Interval". Die Doku nennt die Formel offen:
on_percent = coef_int * (Soll - Raumtemperatur) + coef_ext * (Soll - Außentemperatur)Das Ergebnis wird auf den Bereich 0 bis 1 begrenzt. Die Standardwerte sind coef_int 0,6 und coef_ext 0,01, laut Doku passend für einen „standard well-insulated room".
Zwei Rechenbeispiele mit diesen Standardwerten, von mir ausgerechnet. Soll 21 Grad, Raum 19 Grad, draußen 5 Grad: 0,6 mal 2 plus 0,01 mal 16 ergibt 1,36, begrenzt auf 1, also 100 Prozent. Der Heizkörper bekommt volle Leistung. Soll 21 Grad, Raum 20,5 Grad, draußen 5 Grad: 0,3 plus 0,16 ergibt 0,46, also 46 Prozent. Bei einem Zyklus von zehn Minuten wäre ein Schalter 4,6 Minuten an und 5,4 Minuten aus. Der Raum wird nicht mit Vollgas an den Sollwert gefahren und dann abgeschaltet, sondern kurz davor gedrosselt. Das ist der ganze Trick.
Die Nachjustierung beschreibt die Doku in vier Regeln. Wird die Zieltemperatur nach dem Einschwingen nicht erreicht, erhöhen Sie coef_ext. Wird sie überschritten, senken Sie coef_ext. Dauert das Aufheizen zu lange, erhöhen Sie coef_int. Pendelt die Temperatur um den Sollwert, senken Sie coef_int. Dazu kommen eine Mindest-Einschaltdauer und eine Mindest-Ausschaltdauer in Sekunden, damit das Gerät nicht für Sekundenbruchteile schaltet, und seit Version 7.4 eine obere und untere Schwelle. Liegt die Temperatur über Soll plus oberer Schwelle, wird die Heizleistung auf null gezwungen, bis sie wieder unter Soll plus untere Schwelle fällt.
Die Zykluslänge steht in den Hauptattributen. Die Doku nennt fünf Minuten einen guten Wert, in den Tuning-Beispielen stehen für Elektroheizungen fünf bis zehn Minuten mit 30 Sekunden Mindest-Einschaltdauer, für Gas- oder Ölzentralheizungen 30 bis 60 Minuten mit 300 Sekunden, wegen der trägen Reaktion des Wassers.
Die drei Typen
Hier müssen Sie sich beim Anlegen entscheiden, und die Entscheidung hängt allein davon ab, was Ihr Gerät in Home Assistant anbietet.
over_switch steuert einen Schalter an. Das ist die Variante für Elektroheizkörper hinter einer Zigbee-Steckdose oder einem Unterputz-Schaltaktor. Die Doku listet als Entitäten switch, input_boolean, select, input_select und climate. Bei mehreren Geräten staffelt VTherm die Einschaltzeiten, damit nicht alle gleichzeitig ziehen. Für Geräte ohne einfachen Schalter, etwa Nodon-Module für den Fadenpilot-Draht, braucht es benutzerdefinierte Befehle.
over_climate legt sich über eine vorhandene Climate-Entität, also die meisten smarten Heizkörperthermostate. Hier regelt das Gerät selbst, VTherm schickt nur Sollwerte. Mit „Selbstregulierung" korrigiert es den Sollwert nach oben oder unten, bis der Raum wirklich die gewünschte Temperatur hat. Ein Sonderfall ist die „direkte Ventilsteuerung": Hat das Thermostat Zahlen-Entitäten für die Ventilöffnung, setzt VTherm die Öffnung per TPI selbst.
over_valve steuert eine reine Zahl-Entität an, die von 0 bis 100 Prozent geht. Die Doku rät aber ausdrücklich, diesen Typ nur zu wählen, wenn es keine Climate-Entität für das Thermostat gibt. Der Typ over_climate mit direkter Ventilsteuerung sei „much more powerful". Als Beispiel für over_valve nennt die Hardwareliste das Shelly BLU TRV.
Kurz gesagt: Schalter heißt over_switch, Thermostat mit Climate-Entität heißt over_climate, nur eine Zahl heißt over_valve.
Konfigurationsbeispiel: Sonoff TRVZB mit direkter Ventilsteuerung
Aus dem Quick-Start der Doku, in meiner Reihenfolge. Zuvor muss das Thermostat sauber in Home Assistant laufen, wie das mit ZHA oder Zigbee2MQTT geht, steht im Artikel zum Sonoff TRVZB in Home Assistant.
- Integration „Versatile Thermostat" hinzufügen, Typ
over_climate. - Hauptattribute: Name, Raumtemperatursensor und Außentemperatursensor. Als Mindestangabe nennt die Doku genau diese drei.
- Unterliegendes Gerät: die Climate-Entität des TRVZB.
- Regulierungsart „Direct valve control". Die Option „Compensate for underlying temperature" bleibt aus. Die Doku warnt, diese Option dürfe nicht zusammen mit direkter Ventilsteuerung und Kalibrier-Entität verwendet werden.
- Die drei Zahlen-Entitäten eintragen:
opening_degree,closing_degreeundcalibration_offset. Der Schließgrad muss auf Maximum, also 100 Prozent, stehen. - Die Option „Follow underlying temperature change" erst einschalten, wenn die Grundkonfiguration läuft.
self-regulation.md erklärt: opening_threshold (darunter gilt das Ventil als geschlossen), max_closing_degree, minimum_opening_degrees und max_opening_degrees. Die Doku bringt zwei Fälle als Beispiel. Wenn Ihr Ventil eine Totzone von 15 Prozent hat, in der kein Wasser fließt, setzen Sie minimum_opening_degrees auf 15. Wenn das Ventil nie ganz zu und nie ganz auf sein soll, etwa zum Schutz der Umwälzpumpe, nehmen Sie 10 für das Minimum, 90 für max_closing_degree, 10 für den Schwellwert und 50 als Maximum.
Das Regelintervall braucht Sorgfalt. Im Absatz zur Regulierung steht, die Schwelle dürfe bei Ventilsteuerung nicht unter 3 Prozent liegen, „else the Sonoff TRVZB can lost its calibration". Diesen Fall, samt Erklärung des Maintainers, haben wir im TRVZB-Artikel unter „Ventilposition" beschrieben.
Der Fall mit dem Minimum
Die Mindestöffnung hat ihren eigenen Ärger produziert. Im November 2025 meldete ein Nutzer nach dem Update auf Version 8.0.0 im Issue #1220, seine Thermostate stünden dauerhaft auf „heizt". Alle Instanzen mit gesetztem Minimum blieben auf dem Minimum offen, bei ihm 8 Prozent, auch wenn der Sollwert (13 Grad) weit unter der Raumtemperatur (20 Grad) lag. Dazu kam eine zweite Folge: Wenn nur ein Raum heizen will, fließt heißes Wasser durch alle Heizkörper, weil alle ein Stück offen sind.
Der Maintainer antwortete, so solle das Minimum funktionieren: Das Ventil gehe nie unter den Wert, selbst wenn VTherm ausgeschaltet sei. In einem späteren Kommentar legte er nach: Der Parameter existiere, weil bei manchen Installationen zwischen 0 und x Prozent Öffnung gar kein Wasser fließe. Eine Kompensation sei das nicht. Setzen Sie minimum_opening_degrees nur, wenn Sie die Totzone Ihres Ventils wirklich kennen. Den Wert finden Sie, indem Sie die Öffnung langsam hochziehen und beobachten, ab wann der Heizkörper warm wird.
Der externe Raumsensor
Die Daseinsberechtigung des Ganzen ist der Sensor an der richtigen Stelle. Die Doku sagt es deutlich: Er gehöre in die Mitte des Wohnbereichs, weder zu nah am Fenster noch zu nah am Heizkörper. Dazu kommt die Synchronisation der Gerätetemperatur für over_climate, die auf zwei Wegen geht. Der erste nutzt die Kalibrier-Entität des Geräts, der zweite schickt die Raumtemperatur direkt an einen Eingang namens external_temperature_input. Der TRVZB kann beides, bei der zweiten Variante muss die Option sensor_select auf external stehen. Der Aqara W600 hat laut Doku nur die Kalibrier-Entität.
Und der Aqara E1? Er läuft in der Dokumentation unter der Modellnummer SRTS-A01, und die Hardwareliste führt ihn bei den Geräten, die keine hvac_action melden. VTherm weiß dann nicht, ob das Thermostat gerade heizt, und der angezeigte Zustand stimmt nicht immer. „The rest seems functional", steht dort. Auf der Zigbee2MQTT-Seite für das Gerät sind unter anderem external_temperature_input und die Einstellung sensor (intern oder extern) gelistet. Das E1 hat keine steuerbare Ventilöffnung, es geht also nur over_climate mit Selbstregulierung, nicht mit TPI. Wie bei jedem solchen Gerät gilt der Rat aus dem Quick-Start: eingebauten Wochenplan abschalten, nicht den Systemmodus auto nutzen, die geräteeigene Fenster-offen-Erkennung deaktivieren und die internen Presets ignorieren, sonst arbeiten zwei Regler gegeneinander.
Die Selbstregulierung selbst soll vorsichtig starten. Die Doku empfiehlt, erst zu beobachten, wie das Gerät allein regelt, dann mit der Stufe „Light" (maximal 1,5 Grad Korrektur) zu beginnen, Tage zu warten und erst bei Bedarf auf „Medium" (2 Grad) und „Strong" (3 Grad) zu gehen. Der Grund steht ebenfalls dort: Die Korrektur zwingt das Gerät zu mehr Arbeit und kann den Verbrauch und den Verschleiß erhöhen.
Fenster offen
Die Fenster-Erkennung kennt zwei Modi, die sich ausschließen. Im Sensormodus tragen Sie einen binary_sensor oder input_boolean ein, dazu eine Verzögerung in Sekunden und eine Aktion: ausschalten, nur Lüften (bei passenden Geräten), Frostschutz oder Eco. Nach dem Öffnen wartet VTherm die Verzögerung ab. Ist das Fenster dann noch offen, speichert es Modus, Preset und Zieltemperatur und führt die Aktion aus. Beim Schließen läuft es umgekehrt, wieder mit Verzögerung. Mehrere Fenster in einem Raum fassen Sie vorher in einer Gruppe zusammen, was die Doku ebenfalls vorsieht.
Im Automodus gibt es keinen Sensor, VTherm schließt aus dem Temperaturgefälle auf ein offenes Fenster. Die Doku nennt als erprobte Werte für ein Büro 3 Grad pro Stunde als Erkennungsschwelle, 0 Grad pro Stunde zum Beenden und 30 Minuten als Höchstdauer. Für Flure und offene Räume mit ohnehin schwankender Temperatur rät sie davon ab. Dazu liefert VTherm einen Sensor „slope", der die geglättete Steigung in Grad pro Stunde zeigt, damit Sie die Schwellen im Verlaufsdiagramm einstellen können.
Wer die Variante mit einer selbst geschriebenen Automation vorzieht, findet sie im Artikel Fenster offen, Heizung aus in Home Assistant. Entscheiden Sie sich für eine Variante: Wenn VTherm die Fenster regelt, sollte nicht zusätzlich eine Automation oder die Erkennung des Thermostats eingreifen.
Präsenz und Presets
Die Presets heißen Eco, Comfort und Boost, dazu kommt „None" für manuelle Temperaturen. Aktivieren Sie die Präsenzfunktion, bekommt jedes Preset eine Abwesenheitsvariante, die über Zahlen-Entitäten eingestellt wird. Die Doku zeigt ihre eigenen Werte: Eco 17 Grad, Comfort 19, Boost 20, Frostschutz 10. Ist niemand zu Hause, fallen sie auf 16,5, 17 und 17,5 Grad, der Frostschutz bleibt bei 10. Der Präsenzsensor muss on oder home liefern, sobald jemand da ist. Eine Personengruppe taugt nicht direkt, sie braucht laut Troubleshooting-Seite ein Template.
Wer vorheizen will, bevor jemand heimkommt, hängt einen input_boolean in die Gruppe und setzt ihn per Automation, zum Beispiel beim Betreten einer Zone. Wie viel das insgesamt bringt, hängt stark von der Quelle ab, die Spanne von 6 bis 26 Prozent beschreibt der Artikel über die Ersparnis smarter Heizkörperthermostate.
Auto-TPI: Vorsicht bei Ventilen
Neu ist die Funktion „Auto TPI", die die Koeffizienten selbst lernt. Die Doku schränkt gleich im ersten Absatz ein: gedacht für Schalter-Heizungen wie Elektroheizkörper, Kessel oder Fußbodenheizung. Für Thermostate mit Ventil bleibe die Anpassung „problematic due to their non-linearity". Für Heizkörperventile stellen Sie coef_int und coef_ext also vorerst von Hand ein, mit den vier Regeln oben.
VTherm gegen den generic_thermostat
Der Standard-Thermostat von Home Assistant, generic_thermostat, ist ein Zweipunktregler. Sie geben einen Heizer (einen Schalter) und einen Temperatursensor an. Er schaltet ein, wenn die Temperatur um cold_tolerance unter den Sollwert fällt (Standard 0,3 Grad), und aus, wenn sie um hot_tolerance darüber liegt. Mit min_cycle_duration und keep_alive lässt sich das Takten begrenzen. Mehr nicht, es gibt weder Fenster noch Präsenz noch Außentemperatur, und er stellt nie etwas dazwischen ein.
Für einen Elektroheizkörper im Gästezimmer reicht das. Sobald der Heizkörper träge ist, also bei Wasserheizkörpern, schwingt ein Zweipunktregler: Er schaltet zu spät aus, weil der Heizkörper noch nachglüht. VTherm mit TPI bremst vorher ab. Das ist der Gewinn.
VTherm gegen Better Thermostat
Better Thermostat ist die bekanntere Alternative. Das Repository hat 1515 Sterne, die letzte stabile Version 1.9.3 erschien am 6. Oktober 2026, am 11. Oktober folgte die 2.0.0-Beta1. Es verlangt laut README Home Assistant 2026.7.2 oder neuer. Auch Better Thermostat nutzt einen externen Raumsensor, wertet Fenstersensoren aus, gruppiert mehrere Thermostate und wartet die Ventile gegen Festsitzen. Der Unterschied: Better Thermostat ist ein Korrektur-Aufsatz für vorhandene Thermostate und bringt seit Neuestem selbst Regelalgorithmen mit. Die README nennt MPC, PID, TPI und „AI Time Based" und empfiehlt TPI oder AI Time Based als Einstieg.
VTherm ist dagegen ein vollständiger Regler mit eigenem Typ pro Hardwareart, mit Zentralsteuerung, Lastabwurf und Kesselsteuerung. Es kostet mehr Einarbeitung. Meine Einschätzung: Für ein, zwei smarte Thermostate mit gutem Raumsensor ist Better Thermostat der schnellere Weg. VTherm lohnt sich bei mehreren Räumen, gemischter Hardware oder wenn Sie die TPI-Parameter selbst im Griff haben wollen. Beide gleichzeitig auf dasselbe Thermostat zu legen, ist eine schlechte Idee, das gilt für jede zweite Regelschicht.
Welche Hardware überhaupt in Frage kommt, sortiert der Artikel Heizkörperthermostat für Home Assistant: Welches passt?.
Wann es sich lohnt
Bevor Sie VTherm installieren, probieren Sie das Gerät allein mit einem externen Sensor. Die Doku rät das selbst: erst beobachten, dann eingreifen. Halten die Räume die Temperatur, brauchen Sie keine zusätzliche Schicht. Schwanken sie trotz Sensor, ist VTherm das richtige Werkzeug, und dann in dieser Reihenfolge: ein Typ, ein Raum, die Standardwerte 0,6 und 0,01, eine Woche beobachten, erst dann Fenster, Präsenz und Presets dazunehmen. So finden Sie einen Fehler im Zusammenspiel leichter.
