GruppeC/README.md

11 KiB
Raw Permalink Blame History

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.

Datenfluss

Sensoren (Arduino UNO) ➔ WiFi/Bluetooth ➔ Backend (Aggregation & Regeln) ➔ Frontend (Webinterface + 3D-Zwilling)

Aktuell umgesetzt:

DHT11 + CCS811 ─▶ Arduino Uno ─Serial (Pin 0/1)─▶ ESP-01 ─WLAN (Handy-Hotspot)─▶ Laptop: backend/server.py :3000 ◀── Browser
                                                                                                     ▲
                                                                                                     └──▶ Unity-Zwilling (SmartLectureRoom)

Der Unity-Zwilling (eigenes Repo SmartLectureRoom) holt im Modus Verbindung → Backend jede Sekunde GET /api/messwerte ab. Temperatur und eCO₂ vom Arduino ersetzen dann die simulierten Werte, das passende Szenario (Hitze, stickige Luft, Wintermorgen …) wird erkannt und Fenster, Lüftung, Heizung, Jalousie und Licht werden automatisch angesteuert. Die Entscheidung meldet Unity per POST /api/steuerung zurück. Details: README im Unity-Projekt, Abschnitt „Arduino anbinden“.

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

Live-Messwerte laufen Ende-zu-Ende: Der Arduino misst Temperatur, Luftfeuchte, eCO₂ und TVOC, zeigt sie auf dem LCD und sendet sie per ESP-01 an backend/server.py; die Website (frontend/) zeigt sie live mit Verlauf und CO₂-Alarm. Der Unity-Zwilling ist an den Server angebunden (mit simulator.py vorbereitet, mit dem echten Arduino noch nicht getestet). Aggregation/Präferenzen im Backend fehlen noch (siehe docs/offene-punkte.md).

Komponenten und ihre Aufgabe

Hardware

Komponente Aufgabe
Arduino Uno (Haupt-Uno) Herz der Messstation: liest alle 2 s die Sensoren, zeigt die Werte auf dem LCD und gibt sie an den ESP weiter.
DHT11 Misst Temperatur (°C) und Luftfeuchte (%). Langsam, braucht ca. 2 s zwischen zwei Messungen.
CCS811 / CJMCU-811 Misst die Luftqualität: eCO₂ (ppm) und TVOC (ppb, flüchtige organische Stoffe). eCO₂ ist ein aus den Gasen geschätzter CO₂-Wert, keine echte CO₂-Messung. Temperatur und Feuchte vom DHT11 bekommt er zur Korrektur. In den ersten ~20 min nach dem Einschalten oft 400 ppm / 0 ppb.
LCD 16×2 Zeigt die Werte direkt an der Station. Nur 2 Zeilen, daher Wechsel zwischen Temp/Luft und CO2/TVOC. Beim Start zeigt es den WLAN-Status („WLAN OK“ oder „Fehler E1“ …).
Potentiometer Stellt den Kontrast des LCD ein.
ESP-01 (ESP8266) WLAN-Modul, da der Uno selbst kein WLAN hat. Der Uno schickt ihm Textbefehle („AT-Befehle“), der ESP verbindet sich mit dem Hotspot und schickt die Werte an den Laptop.
Zweiter Uno Liefert dem ESP nur Strom (3,3 V), weil der Haupt-Uno zu wenig Strom für den ESP hat. Braucht gemeinsame Masse (GND) mit dem Haupt-Uno.
Handy-Hotspot Das WLAN, in dem sich ESP und Laptop treffen. Muss 2,4 GHz anbieten (iPhone: „Maximale Kompatibilität“).
Laptop Empfängt die Messwerte und stellt die Website bereit.

Software

Datei Aufgabe
firmware/dht11_lcd/dht11_lcd.ino Hauptprogramm auf dem Uno: Sensoren lesen, LCD anzeigen, Senden anstoßen. Speichert außerdem stündlich die Kalibrierung („Baseline“) des CCS811 im EEPROM, damit die Werte nach einem Neustart schneller stimmen.
firmware/dht11_lcd/esp_wifi.h Steuert den ESP: Baudrate finden, mit dem Hotspot verbinden, Messwerte als HTTP-POST an den Laptop schicken.
firmware/dht11_lcd/wifi_config.h Zugangsdaten (Hotspot-Name, Passwort, Laptop-IP). Nicht im Repo, Vorlage: wifi_config.example.h.
backend/server.py Server auf dem Laptop (Port 3000): nimmt die Messwerte vom ESP an, merkt sich die letzten 100, liefert die Website aus und stellt die Werte dem Unity-Zwilling bereit (dessen Steuerbefehle kommen per POST /api/steuerung zurück).
backend/start.bat Startet den Server per Doppelklick und prüft, ob die Laptop-IP zu wifi_config.h passt.
backend/firewall_freigeben.bat Gibt Port 3000 in der Windows-Firewall frei, damit der ESP den Laptop erreicht.
backend/simulator.py Schickt erfundene Werte – zum Testen ohne Arduino. Mit --szenario hitze/stickig/kalt/normal/demo gezielt Szenarien für den Unity-Zwilling auslösen.
frontend/ Website: fragt alle 2 s beim Server die neuesten Werte ab und zeigt Kacheln, Verlaufsdiagramm und CO₂-Alarm ab 1000 ppm.
firmware/esp_test, firmware/ccs811_test, firmware/ccs811_diagnose Testprogramme zur Fehlersuche, im normalen Betrieb nicht nötig.

Ablauf einer Messung

  1. Der Uno liest DHT11 und CCS811 aus und zeigt die Werte auf dem LCD.
  2. Etwa alle 4 s schickt er sie über Pin 0/1 an den ESP-01.
  3. Der ESP sendet sie über den Hotspot an den Laptop (server.py, Port 3000).
  4. Der Browser fragt den Server alle 2 s nach den neuesten Werten und zeigt sie auf der Website.

Hardware (Verkabelung)

Bauteil Anschluss am Uno
DHT11 Daten → Pin 2
LCD 16×2 RS 7, E 8, D4–D7 → 9–12, RW → GND, V0 → Poti
CCS811 (CJMCU-811) VCC → 3,3 V, GND, SDA → A4, SCL → A5, WAK → GND, ADD → GND (Adresse 0x5A)
ESP-01 TX → Pin 0, RX → Pin 1 (gekreuzt!), VCC + EN → 3,3 V, GND; RST, GPIO0, GPIO2 frei

Der 3,3-V-Pin des Uno liefert nur ca. 150 mA, der ESP-01 braucht beim Start kurz bis zu 300 mA. Wir versorgen den ESP deshalb aus einer eigenen 3,3-V-Quelle (zweiter Uno); deren GND muss mit dem GND des Haupt-Uno verbunden sein.

Starten

  1. firmware/dht11_lcd/wifi_config.example.h als wifi_config.h kopieren und Hotspot-Name, Passwort und Laptop-IP eintragen (die Datei ist in .gitignore).
  2. iPhone-Hotspot mit „Maximale Kompatibilität“ einschalten (ESP-01 kann nur 2,4 GHz), Laptop verbinden.
  3. Einmalig backend/firewall_freigeben.bat als Administrator ausführen.
  4. backend/start.bat starten – muss „OK: SERVER_IP … passt“ melden, sonst die angezeigte IP in wifi_config.h eintragen.
  5. ESP-Datenkabel von Pin 0/1 abziehen, firmware/dht11_lcd hochladen, Kabel wieder anstecken, Reset.
  6. LCD zeigt „WLAN OK“, Website: http://localhost:3000

Fehlerbehebung: „WLAN Fehler E1“ (ESP antwortet nicht)

Symptom: Das LCD zeigte nach dem Start immer „WLAN Fehler E1“, egal wie TX/RX gesteckt waren; esp_test zeigte bei jeder Baudrate „keine Antwort“. Zeitweise meldete außerdem der CCS811 „CCS811 Fehler!“.

Ursachen (es waren mehrere gleichzeitig):

  1. TX/RX nach Instructables-Anleitung verkabelt. Die Anleitung „Add WiFi to Arduino UNO“ benutzt den Uno nur als USB-Adapter (leerer Sketch, der Laptop spricht mit dem ESP). Dafür wird gerade verbunden (ESP TX → Pin 1, ESP RX → Pin 0), weil der USB-Chip des Uno intern schon kreuzt. In unserem Projekt spricht aber der Uno selbst mit dem ESP – dann muss gekreuzt werden: ESP TX → Pin 0 (RX), ESP RX → Pin 1 (TX).
  2. Keine gemeinsame Masse. Der ESP hing an der 3,3 V eines zweiten Uno, dessen GND nicht mit dem Haupt-Uno verbunden war. Ohne gemeinsame Masse kommen auf TX/RX keine sauberen Signale an (der ESP läuft trotzdem, die blaue LED blinkt beim Start).
  3. Zu schwache 3,3-V-Versorgung. Hingen ESP und CCS811 gemeinsam am 3,3-V-Pin des Uno, brach die Spannung beim Start des ESP ein: Der ESP startete unzuverlässig, und der CCS811 antwortete beim Initialisieren nicht („CCS811 Fehler!“). Der Sketch startet den CCS811 deshalb jetzt erst nach dem WLAN und versucht es bei Fehlern erneut.

So haben wir es eingegrenzt (Durchreiche-Test, ohne eigenen Sketch):

  1. Leeren Sketch (Datei → Beispiele → 01.Basics → BareMinimum) auf den Uno laden.
  2. ESP gerade anschließen: TX → Pin 1, RX → Pin 0, gemeinsame Masse.
  3. Serial Monitor auf 74880 Baud, ESP neu einstecken → lesbare Bootmeldung (SDK ver: …) heißt: ESP lebt, TX-Leitung ok.
  4. Serial Monitor auf 115200 Baud und „Sowohl NL als auch CR“, AT senden → OK heißt: ESP voll funktionsfähig.
  5. AT+CWMODE=1 und AT+CWJAP="<SSID>","<Passwort>" → WIFI CONNECTED, WIFI GOT IP, OK heißt: Hotspot ok.
  6. Optional AT+UART_DEF=9600,8,1,0,0: ESP dauerhaft auf 9600 Baud (vom Uno zuverlässiger empfangen, der Sketch erkennt 9600 automatisch).
  7. Danach für dht11_lcd wieder gekreuzt anschließen.
LCD Bedeutung
WLAN Fehler E1 ESP antwortet nicht: TX/RX nicht gekreuzt, GND fehlt, Strom zu schwach
WLAN Fehler E2 ESP antwortet, Station-Modus nicht setzbar
WLAN Fehler E3 Hotspot nicht erreichbar: SSID/Passwort, „Maximale Kompatibilität“ aus, Hotspot aus
CCS811 Fehler! Sensor antwortet nicht am I2C: Verkabelung prüfen, firmware/ccs811_diagnose zeigt den genauen Schritt

„Mal geht's, mal nicht“ (E1 trotz richtiger Verkabelung)

Beobachtung: Bei korrekter, gekreuzter Verkabelung kam trotzdem manchmal „WLAN Fehler E1“. Zuverlässig lief es nur mit diesem Ablauf:

  1. ESP gerade anschließen (TX → Pin 1, RX → Pin 0), Reset am Haupt-Uno
  2. ESP gekreuzt anschließen (TX → Pin 0, RX → Pin 1), nochmal Reset

Vermutete Ursache: Der Sketch sucht beim Start die Baudrate des ESP (115200, 9600, 57600, 38400). Jeder Versuch mit falscher Baudrate – und auch der Uno-Reset selbst, bei dem die TX-Leitung kurz offen ist – kommt beim ESP als Zeichensalat an. Der ESP hängt diesen vor den nächsten Befehl (x#~AT statt AT), antwortet ERROR statt OK, und die Suche dreht sich im Kreis.

Fix in der Firmware: espBaudrateFinden() in esp_wifi.h schickt jetzt vor jedem AT eine leere Zeile. Damit schließt der ESP den Zeichensalat als eigene (ungültige) Zeile ab, und das folgende AT kommt sauber an. Seitdem reicht einmal gekreuzt anschließen + Reset (am Aufbau bestätigt). Der Ablauf oben ist nur noch Notlösung, falls es doch wieder auftritt.

Weitere Ursachen für wechselndes Verhalten:

  • Strom am Limit: Ein Elko (100–470 µF) direkt zwischen VCC und GND am ESP fängt die Stromspitzen ab.
  • iPhone-Hotspot versteckt sich nach einer Weile ohne verbundenes Gerät (dann E3): vor dem Reset Einstellungen → Persönlicher Hotspot öffnen.
  • Wackelkontakte an GND, TX oder RX im Steckbrett.