Dokumentation

Das Große Ganze 

Statt isolierter Thermostate, die blind vor sich hin heizen, haben wir ein „zentrales Gehirn“ für die Schule entwickelt. Das System funktioniert im Kern wie ein intelligenter Hausmeister, der jeden Raum einzeln überwacht:

1.      Der Stundenplan-Modus: Das System weiß dank einer digitalen Tabelle (Google Sheets/CSV) genau, wann in welchem Raum Unterricht stattfindet. Es berechnet selbstständig die nötige Vorheizzeit, sodass der Raum pünktlich zur ersten Stunde warm ist. Ist der Raum nach dem Unterricht leer, wird die Temperatur automatisch abgesenkt.

2.      Die Fenster-Automatik: Wird ein Fenster zum Lüften geöffnet, registriert das System dies sofort und dreht das Heizkörperventil rigoros zu (Frostschutz). So wird nicht sprichwörtlich "zum Fenster hinaus" geheizt.

3.      Der automatische Reset: Lehrkräfte können die Temperatur jederzeit am Wandthermostat im Raum manuell anpassen. Um jedoch dauerhafte Energieverschwendung zu verhindern, setzt das System jede Nacht um Mitternacht alle manuellen Änderungen zurück. Am nächsten Morgen startet das Gebäude wieder streng nach dem effizienten Stundenplan.

Nutzerrollen: Wer macht was?

Das System ist so gestaltet, dass es im Hintergrund unsichtbar arbeitet, aber bei Bedarf für verschiedene Nutzergruppen zugänglich ist:

·         Lehrkräfte & Schüler (Lokale Bedienung): Interagieren ganz natürlich mit dem Raum. Sie lüften bei Bedarf oder passen die Temperatur über das physische Rädchen am Wandthermostat an. Sie müssen keine App bedienen.

·         Hausmeister / Gebäudemanagement (Zentrale Steuerung): Haben über Home Assistant den kompletten Überblick. Sie können Raumtemperaturen, Luftfeuchtigkeit und CO₂-Werte zentral ablesen und auf Knopfdruck ganze Gebäudeteile in den „Ferienmodus“ schicken.

·         Schulverwaltung (Planung): Pflegt ganz einfach eine Online-Tabelle (Google Sheet) mit den aktuellen Unterrichtszeiten. Das System synchronisiert diese Daten automatisch im Hintergrund.

Aufbau des Python Skripts

Obwohl Home Assistant eigene Automatisierungsmöglichkeiten bietet, wurde sich bewusst für ein externes, zentrales Gehirn in Form eines objektorientierten Python-Skriptes entschieden. Dies ermöglicht eine wesentlich komplexere Zustandsverwaltung, saubere Programmierung und eine einfache Anbindung an externe Datenquellen (wie Stundenpläne).

Aufbau des Python-Backends (Modul-Architektur)

Das Python-Skript ist modular aufgebaut und verarbeitet Daten nach dem Prinzip einer zustandsgesteuerten Endlosschleife (State Machine).

• models.py (Datenmodellierung): Hier ist das System objektorientiert abgebildet. Für jeden Schulraum wird ein Objekt der Klasse RaumZustand instanziiert. Diese Objekte kapseln alle relevanten Parameter: Betriebsmodus (Ferien, Stundenplan, Manuell), aktuelle Temperaturen, Stundenplandaten sowie den aktuellen Zustand von Sensoren (Fenster, Bewegung). Diese Raum-Objekte werden zentral in einer übergeordneten Klasse (SchulZustand) verwaltet.
• mqtt_handler.py (Event-Listener): Dieses Modul abonniert die von Home Assistant gesendeten MQTT-Topics. Eintreffende Sensor-Ereignisse (z. B. "Fenster geöffnet", "Bewegung erkannt" oder "Wandthermostat manuell verstellt") werden hier asynchron empfangen und aktualisieren sofort die entsprechenden Variablen im jeweiligen Raum-Objekt.
• logic.py (Regelwerk): Das Herzstück der Anwendung. Hier befindet sich die Funktion logik_auswerten(), welche die komplexen Wenn-Dann-Beziehungen berechnet (Vorheizzeiten, Absenktemperaturen bei fehlender Bewegung, manueller Overrides).
• ha_api.py (Aktorik): Wenn die Logik entscheidet, dass eine Temperatur geändert werden muss, nutzt dieses Modul die REST-API von Home Assistant, um den Steuerbefehl als HTTP-Request an die Hardware durchzureichen.
• main.py (Der Taktgeber): Hier läuft die Hauptschleife (Main-Loop). Sie ruft zyklisch (z.B. alle 2 Sekunden) die logik_auswerten() für alle Räume auf.

Dynamische Datenversorgung (Cloud-Sync)

Um den Verwaltungsaufwand für die Schule zu minimieren, werden Heiz- und Stundenpläne nicht fest im Code hinterlegt. Die Initialisierung der Raum-Objekte erfolgt über eine lokale CSV-Datei.

• Der Service cloud_sync.py: Dieser läuft als eigenständiger, paralleler Prozess. Seine einzige Aufgabe ist das regelmäßige Abfragen (Polling) eines online freigegebenen Google Sheets.
• Watchdog-Pattern: Werden im Google Sheet Änderungen am Stundenplan vorgenommen, lädt cloud_sync.pydie Daten herunter und überschreibt die lokale CSV-Datei. In der main.py wacht ein Dateisystem-Beobachter (Watchdog) über diese CSV. Sobald sie sich ändert, liest die Hauptanwendung den Stundenplan im laufenden Betrieb neu ein, ohne dass das System neugestartet werden muss.

 Architektonische Besonderheiten & Konfliktlösung

Bei der Kombination von autarken Smart-Home-Komponenten und zentraler Software-Logik entstehen oft Konflikte ("Race Conditions"). Diese Architektur löst diese Herausforderungen wie folgt:

Dezentrales Fallback (Die Fenster-Logik)

Während die gesamte Intelligenz in Python liegt, gibt es eine sicherheitsrelevante Ausnahme: Die Fenstersteuerung. Fällt das Netzwerk, der Raspberry Pi oder das Python-Skript aus, bestünde im Winter bei offenem Fenster Frostgefahr. Daher wird hier die Direktverknüpfung der Homematic IP Ebene genutzt. Wird ein Fenster geöffnet, regelt die CCU3 das Thermostat in Millisekunden autark herunter. Das Python-Skript registriert über MQTT lediglich passiv: "Das Fenster ist offen". Die Logik geht für diesen Raum sofort in einen Pausen-Modus und sendet keine Steuerbefehle mehr, um der CCU3 nicht ins Handwerk zu pfuschen. Erst wenn das Fenster geschlossen wird, übernimmt das Python-Skript wieder die Kontrolle.

Traffic-Minimierung (Spam- und Echo-Filter)

Um den Funk-Duty-Cycle der CCU3 nicht zu überlasten (gesetzliche Sendebeschränkung für Funkgeräte) und die Home Assistant API zu schonen, verfügt das Skript über einen Spam-Filter. Am Ende der Funktion logik_auswerten() wird der neu berechnete Soll-Wert mit dem zuletzt gesendeten Wert (letzte_gesendete_temp) verglichen. Ein API-Call an die Heizung erfolgt ausschließlich dann, wenn sich die Soll-Temperatur tatsächlich geändert hat. Zudem ignoriert ein "Echo-Schutz" im MQTT-Handler die Bestätigungsnachrichten der Thermostate, damit das System eigene Änderungen nicht fälschlicherweise als manuellen Eingriff durch einen Lehrer interpretiert.

Link zu GitHub: https://github.com/bitshit24/smart-facility-BBS2-Wob