Zusammenspiel
Kurz zusammengefasst, wie ein Commit am Ende zu einer echten Temperaturänderung im Gebäude fßhrt:
- Commit auf GitHub lĂśst die Jenkins-Pipeline aus.
- Jenkins lädt den Code, baut ein Docker-Image (inklusive Qualitäts-Checks â Lint, Typecheck, Tests) und deployt den Container auf dem Server.
- Das laufende Programm holt sich periodisch die Buchungen aus ChurchTools Ăźber einen technischen Nutzer.
- Fßr jede relevante Buchung wird der beste Heizzeitplan berechnet (siehe Heizungslogik fßr die fachliche Erklärung).
- Bei Bedarf wird eine Anfrage an HomematicIP geschickt, um die Zieltemperatur zu setzen.
- Zusätzlich hält das System eine WebSocket-Verbindung zu HomematicIP, ßber die es laufend Updates zu Gruppen, Geräten und Wetter erhält.
- Alle Daten â sowohl aus der Berechnung als auch aus dem WebSocket â werden dauerhaft in InfluxDB gespeichert.
- Grafana greift auf InfluxDB zu und stellt die Daten als Graphen dar (siehe Grafana-Dashboards).
flowchart TD
A["GitHub Commit"] --> B["Jenkins Pipeline
Build + Quality Gates"] B --> C["Docker-Deployment
auf dem Server"] C --> D["Cron: ChurchTools-
Buchungen lesen"] D --> E["Heizplan berechnen"] E --> F["HomematicIP:
Temperatur setzen"] C --> G["WebSocket: HomematicIP-Updates
Gruppe / Gerät / Wetter"] F --> H["InfluxDB"] G --> H H --> I["Grafana"]
Build + Quality Gates"] B --> C["Docker-Deployment
auf dem Server"] C --> D["Cron: ChurchTools-
Buchungen lesen"] D --> E["Heizplan berechnen"] E --> F["HomematicIP:
Temperatur setzen"] C --> G["WebSocket: HomematicIP-Updates
Gruppe / Gerät / Wetter"] F --> H["InfluxDB"] G --> H H --> I["Grafana"]
FĂźr die genaue Modul-Architektur (welche Datei was macht) siehe das englische docs/architecture.md im Repository.