DH40 — Datenfluss

English version · Projektübersicht · VPS-Demo-Parität · VPS-Betrieb · Test-Labor Mac + VPS

Wie Sensor-, App- und Gesundheitsdaten in DeinHaus 4.0 fließen — vom Raspberry Pi im Haushalt über die THD-Server bis zu Forschungs-Tools.

Referenz-Stack: dh40-software-and-hardware-architecture-master/wohnung/docker/ (Edge) und …/thd/ (zentral).

Überblick

Es gibt vier parallele Datenpfade (zwei am Haushalt-Edge, ein Cloud-Gesundheitsimport, ein Jetson-Forschungspfad):

Tablet und Labor-UI lesen lokale Sensordaten (MQTT + Influx). Z-Wave- und Button-Daten werden über VPN + MQTT-Bridge zum THD repliziert. Withings umgeht die Pi-Datenebene — siehe §3. Kameras sind ein separates Forschungsspoor auf Jetson — siehe §4.

1. Sensordaten (Edge)

Quelle

• Z-Wave über zwavejs2mqtt (Tür, Bewegung, Klima, Steckdose, Rauch, …)
• Weitere MQTT-Quellen (ESP32, …) am selben Broker — bei passendem Topic/JSON-Format
• IP-Kameras sind nicht im Produktions-Pi-Docker-Stack; Jetson-Forschungsprototypen siehe §4

MQTT-Topics

Muster zwavejs2mqtt/<gateway>/<node>/…. Beispiele:

Vollständige Bridge-Liste: wohnung/docker/mosquitto2mosquitto/config/mosquitto.conf.

Nachrichtenformat (JSON für Telegraf)

{
  "time": 1719000000000,
  "value": "22.5",
  "nodeName": "Raumklimasensor",
  "nodeLocation": "Wohnzimmer"
}

Tags über topic_parsing: sensor_id, measured, measured_detail.

Nach InfluxDB

MQTT (1883) → Telegraf → Measurement mqtt_consumer

• Datenbank sensors, Retention autogen
• Flux-Bucket in dh40-app: sensors/autogen
• Browser-Zugriff über influxdb-proxy (HTTPS, Port 8087)

Nach MariaDB (Studie)

Derselbe MQTT-Strom wird per Bridge zu THD HiveMQ gesendet (TLS, Zertifikate, Präfix data/<home_id>/). Konnektoren schreiben in dh40 (roh).

2. Tablet-App (dh40-app)

Config

Button-Log (Aktivitätsprotokoll)

Produktion: mqtts://<pi>:8883. Topics werden zur Bridge nach THD gespiegelt.

Wohndaten-Charts

Abfrage per Influx Flux (nicht MQTT): Temperatur, Feuchte, Leistung, VOC, CO₂, Bewegung, Türen, Akkus — 24h / 7d / 30d.

3. Withings-Gesundheitsdaten

Withings-Geräte verbinden sich nicht mit dem Raspberry Pi und nutzen kein lokales MQTT oder Influx. Sie koppeln mit dem Smartphone des Teilnehmers und der Withings-Cloud (Health Mate). Die Studie importiert Gesundheitsmetriken per zentralem Batch-Job am THD — parallel, aber getrennt von der Z-Wave-Edge-Pipeline.

Repos: dh40-withings-mariadb-main, dh40-withings-auth-server-main, dh40_config_provider_poc-main, dh40-app-withings-poc-master (nur POC).

Geräte und Teilnehmer-UX

OAuth-Einrichtung (einmal pro Studien-Haushalt)

1. Forschungsteam startet dh40-withings-auth-server (Flask) oder gleichwertigen OAuth-Flow.
2. Teilnehmer autorisiert die DH40-Withings-Anwendung im Browser.
3. Callback liefert refresh_token und access_token.
4. Tokens liegen am THD unter Withings-Tokens/<home_id>/credentials.json.

Der Pi-config-provider kann config.json mit OAuth-Feldern ausliefern — für dh40-app-withings-poc. In der Haupt-dh40-app ist fetchWithingsConfig deaktiviert; der Produktionsimport hängt nicht vom Tablet ab.

Zentraler Batch-Import (dh40-withings-mariadb)

Läuft auf THD Docker, nicht auf dem Pi:

Schreibziele: dh40_withings (roh) und dh40_warehouse / database_science.

Withings vs. Z-Wave

Mosquitto-Bridge-Hinweis

Die Pi-Bridge hat eine eingehende Regel data/<home_id>/withings/# (HiveMQ → lokaler Mosquitto). Das ist nicht der Hauptimport; Produktionsdaten kommen über withings_to_db.py am THD.

Forschungsnutzung

Withings-Tabellen in database_science für dh40-streamlit, sensor-data-science, dh40-spark — über THD-VPN-Exporte (https://dh40-vpn.th-deg.de:8443).

4. Kamera und Notfallerkennung (Forschung)

Video- und Audio-Notfallerkennung in DH40 sind Forschungs-Nebenprojekte — sie sind nicht im Standard-Pi-Stack (wohnung/docker/), nicht auf der öffentlichen VPS-Demo und im Archiv nicht an dh40-app-Charts oder die HiveMQ-Studien-Bridge angebunden.

Repos: dh40-camera-module-master, dh40-emergency-detection-main, dh40-smart-mirror-2-main (Messe-Emotionsdemo).

Projekte im Überblick

Ablauf dh40-camera-module (Video-Sturzerkennung)

Typisches Labor-Setup laut Repo-README:

1. Jetson Nano mit USB-Kamera, Docker + NVIDIA-Runtime.
2. mediapipe/start.sh startet Pose-Schätzung (pose_estimation.py / main.py).
3. MediaPipe Pose extrahiert Körper-Landmarks pro Frame.
4. FallDetector wertet Bewegung, Winkel und Bounding-Box über ein kurzes Frame-Fenster aus.
5. Bei validiertem Sturz: stdout (Fall detected). MQTT-Code ist vorbereitet, aber auskommentiert.

Edge-ML auf dem Jetson — kein Video-Streaming zum Tablet oder THD.

dh40-emergency-detection (Audio + Video)

Keine Anbindung an Mosquitto, InfluxDB oder MariaDB im Archiv.

vs. Produktion und Überwachungskameras

Anbindung an den Pi-MQTT-Bus?

Prinzipiell könnte ein Custom-Publisher (z. B. fall_detected) an Mosquitto senden — main.py skizziert paho.mqtt. Im Archiv ist das nicht umgesetzt. Video wird nicht in Influx oder MariaDB gespeichert.

Forschungsnutzung

Ergebnisse in lokalen Logs, CSV und Notebooks — kein automatischer Pfad zu Spark/Streamlit, außer man exportiert manuell.

5. Laborvisualisierung

Abonniert MQTT (WebSocket) für Live-Kacheln auf dem Grundriss — ohne Influx.

6. Sicherheit und Uplink

Ohne VPN und vertrauenswürdige Zertifikate läuft die Bridge nicht.

7. TH Deggendorf (zentral)

Exporte: https://dh40-vpn.th-deg.de:8443 (THD-VPN). Siehe dh40-spark-main/data/README.md.

8. Forschung (Batch)

Getrennt vom Live-Edge-Stack — arbeitet auf Exporten, nicht auf Live-MQTT.

9. Öffentliche VPS-Demo (_demo/)

Simuliert den Haushalt-Edge für Demos — keine Verbindung zu HiveMQ/MariaDB.

Details: demo-production-parity.md, vps-operations_de.md.

10. Kurzreferenz

Siehe auch

• readme_de.md
• deployment_de.md
• _demo/readme.md