KNX-Raumtemperaturregler in Home Assistant: zwei Sollwerte

Aktualisierung, Oktober 2026. Die erste Fassung dieses Posts vom Juni hat ein Symptom an meinen KNX-Raumcontrollern mit einer Ursache erklärt, die ich nie geprüft hatte. Dort stand, dass nur die Voreinstellung Auto eine Solltemperatur aus Home Assistant zulässt, dass die Sollwerte von Komfort und Economy im Gerät fest vorgegeben sind und dass der Regler jeden Schreibvorgang überstimmt. Die Tests vom 23. Oktober zeigten, dass sich der gemeldete Sollwert durch Schreiben der Basis änderte, ohne vorherigen Betriebsartenbefehl. Die tatsächliche Betriebsart konnte ich dabei nicht auslesen, und den Rat, zuerst auf Auto zu schalten, habe ich nie geprüft.

Auf der Standard-Thermostatkarte von Home Assistant habe ich eine Temperatur eingestellt, und einen Moment später zeigte die Karte einen anderen Wert, in meinen Tests ein bis zwei Grad weniger. Meine Schreibvorgänge kamen am KNX-Raumtemperaturregler an, während Home Assistant Komfort anzeigte; die tatsächliche Betriebsart konnte ich am Gerät nicht auslesen. Danach zeigt die Karte den vom Regler zurückgemeldeten Sollwert. Dieser Beitrag beschreibt die Tests vom 23. Oktober sowie das Skript und die Dashboard-Karte, die ich für die 11 Raumcontroller im Haus gebaut habe.

Die fünf HVAC-Betriebsarten einer KNX-Climate-Entität

Die Regler nehmen die Standard-KNX-Betriebsart (DPT 20.102) mit fünf Zuständen entgegen: Auto, Komfort, Standby, Economy und Frostschutz. Home Assistant zeigt sie als Voreinstellungen. Meine Automationen benutzen Komfort für den Tag, Economy für die Nacht und Frostschutz, solange ein Fenster offen ist. Laut Gerätedokumentation ist Standby ein Absenkbetrieb. Die frühere Fassung dieses Posts hat Standby als ausgeschaltete Heizung behandelt, was die Dokumentation nicht hergibt.

Die Karte kann nicht verraten, in welcher Betriebsart der Regler tatsächlich steht. Im ETS-Projekt haben meine Regler kein lesbares Statusobjekt für die Betriebsart. Home Assistant schickt Moduswechsel an das Befehlsobjekt. Nach einem Neustart liefert dieses Objekt Standby zurück, auch wenn Home Assistant vorher Komfort gesendet hat, und die tatsächliche Betriebsart lässt sich darüber nicht prüfen. Die angezeigte Voreinstellung ist nur verlässlich, wenn Home Assistant sie selbst geschrieben hat, und das ist der Hintergrund des Posts zu Standby nach dem Neustart.

Zwei Werte hinter einer Home-Assistant-Thermostatkarte

Laut Herstellerdokumentation und ETS-Export hat jeder der 11 JUNG-Regler einen beschreibbaren Eingang für die Komfort-Basistemperatur und einen lesbaren Ausgang für die aktuelle Solltemperatur. Home Assistant benutzt den ersten als Adresse der Zieltemperatur und den zweiten als deren Statusadresse. Der Regler rechnet Betriebsart und eine eventuelle lokale Verschiebung am Gerät auf die Basis drauf. Die Climate-Entitäten stehen in der knx.yaml, wie die Schalter, seit ich sie aus der Oberfläche übernommen habe. Der Ausschnitt zeigt sie unter dem Schlüssel knx:, wie in einer Package-Datei; bei knx: !include knx.yaml entfällt dieser äußere Schlüssel. Der neue Sensor ist der zweite Block:

# knx.yaml — ein Raumcontroller (Gruppenadressen sind Platzhalter)
knx:
  climate:
    - name: "Thermostat Raum A"
      temperature_address: "9/0/3"               # Raumtemperatur (lesen)
      target_temperature_address: "9/1/3"        # Komfort-Basistemperatur (schreiben)
      target_temperature_state_address: "9/2/3"  # wirksamer Sollwert, den der Regler meldet
      operation_mode_address: "9/3/3"            # Betriebsartenbefehl, kein lesbarer Status
      temperature_step: 0.5
      min_temp: 18.0
      max_temp: 25.0
  sensor:
    # eigener, rein lesender Sensor auf derselben Sollwert-Adresse
    - name: "RC Sollwert Raum A"
      state_address: "9/2/3"
      type: temperature
      sync_state: init
      always_callback: true   # jede Antwort aktualisiert last_updated, auch bei gleichem Wert

Die Basis zurückzulesen funktioniert hier nicht. Der Komfort-Eingang war nicht zum Lesen vorgesehen, sein Lese-Flag wurde in der ETS nachträglich gesetzt, und die Antworten ergeben decodiert Werte wie 0,21 °C, aus Gründen, die ich nicht gefunden habe. Die einzige verlässliche Rückmeldung ist der wirksame Sollwert.

Was die Tests vom 23. Oktober gezeigt haben

Am getesteten Regler habe ich ohne jeden Betriebsartenbefehl eine Basis von 23 °C geschrieben. Home Assistant zeigte Komfort an, was wie oben beschrieben keine Bestätigung vom Gerät ist. Der Regler meldete 21 °C, von sich aus und auf eine frische Leseanfrage. Eine Basis von 25 °C ergab 23 °C, das sah nach einer festen Differenz von −2 K aus.

Dann habe ich den Sollwert am Regler selbst um ein Grad erhöht, und er meldete 24 °C. Im Home-Assistant-Dialog habe ich ihn auf 23 °C gesenkt, Home Assistant schrieb eine Basis von 23 °C, und der Regler meldete 22 °C. Die Differenz betrug jetzt −1 K, eine Automation, die immer 2 K draufrechnet, wäre also nach einem Tastendruck an der Wand falsch gewesen. Ob die ursprünglichen −2 K von der Betriebsart oder einer lokalen Verschiebung kamen, weiß ich nicht.

Halbe Grad setzte der Regler nicht genau um. Mit dem Ziel 23,5 °C ergab eine Basis von 23,5 den Wert 23, eine Basis von 24 ebenfalls 23 und eine Basis von 24,5 den Wert 24. Getestet habe ich das nur an einem Regler und die neue Bedienung für alle auf ganze Grad begrenzt.

Auf Auto habe ich während dieser Tests keinen Regler geschaltet, und was Auto mit dem gemeldeten Sollwert macht, habe ich nicht getestet. Laut Dokumentation lässt sich die Komfortbasis auch im Komfortbetrieb schreiben; in meinem Versuch ging das ohne vorherigen Betriebsartenbefehl, die tatsächliche Betriebsart konnte ich aber nicht prüfen.

Die Lösung: ein Rückmeldesensor und ein korrigierendes Skript

Jeder Regler hat jetzt einen eigenen, rein lesenden KNX-Sensor auf der Adresse des wirksamen Sollwerts. Mit always_callback aktualisiert jede Antwort den Zeitstempel last_updated des Sensors, auch bei unverändertem Wert, und so kann das Skript eine frische Antwort von einem Wert unterscheiden, den Home Assistant schon hatte.

Das Skript bekommt einen Raum und eine Wunschtemperatur in ganzen Grad von 18 bis 25 °C. Es fordert einen frischen Wert an und wartet bis zu 5 Sekunden. Meldet der Regler den Wunschwert bereits, hört es ohne Schreiben auf. Andernfalls schreibt es eine Basis, wartet eine Sekunde und liest erneut. Für den nächsten Versuch addiert das Skript die Differenz zwischen Wunschwert und Rückmeldung zur zuletzt geschriebenen Basis; diese Differenz ermittelt es bei jedem Aufruf neu. Nach drei Schreibvorgängen, oder wenn die nächste Basis 18–25 °C verlassen würde, hört es mit einem Fehler und dem zuletzt gemeldeten Wert auf. Erfolg meldet es erst, wenn der Regler den gewünschten Sollwert zweimal im Abstand von einer Sekunde zurückgemeldet hat. Der Ausschnitt unten zeigt nur die Korrekturschleife; Raumzuordnung, Variablen und das separate Leseskript fehlen darin.

# packages/raumcontroller.yaml — gekürzt
script:
  rc_set_temperature:
    mode: single                 # ein Auftrag zur Zeit, keine konkurrierenden Korrekturschleifen
    fields:
      entity_id: {}              # Climate-Entität des Raums
      temperature: {}            # gewünschter wirksamer Sollwert, ganze Grad 18–25
    sequence:
      # frisch lesen: knx.read, dann bis zu 5 s auf ein neueres last_updated warten
      - &read_fresh
        action: script.rc_read_setpoint
        data: { address: "{{ room.address }}", sensor: "{{ room.sensor }}" }
        response_variable: reading
      # (schon richtig -> Erfolg ohne Schreiben melden; hier weggelassen)
      - repeat:
          count: 3
          sequence:
            - if: "{{ candidate < 18 or candidate > 25 }}"
              then:
                - stop: "Mit den Basisgrenzen 18–25 °C nicht erreichbar."
                  response_variable: result   # ok: false und der zuletzt gemeldete Sollwert
            - action: climate.set_temperature   # schreibt die Komfortbasis
              target: { entity_id: "{{ entity_id }}" }
              data: { temperature: "{{ candidate }}" }
            - delay: { seconds: 1 }
            - *read_fresh
            - variables:
                actual: "{{ reading.actual }}"   # den neuen Messwert für den nächsten Schritt übernehmen
            # (keine frische Antwort -> Fehlerergebnis; weggelassen)
            # (Treffer -> 1 s warten, erneut lesen, Erfolg erst beim zweiten Treffer; weggelassen)
            - variables:
                candidate: "{{ (candidate + wanted - actual) | round(2) }}"

Das Skript läuft im Modus single und hält die Temperatur danach nicht fest: spätere Änderungen am Regler oder durch das Zeitprogramm gelten wie gewohnt. Bei der gemessenen Differenz von −1 K bräuchte ein wirksamer Sollwert von 25 °C eine Basis von 26 °C, die Home Assistant nicht schreiben darf, deshalb zeigt die Karte einen Fehler. Jeder andere Aufruf von climate.set_temperature, aus einem anderen Dashboard oder von einem Sprachassistenten, schreibt weiterhin direkt die Basis und umgeht das alles, Automationen sollten deshalb das Skript aufrufen.

Die Dashboard-Karte und die Tests

Alle 11 Standard-Thermostatkacheln auf meinem Haupt-Dashboard sind durch eine kleine eigene Karte ersetzt, mit Raumtemperatur, wirksamem Sollwert aus dem neuen Sensor und einem Feld mit Plus- und Minustaste in ganzen Grad. Ein leeres Feld startet beim zuletzt gemeldeten Sollwert. Gesendet wird erst, wenn Übernehmen das Skript startet. Während eines Auftrags sind die Bedienelemente gesperrt, bei 18 und 25 °C ist die jeweilige Taste deaktiviert, und das Ergebnis bleibt auf der Karte stehen, auch bei Fehlern.

Elf automatisierte Tests spielen die tatsächlichen YAML-Sequenzen des Skripts gegen einen simulierten Bus durch: positive, negative und sich ändernde Differenzen, ein bereits passender Wert, fehlende Antworten in jedem Schritt, die Basisgrenzen, zu viele Versuche und ungültige Eingaben. Browsertests decken die Karte ab. Am echten Regler habe ich 24 °C angefordert und nach einer Basis von 25 °C auch 24 °C zurückgemeldet bekommen; die nächste Anforderung von 23 °C ergab bei einer Basis von 24 °C den Wert 23 °C.

Automationen, die Voreinstellungen umschalten

Die Heizungsautomationen schreiben nie eine Temperatur, nur die Voreinstellung, deshalb hat das Sollwertproblem sie nicht betroffen. Ein Helfer namens Heizung Nachtmodus geht um 21:00 an und um 05:00 aus, und das setzt alle 11 Regler auf Economy beziehungsweise Komfort. Die frühere Fassung nannte 06:00, weil die Entity-ID der alten Automation das sagt, gelaufen ist sie aber immer um 05:00. Für den Nachtbetrieb war an einer Stelle Standby eingestellt, an zwei anderen Economy. Auf der neuen Instanz habe ich alle drei auf Economy gestellt und den Helfer so eingerichtet, dass er seinen Zustand über einen Neustart behält.

Die Fensterlogik deckt acht Räume ab. Ist ein Fenster 5 Sekunden offen, geht der Raum auf Frostschutz, und 5 Sekunden nach dem Schließen kehrt er in die Betriebsart zurück, die gerade gilt. Auf der alten Instanz waren das 16 kopierte UI-Automationen, und Schließen setzte immer Komfort, auch nachts. Auf der neuen Instanz ist es eine Automation mit einer Tabelle von Fenster zu Regler, und die Tag- und Nachtautomationen lassen Räume mit offenem Fenster aus. Mehr dazu im Fenster-Post.

Ohne lesbaren Betriebsartenstatus ist das erneute Senden der Betriebsart nach einem Start der einzige Weg zu einem bekannten Zustand. Die Start-Automation wartet 30 Sekunden und setzt dann den Nacht- oder Tagmodus, wieder ohne Räume mit offenem Fenster. Auf der alten Instanz ist sie seit Januar deaktiviert. Die in diesem Abschnitt beschriebenen neuen Heizungsautomationen sind auf der neuen Instanz eingerichtet, bleiben aber abgeschaltet, bis ich die Heizung umziehe; bis dahin steuert die alte Instanz Zeitplan und Fensterlogik. Rückmeldesensoren, Skript und Karte sind auf der neuen Instanz bereits im Einsatz. Ob ich diese Wahl zwischen Tag- und Nachtmodus beim Start nach dem Umzug der Heizung beibehalte, habe ich noch nicht entschieden.

Häufige Fragen

Warum zeigt mein KNX-Thermostat eine andere Temperatur, als ich in Home Assistant eingestellt habe?

Bei Reglern wie meinen sendet Home Assistant die Komfortbasis und zeigt danach den Sollwert an, den der Regler meldet, und der enthält Betriebsart und eine eventuelle lokale Verschiebung. Die Standardkarte hat nur Platz für einen Zielwert.

Muss ich vor dem Verstellen der Temperatur auf Auto schalten?

Meine Schreibvorgänge kamen am JUNG-Regler an, ohne dass ich vorher die Betriebsart gewechselt habe. Auto selbst und dessen Einfluss auf den gemeldeten Sollwert habe ich nicht getestet.

Kann ich die Differenz mit einem festen Offset ausgleichen?

Nicht verlässlich. Die gemessene Differenz ging nach einer einzigen lokalen Verstellung von −2 K auf −1 K, deshalb berechnet das Skript sie bei jedem Aufruf aus frischen Rückmeldungen neu und gibt nach drei Versuchen auf.