DH40 — Data flow

Deutsche Version · Project overview · VPS demo parity · VPS operations · Test lab: Mac edge + VPS

How sensor, app, and health data move through DeinHaus 4.0 — from a household Raspberry Pi to TH Deggendorf servers and research tooling.

Canonical stack: dh40-software-and-hardware-architecture-master/wohnung/docker/ (edge) and …/thd/ (central).

Overview

DH40 uses four parallel data paths (two at the household edge, one cloud-only health import, one Jetson research):

The tablet and lab UIs read local sensor data (MQTT + Influx). Anonymised Z-Wave and button data replicate to THD over VPN + MQTT bridge. Withings bypasses the Pi data plane — see §3. Cameras are a separate research track on Jetson — see §4.

1. Sensor data (edge)

Source

• Z-Wave devices via zwavejs2mqtt (door, motion, climate, power, smoke, …)
• Other MQTT publishers (ESP32, etc.) on the same broker — if they use the expected topic/JSON shape
• IP cameras are not part of the production Pi Docker stack; see §4 for Jetson-based research prototypes

MQTT topics

Topics follow the zwavejs2mqtt/<gateway>/<node>/… pattern. Examples:

Full bridge topic list: wohnung/docker/mosquitto2mosquitto/config/mosquitto.conf.

Message format

Telegraf mqtt_consumer expects JSON (see influxdb/telegraf/mytelegraf.conf):

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

topic_parsing adds tags: sensor_id, measured, measured_detail.

Into InfluxDB

MQTT (1883) → Telegraf → InfluxDB measurement mqtt_consumer

• Database: sensors, retention policy autogen
• Flux bucket name in dh40-app: sensors/autogen
• Browser queries via influxdb-proxy (nginx HTTPS + CORS) on Pi port 8087

Into MariaDB (study)

Same MQTT stream is bridged to THD HiveMQ (TLS, client certificates, topic prefix data/<home_id>/). Connectors write to MariaDB database dh40 (raw).

2. Tablet app data (dh40-app)

Config (unlock + Withings)

Served by config-provider (nginx). App maps home ID → study group → training video week.

Button log (activity protocol)

When the resident taps UI buttons, dh40-app publishes via MQTT over WebSocket:

Production: mqtts://<pi>:8883. These topics are also bridged to HiveMQ for MariaDB.

Wohndaten charts

dh40-app queries InfluxDB Flux (not MQTT) for historical sensor charts:

• Temperature, humidity, power, VOC, CO₂, CO, motion heatmap, doors, batteries
• Ranges: 24h / 7d / 30d
• Auth: deinhaus40 + household Influx password

3. Withings health data

Withings devices do not connect to the Raspberry Pi and do not use local MQTT or Influx. They pair with the participant’s phone and Withings’ cloud (Health Mate). The study imports health metrics via a central batch job on THD, parallel to but separate from the Z-Wave edge pipeline.

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

Devices and participant UX

OAuth setup (once per study home ID)

1. Research staff run dh40-withings-auth-server (Flask) or an equivalent OAuth flow.
2. Participant authorizes the DH40 Withings application in the browser.
3. Callback yields refresh_token and access_token.
4. Tokens are stored on THD under Withings-Tokens/<home_id>/credentials.json (e.g. 01V56TVL).

The Pi config-provider may also serve config.json with OAuth fields — used by dh40-app-withings-poc (browser → Pi config → Withings API). In the main dh40-app, fetchWithingsConfig is disabled (App.tsx); production import does not depend on the tablet fetching tokens.

Central batch import (dh40-withings-mariadb)

Runs on THD Docker (docker-compose.yml), not on the Pi:

withings_to_db.py calls the Withings API (refreshing tokens as needed):

Writes go to dh40_withings (raw) and dh40_warehouse / database_science (research warehouse).

Withings vs Z-Wave — quick comparison

Mosquitto bridge note

The Pi bridge config includes an inbound rule data/<home_id>/withings/# (HiveMQ → local Mosquitto). This is not the primary Withings import path; production data enters via withings_to_db.py on THD.

Research consumption

Withings tables in database_science feed batch tools: dh40-streamlit, sensor-data-science, dh40-spark — via THD VPN exports (https://dh40-vpn.th-deg.de:8443), same as other study data.

4. Camera and emergency detection (research)

Video and audio emergency detection in DH40 are research sidecars — they are not deployed in the standard household Pi stack (wohnung/docker/), not on the public VPS demo, and not integrated with dh40-app live charts or the HiveMQ study bridge in the archived code.

Repos: dh40-camera-module-master, dh40-emergency-detection-main, dh40-smart-mirror-2-main (trade-show emotion demo).

What exists in the repos

dh40-camera-module flow (video fall detection)

Typical lab setup from the repo README:

1. Jetson Nano with USB camera, Docker + NVIDIA runtime.
2. mediapipe/start.sh runs pose estimation (pose_estimation.py / main.py).
3. MediaPipe Pose extracts body landmarks per frame.
4. FallDetector applies geometric rules (neck/COM movement, body angle, bounding-box aspect ratio) over a short frame window.
5. On validated fall: logs to stdout (Fall detected). MQTT publish code exists but is commented out — no broker, topic, or Pi integration configured.

This is edge ML on Jetson, not streaming video to the tablet or THD.

dh40-emergency-detection flow (audio + video research)

Parallel research track (contactless emergency detection):

No connection to Mosquitto, InfluxDB, or MariaDB in the archived codebase.

vs production DH40 and vs consumer surveillance

Could cameras join the Pi MQTT bus?

In principle, a custom publisher could send events (e.g. fall_detected) to Mosquitto if someone implements the bridge — main.py even sketches paho.mqtt. Nothing in the canonical architecture repo does this today. Video itself is not stored in Influx or MariaDB.

Research consumption

Results stay in local logs, CSV, and notebooks on the Jetson or developer machine until manually exported. They do not flow through dh40-spark / Streamlit pipelines unless researchers add that separately.

5. Lab visualization

dh40-laborvisualisierung subscribes to the same MQTT broker (WebSocket) and updates floor-plan tiles in real time. It does not use Influx for the live view.

6. Security and uplink

Without VPN + trusted certs, the Mosquitto → HiveMQ bridge does not run.

7. TH Deggendorf (central)

Exports for researchers: https://dh40-vpn.th-deg.de:8443 (THD VPN required). See dh40-spark-main/data/README.md.

8. Research and analytics (batch)

Downstream tools work on exports, not live MQTT:

This path is orthogonal to the live household stack: no Influx on the research laptops unless you build a separate export.

9. Public VPS demo (_demo/)

The IONOS demo simulates the household edge for presentations. It does not connect to HiveMQ or MariaDB.

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

10. Quick reference — who talks to what

See also

• readme.md — project map and glossary
• deployment.md — which repo to run where
• _demo/readme.md — build and run the public demo