Lesezeit: ca. 6–8 Minuten
Früher lief unsere Heizung nach festen Zeiten – praktisch, aber nicht besonders klug.
An milden Tagen wurde unnötig geheizt, bei plötzlichem Kälteeinbruch sprang sie zu spät an.
Heute steuert sich das System selbst:
Außentemperatur und der Temperaturunterschied zwischen Vorlauf und Rücklauf (ΔT) entscheiden,
wann sich ein Lauf wirklich lohnt. Ergebnis:
spürbar weniger Energieverbrauch – bei gleichbleibendem Komfort.
Unsere alte Steuerung dachte in Uhrzeiten. Das ist bequem, aber nicht flexibel:
Wenn die Sonne plötzlich herauskommt oder kalter Wind aufzieht, passt ein starrer Plan selten.
Uns war wichtig: Komfort halten, Energie sparen – ohne ständig manuell nachjustieren zu müssen.
Die Lösung: Wir lassen das Haus und das Wetter mitreden.
Dafür beobachten wir die Außentemperatur (geglättet) und schauen auf das, was im Heizkreis wirklich passiert:
ΔT = Vorlauf − Rücklauf. Je größer ΔT, desto mehr Wärme wird gerade abgenommen – dann lohnt sich längeres Laufen.
Ist ΔT klein, sparen wir uns den nächsten Lauf.
Die geglättete Außentemperatur bestimmt, ob der Tag grundsätzlich „mehr“ oder „weniger“ Heizen braucht.
Eine Hysterese verhindert hektische Umschaltungen bei kleinen Schwankungen.
ΔT = Vorlauf − Rücklauf zeigt, wie viel Wärme die Räume gerade aufnehmen.
ΔT groß ⇒ längere ON-Phasen (mehr Zirkulation).
ΔT klein ⇒ längere Pausen (Energie sparen).
Mindest-Laufzeit und Mindest-Pause verhindern „Flattern“.
Wir starten keinen neuen Lauf, wenn der Vorlauf zu kalt ist. So wird nicht „kalt gerührt“ – das spart Strom und reduziert Wärmeverluste in Leitungen.
Geheizt wird nur in einem sinnvollen Zeitfenster (z. B. 06:00–22:00).
Ab 21:45 starten keine neuen Läufe, um 21:55 ist Schluss – so gibt es abends keine „Überzieher“.
Was passiert hier?
ΔT = Vorlauf − Rücklauf. Hohe ΔT ⇒ längere ON-Phasen, niedrige ΔT ⇒ längere OFF-Phasen.
VL_min verhindert Starts, wenn der Vorlauf zu kalt ist. Mindest-AN/AUS stoppt „Flattern“.
# Pseudocode / YAML-Stil (vereinfacht fürs Blog)
# Trigger: periodisch (z. B. alle 60 s)
# Guard: Zeitfenster aktiv UND sensor.heizung_vorlauf_temp >= input_number.heizung_vl_min
# ΔT berechnen (gedanklich: Template-Sensor erledigt das)
dT = states('sensor.heizung_vorlauf_temp') | float(0) - states('sensor.heizung_ruecklauf_temp') | float(0)
# Faktoren & Grenzen
base_on = (states('input_number.heizung_period') | float(60)) * 0.5 # Beispiel: 50 % Grund-ON
dt_low = states('input_number.heizung_dt_low') | float(2.5)
dt_high = states('input_number.heizung_dt_high') | float(9.0)
on_factor_low = states('input_number.heizung_on_factor_low') | float(0.2) # −20 %
on_factor_high = states('input_number.heizung_on_factor_high') | float(0.3) # +30 %
min_on = states('input_number.heizung_min_on') | float(30)
min_off = states('input_number.heizung_min_off') | float(60)
period = states('input_number.heizung_period') | float(60)
# ON-Zeit skalieren
on_time = base_on
if dT >= dt_high:
on_time = base_on * (1 + on_factor_high)
elif dT <= dt_low:
on_time = base_on * (1 - on_factor_low)
# Mindestzeiten sicherstellen
on_time = max(on_time, min_on)
off_time = max(period - on_time, min_off)
# Aktion (vereinfacht)
# switch.turn_on(switch.heizung_pumpe) für on_time Sekunden
# switch.turn_off(switch.heizung_pumpe) für off_time Sekunden
Abends wird nicht „überzogen“: Ab 21:45 keine neuen Starts; um 21:55 harter Stopp.
# Zeitfenster 06:00–22:00
# No-Start ab 21:45, Hard-Stop 21:55
if now() between 06:00..21:45:
allow_new_cycles = true
elif now() between 21:45..21:55:
allow_new_cycles = false # Lauf darf enden, aber kein neuer Start
else:
# 21:55..06:00
# force_off:
# switch.turn_off(switch.heizung_pumpe)
Bei unavailable/unplausibel wechselt das System in einen sicheren Modus und sendet eine Push-Info.
# Wenn ein Kernsensor unavailable ist:
vorlauf = states('sensor.heizung_vorlauf_temp')
ruecklauf= states('sensor.heizung_ruecklauf_temp')
if (vorlauf in ['unavailable','unknown','none']) or (ruecklauf in ['unavailable','unknown','none']):
# switch.turn_off(switch.heizung_pumpe)
# notify.mobile_app_bennys_iphone_16_pro:
# message: "Heizung Failsafe: Sensorproblem erkannt."
pass
| Parameter | Startwert | Wirkung (kurz) |
|---|---|---|
| VL_min | ≈ 38 °C | keine Starts bei „kaltem“ Vorlauf |
| ΔT_low | ≈ 2.5 K | mehr Pausen (Sparen) |
| ΔT_high | ≈ 9 K | längere Laufzeiten (Bedarf hoch) |
| Mindest-AN/AUS | systemabhängig | verhindert Flattern |
| Zeitfenster | 06:00–22:00 | No-Start 21:45, Hard-Stop 21:55 |
In der ersten Woche haben wir nur mitgeloggt: Außentemperatur, Vorlauf/Rücklauf, ΔT, Pumpenstatus.
Danach haben wir Startwerte gesetzt (siehe Tabelle) und die Mindest-An/Aus-Zeiten so gewählt, dass das System ruhig läuft.
In Woche 2 haben wir ΔT_low/ΔT_high um jeweils ±0,5 K feinjustiert. Ergebnis: spürbar weniger Laufzeit an milden Tagen, ohne Komfortverlust.
• An sonnigen Nachmittagen sinkt ΔT schnell → längere Pausen, keine „Leerläufe“.
• Bei Kälteeinbruch fährt die Laufzeit automatisch hoch – kein Nachregeln nötig.
• VL_min war der Gamechanger: keine Starts ohne nutzbare Wärme.
• Subjektiv: Räume fühlen sich gleichmäßig warm an, obwohl die Pumpe seltener läuft.
Die Automatik passt sich an Alltag und Wetter an. Die folgenden Beispiele zeigen, was passiert, warum es passiert, was du im Dashboard siehst und was du tun kannst. So erkennst du schnell, dass die Logik nicht „mystisch“ ist – sie folgt einfachen, transparenten Regeln.
Was passiert: Die Außentemperatur sinkt, ΔT = Vorlauf − Rücklauf steigt. Das System verlängert automatisch die ON-Phasen der Pumpe.
Warum: Ein höheres ΔT bedeutet, dass die Räume mehr Wärme aufnehmen – längere Laufzeit ist effizient, weil Wärme wirklich ankommt.
Was sehe ich im Dashboard: ΔT ↑, Modus wechselt ggf. in „kühl“, Restlaufzeit der aktuellen Periode ↑, nächste Umschaltung nach hinten.
Was kann ich tun: Nichts nötig. Optional Boost starten, wenn es besonders schnell warm werden soll. Tipp: Mindest-AN/AUS nicht zu klein wählen, damit es ruhig bleibt.
Was passiert: Durch Sonneneinstrahlung wird es gefühlt wärmer, ΔT sinkt. Die Pumpe macht längere Pausen, startet seltener.
Warum: Niedriges ΔT bedeutet geringe Wärmeabnahme – Heizen würde kaum Nutzen bringen. Pausen sparen Energie ohne Komfortverlust.
Was sehe ich im Dashboard: ΔT ↓, längere OFF-Phasen, ggf. Modus „mild“. Max-AUS-Grenzen verhindern Auskühlen.
Was kann ich tun: Optional Eco aktivieren, wenn du bewusst mehr sparen möchtest. Wenn ein Raum zu kühl wirkt, kurzzeitig Boost nutzen.
Was passiert: Nach kräftigem Lüften fühlt es sich kurz kühl an. Mit Boost erhöhst du temporär den ON-Anteil; danach kehrt das System automatisch zum Normalbetrieb zurück.
Warum: Boost ist ein zeitlich begrenzter Komfort-Hebel – ideal, um Zieltemperatur schnell zu erreichen, ohne dauerhaft mehr zu verbrauchen.
Was sehe ich im Dashboard: Boost-Status aktiv, erhöhte ON-Dauer in der laufenden Periode; Timer zählt sichtbar herunter.
Was kann ich tun: Boost per Button starten (z. B. 15–30 Min). Abbruch jederzeit möglich. Tipp: Nicht mit dauerhaften Parameteränderungen verwechseln.
Was passiert: Du aktivierst Eco. Der ON-Anteil wird reduziert, Pausen werden länger – Komfortgrenzen sorgen aber dafür, dass es nicht auskühlt.
Warum: Wenn niemand da ist, lohnt sich ein niedrigerer Verbrauch. ΔT und Max-AUS halten das System dennoch stabil.
Was sehe ich im Dashboard: Eco aktiv, OFF-Phasen länger; nächste Umschaltung bleibt planbar.
Was kann ich tun: Eco vor Abwesenheiten aktivieren; bei Rückkehr ggf. kurz Boost nutzen. Tipp: Zeitautomatik für Eco spart Klicks.
Was passiert: Ab 21:45 werden keine neuen Läufe mehr gestartet (No-Start). Um 21:55 ist Hard-Stop – die Pumpe steht spätestens dann.
Warum: So wird abends nicht „überzogen“, und das System rollt sauber ins Nachtprofil – ohne unnötige Restläufe.
Was sehe ich im Dashboard: Hinweis „No-Start aktiv“ ab 21:45; um 21:55 wechselt der Status auf AUS – unabhängig vom ΔT.
Was kann ich tun: Zeiten an Tagesrhythmus anpassen (z. B. Wochenende). Tipp: Nicht zu eng setzen – sonst brichst du sinnvolle Restläufe ab.
Was passiert: Fällt ein Kernsensor (Vorlauf/Rücklauf) aus oder liefert unsinnige Werte (unavailable/unknown), greift Failsafe. Die Pumpe wird sicher abgeschaltet und du erhältst eine Push-Benachrichtigung.
Warum: Ohne valide Messwerte soll die Anlage nicht „blind“ laufen. Failsafe schützt Komfort und Verbrauch.
Was sehe ich im Dashboard: Status „Failsafe aktiv“, Fehlerhinweis im Grund/Reason-Text; nach Rückkehr stabiler Werte normaler Betrieb.
Was kann ich tun: Ursache prüfen (Sensor/Verbindung), ggf. kurzzeitig manuell heizen. Tipp: Benachrichtigungen aufs Hauptgerät routen – so verpasst du nichts.
Nein. Du nutzt nur wenige Schalter: Eco (Sparen) oder Boost (schnell warm). Der Rest läuft automatisch.
Ja. Außentemperatur und ΔT werden laufend bewertet – die Hysterese verhindert nur hektisches Hin-und-Her.
Damit nachts und zu unpassenden Zeiten nicht geheizt wird, selbst wenn ΔT kurzzeitig steigt.
Failsafe greift. Du bekommst eine Benachrichtigung, und das System läuft nicht „blind“ weiter.
Unsere Heizung läuft heute bedarfsgerecht statt blind nach Uhr.
Das spart Energie und Kosten – bei gleichbleibendem Komfort.
Als Nächstes visualisieren wir die Laufzeiten und ΔT noch detaillierter im Dashboard.
Worum geht’s? Die UniFi G4 Doorbell kann nach Updates oder Reboots sogenannte Ghost-Events auslösen. Nach Updates, Stromausfällen oder einem Reboot der UniFi Protect G4 Doorbell melden die Protect-Entitäten in Home Assistant für wenige Sekunden scheinbar echte...
Man kann in der Unifi Network Application so ziemlich alle Einstellungen rund um das Netzwerk vornehmen und ein Breites Spektrum an Regelungen realisieren. Zuerst erstellen wir einen Zeitplan, zu welchen Zeiten ein komplettes VLAN vom Internet Blockiert werden soll....
Unverhofft und unerwünscht – so lässt sich unser jüngstes Abenteuer mit der CFMoto CForce 850 beschreiben. Plötzlich versagte die Servolenkung, begleitet von einem nervenaufreibenden Blinken der Lampe im Cockpit. Doch was als simple Fehlersuche begann, entwickelte...
0 Kommentare