E6a Heizung: Umsetzungs-Log

Verlauf der Umsetzung nach dem Umsetzungsplan. Der Plan bleibt als Vorlage unverändert, hier steht, was tatsächlich passiert ist: je Task Ergebnis, Abweichungen vom Plan (als „Entscheidung“) und Funde nebenbei. Neueste Tasks unten.

Stand

Task	Status	Datum
0 Sicherung und VTherm	erledigt	08.10.2026
1 Raumklima-Modell	erledigt	08.10.2026
2 Offline-Timeouts	erledigt	08.10.2026
3 Helfer, Einspeisung, Notbetrieb	erledigt	08./09.10.2026
4 Zentrale VTherm-Konfiguration, Bad	erledigt (Balkonsensor später)	09.10.2026
5 Zustellprüfung	Schritte 1–3 und 5 erledigt, 4 und 6 brauchen Robin	09.10.2026
6 Tagesprofil, Übersteuerung	erledigt bis auf Schritt 9 (Wach-Erkennung, Samstag)	09.10.2026
7 Vorab-Tests Bad	T1 + T2 bestanden, T3/T7 am Ende	09.10.2026
8 Rollout fünf Räume	VTherm angelegt (aus), Umschalten wartet auf Zentralheizung	09.10.2026
9 Wohnzimmer	VTherm angelegt (aus), Umschalten wartet auf Zentralheizung	09.10.2026
10 T8 und HomeKit	HomeKit erledigt, T8 am Ende	09.10.2026
11 Dashboard	v2 steht (/smart-home-zentrale-v2), wartet auf Robins Prüfung	09.10.2026
12 Wand-iPad	offen (Robin)
13 Sommer-Ventilbewegung	Automation steht, Test tagsüber offen	09.10.2026
14 Abnahme, Abbau	abgenommen, Altlasten abgebaut; offen: Abschlusstests mit Robin	24.10.2026
15 Doku, Abschluss	Betriebsdoku projects/homeserver/smart-home/heizung.md	24.10.2026

Ausgangslage (08.10.2026)

Backup: vor-e6a-2026-10 (ID fd188527), 08.10.2026 16:17, 104 MB, Standard-Backup-Passwort von HA.

AHC: Alle 7 Automationen stehen bereits auf aus (Logbuch: keine Zustandsänderung seit mindestens 30.06.2026, also seit dem Frühjahr aus). Blueprint panhans/advanced_heating_control.yaml, alle mit Kalibrierung external (Delta 0,1), Kalkschutz an, Wintermodus über input_boolean.general_toggle_wintermode.

Raum	Automation	config_hash
Abstellraum	automation.abstellraum_advanced_heating_control	9fe45b2bfaaaa543
Arbeitszimmer	automation.arbeitszimmer_ahc	b98175b921a320c0
Bad	automation.badezimmer_advanced_heating_control	c0bb9a05b05b917c
Esszimmer	automation.esszimmer_test_ahc	c8df6f6a49403275
Küche	automation.kuche_ahc	9765acc0c5f1160b
Schlafzimmer	automation.schlafzimmer_advanced_heating_control	11a42f019765bde5
Wohnzimmer	automation.wohnzimmer_advanced_heating_control	f4025f456a291af2

Das Wohnzimmer-AHC steuert direkt die beiden TRVs (…_hinten, …_vorne), nicht Better Thermostat.

Reset-Automationen: alle 7 an. Sie lösen nur auf Druck des jeweiligen input_button.<raum>_button_heizung_reset aus und setzen dann die Temperatur nach Werktag/Zeitplan.

Raum	Automation	config_hash
Abstellraum	automation.abstellraum_reset_heizung_to_schedule	29b01464eb08afb3
Arbeitszimmer	automation.arbeitszimmer_reset_temperatur_to_scheudler	68f5c734a1509ec0
Bad	automation.badezimmer_reset_heizung_to_schedule	67ff65cdcf16fb74
Esszimmer	automation.esszimmer_reset_heizung_to_schedule	09bab21fa7b1890a
Küche	automation.kuche_reset_heizung_to_schedule	9068ba5a1c646764
Schlafzimmer	automation.schlafzimmer_reset_heizung_to_schedule	6b08ec17f1f4616d
Wohnzimmer	automation.wohnzimmer_reset_heizung	e0f2be2cf24ac4b0

Die Reset-Automation des Wohnzimmers zielt auf Better Thermostat (climate.wohnzimmer_heizung).

Better Thermostat: Eintrag 01JG7Q5SQTMDE56MJVXBKTYQAC „Wohnzimmer Heizung“, loaded. Thermostate climate.wohnzimmer_heizung_hinten + …_vorne, Sensor sensor.wohnzimmer_sensor_temperature, Außen sensor.openweathermap_temperature, keine Fensterverzögerung, Presets away/boost/sleep/comfort/eco/activity/home.

Entscheidung: Die Reset-IDs weichen vom Plan-Muster automation.<raum>_reset_heizung_to_schedule ab (Arbeitszimmer, Küche, Wohnzimmer). In Task 4, 8 und 9 gelten die IDs aus dieser Tabelle. Kostet, falls falsch: eine Reset-Automation bleibt an, wirkt aber nur auf Knopfdruck.

Task 0: Sicherung und VTherm installieren (08.10.2026)

• Backup angelegt (siehe Ausgangslage).
• VTherm per HACS installiert: 10.5.0 (HACS-ID 582589896), neuestes Release vom 01.10.2026. HACS-Mindestversion HA 2026.3.1, wir haben 2026.7.2.
• Release-Notes 10.5.0: Die Funktion „Climate Replication“ liegt jetzt in einem eigenen Plugin; Fehlerbehebungen für over_valve, Sleep/Maintenance-Modus und verzögertes Temperatur-Nachsenden. Für unser over_climate ohne Replication keine Breaking Changes.
• Neustart per ha_restart mit Robins OK, 08.10.2026 16:29. Log: nur der übliche Hinweis „custom integration versatile_thermostat … not tested“, keine Fehler.

Task 1: Raumklima-Modell (08.10.2026)

Vorher (alle sieben Gruppen Typ mean, ignore_non_numeric: false):

Raum	Mitglieder vorher
Abstellraum, Bad, Esszimmer, Küche, Schlafzimmer	je nur der Aqara-Sensor …_sensor_luft_temperature
Arbeitszimmer	…_sensor_luft, …_w100, …_sensor_luft_schreibtisch (VINDSTYRKA)
Wohnzimmer	…_luft_fernseher (VINDSTYRKA), …_luft_hinten (Entität existiert nicht mehr), …_luft_vorne

Nachher:

Raum	sensor.<raum>_sensor_temperature	Primärgruppe (neu, mean)
Abstellraum, Bad, Esszimmer, Küche	unverändert mean über den Aqara-Sensor	–
Arbeitszimmer	first_available: Primär → …_luft_schreibtisch	sensor.arbeitszimmer_temperatur_primaer: …_sensor_luft + …_w100
Schlafzimmer	first_available: Primär → …_luft_ikea	sensor.schlafzimmer_temperatur_primaer: …_sensor_luft
Wohnzimmer	first_available: Primär → …_luft_fernseher	sensor.wohnzimmer_temperatur_primaer: …_luft_vorne

• Das Options-Formular der Gruppen erlaubt den Typwechsel. Die Entitäts-IDs sind gleich geblieben, kein Löschen und Neuanlegen.
• HA bildet aus „primär“ die ID …_primar. Die drei Primärgruppen und die Schwelle (…_luften_schwelle) sind auf die Plan-IDs mit „ae“/„ue“ umbenannt.
• input_number.heizung_lueften_schwelle: 50–80 %, Schritt 1, Wert 65, ohne initial.
• Test: Alle 7 Raumtemperaturen numerisch. Wohnzimmer 21,65 = …_luft_vorne (vorher Mittelwert mit dem VINDSTYRKA: 20,8). first_available_entity_id zeigt in allen drei Räumen auf die Primärgruppe. Der echte Ausfalltest folgt in Task 10 (T8).

Entscheidung: Die drei Primärgruppen und die drei first_available-Gruppen haben ignore_non_numeric: true (Plan: nicht angegeben, Bestand: false). Grund: Im HA-Code (group/sensor.py, 2026.7.2) wird der Gruppenwert bei false leer, sobald ein Mitglied unavailable ist. Damit hätte „erster verfügbarer“ gerade im Ausfall des VINDSTYRKA keinen Wert geliefert, und im Arbeitszimmer hätte ein ausgefallener W100 die Primärgruppe geleert statt auf den Aqara-Sensor zu reduzieren. Kostet, falls falsch: nichts. Mit true rechnen die Gruppen über die verfügbaren Mitglieder, und sind alle weg, ist die Gruppe unavailable (Notbetrieb greift).

Fund: Im Arbeitszimmer misst der W100 gut 2 K mehr als der Aqara-Sensor (24,22 gegen 22,18 °C, 08.10. 16:20). Der Mittelwert liegt damit rund 1 K über dem Aqara. Robin klärt, ob der W100 an einer warmen Stelle hängt (PC, Sonne). Bis dahin bleibt der Plan-Stand.

Task 2: Offline-Timeouts der Raumsensoren (08.10.2026)

• Freigabe Robin 08.10.2026, 180 min.
• Gesendet per docker exec mqtt mosquitto_pub auf dem NUC an zigbee2mqtt/bridge/request/device/options, Antworten parallel mit mosquitto_sub mitgeschnitten.
• Ergebnis: 21 × status=ok, restart_required=false, vorher bei keinem Gerät ein eigener Wert.
• Gegenprobe in configuration.yaml: timeout: 180$ → 21, timeout: 150$ → 8 (TRVs), globale Vorgabe 1500 unverändert.
• Sicherung der Z2M-Konfiguration vorher: NUC ~/e6a-backups/z2m-configuration.yaml.vor-task2 (enthält den Netzwerkschlüssel, deshalb 600/700). Das Verzeichnis /mnt/ssd/container-data/zigbee2mqtt/ ist für robin nicht beschreibbar.

Task 3: Helfer, Einspeisung, Notbetrieb (08.10.2026)

Label heizung (Farbe deep-orange, mdi:radiator) neu angelegt. 47 Entitäten tragen es: die 46 Helfer aus Task 3 plus input_number.heizung_lueften_schwelle aus Task 1. Alle ohne initial.

Art	Entitäten	Startwert
je Raum (×7)	input_boolean.heizung_neu_<raum>, …_halten_<raum>, …_stoerung_<raum>, input_datetime.heizung_uebersteuerung_bis_<raum> (Datum + Uhrzeit), input_text.heizung_block_<raum> (max. 20)	aus / leer
global	input_boolean.heizung_abwesend, …_wach_heute, …_wartung	aus
Uhrzeiten	input_datetime.heizung_aufstehen_lars 07:30, …_aufstehen_robin 09:00, …_wochenende_spaetestens 10:00, …_wohnzimmer_grund_ab 19:00, …_nachtruhe 23:00	gesetzt
Zahlen	input_number.heizung_wohnzimmer_grundtemperatur 19 °C, …_vorlauf_bad_kueche 60 min, …_vorlauf_sonstige 30 min	gesetzt

Anzeigenamen mit echten Umlauten („Heizung Störung: Küche“, „Heizung Übersteuerung bis: …“). Weil HA beim Anlegen „ü“ zu „u“ macht, wurden diese Helfer mit „ue/oe“ angelegt und danach umbenannt, die IDs entsprechen dem Plan. input_datetime.heizung_uebersteuerung_bis_<raum> steht nach dem Anlegen auf 08.10.2026 00:00, also in der Vergangenheit. Das passt zur Profil-Bedingung „Übersteuerung abgelaufen“.

Einspeisung: automation.heizung_raumtemperatur_an_die_trvs_e1_einspeisung nach Plan, Schritt 2, mit der Anmerkung (persistent_notification.dismiss vor dem Publish).

Entscheidung: Zwei Abweichungen vom Plan-Entwurf. - Der Änderungs-Trigger hat to: null. Damit lösen reine Attributwechsel der Gruppen (z. B. first_available_entity_id) nicht aus. Kostet, falls falsch: nichts. Jede Wertänderung bleibt ein Zustandswechsel. - Im Notbetrieb wird select.<trv>_sensor nur auf internal gesetzt, wenn er nicht schon dort steht. Der Plan setzte ihn bei jedem Durchlauf, also mindestens alle 30 min ein unnötiger Zigbee-Write. Kostet, falls falsch: nichts. Fällt das TRV von sich aus zurück, greift die Bedingung wieder.

Best-Practice-Warnungen von ha-mcp (Template-Bedingungen, Template in target.entity_id): begründet. Die Entitätsnamen entstehen aus dem Raumschlüssel zur Laufzeit, und condition: state nimmt kein Template als entity_id. Das steht so im Plan.

Test Schritt 3: Manuell ausgelöst, alle heizung_neu_* aus. Trace: alle 7 Räume an der Bedingung heizung_neu_<raum> gestoppt, kein mqtt.publish. Bestanden.

Offen: Schritt 5 (Notbetrieb-Test, Review-Fokus 2) nach Task 4.

Advisor-Review Task 1–3 (Fable 5.1, 08.10.2026) und Umbau der Einspeisung

Robin hat am 08.10. angeordnet, für Reviews zwischendurch und bei Fehlern Fable 5.1 als Advisor zu nutzen. Das Review hat zwei kritische Fehler im Plan-Entwurf der Einspeisung gefunden, beide sind nachgeprüft:

1. Notbetrieb-Push ohne Sperre. Persistente Benachrichtigungen sind seit HA 2023.6 keine States mehr (states.persistent_notification | count = 0). state_attr('persistent_notification.…','title') is none ist damit immer wahr, es wäre alle 30 min ein Push gekommen, im Wohnzimmer zwei.
2. Die 0,2-K-Schwelle hätte nie gegriffen. Z2M meldet external_temperature_input nie zurück, number.<trv>_external_temperature_input steht bei allen TRVs auf unknown (geprüft). Jede Sensormeldung wäre ein Zigbee-Write gewesen: 120–290 pro Tag und TRV statt ≤ 50.

Dazu wichtige Punkte: Schein-Notbetrieb bei jedem HA- oder Z2M-Neustart (Sensoren kurz unknown), Keep-alive als halber Batterieverbrauch, und ein erster Wert nach dem Umschalten auf external kann verloren gehen, wenn das TRV länger als 5 s braucht. Die Ruling zu ignore_non_numeric (Task 1) hat das Review bestätigt.

Entscheidung (Umbau, ersetzt den Plan-Entwurf): - 14 neue Helfer mit Label heizung: input_boolean.heizung_notbetrieb_<raum> (Merker, auch für den Dashboard-Status „Notbetrieb“) und input_number.heizung_gesendet_<raum> (−10…60 °C, Schritt 0,01, zuletzt gesendeter Wert; gilt im Wohnzimmer für beide TRVs). - Gesendet wird, wenn die Raumtemperatur um ≥ 0,2 K vom gesendeten Wert abweicht, beim Einschalten des Raums (aktivierung, nur dieser Raum) und als Keep-alive nur, wenn der Helfer seit 25 min nicht geschrieben wurde (last_reported). - Notbetrieb nur über einen eigenen Trigger „5 min unavailable/unknown“ oder im Keep-alive, wenn die Gruppe seit über 5 min nicht numerisch ist. Sonst wird ein Raum ohne Wert nur übersprungen. Push, Benachrichtigung und Merker gibt es je Raum genau einmal. Kehrt die Temperatur zurück, gehen Merker und Benachrichtigung weg und das TRV wird wieder auf external gestellt. - Steht ein TRV auf internal, wird es umgestellt. Die Automation wartet bis 30 s auf die Bestätigung (wait_template, weil die Entität dynamisch ist) und sendet nur dann. Bei unknown/unavailable des Selects wird das TRV in diesem Durchlauf übersprungen. - Kostet, falls falsch: Die Automation ist komplexer als im Plan. Rückweg: Config-Backup von ha-mcp. Die Batterie-Schätzung danach liegt bei rund 60–80 Writes pro Tag und TRV, die Schwelle wird nach T7 entschieden.

Folge für spätere Tasks: Task 4, Schritt 6, und T1 (Task 7) prüfen den eingespeisten Wert nicht an number.<trv>_external_temperature_input (bleibt unknown), sondern an input_number.heizung_gesendet_<raum> und an climate.<trv> → current_temperature.

Bewusst offen: - Spec 9, letzte Zeile („TRV fällt auf internal zurück → bei Wiederholung Push“). Die Einspeisung korrigiert den Rückfall still, ein Push fehlt noch. - Bei first_available-Gruppen nach jedem Bearbeiten in der Oberfläche die Reihenfolge prüfen (state_attr(…,'entity_id'), Primär zuerst). Der Entitäten-Picker kann umsortieren.

Test erneut: Manuell ausgelöst, alle Räume aus. Variablen korrekt (numerisch true, notbetrieb_jetzt false, senden true wegen Startwert −10), alle Räume stoppen am Schalter, kein Publish.

Task 4: Zentrale VTherm-Konfiguration und Bad

Vorab geprüft gegen VTherm 10.5.0 (Doku und Code, Spec-Prüfpunkt 2):

Entscheidung: „Außensensor prüfen: aus“ (Plan Task 4, Schritt 1) gibt es nicht in der Oberfläche, sondern nur als globale YAML-Option versatile_thermostat: safety_mode: check_outdoor_sensor: false. Sie wird nicht gesetzt. Grund: In feature_safety_manager.py (10.5.0) ist should_climate_be_in_safety = False fest verdrahtet (Issue 99). Ein over_climate-VTherm geht nie in Safety, Außensensor-Ausfall und Safety-Verzögerung wirken also nicht. Die Fallstrick-Notiz „VTherm ohne Self-Regulation hat aktiven Safety-Modus“ trifft auf 10.5.0 nicht zu. Kostet, falls falsch: Ein OpenWeatherMap-Ausfall würde VTherm in Safety schicken; das zeigt sich am Preset safety.

Entscheidung: Preset-Temperaturen sind in 10.5.0 Zahlen-Entitäten und werden nicht im Dialog eingetragen. Das Bad bekommt „zentrale Presets nutzen“ = aus, weil sein Komfortwert (21) von der Zentrale (20) abweicht (Plan Schritt 4 hatte das als Fallback vorgesehen). Die zentralen Werte setzt Claude über die Zahlen-Entitäten der Zentralkonfiguration.

Ausgangslage Bad-TRV: off, Ziel 5 °C, sensor: internal, window_detection: on, Schrittweite 0,5.

Anlage (Robin, Oberfläche, 08./09.10.): Zentralkonfiguration (01M4G3Q6XC7FG1T1PJ8YSPV2WG) und „Heizung Badezimmer“ (01M4G3Z2M3ETRJ9B4VNZBXYFYW). Robin hat keine Abweichungen der Oberfläche gemeldet.

Schritt 3 (09.10.): climate.heizung_badezimmer, wie im Plan erwartet. hvac_modes off/heat, Presets none/frost/eco/comfort/boost, Fenster: Sensor binary_sensor.badezimmer_sensor_window, Aktion Frostschutz, 30 s auf und zu. Self-Regulation aus (is_regulated: false), „Follow underlying temp change“ aus, zentraler Modus an. Safety-Verzögerung 180 min. Weitere Entitäten: number.heizung_badezimmer_preset_{comfort,eco,boost,frost}_temp, sensor.heizung_badezimmer_temperature_slope, …_ema_temperature, binary_sensor.heizung_badezimmer_window_state, switch.heizung_badezimmer_follow_underlying_temp_change. Zentral: number.central_configuration_preset_*_temp, select.central_configuration_central_mode (Auto).

Schritt 4: Zentrale Presets 20/17/24/7, Bad 21/17/24/7 (Komfort/Eco/Boost/Frost).

Schritt 5 (09.10. 12:42): Reset Bad aus (AHC Bad war schon aus), switch.badezimmer_heizung_window_detection aus, input_boolean.heizung_neu_badezimmer an, VTherm Bad heat + Preset eco (Ziel 17 °C).

Schritt 6: Die Einspeisung lief über den Trigger aktivierung. select.badezimmer_heizung_sensor ging nach 0,6 s auf external, danach genau ein Publish {"external_temperature_input": 19.4} an zigbee2mqtt/badezimmer_heizung/set, input_number.heizung_gesendet_badezimmer = 19,4. Das TRV meldet current_temperature 19,4 und heat/17 °C. Damit ist auch T1 (Dezimalwerte) im Ansatz belegt, die E1 zeigt den Wert nicht gerundet. Endgültig in Task 7 mit einem Wert mit zwei Nachkommastellen.

Schritt 7: sensor.heizung_badezimmer_temperature_slope hat state_class: measurement (°C/h). Die Aufheizrate geht also in die Langzeitstatistik.

Später: Außensensor in der Zentralkonfiguration auf den Balkonsensor umstellen, sobald er montiert ist.

Task 3, Schritt 5: Notbetrieb-Test (09.10.2026, Review-Fokus 2)

Testkopie der Einspeisung mit festem temp = unavailable und Trigger-ID notbetrieb, nur Bad: - 1. Lauf: select.badezimmer_heizung_sensor → internal, input_boolean.heizung_notbetrieb_badezimmer an, Push und Benachrichtigung, kein Publish. - 2. Lauf: kein Select-Write, kein zweiter Push (Merker greift). - Testkopie gelöscht, echte Einspeisung ausgelöst: Merker aus, Benachrichtigung entfernt, TRV zurück auf external, Wert gesendet.

Bestanden.

Nebenbei 09.10.2026

Luftfeuchte-Gruppen korrigiert (Fund aus dem Thermal-Comfort-Review, siehe unten): sensor.esszimmer_sensor_humidity enthielt den Schlafzimmer-Sensor. sensor.wohnzimmer_sensor_humidity mittelte …_luft_vorne, den nicht mehr vorhandenen …_luft_hinten und den VINDSTYRKA …_fernseher (71 %, rund 11 % über dem Aqara), damit 65,0 %, und hätte die Lüftungsschwelle fälschlich gerissen. Beide stehen jetzt auf dem Aqara-Sensor des Raums (ignore_non_numeric: true): Esszimmer 62,5 %, Wohnzimmer 59,0 %. Entscheidung: Kein VINDSTYRKA-Ersatz bei der Feuchte, weil die Abweichung zu groß ist. Kostet, falls falsch: Fällt der Aqara aus, fehlt der Lüftungshinweis in diesem Raum.

W100 Arbeitszimmer: Robin stellt ihn vom Schreibtisch (Technik) an eine kühlere Stelle. Danach die Differenz zum Aqara-Sensor erneut prüfen.

Thermal Comfort (Fable-Advisor, 09.10.): Bestand v2.2.6 mit 6 Einträgen (Wohnzimmer fehlt), Eingänge sind die Aqara-Einzelsensoren. In vier Räumen hängen je 15 verwaiste YAML-Entitäten, die lebenden tragen deshalb _2. Empfehlung: jetzt nur den Lüftungshinweis in Task 11 um „Taupunkt außen < Taupunkt innen − 2 K“ ergänzen (TC-dew_point je Raum, sensor.openweathermap_dew_point). Aufräumen der verwaisten Entitäten, Wohnzimmer-Eintrag und Umstellung auf die Raumgruppen gehören zu #258. Perception- und Hitzeindizes nicht aufs iPad, TC nicht in die Regelung. Schimmelrisiko bleibt „später“ (Spec 13); vorher eine Woche Messung mit einem Aqara-Sensor in der kältesten Außenwandecke.

ha-mcp 8.6.0: Ab 8.x richtet ha_set_integration Integrationen über ihren Einrichtungsdialog ein. Damit kann Claude die übrigen 6 VTherm-Instanzen selbst anlegen. Robin hat das Update freigegeben: homeserver#260 (7.12.1 → 8.6.0, Digest gepinnt). Läuft vor Task 8.

Task 5: Zustellprüfung (09.10.2026)

automation.heizung_zustellpruefung (Label heizung). Die Einspeisung heißt jetzt wie im Plan automation.heizung_e1_einspeisung, beide IDs wurden nach dem Anlegen umbenannt, weil HA sie aus dem Alias bildet. target_temp_step der E1 = 0,5 (Toleranz 0,26 K passt).

Entscheidung: Drei Abweichungen vom Plan-Entwurf. 1. Störung je Raum statt je TRV. Der Entwurf setzte und löschte heizung_stoerung_<raum> in der TRV-Schleife. Im Wohnzimmer hätte ein funktionierendes zweites TRV die Störung des ersten sofort gelöscht, und jeder 15-min-Abgleich hätte erneut gepusht (widerspricht Review-Fokus 5). Jetzt sammelt die Automation nach der TRV-Schleife alle abweichenden TRVs (fehler) und setzt den Schalter einmal je Raum. Der Push nennt die betroffenen TRVs. 2. Nicht erreichbare TRVs (unavailable/unknown) werden nicht dreimal im Abstand von 2 min wiederholt, sondern sofort als Störung gewertet. Das spart bis zu 6 min Warteschlange je Lauf. HA überspringt Befehle an nicht verfügbare Entitäten ohnehin. 3. to: null am Modus-Trigger. Ohne ihn löste jede Attributänderung von VTherm (Zeitstempel, EMA) die Prüfung aus, im Test 3 Läufe in 40 s (heat → heat).

Kostet, falls falsch: nichts Funktionales. Die Automation ist etwas länger als der Entwurf.

Test Schritt 2 (Positivfall): VTherm Bad auf comfort (21 °C). Läufe nach 2 min: kein climate.set_*, heizung_stoerung_badezimmer aus, TRV heat/21. Bestanden.

Test Schritt 3 (Reparatur): climate.badezimmer_heizung direkt auf 26 °C (12:52). Abgleich 13:00: ein Versuch (set_hvac_mode heat, set_temperature 21), nach 2 min TRV = 21, fehler leer, kein Push. Bestanden.

Test Schritt 5 (Wartungssperre): heizung_wartung an, Auslösen mit Bedingungen → failed_conditions. Wieder aus. Bestanden.

Offen (braucht Robin): Schritt 4 (Batterie aus dem Bad-TRV, Störungs-Push genau einmal) und Schritt 6 (Badfenster öffnen, Review-Fokus 3).

ha-mcp 8.6.0 ausgerollt (09.10.2026)

homeserver#260 von Claude gemergt (Robin: „Merge gerne selber, und roll es dann aus“), Squash f06410b. Auf dem NUC als root: git merge --ff-only refs/remotes/origin/main (3 Commits: #260 und zwei Paperless-Seed-Änderungen, die nur beim manuellen Seed-Lauf greifen), dann docker compose pull ha-mcp und up -d ha-mcp. Container läuft mit 8.6.0@sha256:7426fb16…, 0 Neustarts, WebSocket zu HA verbunden. HA selbst wurde nicht neu gestartet.

Funde auf dem NUC-Klon /opt/rpi-docker-compose: - git pull als robin scheitert mit failed to write object. .git gehört root, also Rechte und keine Korruption. Deploys laufen deshalb über nuc-root. - Es gibt einen verwaisten lokalen Branch origin/main (refs/heads/origin/main auf 912c4e0, alter Ollama-Stand). Er macht origin/main mehrdeutig (git log HEAD..origin/main zeigte 13 alte Commits und eine rückwärts laufende Traefik-Umbenennung). Nicht gelöscht, Robin entscheidet. Bis dahin immer refs/remotes/origin/main verwenden. - Untracked homepage/secrets.env im Klon (nicht angefasst).

Damit ha_set_integration im Claude-Client erscheint, muss Claude Code die MCP-Verbindung neu aufbauen (/mcp → homeassistant → Reconnect, oder neue Session).

Task 6: Tagesprofil und Übersteuerung (09.10.2026)

Angelegt (alle mit Label heizung): - Skripte: script.heizung_raum_profil (nach Plan), script.heizung_uebersteuern_2h, script.heizung_halten, script.heizung_fortsetzen, script.heizung_alle_eco, script.heizung_boost_bad, script.heizung_abwesend - Automationen: automation.heizung_tagesprofil, automation.heizung_wach_erkennung, automation.heizung_uebersteuerung_ablauf (IDs nach dem Anlegen auf die Plan-Namen umbenannt)

Entscheidungen: - Boost: Der VTherm-Dienst versatile_thermostat.set_timed_preset heißt im Feld duration_minutes, nicht duration_min wie im Plan. Kostet, falls falsch: nichts, ha_list_services hat das Feld so geliefert. - Grundtemperatur Wohnzimmer: Der Taktgeber hat einen eigenen Trigger auf input_number.heizung_wohnzimmer_grundtemperatur. Steht das Wohnzimmer auf Block grund (ohne Halten und ohne laufende 2-h-Übersteuerung), erzwingt er das Profil. Im Plan hätte eine Änderung der Grundtemperatur am Tablet erst am nächsten Tag gewirkt, weil das Profil nur bei einem Blockwechsel schreibt. Kostet, falls falsch: nichts. - Taktgeber-Trigger: zusätzlich die beiden Vorlauf-Helfer (sie verschieben den Blockbeginn). Alle Helfer-Trigger haben to: null. - script.heizung_abwesend ruft beim Ausschalten das Profil in jedem Raum mit continue_on_error: true auf, wie der Taktgeber.

ha-mcp 8.6.0: Skripte und Automationen verlangen im strikten Modus eine Lesebestätigung aus dem Best-Practice-Leitfaden (BestPracticeKey, wechselt stündlich). Beim Anlegen kommt sie aus ha_get_skill_guide.

Tests: - Blockberechnung vorab live für alle 7 Räume (Fr. 13:48): fruh 06:30, tag 08:30. Abstellraum und Schlafzimmer eco, alle anderen comfort. Wie erwartet. - Erster Takt 13:55: input_text.heizung_block_badezimmer = comfort, die übrigen Räume übersprungen (nicht umgestellt). - Schritt 6, Neustart-Schutz (Review-Fokus 1): ['07:30:00','unknown'] → 1 Treffer, ['07:30:00','09:00:00'] → 2, ['07:30:00','unavailable',''] → 1. Testkopie mit uhrzeiten_ok = false und erzwingen = true für das Bad: Lauf aborted an der ersten Bedingung, VTherm-Preset und Block unverändert. Kopie gelöscht. Bestanden. - Schritt 5, Profil im Bad: heizung_nachtruhe auf 13:55 gesetzt → sofort (der Helfer-Trigger löst aus) Block eco, VTherm Eco/17 °C. - Schritt 7, Übersteuerung A (Review-Fokus 4): Bei Block eco VTherm Bad auf 22 °C (14:00) → Preset none. Takte 14:00, 14:05, 14:10: Zielwert bleibt 22 °C, das TRV ebenfalls 22. Blockwechsel (nachtruhe zurück auf 23:00) → Preset comfort/21 °C, die Übersteuerung ist beendet. Bestanden. - Schritt 8, Übersteuerung B: 22 °C + script.heizung_uebersteuern_2h → Ablauf 16:11, Block manuell. Ablauf auf 14:14:30 vorgezogen. Um 14:13 noch none/22, automation.heizung_uebersteuerung_ablauf löst um 14:14:30 aus → comfort/21. Bestanden. - Schritt 8, Übersteuerung C: script.heizung_halten + 22 °C, Blockwechsel nach Eco provoziert → bleibt 22 °C. script.heizung_fortsetzen → Halten aus, Ablauf auf 1970 zurückgesetzt, sofort Eco/17 (Nachtruhe stand auf 14:10). nachtruhe zurück auf 23:00 → comfort/21. Bestanden. - Schritt 9, Wach-Erkennung: offen bis Samstag, 10.10. Erste Bewegung nach 07:00 → heizung_wach_heute an → Bad und Küche innerhalb von 5 min comfort. - Nicht im Plan getestet: alle_eco, boost_bad, abwesend. Diese kommen in die Abschlusstests.

Task 7: Vorab-Tests im Bad

• T1 Dezimalwerte: Erste Einspeisung 19,4 → TRV current_temperature 19,4 (Task 4). Ein Wert mit zwei Nachkommastellen steht noch aus und wird beim nächsten Abgleich nachgetragen.
• T2 Rückfall: Start 09.10. 14:17, input_boolean.heizung_neu_badezimmer aus (keine Einspeisung, keine Zustellprüfung, kein Profil im Bad; VTherm bleibt auf Komfort). Ende frühestens 17:17. Danach Verlauf von select.badezimmer_heizung_sensor auswerten und Schalter wieder an.
• T3 Display (Robin), T7 Batterie (nach 7 Tagen): in die Abschlusstests verschoben (Robin 09.10.: alle Tests mit ihm gesammelt am Ende).

Dashboard (Task 11) parallel

Robin hat am 09.10. gebeten, das Dashboard schon parallel zu bauen, damit er früh Feedback geben kann. Ein Subagent (Opus) baut /smart-home-zentrale nach Task 11 und Spec 7, mit dem Lüftungshinweis nach Fables Vorschlag (relative Feuchte ≥ Schwelle und Taupunkt außen < Taupunkt innen − 2 K). Er darf nur dieses Dashboard anlegen.

Abschlusstests mit Robin (gesammelt)

Robin will alle Tests, die ihn brauchen, gesammelt am Ende machen (09.10.): - Task 5, Schritt 4 (T4): Batterie aus dem Bad-TRV → genau ein Push „Befehl nicht angekommen“, danach Entwarnung - Task 5, Schritt 6 (T5, Review-Fokus 3): Badfenster öffnen → VTherm 7 °C, Prüfung „repariert“ nicht auf Komfort, nach dem Schließen wieder Komfort - Task 7, T3: Display des Bad-TRVs ablesen - Task 9, Schritt 5 (Review-Fokus 5): Batterie aus wohnzimmer_heizung_hinten - Task 10, T8: VINDSTYRKA Schreibtisch ausstecken - alle_eco, boost_bad, abwesend einmal durchspielen - Zum Heizbeginn: valve_alarm an Arbeitszimmer und Wohnzimmer vorne beim Regeln beobachten; bleibt er an, Ventiladapter prüfen (Task 13)

Heizung aus (09.10.2026, 14:18)

Robin: Die Zentralheizung läuft noch nicht, und die Heizkörper müssen vorher entlüftet werden. VTherm Bad deshalb auf off, das TRV folgt nach gut 30 s (14:18:23). Umgeschaltet wird erst, wenn die Heizung läuft. T2 läuft trotzdem weiter, weil es nur den Sensormodus des TRVs beobachtet.

Task 8/9: VTherm-Instanzen angelegt (09.10.2026, 14:20)

Robin hat entschieden: jetzt anlegen, später umschalten. Claude hat die Instanzen per ha_set_integration (ha-mcp 8.6.0) angelegt, ohne Oberfläche.

Fund: Der VTherm-Dialog startet mit async_step_user, Vorgabe thermostat_type = thermostat_over_switch. Ein Aufruf ohne Typ hat einen over_switch-Dialog geöffnet. Er blieb unvollständig im Menü (configuration_not_complete), angelegt wurde nichts, und er verfällt von selbst. Danach immer mit thermostat_type: thermostat_over_climate und der Menüfolge main, features, type, presets, window, advanced, lock, finalize.

Konfiguration je Raum (identisch zum Bad, gegengeprüft über die Attribute): over_climate, Zyklus 5 min, zentrale Hauptparameter und zentraler Modus an, Fenster-Feature an (zentrale Fensterparameter: Frostschutz, 30 s), keine Self-Regulation, kein Temperatur-Sync, „Follow underlying“ aus, zentrale Erweitert- und Lock-Parameter.

Raum	Entry	Entität	Fenster	Geräte
Abstellraum	01M4G9Q1QXPYTRWPMSDG9XCAKP	climate.heizung_abstellraum	binary_sensor.abstellraum_sensor_window	climate.abstellraum_heizung
Arbeitszimmer	01M4G9Q4T6YCMD5ZC67AQS0C3F	climate.heizung_arbeitszimmer	binary_sensor.arbeitszimmer_sensor_fenster	climate.arbeitszimmer_heizung
Esszimmer	01M4G9Q7PSWDAXE6ZW0YVE14W2	climate.heizung_esszimmer	binary_sensor.esszimmer_sensor_window (Fenster Bad + Arbeitszimmer)	climate.esszimmer_heizung
Küche	01M4G9PMMEKXGK4N4ENBJVRV7P	climate.heizung_kueche (Anzeige „Heizung Küche“)	binary_sensor.kueche_sensor_window	climate.kueche_heizung
Schlafzimmer	01M4G9QAQRR84FBH99GDS6957T	climate.heizung_schlafzimmer	binary_sensor.schlafzimmer_sensor_window	climate.schlafzimmer_heizung
Wohnzimmer	01M4G9QD7CASMRNPNT8FSXZGZ2	climate.heizung_wohnzimmer	binary_sensor.wohnzimmer_sensor_window (Dachterrassen-Türen)	climate.wohnzimmer_heizung_vorne, …_hinten

Alle Instanzen stehen auf off, alle TRVs auf off, alle melden is_ready, auch das Wohnzimmer mit zwei TRVs. Label heizung an allen 7 Raumreglern.

Entscheidung: Alle Räume haben eigene Presets („zentrale Presets nutzen“ aus), wie das Bad. Arbeitszimmer und Küche weichen ohnehin ab, und die Spec sieht die Preset-Temperaturen je Raum am Tablet vor. Kostet, falls falsch: Eine zentrale Änderung muss je Raum nachgezogen werden.

Presets (Komfort/Eco/Boost/Frost): Abstellraum 20/17/24/7, Arbeitszimmer 21/17,5/24/7, Esszimmer 20/17/24/7, Küche 21/17/24/7, Schlafzimmer 20/17/24/7, Wohnzimmer 20/17/24/7. Boost steht überall auf 24 statt der Vorgabe 5 °C, obwohl die Spec Boost nur fürs Bad vorsieht. Sonst würde ein versehentliches „Boost“ den Raum auf 5 °C stellen. Die Zahlen-Entitäten zeigen die Werte. Das Attribut preset_temperatures der Raumregler zeigte direkt danach noch 5,0, weil VTherm den Zustand im ausgeschalteten Zustand noch nicht neu geschrieben hatte. Beim Umschalten prüfen.

Offen bis zum Umschalten (Plan Task 8, Schritt 4ff. und Task 9): AHC und Reset-Automation je Raum aus, window_detection des TRVs aus, heizung_neu_<raum> an, Profil erzwingen, prüfen. Better Thermostat Wohnzimmer steht schon auf off und wird in Task 14 entfernt.

Advisor-Review Task 5/6 (Fable 5.1, 09.10.2026) und Nacharbeit

Bestätigt hat das Review: Störung je Raum, unavailable-TRV ohne Wiederholungsschleife, to: null, Toleranz 0,26, Fenster → Soll 7 °C (kein „Reparieren“), VTherm off → TRV off, keine Doppelwrites VTherm ↔ Prüfung, Neustart-Schutz, Feiertag über workday_sensor, Sommerzeitwechsel im Eco-Fenster.

Behoben (Entscheidungen): 1. Kritisch: Ein Raumregler, der nicht bereit ist (is_ready: false, z. B. beim Reload oder im Wohnzimmer mit einem TRV offline), meldet off statt unavailable. Die Zustellprüfung hätte dann alle TRVs des Raums abgeschaltet, im Wohnzimmer auch das gesunde. Neu: Die Prüfung überspringt Räume, deren Raumregler nicht is_ready meldet. 2. Nachtruhe vor 05:00 (z. B. 00:00) hätte alle Räume ganztags auf Eco gelegt. Neu: Eco gilt jetzt < 05:00 oder Nachtruhe ≥ 05:00 und jetzt ≥ Nachtruhe. Eine Nachtruhe nach Mitternacht wirkt also ab 00:00 (simuliert: 23:00/14:30 → Tag, 00:00/14:30 → Tag, 00:00/03:20 → Eco). Bewusst: Die 05:00-Untergrenze kappt den Vorlauf (Aufstehen 05:45 − 60 min → Start erst 05:00). 3. Wach-Erkennung: Sie gilt bis zur eingestellten Nachtruhe statt fest bis 23:00, mit einem zusätzlichen festen Reset um 04:55. Sonst hätte Bewegung nach einer früheren Nachtruhe wach_heute über Nacht stehen lassen. 4. Halten gilt immer. erzwingen hebt Halten nicht mehr auf, das tut nur noch script.heizung_fortsetzen, das Halten vorher ausschaltet. Vorher hätten „Zurück“ (Abwesend aus) und der Ablauf einer 2-h-Übersteuerung einen gehaltenen Raum überschrieben, der Halten-Schalter wäre aber an geblieben. 5. Manuelles Aus war eine Übersteuerung ohne Ende, weil das Profil nur Presets setzt. Neu: Beim Blockwechsel schaltet das Profil einen Raumregler wieder auf heat, wenn er aus ist, hvac_off_reason leer oder hvac_off_manual ist (beim Ausschalten per Dienst steht None, bei neu angelegten hvac_off_manual) und select.central_configuration_central_mode = Auto. Fenster, Safety und zentraler Modus bleiben unberührt. 6. Boost ↔ Blockwechsel: Laut VTherm-Doku (feature-timed-preset) bricht ein manueller Preset-Wechsel einen laufenden Timed-Preset ab. Ein Blockwechsel während Boost beendet den Boost also, VTherm stellt danach nichts zurück. Kein Umbau nötig. In die Abschlusstests aufgenommen. 7. Abgleich 30 s nach dem Takt (minutes: /15, seconds: 30), damit er nicht mit Blockwechseln auf Viertelstunden kollidiert. Korrigiert wird nur, was abweicht (Preset, Modus und Ziel getrennt). 8. TRV-Preset: Die Prüfung erwartet die E1 auf Preset manual (Optionen manual/away/auto) und stellt sie zurück, wenn sie z. B. nach einem Batteriewechsel auf auto (eigener Zeitplan) steht.

Bewusst so gelassen und notiert: Ein erreichbares, aber stummes TRV kostet je Abgleich bis zu 6 min Warteschlange (Wohnzimmer 12), max 10 reicht rechnerisch. alle_eco, abwesend, boost und VTherm selbst ignorieren heizung_neu_<raum>. Das gehört in die Betriebsdoku (Task 15). uebersteuern_2h speichert lokale Zeit, in der Umstellungsnacht kann der Ablauf ±1 h liegen.

Zusätzlich in die Abschlusstests: Fenster auf während einer laufenden 2-h-Übersteuerung (Spec 5.4: Fenster schlägt sie, danach gilt sie weiter). HA-Neustart mit aktiver Übersteuerung A (mit Robins OK). Nach dem Fenstertest prüfen, dass das Ziel 21 °C ist und nicht ein gemerktes 22 °C (requested_state). Boost, danach Blockwechsel.

Zentraler Modus: Heizperiode aus (09.10.2026, 14:40)

Entscheidung: select.central_configuration_central_mode = Frost protection (Spec 5.1: Sommer = Frostschutz). Er ist der Schalter für „Heizperiode aus“, solange die Zentralheizung nicht läuft. Wirkung: Ausgeschaltete Raumregler bleiben off (der Frostschutz greift nur bei laufenden), alle 8 TRVs off. Durch Punkt 5 schaltet das Profil nichts ein, solange der Modus nicht Auto ist. Zum Heizbeginn: Modus auf Auto, dann schaltet der nächste Blockwechsel jeden umgestellten Raum auf heat (oder sofort per script.heizung_fortsetzen).

Task 11: Dashboard, erste Fassung (09.10.2026)

Gebaut von einem Opus-Subagenten (nur dieses Dashboard, sonst keine Änderungen): /smart-home-zentrale (Storage, Seitenleiste, ohne Adminpflicht, Icon mdi:home-thermometer). Ansichten start, raum-<raum> (7 Unterseiten, Zurück → Start) und einstellungen. 139 referenzierte Entitäten, alle vorhanden. Karten: Mushroom-Template, tile, markdown, thermostat, history-graph, entities, button, heading. Kein card-mod, ApexCharts, simple-thermostat oder Scheduler.

Entscheidungen des Subagenten: - Status-Template nach den echten VTherm-10.5.0-Attributen, für das Bad getestet. Reihenfolge, wenn mehreres zutrifft: noch nicht umgestellt, Störung, Notbetrieb, Fenster offen, Aus, Boost bis HH:MM, Manuell · gehalten, Manuell bis HH:MM, Grundtemperatur, Manuell bis zum nächsten Zeitplanwechsel, Abwesend, Frostschutz, Heizt, Eco, Ziel erreicht. - „Nächster Zeitplan“ wird wie in script.heizung_raum_profil berechnet. Für morgen gilt der Wochentag, Feiertage zählen dabei nicht. - Lüftungshinweis wie von Robin gewünscht: Feuchte ≥ Schwelle und Taupunkt außen mehr als 2 K unter innen → „Lüften lohnt sich“, sonst „Feuchte hoch, Lüften bringt gerade wenig“. Den Innen-Taupunkt liefert Thermal Comfort (…_dew_point_2), wo vorhanden, sonst rechnet die Karte ihn per Magnus-Formel (im Wohnzimmer). Im Bad weichen beide Werte nur 0,02 K voneinander ab. - Müll: kompakte Kachel mit dem nächsten Termin aus calendar.bremer_stadtreinigung, „Heute“ und „Morgen“ hervorgehoben. Die Kalenderkarte war zu groß und zeigt am Wochenende nichts. Lücke: An Tagen mit zwei Fraktionen erscheint nur die erste. - Thermostat und Übersteuerungsknöpfe erscheinen erst, wenn der Raum umgestellt ist (heizung_neu_<raum> an). - Zentraler Modus im Einstellungs-Tile auf „Auto“ (Winter) und „Frost protection“ (Sommer) beschränkt.

Offen: Robins Prüfung auf iPad und iPhone (Screenshot-Beta in ha-mcp ist aus, Layout ungeprüft). Fragen des Subagenten an Robin: große Ist-Temperatur ohne card-mod nur fett im Titel (reicht das oder button-card?), Bestätigung für „Alle Eco“ und „Abwesend“, Sensoren je Müllfraktion (Änderung an der Integration), englische Optionsnamen beim zentralen Modus. Erzeugungsskripte lagen im Session-Scratchpad.

Robins Feedback zu v1 (09.10.2026): „Schaut nicht annähernd so schick aus wie im Mockup.“ (1) Große Ist-Temperatur wie im Mockup: ja. (2) Bestätigung bei „Alle Eco“/„Abwesend“: ja. (3) Müll: an Abholtagen oft 2 Fraktionen, Sensoren je Fraktion: ja. (4) Englische Optionen beim zentralen Modus: okay, aber nicht schön. Auftrag: tiefe Recherche mit Exa und Fable für ein „state of the art“-Dashboard nahe am Mockup. Läuft. Ergebnis wird ein Bauplan, neue HACS-Abhängigkeiten nur nach Robins Freigabe.

Recherche v2 (Fable mit Exa, 09.10.2026): Bauplan unter recherche/dashboard-v2-bauplan.md. Kernaussagen: Das Mockup ist flach-dunkel (kein Glas) und ohne card-mod fast vollständig erreichbar, über das Theme zentrale-dunkel, native Karten und die schon installierte button-card. Die Statuslogik wandert in Template-Sensoren. Vor dem HA-Update auf 2026.9 (#246) muss ein alter extra_module_url-Eintrag auf card-mod.js in configuration.yaml geprüft werden, sonst lädt das Frontend nicht.

Robins Entscheidungen zu v2 (09.10.2026): - Statuslogik als UI-Template-Helfer (kein YAML unter /config) - Müll: die nächsten 2 Abholtage, je mit allen Fraktionen - Raumseiten mit Zusatzkarten: Versatile-Thermostat-UI-Card und mini-graph-card statt nativer Thermostat- und Verlaufskarte - Presets als 7 kompakte Listen - Weitere HACS-Karten sind erlaubt, wenn sie das Design nötig verbessern („nicht zu viel“)

v2 entsteht parallel unter /smart-home-zentrale-v2 (Opus-Subagent), v1 bleibt zum Vergleich.

Task 11: Dashboard v2 (09.10.2026)

Ein Opus-Subagent hat v2 nach dem Bauplan gebaut. Nach einem Rate-Limit-Abbruch wurde er mit seinem Kontext fortgesetzt. Ergebnis: /smart-home-zentrale-v2/start (Storage, Seitenleiste, ohne Adminpflicht). v1 bleibt unverändert. Config-Hash 199f823dc52dd1c9.

• Aufbau: Start (Uhr, Wetter, Gerätestatus, 7 Raumkacheln mit großer Ist-Temperatur, Legende, Schnellaktionen, Müll), 7 Raumseiten, Einstellungen (zweispaltig, Sommer/Winter-Segment, Stepper, 7 Preset-Listen und die zentralen Presets). Fast alles ist button-card mit 33 eigenen Templates, Farben und Radien wie im Mockup. Für das iPhone baut sich das Layout ohne card-mod um.
• Bestätigung (Titel, Text, „Ja“/„Abbrechen“) bei „Alle Eco“, beim Einschalten von „Abwesend“ und bei Sommer/Winter. „Alle Eco“ und „Boost Bad“ sind im Sommerbetrieb gesperrt.
• 28 Template-Helfer (Label heizung): sensor.heizung_farbe_<raum> (Statusklasse), sensor.heizung_status_<raum> (Text), sensor.heizung_naechster_zeitplan_<raum>, sensor.heizung_lueften_<raum> (Taupunktvergleich).
• Müll: Waste Collection Schedule ist per Oberfläche konfiguriert, die zwei Sensoren kamen über den Options-Dialog: sensor.muell_naechster_abholtag, sensor.muell_uebernaechster_abholtag (z. B. „Bioabfall + Restmüll“ → „Bio + Rest“).
• HACS: versatile-thermostat-ui-card 3.4.0 (17.09.2026) installiert, Ressource registriert. mini-graph-card v0.13.0 war schon installiert und wird für den Verlauf mit zweiter Achse genutzt. Weitere Karten waren nicht nötig.
• Geprüft wurde in einer lokalen WebKit-Vorschau mit der echten button-card (iPad quer, iPhone) und simulierten Zuständen. Die HA-Screenshot-Funktion ist aus. Ein Fable-Review hat keine harten Fehler gefunden, seine Hinweise sind eingearbeitet (Verlauf lädt einmal je Raum, „Grundtemperatur“ nur, wenn das Ziel ihr entspricht).

Abweichungen vom Bauplan: - Kein Theme zentrale-dunkel: ha_manage_theme kann Themes nur auswählen, nicht anlegen, und /config ist gesperrt. Das Dashboard färbt sich trotzdem unabhängig vom Profil, nur die Dialoge folgen dem Profil-Theme. - mini-graph-card: Die letzte stabile Version ist v0.13.0, 16 Monate alt, seitdem gibt es nur Pre-Releases. Sie war schon installiert. Offen für Robin: behalten oder durch native Verlaufskarten ersetzen. - VT-Card-Optionen weichen vom README ab (classic statt „classical“, disable_sleep), korrigiert.

Bekannte Lücken: Systemschrift statt Figtree. Die Ziel-Linie ist durchgezogen statt gestrichelt. „Nächster Zeitplan“ kennt für morgen keine Feiertage. Die VT-Card schreibt viele Konsolenmeldungen. button-card hat ein Speicherleck (#1211), deshalb sollte die Kiosk-App täglich neu laden.

Nebenbei aufgefallen (nicht angefasst): sensor.gemessene_steckdosen_power meldet wiederholt „Template loop detected“ → #258.

Task 7: T1 und T2 ausgewertet (09.10.2026, 19:43)

Hinweis zu den Zeiten: Die Arbeitsmaschine läuft auf UTC. Geplant war das Ende von T2 um 17:17 Ortszeit, ausgewertet wurde erst um 19:42, als Robin nachfragte. Bei Zeitangaben künftig immer die HA-Ortszeit nehmen.

T2 Rückfall: bestanden. Die Einspeisung war von 14:15:41 bis 19:43:31 aus (input_boolean.heizung_neu_badezimmer), also 5 h 28 min. Im HA-Verlauf steht select.badezimmer_heizung_sensor durchgehend auf external, ohne einen Wechsel. Weil HA bei MQTT-Entitäten nur Änderungen mitschreibt, kam die Gegenprobe direkt vom Gerät: lesender mosquitto_sub auf zigbee2mqtt/badezimmer_heizung → frische Meldung (last_seen 19:43:33) mit "sensor": "external", "local_temperature": 19.4 (der zuletzt eingespeiste Wert). Ein Rückfall auf internal hätte den eigenen, 1–3 K zu kalten Fühlerwert gezeigt. Entscheidung: Keep-alive bleibt bei 30 min mit 25-min-Sperre. Kostet, falls falsch: nichts, die E1 hält den Wert nach dieser Messung mehr als 5 h.

T1 Dezimalwerte: bestanden. Nach dem Wiedereinschalten (19:43:31, Trigger aktivierung) meldet die E1 "local_temperature": 19.23 (Raum 19,23, last_seen 19:46:33). Die E1 übernimmt zwei Nachkommastellen, die 0,2-K-Schwelle bleibt.

Nebenbei: Die Z2M-Meldung enthält last_seen (in Z2M aktiviert), und external_temperature_input ist im Zustand immer null. Das bestätigt den Fund aus dem ersten Fable-Review.

Bad danach: heizung_neu_badezimmer an, Einspeisung aktiv, VTherm off, zentraler Modus Frostschutz, es wird also nicht geheizt.

Dashboard v2: Verlauf nachgebessert (09.10.2026, abends)

Robins Feedback: v2 „gefällt mir wesentlich besser“, bleibt so. Der Verlauf auf den Raumseiten sollte aber eine Zeitachse, Hover-Werte, ein kombiniertes Diagramm und die Werte aus den alten Dashboards bekommen. Weitere Details folgen erst, wenn die Räume umgestellt sind und echte Werte laufen.

Umgesetzt (Opus-Subagent): Neue HACS-Karte a-better-history-card 0.3.1 (KipK/a-better-history-card, Release 06.08.2026, Apache-2.0, im HACS-Store). Je Raumseite ein kombiniertes Diagramm: - Zeitachse (um Mitternacht mit Datum) und Tooltip mit allen Werten - zwei y-Achsen (°C / %) - Linien: Temperatur, Zielwert (Treppe), Feuchte, Außentemperatur - Heizphasen als Fläche und Band, Fenster-offen-Band - Legende zum Ausblenden einzelner Kurven

mini-graph-card ist in v2 damit ersetzt (sie kann keine Zeitachse) und bleibt installiert. Übernommen aus den alten Dashboards: Temperatur und Feuchte mit zweiter Achse (Heizung), Außentemperatur (Klima), Uhrzeit-Achse. Nicht übernommen: Farbskala und 7/14/30-Tage-Ansicht, dafür bleibt „Klima“.

Entscheidung des Subagenten, bestätigt: Die „Statistics Graph Chart Card“ (am mächtigsten) wurde nicht installiert, weil sie proprietär lizenziert und verschleiert ist. Eine Karte mit vollem HA-Zugriff, die man nicht prüfen kann, kommt nicht ins System. Kostet, falls falsch: keine gestrichelte Ziel-Linie und keine Jetzt-Linie.

Risiko: Das Projekt ist jung (seit Mai 2026, 15 Sterne, ein Entwickler). Beim HA-Update auf 2026.9 gezielt prüfen, zusammen mit der mini-graph-card-Frage. Robin will dauerhaft ein kombiniertes Diagramm.

Grenzen: Zielwert als Treppe statt gestrichelt. Tooltip-Zustände eventuell englisch (idle, off). Das Datumsformat stand in der Vorschau auf US, in HA mit Robins Spracheinstellung prüfen. Zielwert und Heizphasen haben erst ab dem 09.10. Verlauf.

Zweites Fable-Review zu v2 eingearbeitet: Ein fehlender Regler zeigt jetzt „Störung“ statt „nicht umgestellt“. Die Raumseiten richten sich nur nach heizung_neu_<raum>. Unbekannte Status werden in der Übersicht gezählt, die Müll-Kacheln rendern alle 5 min neu. Config-Hash e8ca3cc1acdfa4d2.

Nachtrag 09.10. abends (Robin): Achsen in ganzen Zahlen und Außentemperatur standardmäßig aus. - Außentemperatur: auf allen 7 Raumseiten entfernt (die Karte kann Kurven nicht vorab ausblenden). Die °C-Achse richtet sich jetzt nur nach Raum und Ziel. - Ganze Zahlen an den Achsen: mit a-better-history-card 0.3.1 nicht einstellbar, die Karte leitet die Nachkommastellen aus den Messwerten ab. Feature-Request mit Robins OK gestellt: KipK/a-better-history-card#8 (verweist auf das verwandte #7, Anzeigegenauigkeit der Werte). Beim Diagramm-Check zum 2026.9-Update nachsehen, ob er umgesetzt ist. - Config-Hash v2: 44dee5c962447142.

Task 10, Schritt 2/3: HomeKit (09.10.2026, 21:36)

Fund: Die HomeKit-Bridge „HomeAssistant Climate“ ist per YAML konfiguriert (packages/homekit.yaml, Options-Flow nur yaml). Ihr Filter war include_domains: [climate] ohne die beiden Wohnzimmer-TRVs. Damit kamen die 7 neuen VTherm-Raumregler seit ihrer Anlage automatisch zusätzlich in HomeKit. In der Home-App gab es doppelte Thermostate je Raum, und über die TRV-Einträge ließ sich am neuen System vorbei steuern.

Änderung (Robins Freigabe, die erste Datei-Änderung unter /config in E6a): Sicherung nach nuc-root:/root/e6a-backups/homekit.yaml.vor-task10. Danach nur den Filter der Climate-Bridge auf include_entities mit den 7 climate.heizung_* umgestellt und Kommentare ergänzt. config_check gültig, homekit.reload ohne HA-Neustart. Gegenprobe über die Diagnose der Bridge: Der Filter enthält genau die 7 Raumregler, keine Fehler im Log.

Robin/Lars: In der Home-App die 7 neuen Thermostate den Räumen zuordnen. Die alten TRV-Einträge sollten verschwinden.

Nebenbei: In der YAML-Konfiguration gibt es keinen extra_module_url-Eintrag für card-mod (grep über alle YAML-Dateien außer custom_components/www). Das von Fable genannte Risiko „Frontend lädt nach dem Update auf 2026.9 nicht“ besteht damit nicht. card-mod ist nur noch als Lovelace-Ressource registriert (#257). Unter packages/ liegt außerdem heating.yaml (alte Heizungs-Helfer?). Vor dem Abbau in Task 14 prüfen.

Dashboard v2, Runde 3 (09.10.2026, abends)

Wünsche von Robin und Lars, umgesetzt von einem frischen Opus-Subagenten mit den vorhandenen Bauskripten. Config-Hash abd5e11dc0490feb. 1. Thermostat auf allen Raumseiten: Die VT-Card steht überall. Bei nicht umgestellten Räumen steht darunter „Noch nicht im Zeitplan – Bedienung wirkt direkt auf den Raumregler“. Die Übersteuerungsknöpfe erscheinen weiter nur in umgestellten Räumen. 2. Bug „Bad zeigt immer dieselbe Temperatur“: Das Diagramm zeichnete in umgestellten Räumen current_temperature des Raumreglers. Der Wert ist auf 0,1 gerundet, wird selten gespeichert und hat erst seit der Anlage am 09.10. Verlauf. Daraus wurde eine flache Treppe. Jetzt kommt die Temperatur immer aus sensor.<raum>_sensor_temperature und die Feuchte aus sensor.<raum>_sensor_humidity. Vom Raumregler kommen nur noch Ziel und Heizphasen. 3. Lars: Kontrast und Raumfarben: - Hintergrund #090b0e, Karten #22262f mit heller Kante und Schatten, Sekundärtext #bcc2cc. - Der Status steht als Pill mit Icon und Text. - Raumfarben: Wohnzimmer #e3cf5a, Arbeitszimmer #41d69a, Esszimmer #97d65a, Küche #e665c4, Bad #3fd0d8, Schlafzimmer #7073f0, Abstellraum #cbbd9a. Sie sitzen im Icon-Feld, an der Oberkante und als leichter Verlauf. - Text-Kontrast überall mindestens 4,5:1, der Abstand Raumfarbe zu Statusfarbe ΔE ≥ 18,7. Zusätzlich trennt die Form: Der Status ist immer eine Pill, der Raum eine Kante bzw. das Icon. 4. Neue Ansicht /smart-home-zentrale-v2/zeitplan: Je Raum ein Tagesbalken für heute (mit Jetzt-Linie) und kompakt Werktag sowie Wochenende/Feiertag, mit Uhrzeiten an den Blockgrenzen. Erreichbar über den Kalender-Knopf auf Start und aus den Einstellungen. Grundlage sind 7 neue Template-Helfer sensor.heizung_zeitplan_<raum> (Format heute;Werktag;Wochenende, Blockgrenzen in Minuten), gegen die Formel aus script.heizung_raum_profil geprüft: 30.240 Fälle ohne Abweichung.

Ein Fable-Review hat 4 kleine Punkte gefunden, alle eingearbeitet.

Claude danach: sensor.heizung_naechster_zeitplan_<raum> (7 Helfer aus Runde 1) nutzte noch die alte Nachtruhe-Regel (t >= Nachtruhe or t < 05:00). Mit einer Nachtruhe nach Mitternacht hätte er ganztags Eco gemeldet. Per ha_set_integration (Options-Patch) auf die Skript-Regel t < 05:00 or (Nachtruhe ≥ 05:00 and t ≥ Nachtruhe) umgestellt. Gegenprobe Fr 21:52: Abstellraum und Schlafzimmer „Keiner · Raum bleibt auf Eco“, die übrigen „23:00 Eco …“.

Hinweis Vorschau: Die lokale Vorschau rechnet für die Wochenend-Beschriftung mit simulierten Helferwerten (wochenende_spaetestens 09:00). Live steht dort 10:00, also auch „warm um 10:00“.

Task 13: Sommer-Ventilbewegung (09.10.2026, 22:15)

Schritt 1, eingebauter Schutz? Nein. Die E1 (SRTS-A01) bietet über Z2M nur setup, calibrated, calibrate (Ventil kalibrieren), child_lock, window_detection, window_open, valve_detection, valve_alarm, away_preset_temperature, schedule, schedule_settings, Sensor und externe Temperatur an. Quellen: Z2M-Geräteseite docs/devices/SRTS-A01.md und die HA-Entitäten des Arbeitszimmer-TRVs. Die Aqara-Handbücher (v2, v4) nennen nur die Modi Manuell, Frostschutz und Aus, keinen Verkalkungsschutz.

Schritt 2, Automation: automation.heizung_ventilbewegung_sommer (Label heizung). Montags 11:00, nur wenn select.central_configuration_central_mode auf „Frost protection“ oder „Stopped“ steht (Sommerbetrieb). Ablauf: Wartung an (Zustellprüfung pausiert), alle 8 TRVs heat/30 °C, 10 min warten, dann je TRV zurück zum Soll seines Raumreglers (bei heat dessen Zielwert, sonst 7 °C und off), Wartung aus.

Entscheidung: Zwei Abweichungen vom Plan. - Rückkehr zum Soll des VTherm-Raumreglers statt fest auf 7 °C, damit ein im Sommer eingeschalteter Raum nicht verstellt wird. - continue_on_error je TRV, damit ein nicht erreichbares TRV die anderen nicht blockiert.

Kostet, falls falsch: nichts.

Schritt 3, Test: Absichtlich nicht um 22 Uhr, weil die Ventilmotoren 10 min lang in allen Räumen hörbar arbeiten. Test tagsüber per automation.trigger (Bedingungen überspringen), erwartet: alle TRVs danach wieder off, Wartung aus.

ha-mcp: YAML-Bearbeitung und Screenshots ausgerollt (10.10.2026)

homeserver#261 von Claude gemergt (00118bd), nachdem Robin das Token für den Screenshot-Dienst angelegt hatte (eigener HA-Benutzer, damit Screenshots nicht das Theme seiner Sitzungen umschalten). Auf dem NUC als root: git merge --ff-only refs/remotes/origin/main, Image homeserver/ha-mcp-screenshot:8cafe6e gebaut, Datenverzeichnis /mnt/ssd/container-data/ha-mcp angelegt (999:999, 0700), up -d ha-mcp ha-mcp-screenshot. Beide Container healthy.

In HA: Komponente ha_mcp_tools v2.1.2 über HACS installiert, HA neu gestartet (Robins OK), Config-Eintrag „HA-MCP File & YAML Tools“ angelegt (Menüpunkt tools, ohne zusätzliche YAML-Schlüssel und Verzeichnisse). „HA-MCP Server“ ist bewusst nicht angelegt. Danach /mcp → Reconnect, dann erscheinen ha_config_set_yaml und ha_get_dashboard_screenshot.

Screenshot-Test: ha_config_get_dashboard(include_screenshot=true) rendert /smart-home-zentrale-v2 (1280×800). RAM danach: ha-mcp 139 MiB, Screenshot-Dienst 44 MiB (Grenze 1 GiB). Den Spitzenwert während des Renderns hat das nicht erfasst.

YAML-Test nach der festen Regel (Diff im Chat, Bestätigung erst nach Robins Go, je Schreibvorgang einzeln): 1. template: mit einem Konstanten-Sensor in packages/ha_mcp_yamltest.yaml geschrieben, template.reload, sensor.ha_mcp_yaml_test = ok. 2. Schlüssel wieder entfernt (Datei enthielt danach {}), template.reload, Registry-Eintrag gelöscht, Datei per rm gelöscht.

Funde: - Nach einem template:-Edit nennt das Werkzeug homeassistant.reload_custom_templates als Reload-Dienst. Das lädt nur Jinja-Makros. Richtig ist template.reload. - remove löscht nur den Schlüssel, nie die Datei. Eine leere Paketdatei bleibt mit {} zurück. - Vor jedem Schreiben läuft eine Konfigurationsprüfung (config_check: ok). - Beim Neustart Fehler im Log, die nichts mit der Änderung zu tun haben: Pi-hole-Integration löst pihole.local.robinwerner.net nicht auf, Bluetooth ohne NET_ADMIN. Nicht geprüft, ob sie schon vorher auftraten. - Swap auf dem NUC fast voll (4036 von 4095 MiB), RAM verfügbar 12,8 GB. Steht bei den Folgepunkten aus #261.

Task 13, Schritt 3: Test der Sommer-Ventilbewegung (10.10.2026)

Erster Lauf (15:44, automation.trigger mit skip_condition): Die VTherm-Raumregler blieben aus, das Zurückstellen klappte bei allen 8 TRVs (Meldung bis zu 6 s verzögert). Das Öffnen nicht: Wohnzimmer vorne/hinten liefen mit 20 statt 30 °C (off/30 → heat/30 → heat/20 binnen 8 s, ohne Automation oder Skript dazwischen), das Arbeitszimmer ging nie auf heat.

Ursache (Fable-Analyse mit Z2M-Quellcode und -Issues): Modus (system_mode, Lumi-Attribut 0x0271) und Sollwert (occupied_heating_setpoint) sind zwei getrennte Zigbee-Schreibvorgänge ohne garantierte Reihenfolge. Die E1 speichert einen eigenen Heiz-Sollwert und holt ihn beim Wechsel off → heat zurück; ein vorher gesendeter Sollwert wird dabei überschrieben. Bei 5 TRVs kam zufällig der Modus zuerst an. Im Arbeitszimmer ging der Modus-Schreibvorgang vermutlich im Zigbee-Timeout verloren. Verwandte Issues: Koenkk/zigbee2mqtt#21620, #19342, #15641. valve_alarm meldet nur („Regelung auffällig, Ventil/Kalibrierung prüfen“) und blockiert nichts.

Umbau der Automation: 1. Erst set_hvac_mode heat an alle, warten bis alle heat melden (max. 60 s), Abweichler einmal nachsenden. 2. Erst dann 30 °C, 30 s Rückholfenster abwarten, Abweichler einmal nachsenden. 3. Zurückstellen wie bisher (Sollwert, dann off), danach Kontrolle und für Abweichler ein zweiter Durchgang. 4. Was am Ende abweicht, geht als Push an Robin.

Kalibrierung: Arbeitszimmer und Wohnzimmer vorne (beide valve_alarm) über button.*_calibrate kalibriert (Robins OK), beide nach ca. 18 s wieder calibrated: on. valve_alarm steht weiter an (Stand seit dem HA-Neustart 15:03) → bei Heizbeginn beobachten; bleibt er beim Regeln an, Ventiladapter prüfen (Abschlusstest-Liste).

Zweiter Lauf (16:23–16:35): Alle 8 TRVs nach 8 s heat, alle auf 30 °C ohne Nachsenden, alle zurück auf off/7, keine Abweichung in beiden Kontrollrunden, kein Push, Wartung aus, VTherm durchgehend aus. Bestanden.

Winterbetrieb: VTherm 10.5.0 schickt erst den Modus, dann nach 2 s den Sollwert; das Zurückholen der E1 kommt später (6–8 s) und kann den Wert überschreiben. Die Zustellprüfung (Task 5) vergleicht Modus und Sollwert und stellt bis zu dreimal im 2-min-Abstand nach — das deckt den Fall ab. Entscheidung (Robin): Zum Heizbeginn in allen 7 VTherm zusätzlich „Fix incorrect state“ (repair_incorrect_state) einschalten; follow_underlying_temp_change bleibt aus, sonst würde VTherm den zurückgeholten Wert als Ziel übernehmen.

Task 12: Wand-iPad Esszimmer (10.10.2026)

Abweichungen vom Plan: - Eigenes Gerät „iPad Esszimmer“ (iPad Pro 11″, iPad8,1, iPadOS 26.7.1), nicht Robins iPad. Robin hat den Benutzer „Wandtablet“ (ohne Admin) angelegt, die App angemeldet, Kiosk-Modus aktiviert, Standard-Dashboard v2. Geräte-Chip und Navigation funktionieren ohne Adminrechte (Robin geprüft). - Ladegerät an einer Shelly Plug M Gen3 (WLAN, 10.10.10.29) statt Zigbee-Stecker, weil die Shellys genauer messen und der Verbrauch aufgezeichnet werden soll. Gerät „iPad Esszimmer Ladegerät“, Bereich Esszimmer, Entitäten switch.ipad_esszimmer_ladegeraet, sensor.ipad_esszimmer_ladegeraet_leistung, sensor.ipad_esszimmer_ladegeraet_energie. Shelly-RPC Switch.SetConfig initial_state: on (nach Stromausfall ein, Robins Wahl). Energiezähler als erstes Gerät im (bisher leeren) Energie-Dashboard; Neuaufbau des Energie-Dashboards in homeserver#262. - Der App-Akkusensor war in der App deaktiviert (disabled_by: integration); Robin hat ihn in der App eingeschaltet.

automation.ipad_esszimmer_akku_schutz: unter 20 % (2 min) Laden an, über 80 % (2 min) aus; stündlich (:07) und nach HA-Start Nachprüfung gegen verpasste Schwellen; unter 15 % Laden an und Push an Robin; meldet die App 1 h keinen Akkustand, lädt das iPad sicherheitshalber. Prüfung nach 24 h Ladeverlauf (Plan Schritt 4) steht aus.

automation.ipad_esszimmer_display_nach_heizungs_zeitplan (Robin-Wunsch, nicht im Plan): Der Kiosk-Modus der iOS-App nimmt Befehle per notify.mobile_app_ipad_esszimmer an (kiosk_show/hide_screensaver, kiosk_set_screensaver_mode, kiosk_set_brightness, kiosk_reload, kiosk_default; Companion-Doku ios-kiosk-mode.md). Gekoppelt an den Heizungs-Zeitplan: - Nacht ab input_datetime.heizung_nachtruhe: Bildschirmschoner schwarz, Helligkeit 15 %. „Bei Kamerabewegung aufwecken“ (App-Einstellung) zeigt nachts das Dashboard gedimmt. - Tag ab früherer Aufstehzeit (Werktag) bzw. Wach-Erkennung, spätestens Wochenende-Zeit (frei): Bildschirmschoner gedimmt 25 %, Helligkeit 70 %. - Nach HA-Start und Wiederanlauf des Kiosk-Modus: Modus neu setzen, 30 s verzögert. - 03:30 kiosk_reload + kiosk_default gegen das Speicherleck von button-card.

Funde: - Erster Lauf (22:40) brach mit Action notify.mobile_app_ipad_esszimmer not found ab: Das Einschalten des Akkusensors lud die mobile_app-Integration neu, der Kiosk-Modus meldete sich vor dem notify-Dienst zurück. Fix: 30 s Wartezeit vor dem Prüfen. - Test: Probelauf 22:47 (Tag) fehlerfrei; Nachtruhe 23:00 → Bildschirmschoner an (23:00:06), Helligkeit 15 %. Robin bestätigt: Display aus, bei Bewegung leicht gedimmt an. - Die Shelly hat keine Gerätepasswort-Sicherung (auth_en: false), Matter ist an. Empfehlung an Robin: Passwort setzen, danach die HA-Integration mit Zugangsdaten neu konfigurieren.

Nachtmodus für Licht (Robin-Wunsch, 10.10. abends): Neuer Helfer input_boolean.nachtmodus. Die Tag/Nacht-Automation (umbenannt in „Tag/Nacht nach Heizungs-Zeitplan (Nachtmodus, iPad Esszimmer)“, Entität unverändert automation.ipad_esszimmer_display_nach_heizungs_zeitplan) setzt ihn als ersten Schritt jedes Zweigs, also auch dann, wenn der notify-Dienst des iPads fehlt. automation.esszimmer_bewegung (Blueprint freakshock88) ruft jetzt script.esszimmer_licht_bewegung statt direkt scene.esszimmer_lichter_bewegung: tagsüber die Szene wie bisher, im Nachtmodus Ensis und Wandlicht mit Helligkeit 8/255 (Ensis 2200 K). Die Zeitdauer des gedimmten Dashboards nachts ist die App-Einstellung „Zeit bis Start“ des Bildschirmschoners (plus Abklingzeit der Kamerabewegung) und gilt tags wie nachts; per Befehl nicht steuerbar.

Issues: homeserver#262 (Energie-Dashboard neu), homeserver#263 (Shellys absichern und einheitlich konfigurieren), beide unter E6 #189.

Robin bestätigt (10.10. abends): iPad-Einstellungen passen, Nachtlicht-Helligkeit passt.

Heizbeginn: Task 8/9 umgeschaltet (10.10.2026, 23:19)

Zentralheizung an (Robin, Heizkörper entlüftet, außen 9 °C). Entscheidung (Robin): alle Räume heute statt gestaffelt nach Plan, weil sonst niemand die übrigen Räume regelt (AHC seit dem Frühjahr aus, TRVs aus). Start in der Nachtruhe, also zuerst überall Eco.

Reihenfolge: 1. select.central_configuration_central_mode → Auto. 2. Bad: Profil erzwungen → heat, Eco 17 °C. 3. Abstellraum, Arbeitszimmer, Esszimmer, Küche, Schlafzimmer: Reset-Automationen aus (AHC war schon aus), switch.<raum>_heizung_window_detection aus, heizung_neu_<raum> an, Profil erzwungen. 4. Wohnzimmer: automation.wohnzimmer_reset_heizung aus (AHC, Better Thermostat und beide window_detection waren schon aus), heizung_neu_wohnzimmer an, Profil erzwungen. 5. Zentrale Konfiguration, Schritt „advanced“: repair_incorrect_state: true (gilt für alle 7, weil sie die zentralen Erweitert-Parameter nutzen; Entscheidung aus Task 13). Safety-Verzögerung blieb 180 min.

Prüfung 23:21 (Plan Task 8 Schritt 5 / Task 9 Schritt 4): Alle 7 Raumregler heat, Preset eco (Arbeitszimmer 17,5, sonst 17), is_ready, Block eco, keine Störung. Alle 8 TRVs heat auf dem Eco-Sollwert, Preset manual, Sensor external, Einspeisung ≈ Raumtemperatur (z. B. Abstellraum 18,84 bei 18,8; Wohnzimmer beide TRVs 19,66 bei 19,7). is_repair_incorrect_state_configured: true überall.

Offen aus Plan Task 8/9: Küche – Frage nach den Ventilator-Automationen für den Abbau (Task 14); Wohnzimmer Schritt 4 „ab 19:00 Block grund“ am 11.10. prüfen; Task 9 Schritt 5 (Batterie aus wohnzimmer_heizung_hinten) gehört zu den Abschlusstests mit Robin.

Task 14: Abnahmephase gestartet (10.10.2026)

Startdatum 10.10.2026, 23:19. Zwei Wochen beobachten (bis 24.10.2026): jede Störungsmeldung samt Ursache und jedes korrigierende Nachdrehen ins Log. Danach Abnahme durch Robin (und Lars zufrieden), erst dann Abbau.

Anpassungen nach dem Heizbeginn (10.10.2026, 23:30–23:45)

• Arbeitszimmer Eco 17 °C (vorher 17,5), von Robin selbst über number.heizung_arbeitszimmer_preset_eco_temp geändert. Robins erster manueller Test im Arbeitszimmer hat funktioniert (offenes Fenster 23:34 → Frostschutz 7 °C, Status „Fenster offen“).
• Schlafzimmer Eco = Frostschutz 7 °C (number.heizung_schlafzimmer_preset_eco_temp), Komfort bleibt 20 °C.
• Schlafzimmer bekommt Komfortblöcke (Robin): werktags 10:00–18:00, an freien Tagen ab Wach-Erkennung (spätestens Wochenende-Zeit minus Vorlauf übrige Räume) bis 20:00. Drei neue Helfer (Label heizung): input_datetime.heizung_schlafzimmer_komfort_ab (10:00), …_komfort_bis_werktag (18:00), …_komfort_bis_frei (20:00). Nachgezogen:
• script.heizung_raum_profil: Zweig schlafzimmer, Neustart-Schutz prüft jetzt 8 Uhrzeit-Helfer
• automation.heizung_tagesprofil: die drei Helfer als Auslöser
• sensor.heizung_zeitplan_schlafzimmer und sensor.heizung_naechster_zeitplan_schlafzimmer (nur Schlafzimmer; die anderen Räume sind unverändert)
• Abgleich Skript ↔ Zeitplan-Helfer: 2880 Fälle (jede Minute, Werktag und frei), 0 Abweichungen
• offen: die drei Uhrzeiten in der Einstellungsansicht des Dashboards
• Küchenventilator (switch.kueche_steckdose_ventilator, kleiner Ventilator am verbauten Heizkörper): automation.kueche_ventilator_an umgebaut zu „Küche: Heizungsventilator nach Heizplan“ — ein, solange climate.heizung_kueche heizt und der Zielwert ≥ Komfort-Temperatur ist (Komfort, Boost oder manuell höher; Fenster offen senkt auf Frostschutz), aus nach 10 min ohne diese Bedingung, Abgleich nach HA-Start. War bisher aus, jetzt an. automation.kueche_ventilator_aus gelöscht (Robins OK). Die Frage aus Plan Task 8 ist damit beantwortet: Der alte AHC-Zeitplan schedule.kueche_scheudler_heizung wird für den Ventilator nicht mehr gebraucht und kann in Task 14 mit weg.
• Dashboard-Rückmeldungen (Luftfeuchte auf den Raumkacheln, Thermostat-Karte in den Raumansichten verschoben, Lüftungshinweise zu lang) an einen Subagenten übergeben.
• Schlafzimmer am Wochenende (Robin, Nachtrag): Komfort ab wach, spätestens 11:00 (statt Wochenende-Zeit minus Vorlauf), bis 20:00; werktags unverändert 10:00–18:00. Vierter Helfer input_datetime.heizung_schlafzimmer_komfort_ab_frei (11:00); Skript (Neustart-Schutz jetzt 9 Helfer), Taktgeber und die beiden Schlafzimmer-Zeitplanhelfer nachgezogen, erneut 2880 Fälle ohne Abweichung. Dashboard: vier Schlafzimmer-Uhrzeiten in den Einstellungen; Zeitplan-Ansicht zeigt beim Schlafzimmer kein „warm um“ (galt nur für die anderen Räume).
• Dashboard-Subagent fertig: Raumkacheln zeigen Ziel und Luftfeuchte; Thermostat-Karte in den Raumansichten zentriert (die Karte setzt +/− fest auf 90 % der Breite, daher 22 px Versatz nach links) und gleich hoch wie der Verlauf (414 px); Lüftungs- und Aufheizhinweis auf Überschrift + eine Zeile gekürzt (Taupunkt entfällt). Backup vor den Änderungen: Session-Scratchpad dashboard-v2-backup-20261010-213445.json.
• Fund: Der Screenshot-Dienst rendert in UTC (Uhr und „jetzt“-Marke 2 h früher). Betrifft nur Screenshots, nicht das iPad. Folgepunkt: TZ=Europe/Berlin für ha-mcp-screenshot.

Nach zwei Zeitplan-Läufen (12.10.2026)

Robin: Der Zeitplan lief zweimal und bisher gut.

• Komfort-Temperaturen angehoben (Robin, 12.10. 13:36, über die Preset-Regler): Arbeitszimmer 21 → 22 °C, Bad 21 → 22 °C, Esszimmer 20 → 21 °C, Küche 21 → 21,5 °C. Unverändert: Abstellraum 20, Schlafzimmer 20, Wohnzimmer 20, Grundtemperatur Wohnzimmer 19, Eco überall 17 (Schlafzimmer 7).
• Küchenventilator „ging nicht aus“ (11.10.): Kein Fehler der Automation. Logbuch: Robin hat ihn um 22:49 per HomeKit ausgeschaltet. Bis dahin lief er, weil die Küche im neuen Plan bis zur Nachtruhe (23:00) auf Komfort stand; die Automation hätte ihn um 23:10 ausgeschaltet (Trace 23:10, aus-Zweig). Der alte AHC-Plan endete um 19:00 (werktags) bzw. 20:00. Entscheidung (Robin): Die Küche heizt früher herunter, der Ventilator folgt dem Komfort wie bisher. Neuer Helfer input_datetime.heizung_kueche_komfort_bis (20:00, täglich).
• Abstellraum bekommt einen Zeitplan (Robin): Komfort 20 °C mit denselben Uhrzeiten wie das Schlafzimmer (werktags 10:00–18:00, frei ab wach, spätestens 11:00, bis 20:00). Entscheidung (Robin): Außerhalb davon Eco 17 °C wie bisher, nicht Frostschutz. Vorher stand der Abstellraum den ganzen Tag auf Eco.
• Nachgezogen:
• script.heizung_raum_profil: Abstellraum nutzt den Schlafzimmer-Zweig, Küche endet um heizung_kueche_komfort_bis, Neustart-Schutz prüft jetzt 10 Uhrzeit-Helfer
• automation.heizung_tagesprofil: neuer Helfer als Auslöser
• sensor.heizung_zeitplan_{kueche,abstellraum} und sensor.heizung_naechster_zeitplan_{kueche,abstellraum}; der Abstellraum nutzt die Schlafzimmer-Vorlage
• Dashboard-Einstellungen: Zeile „Küche warm bis“, die Schlafzimmer-Zeilen heißen jetzt „Schlafzimmer + Abstellraum“
• Abgleich Skript ↔ Zeitplan-Helfer: 5760 Fälle (Küche und Abstellraum, jede Minute, Werktag und frei), 0 Abweichungen
• Wirkung geprüft: Taktgeber 16:35 → Abstellraum Block comfort, Raumregler und TRV auf 20 °C.
• Boost in jedem Raum und für alle (Robin): script.heizung_boost (Feld raum: ein Raum oder alle) arbeitet als Umschalter. Läuft in den gewählten Räumen ein zeitlich begrenztes Preset, bricht es ab (versatile_thermostat.cancel_timed_preset), sonst 30 min Boost per set_timed_preset für alle gewählten Regler im Modus heat. Test Abstellraum: Boost 24 °C bis 17:07, zweiter Aufruf → zurück auf Komfort 20 °C. Dashboard: Schnellaktion „Boost alle“ ersetzt „Boost Bad“ (zeigt „Läuft bis …, tippen: beenden“); jede Raumansicht hat unter „Übersteuerung“ den Knopf „Boost 30 Min.“ bzw. „Boost bis HH:MM“ neben „Zeitplan fortsetzen“ (neue Vorlage boost_raum). script.heizung_boost_bad wird nicht mehr benutzt; Löschen wartet auf Robins OK.
• Thermostat-Karte getauscht (Robin: „immer noch etwas verrückt“): Vergleich in einer vorübergehenden Testansicht, Robin wählt die eingebaute HA-Thermostatkarte mit Preset-Leiste (Frost/Eco/Komfort/Boost) statt custom:versatile-thermostat-ui-card. Rad auf 270 px Breite begrenzt, damit die Karte so hoch bleibt wie der Verlauf (414 px); der alte Versatz left: -22px entfällt. Ein/Aus steckt im Drei-Punkte-Menü. Die VTherm-UI-Karte (HACS) wird im Dashboard nicht mehr benutzt.
• Fehler bei mir, behoben: Den Helfer heizung_kueche_komfort_bis hatte ich mit initial: 20:00 angelegt; das hätte ihn bei jedem Neustart zurückgesetzt. Jetzt initial: "", laut Quellcode (if not config.get(CONF_INITIAL)) gleichbedeutend mit „letzten Wert wiederherstellen“, wie bei allen anderen Heizungs-Uhrzeiten.

Vorfall: Recorder „disk I/O error“ (12.10.2026, 16:39–16:45)

• Symptom: Ab 16:39:54 zeigte jeder Verlauf „Unable to load history“, im Systemlog sqlite3.OperationalError: disk I/O error beim Öffnen neuer Recorder-Verbindungen.
• Befund: Der HA-Prozess hielt home-assistant_v2.db-wal und -shm noch offen, beide waren aber gelöscht ((deleted) in /proc/<pid>/fd). Eine neue, leere WAL-Datei entstand um 16:39:54.062, der erste Fehler kam 4 ms später. Die Aufzeichnung lief in die gelöschte WAL weiter, neue Lese-Verbindungen scheiterten. Kein Platzmangel (18 % / 17 % belegt), keine Kernel-Meldungen zu Datenträgern, auf dem Host lief zu dem Zeitpunkt kein Timer und kein Container außer dem ohnehin minütlich neustartenden mqdockerup. Wer die Dateien entfernt hat, ist offen.
• Behebung: sauberer HA-Neustart (ha_restart, Robins OK) um 16:45; beim Herunterfahren wurde die WAL zurückgeschrieben. Danach -wal/-shm normal, Verlauf lückenlos, alle 7 Raumregler mit denselben Presets und Sollwerten wie vor dem Neustart, is_ready.
• Fund nebenbei: mqdockerup (micrib/mqdockerup:v1.23.8) startet jede Minute neu (Exit 1).

Aufräumen nach Robins OK (12.10.2026, 17:00)

• script.heizung_boost_bad gelöscht (vorher geprüft: keine Verweise mehr).
• HACS-Karte jmcollin78/versatile-thermostat-ui-card 3.4.0 deinstalliert, Ressource entfernt; vorher alle Dashboards durchsucht, keine Nutzung mehr.
• Altes Dashboard /smart-home-zentrale (v1) gelöscht, Robins Wunsch. Sicherung der Konfiguration auf dem NUC: /root/e6a-backups/dashboard-smart-home-zentrale-v1-20261012.json. v2 verwies nicht darauf.
• mqdockerup: wahrscheinliche Ursache ist speedtest-tracker-db, das mit einem Image ohne Tag läuft (nur ID 99d320a6265d). Issue homeserver#266, auf dem Board.

Dashboard-Rückmeldungen und Wetter-Eco (16.10.2026)

• Recorder-Vorfall zum zweiten Mal: Ab 14:55:52 wieder „Unable to load history“, Ursache wie am 12.10.: Der HA-Prozess hielt gelöschte home-assistant_v2.db-wal/-shm offen (diesmal gab es gar keine Datei auf der Platte mehr). Kein Host-Ereignis zu der Zeit; die Fehler treten erst auf, wenn eine neue DB-Verbindung aufgemacht wird (hier eine Verlaufsabfrage von Better Thermostat), die Löschung kann also früher gewesen sein. Hypothese, nicht belegt: Code im HA-Prozess öffnet und schließt die Datenbankdatei an SQLite vorbei (z. B. beim Backup, das täglich um 05:00 läuft); dadurch fallen die POSIX-Sperren der Recorder-Verbindungen weg, und eine später schließende Verbindung räumt -wal/-shm als vermeintlich letzte ab. Neustart 18:22 mit Robins OK; Verlauf danach lückenlos, alle Räume unverändert.
• Beobachter: /root/ha-wal-watch.py als vorübergehende Unit ha-wal-watch.service (systemd-run, überlebt keinen NUC-Neustart). Prüft alle 5 s, ob -wal/-shm existieren und ob ein Prozess gelöschte Handles hält, und schreibt jede Änderung samt Prozessliste nach /var/log/ha-wal-watch.log. Stoppen: systemctl stop ha-wal-watch.
• iPad Esszimmer (Robin: Bewegungserkennung unzuverlässig, lieber strikt nach Zeitplan): neue automation.ipad_esszimmer_display_nach_uhrzeit. 07:00–23:00 Bildschirmschoner gedimmt auf 10 %, bei Berührung 70 %; 23:00–07:00 schwarz, bei Berührung 50 %. Stündlich (:17) werden Modus und Helligkeiten erneut gesendet, ohne den Bildschirmschoner ein- oder auszuschalten; 03:30 Neuladen wie bisher. Die alte Automation heißt jetzt automation.nachtmodus_nach_heizungs_zeitplan und setzt nur noch input_boolean.nachtmodus für das Esszimmerlicht. In der App stellt Robin ein: „Zeit bis Start“ 2 min (gilt tags und nachts, per Befehl nicht steuerbar), „Bei Kamerabewegung aufwecken“ aus.
• Boost alle zeigte falschen Zustand (bei nur einem geboosteten Raum stand „alle“ auf aktiv, ein Tipp hätte den Raum-Boost abgebrochen): script.heizung_boost bricht bei alle nur noch ab, wenn alle heizenden Räume boosten, sonst boostet es die übrigen. Die Kachel zeigt „Boost läuft in Bad · tippen: alle boosten“ und ist nur aktiv, wenn alle boosten. Test mit dem Bad bestanden, Boost danach abgebrochen.
• Eco bei warmem Wetter (Robin): neuer Regler input_number.heizung_aussen_eco_ab (17 °C, Dashboard → Einstellungen) und Template-Binärsensor binary_sensor.heizung_draussen_warm (an ab Schwelle, aus erst 1 K darunter; Quelle sensor.openweathermap_temperature, ohne gültigen Wert bleibt der letzte Zustand). Entscheidung (Robin): alle Räume, auch das Bad. script.heizung_raum_profil setzt bei warm Block eco (nach Abwesend, vor dem Zeitplan; Halten und 2-h-Übersteuerung gelten weiter), Taktgeber reagiert sofort auf den Sensor. Die 14 Zeitplan-Helfer zeigen „Draußen warm · Eco bis es abkühlt“ bzw. eine durchgehende Eco-Zeile für heute. Aktiv seit 18:30 (außen 17,9 °C): alle 7 Räume Eco.
• Kopfzeile „Start“ auf dem iPad: Dashboard-Konfiguration kiosk_mode: kiosk: [[[ user_name … === 'wandtablet' ]]] (HACS kiosk-mode 14.2.1 war schon installiert) blendet Kopfzeile und Seitenleiste nur für den Benutzer Wandtablet aus; andere Geräte behalten sie. Notausgang: ?disable_km an die URL hängen.

W100 Arbeitszimmer und iPad-Dimmstufe (16.10.2026, abends)

• W100 zeigt und stellt den Sollwert (Robin): neue automation.w100_arbeitszimmer_sollwert_mit_heizung_abgleichen. Der W100 (Thermostat-Modus, virtueller Thermostat climate.arbeitszimmer_w100 von Z2M) stand auf cool mit 15 °C und war nicht verbunden. Jetzt: Sollwert von climate.heizung_arbeitszimmer → mittlere Zeile des W100 (Modus heat, bei ausgeschalteter Heizung off), bei jeder Änderung, nach HA-Start und alle 30 min. Tasten am W100 → PMTSD_from_W100_Data → Sollwert als manuelle Änderung an den Raumregler (gilt bis zum nächsten Blockwechsel). Keine Schleife, weil der W100 nur bei Tastendruck meldet. Der W100 zeigt nur ganze Grad (Firmware schneidet ab). Die zweite Zeile (Außentemperatur, automation.w100_externe_temperatur_feuchtigkeit_aktualisieren) bleibt. Robin hat die Tasten getestet, Trace bestätigt.
• iPad-Dimmstufe tagsüber 25 % statt 10 %: Robin meldete „Display einfach aus“. Laut App lief der Bildschirmschoner korrekt im Modus gedimmt an (18:43), 10 % wirkt beim dunklen Dashboard aber wie aus. 25 % war der zuvor bestätigte Wert.
• Auffällig, offen: Ab 18:30 misst die Shelly-Steckdose des iPad-Ladegeräts 0 W, während das iPad bei 40 % „Charging“ meldet. Wird beim Ladeverlauf-Check (Task 12, Schritt 4) angesehen.

iPad-Hintergrundlicht und Zigbee-Störung (16./17.10.2026, nachts)

• iPad nachts nicht wirklich dunkel: Der schwarze Bildschirmschoner lässt die LCD-Hintergrundbeleuchtung an (Sensor sensor.ipad_esszimmer_kiosk_brightness meldete 50 %). Laut Quellcode der App senkt der Bildschirmschoner die echte Beleuchtung nur, wenn in der App unter Bildschirmschoner der Schalter „Dimmen“ an ist (per Befehl nicht schaltbar); die Stufe ist dann der Wert aus kiosk_set_screensaver_brightness. Robin hat den Schalter eingeschaltet, automation.ipad_esszimmer_display_nach_uhrzeit setzt nachts zusätzlich kiosk_set_screensaver_brightness 0. Ergebnis: Beleuchtung im Bildschirmschoner 23:37–00:43 durchgehend 0 % (Robin: „viel besser“). Folgen und offene Punkte:
• Tagsüber wirkt der gedimmte Bildschirmschoner jetzt dunkler, weil 25 % nun echtes Licht und Abdunklung zugleich sind → mit Robin prüfen, ggf. 40–45 %.
• Nach dem Aufwecken kommt nachts 70 % statt 50 %: Die App merkt sich beim Start des Bildschirmschoners die Helligkeit davor, kiosk_set_brightness während des Bildschirmschoners ändert diesen Wert nicht. Abhilfe (50 % nach dem Aufwecken nachschicken) tagsüber testen.
• 0 % ist beim LCD nicht schwarz. Ganz aus ginge nur mit Sperren (Kurzbefehl „Bildschirm sperren“), dann kommen aber keine HA-Befehle an. Entscheidung (Robin): erst die nächtliche Akku-Entladerate vorher/nachher auswerten.
• Störung Arbeitszimmer: Das Ventil arbeitszimmer_heizung (Aqara E1) nahm ab 16.10. 16:35 keine Befehle mehr an (Z2M Timeout after 10000ms, 56 Fehler; von 16.09. bis 16.10. kein einziger), meldete aber weiter Werte. Es blieb auf 22 °C statt Eco 17 °C, die Zustellprüfung setzte um 23:06 input_boolean.heizung_stoerung_arbeitszimmer und schickte den Push. Nach dem Z2M-Neustart hingen Befehle und Reconfigure ohne Rückmeldung. Laut Fable ist das so gewollt: Das E1 hat ein Check-in-Intervall von 1 h, und so lange warten gescheiterte Befehle in der Warteschlange von zigbee-herdsman. Wahrscheinliche Ursache ist ein veralteter Parent bzw. eine veraltete Route. Lösung: Robin hat die Batterie kurz entnommen (17.10. ~00:40), danach übernahm das Ventil 17 °C.
• Notbetrieb Esszimmer: esszimmer_sensor_luft ist seit ~18:48 stumm (Akku zuletzt 90 %). Ab 21:53 regelt der Raum mit dem Fühler am Ventil, wie vorgesehen. Robin tauscht die Batterie.
• Ping-Flut in Z2M: Die Router-Steckdose steckdose_wohnzimmer_sideboard ist seit ~10.09. weg. Ab 15.10. 14:26 hat Z2M sie alle ~12 s angepingt (~7000 Fehlversuche/Tag). Robin hat sie entfernt, die Pings liefen unter der IEEE-Adresse weiter (Availability-Bug Koenkk/zigbee2mqtt#32936, behoben ab 2.14.1, wir haben 2.12.0). Robin hat Z2M um 23:52 neu gestartet, danach war Ruhe. Ob die Flut den Ventilausfall ausgelöst hat, ist nicht belegt.
• Folge-Issue: homeserver#267 (Zigbee-Netz stabilisieren, Routen analysieren, Z2M-Update), auf dem Board.

Zigbee-Netz, Z2M 2.14 und iPad-Akku (17.10.2026, nachmittags)

• Z2M 2.12.0 → 2.14.2 (homeserver#268): Die Release Notes 2.12.1–2.14.2 enthalten keine Breaking Changes für Docker und nichts zum E1. Der Ping-Bug ist schon in 2.14.0 behoben (Koenkk/zigbee2mqtt#32937). Renovate hielt den Update-PR wegen seines PR-Limits zurück. Vorher gesichert: Konfiguration, Datenbank, Koordinator-Backup, state.json (NUC /root/e6a-backups/z2m-pre-2.14-20261017-1733). Neustart 17:33, danach in allen 7 Räumen gleicher Sollwert an Raumregler und Ventil, kein Fehler im Log. kueche_steckdose_kaffee ist seitdem wieder online.
• Netzkarte (raw, mit Routen, Robins OK): 73 Geräte, davon 32 Router und 41 Endgeräte.
• Die Ventile hängen an Routern im selben oder im Nachbarraum, mit guter Verbindung (LQI 157–255): Arbeitszimmer → Hue Stehlampe (255), Abstellraum und Bad → Hue-Steckdose Druckerlicht (214/208), Esszimmer → Hue Tisch (253), Küche → Hue Schrank (252), Schlafzimmer → Hue Malm (252), Wohnzimmer hinten → Hue Leiste (231), vorne → Innr-Steckdose Lego (157).
• Kein Router stammt von einem Hersteller, mit dem ältere Aqara-Sensoren laut Z2M-Doku Probleme haben (Centralite, GE, Iris, Ledvance/OSRAM, Legrand, SmartThings, Securifi, Sylvania). Im Netz sind Hue, Aqara-Steckdosen, IKEA-Luftsensoren, Innr und Nous.
• Die schwächsten Strecken haben Fenstersensor Arbeitszimmer rechts (68), Lichtschalter Schlafzimmer (65) und IKEA-Knopf (84), alle weit über der Schwelle „schwach“ (< 20). Jeder Raum hat genug Router; die entfernte Sideboard-Steckdose hinterlässt im Wohnzimmer (10 Router) keine Lücke.
• Innr SP 240 und Nous A7Z liefern keine Routentabelle (Fehlermeldung beim Abruf, harmlos).
• Ausfall vom 16.10. bleibt ohne belegte Ursache: Das Log (Stufe info) zeigt um 16:35 weder einen Router-Ausfall noch ein Neuanmelden. Fast alle Fehler am Ventil waren „Request superseded“: Befehle warteten in der Warteschlange und wurden vom jeweils nächsten ersetzt. Der Esszimmer-Luftsensor kam am 17.10. um 13:25 mit der alten Batterie (2985 mV) zurück, die neue (3185 mV) folgte um 14:15. Beide Ausfälle endeten also mit einem Neuanmelden, das passt eher zu einem veralteten Parent als zu einer leeren Batterie. Seit 17.10. 00:40 gab es keinen Schreib- oder Zustellfehler mehr. Neu anlernen ist deshalb nicht nötig, das Debug-Log blieb aus.
• Altlasten im Broker: Die gespeicherten „offline“-Meldungen der entfernten Geräte steckdose_wohnzimmer_sideboard, arbeitszimmer_steckdose_entfeuchter und arbeitszimmer_steckdose_oculus sind gelöscht. Tatsächlich offline sind noch abstellraum_sensor_luft_box1 (seit 16.09.), abstellraum_sensor_luft_box2 (seit 12.05.) und kueche_sensor_wasser_waschmaschine (seit 11.12.2025), siehe homeserver#237.
• Koordinator-Firmware: Z-Stack 3.x.0 vom 16.07.2024. Die neuere 20250321 bringt nur Korrekturen bei BUFFER_FULL und ein SDK-Update, kein Anlass zum Flashen während der Abnahme.
• iPad-Akku: Der Schutz griff nachts nicht. Den Akkustand meldet die App nur, solange sie aktiv ist; im Bildschirmschoner bleibt der Sensor still auf dem letzten Wert stehen. Am 17.10. kam um 00:43 50 %, der nächste Wert um 12:17 war 1 %, das Ladegerät war seit 16.10. 20:02 aus. Der Zweig „eine Stunde kein Akkustand → laden“ reagierte nur auf unavailable/unknown. Jetzt prüft automation.ipad_esszimmer_akku_schutz stündlich (:07) auch, wann zuletzt ein Wert kam (last_reported); liegt das über 1 h zurück, schaltet das Ladegerät ein. Aus geht es erst wieder, wenn ein Wert über 80 % ankommt. Folge: Nachts lädt das iPad, voraussichtlich bis 100 %.
• Entladerate nachts, grob: Belastbar messen lässt sie sich so nicht, weil im Bildschirmschoner keine Werte kommen. Vorher (13./14.10., ohne „Dimmen“): 85 % → 15 % in 10 h, etwa 7 %/h. Nachher (16./17.10.): Die 50 % von 00:43 reichten bis 12:17 (1 %), darin gut 5 h Tagbetrieb. Bei etwa 7 %/h tagsüber (15.10.: 95 % → 10 % in 12 h) bleiben für die Nacht rund 2 %/h. Das Ladegerät liefert höchstens 6,7 W; mit Display an steigt der Akku nur um etwa 8 %/h.
• Nach dem Aufwecken nachts 50 %: Neuer Auslöser in automation.ipad_esszimmer_display_nach_uhrzeit, Bildschirmschoner on → off. Zwischen 23 und 7 Uhr wird kiosk_set_brightness 50 nachgeschickt, sonst passiert nichts. Wirkung beim nächsten nächtlichen Aufwecken prüfen, dabei auf Bestätigungsmeldungen der App achten.
• Tag-Dimmstufe: Entscheidung (Robin): bleibt bei 25 %.
• Geräte entfernt (Robins OK, 17.10. abends): die drei namenlosen Geräte (Philips 929002398602, IKEA E1812, Aqara PS-S04D) und beide Wassersensoren (kueche_sensor_wasser_spuelmaschine, kueche_sensor_wasser_waschmaschine, „aktuell ohne Funktion“). Das normale Entfernen scheiterte bei allen fünf (mgmtLeaveRsp nach 10 s, Batteriegeräte schlafen), daher force. Die gespeicherten Verfügbarkeitsmeldungen im Broker sind gelöscht, HA hat die Entitäten mit entfernt. automation.kueche_wasseraustritt ist abgeschaltet (nicht gelöscht), auf dem Dashboard „Gerätezustand“ ist die Kachel „Wasser Spülmaschine“ entfernt, die Überschrift heißt jetzt „Rauch“. Die beiden Abstellraum-Luftsensoren (Box 1/2) bleiben (Robin), sind aber weiter offline.

Recorder-Vorfall Nr. 3 gelöst, Klingel, Nachtruhe Mo–Do (20./21.10.2026)

• Recorder disk I/O error (20.10. 11:00), Ursache belegt: ha-wal-watch zeigt, dass am 18.10. um 02:13 WAL und SHM der HA-Datenbank unter dem laufenden HA verschwanden, und zwar während des borgmatic-Hooks predeploy-backup.sh, der die DB mit sqlite3 .backup von außen öffnete. Seitdem schrieb HA in gelöschte Dateien, bis eine neue Verbindung am 20.10. den Fehler auslöste. Gelöschte Dateien gesichert (/root/e6a-backups/wal-vorfall3-20261020-1104), HA-Neustart 11:05. Fix: HA-DB aus dem sqlite3-Backup genommen (homeserver#272); gesichert bleibt sie über die wöchentlichen HA-Backups und als Datei im Borg-Archiv. Nacht 20./21.10. sauber, ha-wal-watch am 21.10. beendet (Log /root/e6a-backups/ha-wal-watch-final-20261021.log). Regel: Die laufende HA-DB öffnet außer HA niemand per SQLite, auch nicht lesend.
• Klingel aufs iPad (homeserver#275): Die Echtzeit-Ereignisse von Ring waren seit über einem Jahr tot (firebase-messaging 0.4.5, home-assistant/core#157764), die neue Haustür-Klingel (doorbell_sunray) kannte HA nicht. Eigene Integration ring_fixes (homeserver#273, #274, zweimal von Fable reviewt) patcht beides zur Laufzeit. Test 20.10.: Ereignisse kommen in HA sekundengenau an, HA schickt die Mitteilung nach 0,3 s. automation.klingel_ipad_esszimmer_laeuten: kritische Mitteilung bei Haustür und Intercom. Robin hörte nur den kurzen Systemton → eigener Gong klingel-gong.wav (Ding-Dong, 7 s, /local/klingel-gong.wav), von Robin in der HA-App importiert; Test 22.10. 20:15 an der Haustür: Gong klingt (Robin). Am Intercom kommt die Mitteilung einige Sekunden später, die Verzögerung liegt im Push-Dienst von Apple, nicht in HA.
• iPad-Nachtmodus: Entscheidung (Robin 21.10.): passt so („funktioniert wirklich super“), der Test mit geführtem Zugriff entfällt.
• Nachtruhe Mo–Do 22:00 (Robin 21.10.): neuer Helfer input_datetime.heizung_nachtruhe_mo_do (22:00). script.heizung_raum_profil, Taktgeber und die 14 Zeitplan-Anzeigen rechnen die Nachtruhe jetzt pro Wochentag: Mo–Do ab 22:00, Fr–So weiter ab heizung_nachtruhe (23:00). Dieser Helfer steuert weiterhin den Nachtmodus von Licht und iPad, der bleibt bei 23:00. Neustart-Schutz jetzt 11 Helfer. Die Zeitplan-Karte zeigt in der allgemeinen Zeile „Werktag“ 22:00, der Freitag (23:00) ist dort nicht eigens abgebildet; die Zeile für heute ist exakt. Einstellungen: neue Zeile „Nachtruhe Mo–Do“, die alte heißt „Nachtruhe Fr–So“. Alte Vorlagen gesichert (/root/e6a-backups/zeitplan-templates-vor-nachtruhe-mo-do-20261021.json).
• Abstellraum (Robin 21.10.): Komfort werktags 19 °C, Wochenende und Feiertage 20 °C über automation.heizung_abstellraum_komfort_nach_werktag (setzt number.heizung_abstellraum_preset_comfort_temp). Zeiten unverändert, heute sofort auf 19 °C übernommen.

Task 14, Schritt 2: Abnahme (24.10.2026)

Robin hat am 24.10.2026 abgenommen (Kommentar in homeserver#185). Das eine korrigierende Eingreifen (Batterie Arbeitszimmer, 17.10.) hält die Abnahme laut Robin nicht auf. Lars ist bisher zufrieden, später noch einmal nachfragen.

Sichtung der Störungen

• Der Recorder reicht 10 Tage zurück (ab 14.10.). In dieser Zeit gab es genau zwei Störungen, beide gemeldet:
• Arbeitszimmer-Ventil: heizung_stoerung_arbeitszimmer war am 16.10. zweimal an, 18:36–20:44 und 23:06 bis 17.10. 00:45 (im Eintrag vom 16./17.10. stand nur das zweite Mal)
• Notbetrieb Esszimmer 16.10. 21:53 bis 17.10. 12:35
• Z2M-Log seit dem Update auf 2.14.2 (17.10. 17:33): kein Schreib- oder Zustellfehler an einem Ventil. Weiter auffällig ist nur kueche_steckdose_kaffee mit 5–21 gescheiterten Pings pro Tag (keine Heizung, Folgepunkt „umstecken testen“).
• Die Heizungs-Pushes gehen an notify.mobile_app_robins_iphone, den Dienst gibt es. Fund nebenbei: Die Energie-Meldungen in packages/energy_monitoring.yaml rufen das nicht mehr vorhandene notify.mobile_app_robin auf und kommen nie an, siehe homeserver#262.
• Zeitplan 17.–24.10. ohne Abweichung: Wohnzimmer täglich 19:00 grund, Nachtruhe Mo–Do 22:00 und Fr 23:00, Küche 20:00 Eco, Schlafzimmer und Abstellraum werktags 10–18, Wochenende ab 11. Manuelle Eingriffe (Wohnzimmer 20.10., 22.10. und 23.10. abends, Schlafzimmer 20. und 21.10.) waren laut Robin lange Abende, kein Fehler.
• valve_alarm: wechselt bei allen 8 Ventilen zwischen an und aus. Laut Z2M-Doku meldet er eine „Temperaturregel-Abweichung“ (Ventil falsch montiert, Ventil defekt oder falsch kalibriert, Verbindung zum externen Fühler gestört), ist also ernst zu nehmen. Siehe „Abstellraum heizt nicht nach“ weiter unten.

T7 Batterie

• Bad-Ventil: stabil um 93,5 % bis 08.10., seit Beginn der Einspeisung etwa 1,2 Prozentpunkte pro Tag weniger (24.10.: 74 %). Hält die Rate, ist der Akku etwa Mitte Dezember leer. Küche etwa 0,7, Esszimmer, Abstellraum und Schlafzimmer etwa 0,4 Punkte pro Tag; Arbeitszimmer und Wohnzimmer melden konstant 100 %.
• Sendungen pro Tag (Änderungen von input_number.heizung_gesendet_<raum>, 17.–23.10.): Bad 52, Arbeitszimmer 73, die übrigen 42–47. Richtwert im Plan ≤ 50. Das Arbeitszimmer sendet am meisten bei 100 %, die Zahl der Sendungen erklärt den Verbrauch also nicht sicher; wahrscheinlicher ist die Arbeit des Ventilmotors (Bad heizt den ganzen Tag auf Komfort).
• Entscheidung (Robin): Sendeschwelle fürs Bad 0,3 K, übrige Räume bleiben bei 0,2 K. Umgesetzt in automation.heizung_e1_einspeisung (Variable schwellen). Batterie weiter beobachten.

Rückmeldungen und Änderungen

• Bad Komfort 22 → 21,5 °C (Robin), über number.heizung_badezimmer_preset_comfort_temp; Raumregler und Ventil haben 21,5 übernommen.
• Robin: Arbeitszimmer tagsüber etwas warm (Technik im Raum), Schlafzimmer und Wohnzimmer zu kalt. Im Wohnzimmer kommt ein W100 an eine andere Stelle (Robin). Nachtruhe Mo–Do 22:00, Abstellraum 19/20 °C, Bad ganztags, Küche bis 20:00 und Küchenventilator passen.
• Gemessen (Stundenmittel 21.–24.10.): Wohnzimmer morgens 19,0–19,5 °C, 20 °C erst gegen 11–12 Uhr (Komfort ab 08:30), nachmittags 20,5–21,9, nach 19:00 fallend auf etwa 20 bis 22:00. Schlafzimmer während Komfort 20,0–21,0, abends und nachts 18,7–19,7.
• iPad nachts schwarz, aber hell (Robin, Nacht 23./24.10.): Das stündliche Auffrischen (:17) schickt kiosk_set_brightness, und das hebt die Hintergrundbeleuchtung im laufenden Bildschirmschoner sofort auf diesen Wert. Belegt durch sensor.ipad_esszimmer_kiosk_brightness: nachts nach jedem :17 auf 50 %, tagsüber ab 07:17 auf 70 % statt 25 %. Beim Wechsel um 23:00 trat das nicht auf, weil danach kiosk_show_screensaver die Bildschirmschoner-Helligkeit neu anwendet. Fix: Das Auffrischen schickt bei laufendem Bildschirmschoner jetzt auch kiosk_show_screensaver. Test 17:17: Beleuchtung 70 → 25 %. Nachtfall in der nächsten Nacht prüfen. Nebenbei: Der Akku fiel in dieser Nacht 22:00–01:11 von 55 auf 15 %, das Ladegerät schaltete um 01:13 ein.
• Entscheidungen (Robin 24.10.), umgesetzt: Arbeitszimmer Komfort 22 → 21,5 °C (der W100 zeigt ganze Grad, also 21). Schlafzimmer Komfort 20 → 21 °C, weil es tagsüber zu kalt ist; ab 18:00 bleibt Eco (Frostschutz). Abstellraum unverändert, er hat einen eigenen Regler. Wohnzimmer: Morgens spielt keine Rolle, abends soll es länger warm bleiben, Komfort bleibt 20 → input_number.heizung_wohnzimmer_grundtemperatur 19 → 20 °C, damit hält der Block grund ab 19:00 die 20 °C bis zur Nachtruhe. Weitere Anpassungen erst, wenn der W100 im Wohnzimmer an seinem neuen Platz hängt.

Task 14, Schritt 3 und 4: Abbau (24.10.2026)

Alles mit Robins OK, vorher HA-Backup vor-e6a-abbau-2026-10-24 (ID 440ddd89, 106 MB). Die Bestandsaufnahme samt Verbraucherprüfung je Entität hat ein Subagent nur lesend erstellt (ha-mcp-Suche und Grep über die HA-Konfiguration). Kein neuer Heizungsbaustein und kein Dashboard v2 nutzte eine der Altlasten.

• Fund vorher: Better Thermostat (climate.wohnzimmer_heizung) lief noch auf heat an denselben beiden Wohnzimmer-Ventilen wie der neue Regler. Er folgte nur den Sollwerten (19:00: 20 → 19 °C wie der neue Regler), plante aber eigene Ventilwartungen. Deshalb kam er zuerst weg.
• Gelöscht per ha-mcp:
• Better-Thermostat-Eintrag samt 15 Unterentitäten, HACS-Komponente KartoffelToby/better_thermostat 1.9.3
• HACS-Karte nervetattoo/simple-thermostat samt Ressource, ungenutzt
• die 7 AHC- und 7 Reset-Automationen, automation.kueche_wasseraustritt (ohne Sensor), danach der Blueprint panhans/advanced_heating_control.yaml
• Dashboard „Heizung“ (lovelace-heizung), Template-Helfer sensor.next_schedule_wohnzimmer (las falsch verdrahtet den Arbeitszimmer-Zeitplan)
• 51 Helfer: 21 input_number (*_number_comfort_temperatur, …_weekend, …_eco_temperatur), 16 input_boolean (*_toggle_party_mode, *_toggle_max_heat, general_toggle_wintermode, general_toggle_guest), 7 input_button (*_button_heizung_reset), 7 schedule.*_scheudler_heizung
• HomeKit-Bridge „HomeAssistant Button:21067“ (gab die alten Reset-Knöpfe an Apple Home, keine YAML-Quelle mehr)
• Gelöscht auf dem NUC (Robins OK, Sicherung mit gleicher Prüfsumme unter /root/e6a-backups/yaml-vor-abbau-20261024/): packages/heating.yaml (die 7 Urlaubs-Zeitpläne *_holiday) und das nicht eingebundene schedule.yaml im Config-Hauptverzeichnis.
• Bleibt: die Migrationsschalter input_boolean.heizung_neu_* (Notschalter je Raum).
• Prüfung (Schritt 4): Konfigurationsprüfung gültig, HA-Neustart 19:00 mit Robins OK. Danach alle 7 Raumregler is_ready mit unveränderten Presets und Sollwerten, im Log keine Verweise auf gelöschte Entitäten, keine verwaisten Registry-Einträge zu Better Thermostat, keine Automation unavailable.
• Climate-Bridge entfernt (Robin will die Heizungen nicht mehr in Apple Home): Wirksam war packages/homekit.yaml (über packages: !include_dir_named packages). Robin hatte die Bridge zunächst aus der nicht eingebundenen, veralteten homekit.yaml im Config-Hauptverzeichnis genommen und dort auch vier Steckdosen gestrichen, die es in HA nicht mehr gibt (Oculus, Heizmatte, Ladestation, Mücken-Stecker). Beides ist nach packages/homekit.yaml übernommen; Pflanzenlampe, Lego und Drucker Licht aus der alten Kopie bleiben draußen (Robin). Die Datei im Hauptverzeichnis ist gelöscht. Sicherungen in /root/e6a-backups/yaml-vor-abbau-20261024/ (packages-homekit.yaml, root-homekit-robin-1858.yaml). Eintrag 01JG7RT283VWN43G6MWBRJWN6V gelöscht, homekit.reload: Bridges Power (7 Steckdosen), Fan und Licht laufen, kein Fehler im Log. In der Home-App bleibt die Bridge „HomeAssistant Climate“ als nicht erreichbar stehen, bis Robin sie dort entfernt.
• Nebenfunde: Die Reparaturmeldung „notify.mobile_app_ipad_esszimmer nicht gefunden“ für automation.ipad_esszimmer_display_nach_heizungs_zeitplan stammt vom 10.10. und ist veraltet (Automation inzwischen umbenannt). 241 alte Registry-Einträge (Sonos, thermal_comfort u. a.) gehören zu homeserver#258. Hue-Dimmer Schlafzimmer seit 21.10. offline, „Hue An“/„Hue Aus“ in packages/schlafzimmer_schalter.yaml nutzen alte Geräte-Auslöser.

Abschlusstests entfallen, Abstellraum heizt nicht nach (24.10.2026, abends)

• Entscheidung (Robin): Die gesammelten Abschlusstests (T3, T4, T5, T8, Ventil-Ausfall Wohnzimmer, Alle Eco/Abwesend/Boost, Fenster in Übersteuerung, Neustart mit Übersteuerung) entfallen. Es läuft im Alltag gut, Robin meldet sich, wenn ihm etwas auffällt. #237 bleibt damit offen, T8 ist nicht gelaufen.
• iPad nachts: Robin bestätigt, das Display ist jetzt wirklich dunkel. Ob es nach dem Auffrischen um :17 dunkel bleibt, ist noch nicht im Verlauf geprüft.
• Abstellraum heizt nicht nach (Robin: „eine Temperatur ist nicht angekommen, keine Fehlermeldung“): Das Ventil hat jeden Sollwert pünktlich übernommen (Z2M-Zustand 10:00 auf 19/20 °C, 18:00 auf 17 °C, kein Schreibfehler), die Zustellprüfung hatte also nichts zu melden. Der Raum zog aber nicht nach: am 22.10. blieb er von 10:00 bis 12:40 bei 17,3–17,4 °C (Soll 19), erst nach einem Hochdrehen von Hand auf 20 °C stieg er; am 21.10. blieb er von etwa 12 bis 15 Uhr bei 18,2 °C (Soll 20). In genau dieser Zeit stand binary_sensor.abstellraum_heizung_valve_alarm durchgehend an (20.10. bis 22.10. 16:41). Am 23. und 24.10. erreichte der Raum sein Soll. Lücke: Die Zustellprüfung prüft nur, ob der Befehl ankommt, nicht, ob der Raum warm wird.
• Kalibriert (Robins OK, 24.10. 23:11): die vier Ventile mit Ventilalarm, abstellraum_heizung, arbeitszimmer_heizung, esszimmer_heizung, wohnzimmer_heizung_hinten, über button.<ventil>_calibrate. Danach alle calibrated: on, Sollwerte unverändert, valve_alarm steht vorerst weiter an (beim nächsten Heizen beobachten). Robin prüft den Abstellraum-Heizkörper zu Beginn der nächsten Komfortphase (warm? entlüften?).
• Neuer Wächter automation.heizung_raum_heizt_nicht_nach (Robin: gleich bauen): meldet einmal je Vorfall per Push und als Benachrichtigung in HA, wenn ein Raum im Heizbetrieb mehr als 1 K unter dem Sollwert liegt und in den letzten 90 min um weniger als 0,2 K wärmer wurde, 60 min lang ununterbrochen. Sollwerte unter 15 °C (Fenster, Frostschutz, Sommer), Notbetrieb und Wartung zählen nicht. Den Anstieg liefern sieben neue Statistik-Helfer sensor.heizung_anstieg_90_min_<raum> (Merkmal change, 90 min, Label heizung). Entscheidung: Eine reine Schwelle (1,5 K unter Soll, 2 h) hätte jeden Morgen gemeldet, weil Bad und Küche nach Eco 17 °C rund 2,5 h zum Aufheizen brauchen; sie steigen dabei aber um gut 1 K/h. Rückblick: Der 22.10. im Abstellraum (17,3 → 17,4 °C in 2,5 h) wäre gegen 11:00 gemeldet worden, das morgendliche Aufheizen nicht. Bei Fehlalarmen Schwellen nachziehen.

Task 15: Betriebsdoku (24.10.2026)

• Neue Seite Heizung unter Homeserver → Smart Home: Aufbau, Räume und Temperaturen, Zeitplan mit allen Helfern, Bausteine (Automationen, Skripte, Helfer), Bedienung, Meldungen und was tun, Raum aus der Steuerung nehmen, Rückweg über die Backups, Fallstricke, Offenes. Stand und Werte aus HA vom 24.10.2026 abgelesen, nicht aus dem Plan.
• Abweichung vom Plan: Der Rückweg „Raum zurück auf AHC“ entfällt, weil AHC abgebaut ist. Die Doku beschreibt stattdessen, wie man einen Raum aus der Steuerung nimmt (Notschalter, Raumregler aus, Ventil auf internal) und welche Backups einen kompletten Rückweg erlauben.
• mkdocs build ohne Warnungen zur neuen Seite.