Grundstruktur Repo

.gitignore

@@ -0,0 +1,23 @@
+# OS / Editor
+.DS_Store
+Thumbs.db
+.vscode/
+.idea/
+
+# Env / Secrets
+.env
+.env.*
+
+# Node
+node_modules/
+dist/
+build/
+
+# Python
+__pycache__/
+*.pyc
+.venv/
+
+# Arduino
+*.hex
+*.elf

CLAUDE.md

@@ -0,0 +1,12 @@
+# CLAUDE.md
+
+UCPS-Projekt (Gruppe C): Lernklima-Aggregation für Vorlesungsräume. Konzept: `docs/aggregationskonzept.md`; offene Entscheidungen: `docs/offene-punkte.md`.
+
+## Struktur
+`firmware/` (Arduino), `backend/` (Aggregation/API), `frontend/` (Web + 3D-Zwilling), `docs/`.
+
+## Fachliche Kernregeln (nicht verletzen)
+- Temperatur/Licht: Durchschnitt aller Live-Eingaben.
+- CO2 ist Hard-Constraint (Standard 1000 ppm): Nutzer können nicht überschreiben.
+- Sensor-Veto: extremer Außenlärm blockiert offene Fenster; extremer Wind ➔ max. gekippt.
+- Sprache der Doku/UI: Deutsch.

README.md

@@ -1 +1,19 @@
-## UCPS Projekt
+# UCPS Projekt – Gruppe C
+
+Dynamische, kontextsensitive Steuerung des Lernklimas im Vorlesungsraum: Sensordaten (Arduino) werden mit Live-Präferenzen von Dozierenden und Studierenden aggregiert und in einem Webinterface samt 3D-Digitalem-Zwilling dargestellt.
+
+Das vollständige Konzept steht in [docs/aggregationskonzept.md](docs/aggregationskonzept.md).
+
+## Datenfluss
+Sensoren (Arduino UNO) ➔ WiFi/Bluetooth ➔ Backend (Aggregation & Regeln) ➔ Frontend (Webinterface + 3D-Zwilling)
+
+## Repo-Struktur
+| Ordner | Inhalt |
+|---|---|
+| `docs/` | Konzept, Architektur- und Entscheidungsdokumente |
+| `firmware/` | Arduino-Sketches für Sensorik und Übertragung |
+| `backend/` | Aggregationslogik (Durchschnitt, CO2-Hard-Constraint, Kontext-Sperren), API, Wetterdaten |
+| `frontend/` | Responsive Webinterface (Live-Werte, Präferenz-Slider) und 3D-Raum |
+
+## Status
+Repo-Grundgerüst; noch kein Code. Tech-Stack offen (siehe Offene Entscheidungen in [docs/offene-punkte.md](docs/offene-punkte.md)).

docs/aggregationskonzept.md

@@ -0,0 +1,40 @@
+# Aggregationskonzept
+
+## 1. Zielsetzung und Grundannahmen
+Ziel des Systems ist die dynamische und kontextsensitive Anpassung des Lernklimas im Vorlesungsraum. Objektive (physikalische/medizinische) Messwerte werden mit den subjektiven Präferenzen von Dozierenden und Studierenden aggregiert, um ein optimales Lernklima zu schaffen.
+
+## 2. Datenerfassung & Erhebung der Nutzerpräferenzen
+Die Datenerhebung teilt sich in objektive Sensordaten und subjektives Nutzerfeedback auf.
+
+- **Initialzustand (statische Grundwerte):** Zu Beginn der Vorlesung startet das System mit einem vordefinierten Baseline-Zustand. Dieser berechnet sich aus aktuellen Wetterdaten (Außentemperatur) und festen medizinischen sowie physikalischen Richtlinien (z. B. empfohlene 21 °C Raumtemperatur, 50 % Luftfeuchtigkeit). Eventuell könnten hier gespeicherte Nutzerpräferenzen verwendet werden.
+- **Dynamische Präferenzerhebung (Live-Feedback):**
+  - Die subjektiven Wünsche der Nutzer werden über ein Webinterface erfasst.
+  - Studierende und Prof können mehrmals pro Vorlesung live ihre aktuellen Präferenzen anpassen (z. B. „Mir ist zu kalt", „Bitte heller" in mehreren Stufen).
+
+## 3. Hardware und Sensorik (Umgebungserfassung)
+Das physikalische Modell misst die Raum- und Umweltwerte kontinuierlich. Die Datenübertragung an das Backend erfolgt drahtlos (z. B. per WiFi oder Bluetooth).
+
+| Messgröße & Ort | Empfohlener Sensor (Arduino UNO) | Anschluss | Funktion im System |
+|---|---|---|---|
+| Temperatur & Feuchtigkeit (Innen, Richtung Fenster) | BME680 (All-in-One) | I2C | Erfasst das Innenklima zur Abgleichung mit dem Initialzustand. |
+| Temperatur & Feuchtigkeit (Außen) | DHT11 oder DHT22 | Digital | Wetter-Baseline für die Heizungs-/Lüftungslogik. Ein Sensor, Mittelwert mit den Werten einer Wetter-App. |
+| Luftqualität / CO2 (Innenraum) | MH-Z19 oder SCD30 | UART / I2C | Strikte Überwachung der Atemluft (medizinische Baseline). |
+| Lichtverhältnisse (Tafel & Richtung Fenster) | BH1750 (Lichtsensor) | I2C | Prüft, ob die Tafel blendet oder es zu dunkel zum Schreiben ist. |
+| Lärm / Lautstärke (Außen) | KY-037 (Mikrofon-Modul) | Analog/Digital | Prüft Störgeräusche von außen (z. B. Straßenverkehr). |
+| (Optional) Feinstaub / Smog (Außen) | SDS011 / API-Anbindung | UART | Indikator, ob überhaupt gelüftet werden darf (Pollen/Verkehr). Empfehlung, Fenster/Türen zu schließen (z. B. bei Großbränden in der Nähe). |
+
+## 4. Aggregationslogik & Konfliktauflösung
+Definiert, wie das System reagiert, wenn Eingaben (Sensoren vs. Nutzer) kollidieren.
+
+- **Primäre Aggregationsmethode (Durchschnitt):** Bei Parametern wie Temperatur und Licht, die auf persönlichem Empfinden basieren, wird der Durchschnitt aller Live-Eingaben aus dem Webinterface berechnet.
+- **Medizinische Hard-Constraints (kein Nutzereinfluss):** Die Luftqualität (CO2) wird ausschließlich anhand medizinisch festgelegter Grenzwerte (z. B. max. 1000 ppm) optimiert. Übersteigt der Sensor diesen Wert, erzwingt das System eine Anpassung (z. B. Lüftungsanlage an / Fenster auf). Nutzer können diesen Wert nicht überschreiben – Gesundheit hat Vorrang vor Komfort.
+- **Kontext-Sperren (Sensordaten-Veto):** Misst der Außen-Lärmsensor extremen Lärm, blockiert das System den Wunsch nach offenen Fenstern und signalisiert dies im Interface. Wird extremer Wind vorhergesagt, wird das Fenster maximal gekippt.
+
+## 5. Systemarchitektur, Webinterface & Visualisierung
+Messergebnisse und resultierende Raumveränderungen müssen für Nutzer transparent dargestellt werden.
+
+- **Datenfluss:** Sensoren (Arduino UNO) ➔ drahtlose Übertragung (WiFi/Bluetooth) ➔ Backend-Logik (Berechnung der Averages) ➔ Frontend (Webinterface).
+- **Nutzer-Interface:** Responsive Web-Anwendung, die während der Vorlesung aufgerufen werden kann. Zeigt aktuelle Live-Werte (Sensordaten) und bietet Slider oder Buttons zur Anpassung der Präferenzen (Temp/Licht).
+- **Visualisierung (Digitaler Zwilling):** Interaktiver 3D-Raum im Browser, dessen Zustand sich live ändert.
+  - Fordert die Durchschnittspräferenz mehr Licht, dimmen die digitalen Lichter hoch.
+  - Steigt das CO2, färbt sich der Raum leicht rötlich, bis sich im 3D-Modell die Fenster öffnen und blaue „Frischluft" visualisiert wird.

docs/offene-punkte.md

@@ -0,0 +1,12 @@
+# Offene Entscheidungen
+
+- [ ] Backend-Sprache/Framework (z. B. Node.js, Python/FastAPI)
+- [ ] Transport Sensoren ➔ Backend (HTTP, MQTT, WebSocket; WiFi vs. Bluetooth). Hinweis: Arduino UNO hat kein WiFi – ggf. ESP-Modul/UNO R4 WiFi.
+- [ ] Live-Updates im Frontend (WebSocket / SSE)
+- [ ] Frontend-Framework und 3D-Bibliothek (z. B. three.js)
+- [ ] Wetter-API (Außentemperatur, Windvorhersage, Feinstaub)
+- [ ] Persistenz (Nutzerpräferenzen, Messverlauf)
+- [ ] Schwellwerte: CO2-Limit (1000 ppm), „extremer Lärm", „extremer Wind"
+- [ ] Gewichtung: Dozent vs. Studierende beim Durchschnitt? Zeitfenster/Verfall alter Eingaben?
+- [ ] Authentifizierung/Anonymität der Nutzer (Mehrfachabgaben verhindern)
+- [ ] Simulation von Sensordaten für Entwicklung ohne Hardware