From 3844dc71ac67037acc37f7eb1b17dcbff05c957a Mon Sep 17 00:00:00 2001 From: 3020772 <3020772@stud.hs-mannheim.de> Date: Thu, 8 Oct 2026 11:10:15 +0200 Subject: [PATCH] Grundstruktur Repo --- .gitignore | 23 +++++++++++++++++++++ CLAUDE.md | 12 +++++++++++ README.md | 20 ++++++++++++++++++- backend/.gitkeep | 0 docs/aggregationskonzept.md | 40 +++++++++++++++++++++++++++++++++++++ docs/offene-punkte.md | 12 +++++++++++ firmware/.gitkeep | 0 frontend/.gitkeep | 0 8 files changed, 106 insertions(+), 1 deletion(-) create mode 100644 .gitignore create mode 100644 CLAUDE.md create mode 100644 backend/.gitkeep create mode 100644 docs/aggregationskonzept.md create mode 100644 docs/offene-punkte.md create mode 100644 firmware/.gitkeep create mode 100644 frontend/.gitkeep diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..906a29e --- /dev/null +++ b/.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 diff --git a/CLAUDE.md b/CLAUDE.md new file mode 100644 index 0000000..8051db0 --- /dev/null +++ b/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. diff --git a/README.md b/README.md index d6ad7b3..042fa94 100644 --- a/README.md +++ b/README.md @@ -1 +1,19 @@ -## UCPS Projekt \ No newline at end of file +# 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)). diff --git a/backend/.gitkeep b/backend/.gitkeep new file mode 100644 index 0000000..e69de29 diff --git a/docs/aggregationskonzept.md b/docs/aggregationskonzept.md new file mode 100644 index 0000000..ca72441 --- /dev/null +++ b/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. diff --git a/docs/offene-punkte.md b/docs/offene-punkte.md new file mode 100644 index 0000000..454b233 --- /dev/null +++ b/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 diff --git a/firmware/.gitkeep b/firmware/.gitkeep new file mode 100644 index 0000000..e69de29 diff --git a/frontend/.gitkeep b/frontend/.gitkeep new file mode 100644 index 0000000..e69de29