Zum Inhalt

E6a Heizung – Recherche Software-Fundament

Stand: 05.10.2026 (Runde 2, vertieft) · Kontext: HA 2026.7, Zigbee2MQTT 2.12, 8× Aqara E1 SRTS-A01, heute AHC 5.3.4 + Better Thermostat (BT). Nur Recherche, keine Systemänderung.

Quellen: - GitHub per gh (Code, Releases, Issues, Discussions) - Web per Exa - HA-Community-Threads per Discourse-API

Datumsangaben sind Veröffentlichungs- bzw. Kommentardaten. Code-Belege beziehen sich auf main/master zum 05.10.2026.

Grenze der Recherche: Exa liefert für Reddit (r/homeassistant) praktisch keine Treffer, auch mit mehreren Formulierungen. Praxisberichte kommen deshalb aus dem HA-Forum, GitHub-Issues/-Discussions, dem französischen HACF-Forum und einem Blog. Reddit ist nicht abgedeckt.

1. Kurzfazit

Anforderung Bestes Fundament Kernbeleg
Raumlogik (Presets, Fenster, Präsenz, 2 TRVs = 1 Raum) Versatile Thermostat (VTherm) over_climate Aktiv gepflegt (10.5.0 vom 01.10.2026, 13 stabile Releases seit März 2026), Maintainer antwortet im Forum und auf GitHub.
Fenster hat absoluten Vorrang VTherm Seit 8.0 trennt VTherm den angeforderten vom angewandten Zustand. Im Code (state_manager.py) steht nur Safety über dem Fenster. AHC 5.5.7 hat dagegen einen offenen Fehler: Fenster schaltet nicht aus (#161, seit 28.02.2026).
Manuelle Änderung respektieren VTherm (UI → Preset none; TRV-Drehung mit „Follow underlying“; set_timed_preset) Der Entwickler am 06.11.2025: „With TRV there is no drawback of using it“. Einschränkung: Eine Änderung binnen 10 s nach einem VTherm-Befehl wird verworfen (steht im Code).
Befehlszustellung prüfen, Retry, Meldung Keine Lösung vollständig → eigene Automation VTherm wiederholt nur den HVAC-Modus. Z2M meldet temperature in HA erst nach erfolgreichem Zigbee-Write; das ist ein brauchbarer Prüfpunkt.
Externe Raumtemperatur (Aqara E1) Eigene schlanke Automation (oder VTherm Mode 2 mit Rundungsfehler) Die E1 nimmt den Wert nur an, wenn Z2M sie als sensor: external führt, sonst still ignoriert (Converter-Code). Rückfall auf internal nach Batteriewechsel und über Tage ist mehrfach berichtet.
Zeitplan, zwei Personen HA-schedule-Helfer + Automation oder Scheduler-Component Die Scheduler-Component wird faktisch nicht mehr gepflegt: Issues werden seit Monaten nur vom Stale-Bot geschlossen, auch ein Bug zu Personen-Bedingungen.
Vorheizen Optional per Zusatzintegration, zunächst messen Kein Fundament hat es eingebaut. Der Smart-Start-Kandidat für VTherm heißt Intelligent Heating Pilot (IHP, Beta).

Empfehlung zur Diskussion: - VTherm over_climate je Raum. - Eine Zeitplanschicht setzt nur Presets. - Eigene, kleine Automationen für: - Einspeisung der Raumtemperatur in die E1, mit Prüfung, ob sensor: external gilt, und Keep-alive; - Sollwert-Prüfung mit Retry und Benachrichtigung; - später Vorheizen. - AHC und BT ablösen, nicht parallel laufen lassen.

2. Anforderungs-Matrix

Legende: ja / teilweise / nein / unbelegt

Anforderung AHC 5.5.7 VTherm 10.5.0 BT 1.9.2 HA-nativ
Manuelle Änderung respektieren (bis Blockende oder Dauer) nein. Physical/UI-Sync schreibt dauerhaft in den Helfer [A1]. Eine Sperre „nicht anfassen für X h“ gibt es nicht, laut panhans am 21.02.2026 „Not, atm … Will put this on my list“ [A6]. teilweise. UI-Änderung → Preset none bis zum nächsten Preset-Befehl [V6]. TRV-Drehung nur mit „Follow underlying“ [V1][V18], dazu Dauer per set_timed_preset [V5]. teilweise. Übernimmt TRV-Änderungen, sofern „child lock“ aus [B3]. Kein Zeitbezug [B4]. –
Fenster hat absoluten Vorrang nein (aktuell). Bug #161: „In normal mode the blueprint does not turn off the heater when the window is opened“, offen seit 28.02.2026, weitere Betroffene im Mai/Juni 2026 [A7]. ja [V3][V4]. Ausnahme set_window_bypass [V7]. teilweise [B2] –
Fenster anderer Räume (Esszimmer) ja [A1] ja (Gruppe) [V2] ja (Gruppe) [B2] Gruppen-Helfer [H2]
Befehlszustellung prüfen, Retry, Meldung nein [A1] teilweise. Nur hvac_mode wird verglichen [V9]; Fehler landen nur im Log. teilweise. Resend bis zur Bestätigung; Watchdog nach 360 s, dann Log-Warnung [B5]. –
Externe Raumtemperatur (E1) teilweise. Bug #176 schreibt select bei jeder Kalibrierung neu [A4]. teilweise. Mode 2 rundet auf ganze Grad (#1960) [V11]. nein. Keine E1-Unterstützung für external_temperature_input [B7]. Sensorgruppe (Mittelwert) [H2]
2 TRVs = 1 Einheit ja ja, aber seit 9.0 nicht betriebsbereit, solange ein TRV keinen Zustand gemeldet hat [V19] ja nein
Vorheizen (lernend) nein nein im Kern; IHP als Ergänzung [P1] nein nein
Zeitpläne ja (schedule-Helfer) extern [V13] nein ja [H1]
Anwesenheit ja ja [V14] nein –
Pflegezustand 2026 ruhend. Letzter Commit 20.01.2026, letzter Forumsbeitrag von panhans 21.02.2026; Fragen danach unbeantwortet („Is there anybody out there?“, 11.05.2026) [A3][A6]. aktiv [V0] aktiv, aber Release-Stau. Fix #2345 seit 02.09. gemergt, nicht released [B1]. nativ

3. Kandidaten im Einzelnen

3.1 Advanced Heating Control (AHC)

  • Version: 5.5.7 (Robin: 5.3.4).
  • Pflege:
  • Blueprint-Commits bis 20.01.2026 [A3].
  • Der Thread hat 3451 Beiträge, der letzte vom 13.08.2026 [A6].
  • panhans' letzter Beitrag ist vom 21.02.2026. Danach bleiben Fragen unbeantwortet, darunter am 11.05.2026 „Is there anybody out there?“ [A6].
  • GitHub-Issues #162–#178 sind ohne Antwort [A3].
  • Ein Nutzer kündigte im März 2026 eine native Integration auf AHC-Basis an; ein Repo existierte da noch nicht (#3466, #3476) [A6].
  • Praxis 2026:
  • Fenster-Bug in 5.5.7 (#161):
    • Gemeldet 28.02.2026.
    • Bestätigt am 03.02.2026 im Forum (#3441: „after i updated AHC to V 5.5.7, my TRV’s didn’t get closed when the window was opened“), am 10.05. und am 21.06.2026.
    • Ein Workaround existiert nur als lokale Patch-Zeile [A7].
  • Manuelles Überschreiben:
    • Im Februar 2026 kam die Frage „do not touch it for at least X hours“ (#3442). Antwort: geht nicht, steht auf der Liste [A6].
    • Am 10.04.2026 wies ein Nutzer darauf hin, dass HA die Quelle einer Änderung inzwischen über context.parent_id/user_id unterscheiden kann (#3491). Eine Antwort darauf gibt es nicht [A6].
  • Aqara E1 mit AHC:
    • Ein Nutzer bekam im Februar 2026 massenhaft Publish 'set' 'sensor' … failed (Delivery failed) und ebenso für external_temperature_input, „Happens to all my thermostats“ (#3445). Antwort: Mesh-Problem [A6].
    • Dazu Bug #176: unnötiges select-Schreiben, Batterie [A4].
  • Physical Change: setzt bei Reload, Update oder unavailable→Zustand fälschlich Werte (#171 [A5]; Forum #3469–#3481: „thermostat went to 30“ nach HA-Update) [A6].
  • Fazit: Ein Weiterbetrieb wäre ein Fundament ohne Pflege mit einem aktuell gebrochenen Muss-Kriterium (Fenster).

3.2 Versatile Thermostat (VTherm)

  • Version/Pflege: 10.5.0 (01.10.2026), stabile Releases fast monatlich. Plugin-Mechanismus seit 10.0 (29.04.2026), 1194 Sterne, 15 offene Issues [V0].
  • Architektur seit 8.0:
  • Ein „requested state“ (Nutzer oder Zeitplan) und ein „current state“ (nach Fenster, Safety, Power …).
  • Zeitfilter: Nutzer- und Scheduler-Befehle gehen sofort raus. Nur Regelungsbefehle werden verzögert, und zwar „resending the desired command later and not ignoring“ [V17a].
  • Das erklärt den Fenster-Vorrang.
  • Fenstervorrang (Code): state_manager.py prüft Safety → Fenster → Rest. Bei offenem Fenster ist der Ist-Modus off, egal was angefordert ist [V3].
  • „Follow underlying temp changes“ (TRV-Drehung):
  • Der Doku-Text rät ab [V1]. Der Entwickler präzisierte im Forum am 06.11.2025: „With TRV there is no drawback of using it. It is more with air pump …“ [V18].
  • Im Code (thermostat_climate.py, Z. 788–797) wird eine TRV-Meldung < 10 s nach einem VTherm-Befehl verworfen („Forget it to avoid loop“).
  • Ein Nutzer berichtete am 08.10.2025, dass deshalb etwa die Hälfte schneller Korrekturen am TRV ignoriert wird [V18].
  • Mit „Follow“ übernimmt VTherm auch einen am TRV gesetzten HVAC-Modus in den angeforderten Zustand (Code Z. 819–826).
  • Risiko (abgeleitet): Meldet eine E1 spontan einen fremden Sollwert, übernimmt VTherm ihn als Nutzerwunsch. Solche Sprünge wurden bei BT mit SRTS-A01 berichtet (#1387, 2024) [B9].
  • Neu seit 9.0, relevant für mehrere TRVs je Raum:
  • „all entities needed by VTherm should have reported a state before the VTherm is totally operational. This is the new fundamental behavior in 9.0“ [V19].
  • Ein Nutzer mit 4 TRVs in einem Raum (2 mit schlechtem Funk) hatte darum eine komplett nicht reagierende Raumheizung (Discussion #1791, 18.02.2026). Der Maintainer lehnt ein Abschalten ab und empfiehlt, den Funk zu fixen [V19].
  • Im Code latcht is_ready, sobald einmal bereit, und betrifft vor allem den Start bzw. Reload [V9b].
  • Befehlswiederholung:
  • „Fix incorrect state“ vergleicht bei climate nur hvac_mode, maximal 5 Versuche, Meldung nur im Log [V8][V9].
  • Der Sollwert wird nicht gegen den Gerätewert geprüft (set_temperature merkt sich nur _last_sent_temperature) [V9].
  • Sync Mode 2 (external_temperature_input): VTherm übernimmt die Schrittweite der Ziel-Entität. Die Z2M-Entität der E1 meldet step: 1, VTherm rundet also auf ganze Grad. Der Maintainer lehnt einen Workaround ab und rät zu input_number-Proxy plus Automation (#1960, Mai 2026) [V11].
  • Praxis (Blog, 11.01.2026):
  • BT- und VTherm-Betrieb, je über mehrere Tage mit InfluxDB gemessen: Moes TRV801Z, over_climate ohne Ventilsteuerung.
  • Ventilsprünge > 10 % gingen von 9–21/Tag (BT) auf 1–2/Tag (VTherm) zurück.
  • Die Boiler-Laufzeit wetterbereinigt sank um rund 47 % → 38 % [X1].
  • Das ist ein Nutzer mit anderem TRV, aber die einzige quantitative Gegenüberstellung, die gefunden wurde.
  • Gegenstimmen: „too complicated for my needs“; einige steigen auf eine simple Automation plus TRV-interne externe Temperatur um (Sonoff-Fälle, 08.10. und 31.10.2025) [V18][X2].

3.3 Better Thermostat (BT)

  • Version/Pflege:
  • 1.9.0 (21.08.2026, großes Release mit MPC v2, Türsensoren, Degraded Mode, „Calibration offsets a device silently ignored are sent again“) [B0].
  • Commits bis 05.10.2026, Hauptentwickler cl445 [B0].
  • Fix #2345 für den E1-Log-Spam (#2341) ist gemergt, aber nicht released [B1].
  • Aqara E1 mit BT (Praxis):
  • Batterie: „last one lasted about 2 weeks“ (Z2M #15004, 15.11.2022), „about two months“ (06.03.2024 und BT Discussion #1302, 29.02.2024).
  • Ein Nutzer kam mit „AI Time Based“ + „Ignore all inputs on the TRV like a child lock“ von 09.11. bis 16.01. auf 53 % (16.01.2025) [B10][B11].
  • BT schloss #1302 am 20.05.2026 als veraltet: „calibration-update frequency has been refined since“ [B11].
  • Spontane Sollwertsprünge bei SRTS-A01 (5 °C, 27 °C; #1387, 2024). Abhilfe war die BT-Option „child lock“ [B9].
  • Binärer Betrieb / Batterie: Ein E1-ähnliches Gerät (Brennenstuhl) pendelte bei BT 1.6.1 zwischen 8 °C und 21,5 °C. Empfehlung: sanftere Kalibrierung, keine Overheat-Protection (#1539, Dez. 2024/Jan. 2025) [B12].
  • Grundsatz: MPC/PID „shines with direct valve control“ (Maintainer wtom, 03.01.2026, #1789). Die E1 hat keine Ventilsteuerung und keine Offset-Entität [B13][Z1].
  • Fazit: Für die E1 bringt BT keinen Vorteil gegenüber VTherm. Robins Log-Spam ist bekannt, gefixt, aber noch nicht ausgeliefert.

3.4 Zeitplan-Schicht

Option Stand 2026 Praxis
HA schedule-Helfer Daten je Block, next_event, Blockstart-Trigger [H1] Bearbeiten nur über Einstellungen (Admin). Im Dashboard zeigt die More-Info nur Zustand und Historie (Forum, 26.12.2025: „you should clic in the settings button which is only available for admin users“) [H3]. Ein Nutzer im VTherm-Thread findet ihn „not great for the WAF“ (06.10.2025) [V18].
Scheduler-Component Letztes Release v3.3.8 (16.11.2024), letzter Commit 01.03.2026 [S1] Issues werden nur noch vom Stale-Bot geschlossen, ohne Maintainer-Antwort: #535 (Personen-Bedingungen mit „any“ kaputt, geschlossen 25.09.2026), #532, #529 [S1]. Für Bedingungen nach Person ist das ein Risiko.
Scheduler-Card v4.0.19 (30.06.2026), Commits 16.09.2026, Kompatibilitäts-Fixes bis HA 2026.5 [S2] Gute iPad- und Handy-Bedienung, hängt aber an der Component.
climate-scheduler (kneave) v1.15.1 (01.03.2026), 148 Sterne [S5] Graphbasierter Klima-Zeitplan. IHP ruft hart scheduler.run_action auf, deshalb ist climate-scheduler nicht direkt kompatibel (IHP Discussion #74, Jan. 2026) [P1].
Schedy (AppDaemon) Wartungsmodus seit 23.02.2022 [S3] –

3.5 Sonstiges

  • Keine native Klimagruppe [H2]; daenny/climate_group ist archiviert [S4].
  • Sensorgruppe (Mittelwert) für mehrere Raumsensoren ist nativ [H2].

4. Aqara E1 (SRTS-A01): Erfahrungen und Befunde

Thema Befund Beleg
Wert wird still verworfen Im Z2M-Converter (lumi.ts, lumi_trv) geht external_temperature_input nur raus, wenn meta.state.sensor === "external". Sonst passiert nichts, ohne Fehler. Der Wert wird als round(x·100) gesendet, also mit Hundertstel. [Z3]
Rückfall auf internal Nach Batteriewechsel bestätigt (Blueprint-Autor, HA-Forum). „jumped back from external to internal after some days“ ohne Eingriff (ebd.). Im Z2M-Thread: „sensor value changes itself sometimes from External to Internal“ (20.10.2022); andere sahen „never reverted“. Die 120-Minuten-Frist nennt nur ein Blueprint (24.02.2026) ohne Beleg. [Z5][Z2][Z4]
Ganzzahlig oder Dezimal? Der Converter überträgt Hundertstel. Ein Nutzer bestätigt, dass 1:1 geschriebene Dezimalwerte ankommen (#1960). Ein Blueprint behauptet „E1 accepts only integer values“ (Feb. 2026), ohne Beleg. Die interne Auflösung des E1-Sensors lag bei mehreren Nutzern bei 1 °C (ZHA, 2024); nach Z2M-OTA „massively better“ (27.11.2025). Ob die Regelung Dezimalstellen nutzt, ist unbelegt. [Z3][V11][Z4][Z8]
Batterie Aqara gibt ~1 Jahr an. Praxisberichte: 2 Wochen bis 2 Monate mit BT (2022–2024); 2 Monate bei 6 E1 mit externem Sensor und minütlichem last_seen (26.02.2025); „drain within days“ bei einem Einzelgerät (16.01.2025); 53 % nach ~2 Monaten mit gedrosseltem BT. Empfehlungen: keine Akkus (Aqara-Doku, lt. Nutzer), Updates drosseln, Toleranz ≥ 0,2 °C. [Z6][Z9][B10][B11]
Zustellfehler Delivery failed für sensor und external_temperature_input bei allen E1 eines Nutzers (Feb. 2026) [A6]. Ein anderer Nutzer hatte E1, die auf Z2M-Befehle nicht reagierten; behoben durch Coordinator-Firmware 7.4.5.0 und den Wechsel des Adaptertyps ezsp→ember (Z2M #24832). [A6][Z10]
valve_alarm Laut Z2M-Doku bei Montage- oder Ventilfehler, falscher Kalibrierung oder „incorrect link to external temperature sensor“. In der Praxis meldete eine E1 einen unbekannten Alarmwert 4 (Z2M #25020, Dez. 2024), verschwunden nach Batteriewechsel; seither wird der Wert geparst. Zu Fehlalarmen speziell mit externem Sensor gibt es keinen Beleg. [Z1][Z11]
Fallback ohne Funk Aqara-Support antwortete auf die Frage nach dem Fallback-Verhalten nur: „only compatible with the Aqara hubs“. Unbelegt. [Z5]

5. Befehlszustellung prüfen (Zigbee)

  • Z2M-Verhalten (Code): thermostat_occupied_heating_setpoint schreibt per entity.write und liefert erst danach {state: {occupied_heating_setpoint}} zurück [Z12].
  • Schlägt der Write fehl (Timeout, „Delivery failed“, „No network route“), gibt es keine Zustandsänderung, und Z2M loggt zigbee_publish_error (Beispiele in Z2M #24832, #16755, #21429).
  • Folgerung (abgeleitet): Das HA-Attribut temperature der E1 springt nur nach erfolgreichem Write auf den neuen Wert. Ein wait_template darauf ist ein brauchbarer Zustellnachweis. Er zeigt aber nicht, dass das Ventil reagiert hat. Die E1 rundet Sollwerte auf 0,5 °C.
  • Praxismuster:
  • Periodischer Abgleich Soll ↔ Ist alle 15 min, „I find it rare that the script actually has to do anything“ (HA-Forum, Tuya-TRVs) [X3].
  • Generic Thermostat mit keep_alive [X3].
  • Eine Automation, die bei Abweichung des Geräte-Sollwerts nachsetzt (Avatto, 2025) [X4].
  • Typische Ursache „empfängt nicht, sendet aber“: TRVs, die an einem bestimmten Router oder am Coordinator hängen (Z2M #13414, #24832); Abhilfe war, Router zu tauschen oder Firmware zu aktualisieren.
  • Kein Fundament meldet Zustellfehler aktiv (VTherm: nur Log; BT: Log, teils Repair-Issue bei Degraded Mode; AHC: nichts; Scheduler-Component: Feature-Wunsch #534 „Option to avoid silent failures“, unbeantwortet) [V8][B5][S1].

6. Vorheizen / Optimum Start

Lösung Stand Praxis/Belege
IHP (RastaChaum) v0.6.3 (03.04.2026, Beta). Danach nur Dependabot. Benötigt VTherm; nativer schedule-Helfer seit 0.6.2 (#80). Viele Kinderkrankheiten bis Frühjahr 2026: HA-Neustart beim Speichern der Konfiguration (#71), Lernsteigung bleibt bei 2 °C/h stehen (#125, behoben 07.04.2026), Antizipationsschleife (#110/#121). Offen: #64, bei Zeitplänen mit Bedingungen startet die Heizung zu spät, weil run_action die Bedingung prüft und still nichts tut. Bei Wärmeerzeugern mit eigener Regelung („hardware with its own regulation“) wurde die Lernkurve chaotisch (#48). Das betrifft over_climate mit TRV-Eigenregelung potenziell (abgeleitet). HACF-Forum: positiv („le comportement est vraiment bon“, 23.01.2026), aber auch Warnung „pas stable encore“ (20.01.2026) [P1][X5].
ha-preheat (Ecronika) v2.11.3 (14.06.2026), 9 Sterne, seit Juni ruhig Eigenständig, nimmt schedule-Helfer, physikalisches Modell (Masse, Verlust, Totzeit), „Optimal Stop“. Forum-Thread mit Feedback zu Fußbodenheizung und Evohome-Vergleich. Kleine Nutzerbasis, Pre-Release-Hinweise [P2][P5].
hvac-comfort-start RC1-004 (19.03.2026), Pyscript – [P3]
Smart Dynamic Preheat (YAML) Forum Feste, manuell kalibrierte Aufheizrate; der Autor verweist für Lernen selbst auf Pyscript [P4].
HACF-Forum-Stand (22.01.2026) – „Le smart start n’existe pas encore sous ha quelque soit le mode de programmation“, VTherm-Nutzer, die von Jeedom kommen [X5].

Vorschlag: in Phasen. Zuerst die Aufheizraten in Bad und Küche aus der Historie messen (VTherm liefert einen slope-Sensor [V2]). Dann eine feste Vorlaufzeit je Raum. Erst danach IHP oder ha-preheat testen, jeweils in einem Raum.

7. Offene Fragen / Unbelegtes

  1. E1-Rückfall auf internal: Wie oft, und mit welcher Frist ohne Updates? Die Berichte widersprechen sich. Test: einen Raum 3 h nicht speisen und sensor beobachten.
  2. Nutzt die E1 Dezimalstellen des externen Werts in der Regelung? Unbelegt.
  3. VTherm 9.0+ mit Wohnzimmer-2-TRV: Wie verhält sich VTherm bei einem TRV, der nach einem HA-Neustart erst spät meldet? Der Maintainer beschreibt „nicht operational bis alle gemeldet haben“. Das sollte man im Test-Raum prüfen.
  4. „Follow underlying“ mit der E1: spontane Sollwertsprünge (BT #1387) und das 10-s-Fenster. Erst testen, dann ausrollen.
  5. AHC #176 und #161 in Robins 5.3.4? Zu prüfen in der lokalen Blueprint-Datei, ob is_external und minimal_config_bypass betroffen sind.
  6. HA-Patch-Version ≥ 2026.7.2 (BT master).
  7. Reddit nicht ausgewertet (keine Exa-Treffer).
  8. Fallback-Verhalten der E1 ohne Coordinator: unbelegt.

8. Quellen

AHC - [A1] Blueprint 5.5.7: https://github.com/panhans/HomeAssistant/blob/main/blueprints/automation/panhans/advanced_heating_control.yaml - [A2] Thread-Kopf mit Breaking Notes 5.5 und FAQ: https://community.home-assistant.io/t/advanced-heating-control/469873 - [A3] Commits (letzter 20.01.2026) und Issues #162–#178: https://github.com/panhans/HomeAssistant - [A4] #176 (29.09.2026): https://github.com/panhans/HomeAssistant/issues/176 - [A5] #171 (01.09.2026): https://github.com/panhans/HomeAssistant/issues/171 - [A6] Forum-Thread, Beiträge #3438–#3503 (02.02.–13.08.2026), per Discourse-API: https://community.home-assistant.io/t/advanced-heating-control/469873 (u. a. #3441, #3442, #3445, #3462, #3469–#3481, #3491, #3496, #3501) - [A7] #161 „Window open does not turn off heater“ (28.02.2026, offen): https://github.com/panhans/HomeAssistant/issues/161

VTherm - [V0] Releases: https://github.com/jmcollin78/versatile_thermostat/releases - [V1] documentation/en/over-climate.md - [V2] documentation/en/feature-window.md - [V3] custom_components/versatile_thermostat/state_manager.py, Z. 112–132 - [V4] documentation/en/troubleshooting.md → „Open Window Detection Does Not Prevent Preset Changes“ - [V5] documentation/en/feature-timed-preset.md - [V6] documentation/en/feature-presets.md - [V7] documentation/en/reference.md → „ByPass Window Check“ - [V8] documentation/en/feature-advanced.md - [V9] underlyings.py (UnderlyingClimate.check_and_repair, set_temperature); [V9b] base_thermostat.py (is_initialized, is_ready) - [V11] #1960 (Mai 2026): https://github.com/jmcollin78/versatile_thermostat/issues/1960 - [V13] documentation/en/additions.md - [V14] documentation/en/feature-presence.md - [V17a] documentation/en/releases.md → Release 8.0 - [V18] Forum-Thread VTherm, Beiträge #236–#281 (Okt. 2025–Jun. 2026): https://community.home-assistant.io/t/versatile-thermostat-a-full-feature-thermostat-energy-door-window-presence-motion-preset-management/546761 (u. a. #236, #237, #238, #240, #243, #244, #248) und thermostat_climate.py, Z. 784–846 - [V19] Discussion #1791 „Ignore offline TRVs“ (18.02.2026): https://github.com/jmcollin78/versatile_thermostat/discussions/1791

Better Thermostat - [B0] Releases 1.9.0/1.9.1/1.9.2: https://github.com/KartoffelToby/better_thermostat/releases - [B1] #2341 und PR #2345 - [B2] docs/faq/window-sensor.md - [B3] docs/Configuration/configuration.md - [B4] docs/deep-explanations/schedule-and-night-mode.md - [B5] #2404 (Kommentar cl445) - [B7] #1082 - [B9] #1387 (SRTS-A01, Sep. 2024–Jan. 2025): https://github.com/KartoffelToby/better_thermostat/issues/1387 - [B10] Z2M Discussion #15004 (2022–2025): https://github.com/Koenkk/zigbee2mqtt/discussions/15004 - [B11] BT Discussion #1302 (29.02.2024, geschlossen 20.05.2026) - [B12] #1539 (28.12.2024) - [B13] #1789 (Jan. 2026)

HA Core - [H1] https://www.home-assistant.io/integrations/schedule/ - [H2] https://www.home-assistant.io/integrations/group/ - [H3] https://community.home-assistant.io/t/how-to-display-a-fullscreen-schedule-view-as-a-dashboard/966741 (26.12.2025)

Scheduler / Sonstiges - [S1] https://github.com/nielsfaber/scheduler-component (Issues #529, #532, #534, #535; Close-Events durch github-actions[bot]) - [S2] https://github.com/nielsfaber/scheduler-card/releases - [S3] https://github.com/efficiosoft/hass-apps - [S4] https://github.com/daenny/climate_group - [S5] https://github.com/kneave/climate-scheduler

Zigbee2MQTT / Aqara - [Z1] https://www.zigbee2mqtt.io/devices/SRTS-A01.html - [Z2] https://github.com/Koenkk/zigbee2mqtt/discussions/14291 und https://github.com/Koenkk/zigbee2mqtt/issues/13993 - [Z3] zigbee-herdsman-converters/src/lib/lumi.ts (lumi_trv, Case external_temperature_input; Commit-Stand 04.10.2026), src/lib/exposes.ts - [Z4] https://community.home-assistant.io/t/aqara-e1-external-temperature-calibration/990316 (24.02.2026) - [Z5] https://community.home-assistant.io/t/z2m-aqara-trv-e1-link-external-temperature-sensor/609689 (Changelog bis 24.03.2025) - [Z6] https://github.com/Koenkk/zigbee2mqtt/discussions/26512 (26.02.2025) - [Z8] https://community.home-assistant.io/t/aqara-thermostat-e1-operation-and-update-challanges/710847 (30.03.2024–27.11.2025) - [Z9] https://www.aqara.com/eu/product/radiator-thermostat-e1/ (Batterieangabe) - [Z10] https://github.com/Koenkk/zigbee2mqtt/issues/24832 (ab 19.11.2024) - [Z11] https://github.com/Koenkk/zigbee2mqtt/issues/25020 (02.12.2024) - [Z12] zigbee-herdsman-converters/src/converters/toZigbee.ts → thermostat_occupied_heating_setpoint

Praxis / Vergleich - [X1] https://pro-it.rocks/versatile-thermostat-vs-better-thermostat-10-days-of-data-changed-my-mind/ (11.01.2026) - [X2] https://community.home-assistant.io/t/versatile-thermostat-wheres-does-one-get-the-required-education-to-get-it-working/950206 - [X3] https://community.home-assistant.io/t/how-to-set-retry-for-zigbee-device-when-applying-a-scene/546691 - [X4] https://community.home-assistant.io/t/configure-time-schedule-through-z2m-is-not-working/854212 - [X5] https://forum.hacf.fr/t/versatile-thermostat-repliquer-une-gestion-jeedom-modes-travail-vacances-anticipation/74433 (20.–23.01.2026)

Vorheizen - [P1] https://github.com/RastaChaum/Intelligent-Heating-Pilot (Issues #48, #64, #71, #80, #110, #125; Discussion #74) - [P2] https://github.com/Ecronika/ha-preheat - [P3] https://github.com/dbullendsl/hvac-comfort-start - [P4] https://community.home-assistant.io/t/smart-dynamic-preheat-calculates-lead-time-based-on-warm-up-rate-rather-than-a-fixed-offset-pure-yaml-no-extra-dependencies/1009573 - [P5] https://community.home-assistant.io/t/intelligent-preheating-physics-based-pilot/962007