Gesundheitsdaten souverän tracken: Self-hosted mit OpenClaw + biohub (2026)

Von Maximilian Naumow — Alle Daten und Screenshots in diesem Artikel stammen aus meinem eigenen QS-Setup. Der Artikel dokumentiert, wie ich mein Whoop, meine Blutwerte und meinen Supplement-Stack in einer lokalen Pipeline zusammenführe.

Key Findings

• Vendor-Lock-in ist real: Whoop-App importiert Gewicht via HealthKit, zeigt es aber nur als Solo-Metrik ohne Cross-Correlation gegen Recovery/HRV. Apple Health kann keine Blutbild-PDFs parsen. Keine App korreliert Supplements mit HRV. Jede App ist ein Analyse-Silo.
• Lokale Aggregation löst das: openclaw-biohub ist eine MIT-lizenzierte Python + Next.js-Pipeline, die Daten aus Wearables, Blutbild-PDFs und einem Supplement-Log in einer SQLite-Datenbank auf deiner Hardware zusammenführt.
• Der eigentliche Payoff: Lag-aware Partial-Pearson-Korrelation zwischen jedem Supplement und deinem Recovery-Score, mit 95% CI und p-value. Zeigt, was in deinen Daten wirkt — und was nicht.
• Stand Juli 2026 real getestet: WHOOP-Adapter läuft auf echtem Gerät (meinem). Adapter für Oura, Fitbit, Apple Health, Garmin sind gebaut und mit Fixture-Daten getestet, brauchen aber Real-Device-Validation. Wer eins hat und helfen mag: siehe unten.
• Nicht medizinisch, nicht kausal: Die Analytik zeigt Korrelationen mit Confidence-Intervall, nicht Kausalität. Das ist trotzdem ~10× informativer als der App-Vendor-Hype-Fluff.
• Repo: github.com/maxnau89/openclaw-biohub — MIT-Lizenz, PRs willkommen.

Das Datensilo-Problem

Wenn du ein Whoop trägst, einen Oura Ring, eine Renpho-Waage nutzt und alle drei Monate ein Blutbild machst, hast du bereits genug Daten für interessante Analysen. Das Problem ist nur: jeder Vendor hält die Daten in seinem eigenen Silo.

• Whoop-App importiert Gewicht via HealthKit, zeigt es aber nur als isolierten Wert — keine Regression gegen Recovery, keine HRV-Delta-Analyse bei Gewichtsschwankung. Keine Blutwerte. Kein Supplement-Log.
• Oura-App hat ein Ökosystem, aber keine Cross-Device-Korrelation gegen fremde Datenquellen.
• Apple Health aggregiert HealthKit-Sources als Zeitreihen, kann aber keine Blutbild-PDFs parsen und macht keine Multi-Variable-Analyse.
• Renpho-App ist eine Waagen-App, punkt.
• Blutbild-PDFs landen im Google-Drive-Ordner und werden nie wieder angeschaut.

Das ist die Realität für ~90 % aller Nicht-Diabetiker die Quantified Self ernsthaft betreiben. Die interessante Frage — “Wenn ich am Mittwoch Zink genommen habe und am Freitag zwei Blutbild-Marker gestiegen sind, ist da ein Muster?” — kann keine dieser Apps beantworten. Weil sie die Daten der jeweils anderen nicht sehen.

Warum ich openclaw-biohub gebaut habe

Ich wollte drei Dinge, die keine bestehende App liefern konnte:

1. Daten auf meiner Hardware. Wenn Whoop morgen 30 %!P(MISSING)reiserhöhung macht oder Abbott den FreeStyle-Libre-Support in Europa einstellt (siehe Rückruf Feb 2026), sind meine historischen Daten trotzdem noch bei mir.
2. Cross-Source-Analyse in Rohform. SQLite-Tabellen für jede Datenquelle, plus eine daily_metrics-Rollup-Tabelle mit allen Metriken pro Tag. Wer SQL kann, kann in 3 Zeilen jede Frage beantworten. Wer nicht, klickt sich durchs Dashboard.
3. Grounding für den Agent. Ich nutze OpenClaw für alles mögliche, unter anderem für tägliche Wellness-Briefings. Ohne strukturierten Datenzugriff muss der Agent raten. Mit SKILL.md-Schnittstelle kann er sagen “deine HRV liegt heute 12 % über Baseline” statt “hoffentlich fühlst du dich gut”.

Das Repo ist github.com/maxnau89/openclaw-biohub, MIT-Lizenz.

Was biohub konkret trackt

Aus dem Stand Juli 2026 direkt aus dem Dashboard:

• Recovery (Score, HRV rmssd, Ruhepuls, SpO₂, Hauttemperatur)
• Schlaf (REM, Deep, Light, Efficiency, Total)
• Strain und Workouts mit HR-Zonen
• Body Composition (Gewicht, Körperfettanteil, Lean Mass — aus Renpho/Apple Health/manuellen Messungen)
• Glucose / CGM (FreeStyle Libre 3, Dexcom Stelo, Abbott Lingo — via Apple Health)
• Blood Panels — 13 Biomarker aus PDFs, mit Referenzbereich-Flagging und Zwei-Punkte-Trend
• Supplement-Stack mit Einnahme-Log und Korrelations-Analyse

Das Adapter-System ist Pattern-basiert: jede Datenquelle hat ein eigenes Verzeichnis unter pipeline/adapters/ und wird in biohub/registry.py registriert. Neue Sources (Polar, Withings, was auch immer) sind ein Nachmittag Arbeit, nicht ein Refactor.

Der eigentliche Payoff: Supplement-Korrelationen

Das ist die Analytik, die keine App-Vendor freiwillig zeigt. Warum? Weil sie unbequem sein kann.

Für jedes Supplement in deinem Stack rechnet biohub:

• Lag-aware Partial-Pearson-Korrelation zwischen Einnahme und Recovery-Score
• 95 % Confidence Interval — wenn die Bandbreite über 0 geht, gibt es keinen Effekt
• p-value — bei p > 0.05 kein statistisch signifikanter Effekt
• Delta in Recovery-Punkten an Einnahme- vs Nicht-Einnahme-Tagen
• Adjustment für Sleep und Strain wenn genug Daten da sind

Konkret aus meiner eigenen Analyse: was ich für “wirksam” hielt (Ashwagandha), zeigte im 60-Tage-Fenster p = 0.42, Delta 0.8 Rec-Punkte — nicht mal die Bandbreite meiner Alltags-Varianz. Was ich für Placebo hielt (Magnesium-Glycinat vor dem Schlafen), zeigte p = 0.031, Delta +4.2 Rec-Punkte, 95 % CI [1.1, 7.3]. Das ist der Grund, warum ich das Setup überhaupt gebaut habe: das eine hätte ich weiterhin blind eingenommen, das andere hätte ich weggelassen — beides falsch.

Wichtige Caveats:

• Korrelation ist nicht Kausalität. Wenn Magnesium mit besserer Recovery korreliert, könnte das auch bedeuten “an stressigen Tagen vergesse ich Magnesium und schlafe schlechter” — die Kausalpfeile sind offen.
• N=1 ist trotz Statistik immer noch N=1. Effekte sind auf mich zugeschnitten, nicht auf dich.
• p-value alleine sagt nichts über Effektstärke. Signifikant, aber winzig ist oft belanglos.
• Multiple-Testing-Problem: wenn du 20 Supplements gleichzeitig gegen Recovery testest, wird ein Wert zufällig p < 0.05 zeigen. Das ist im Dashboard nicht angezeigt — der User muss den Denk-Filter selber aufsetzen.

Aber trotz aller Caveats: was ich hier für mich sehe, ist informativer als alles, was Whoop/Oura/Ultrahuman mir je angezeigt haben.

Setup — was es kostet dich zum Laufen zu bringen

Repo klonen, virtuelle Umgebung aufsetzen, pip install -e .[analytics], OPENCLAW_BIOHUB_HOME=$PWD/.local-data exportieren, dann biohub list-adapters und biohub connect whoop (oder was auch immer du hast). Fürs Dashboard cd dashboard && npm install && npm run dev.

Realistische Zeitschätzung wenn du damit halbwegs vertraut bist: 60-90 Minuten. Wenn du Python/Node nur “manchmal” nutzt: einen Nachmittag. Die exakten Steps stehen im README auf GitHub.

Hardware-mäßig: mein Setup läuft auf einem Hetzner-VPS mit 4 GB RAM. Ein Home-NAS oder Raspberry Pi 4 (4 GB) tut es genauso. Ein Pi Zero reicht fürs Backend, aber nicht für Next.js.

Was biohub NICHT ist

Damit du keine falsche Erwartung mitnimmst:

• Kein Medizinprodukt. Keine Diagnose, keine Behandlung, keine ärztliche Beratung. Für alles Klinische: zum Arzt.
• Keine Cloud-Alternative. Keine Mobile-App, keine Sharing-Features, keine sozialen Elemente. Wer sein “Recovery Rockstar Level” öffentlich vergleichen will, ist bei Whoop und Strava besser aufgehoben.
• Kein Konsumentenprodukt. Das setzt Command-Line-Comfort voraus. Wenn dich cd und npm install überfordert, ist das nicht dein Werkzeug.
• Keine Universalantwort. WHOOP-Adapter ist auf einem realen Gerät validiert (meinem). Die vier anderen (Oura, Fitbit, Apple Health, Garmin) sind gebaut und mit Fixture-Daten getestet, brauchen aber Real-Device-Validation.

Wenn du eines dieser Devices hast und beim Validieren helfen magst: pip install -e .[analytics], biohub connect <slug>, biohub sync <slug>, dann ein Issue mit dem Label device-validation öffnen. Zwei Dinge helfen am meisten: (a) “OAuth-Flow funktioniert” oder “an dieser Stelle bricht es ab”, (b) sanitized API-Response wenn der Adapter etwas mis-parsed.

Für wen das passt

Kaufen — im Sinne von: Zeit investieren — wenn du:

• 2+ Wearables parallel trägst und die Daten korrelieren willst
• Blutbilder regelmäßig machst und die PDFs bisher nur im Drive-Ordner ruhen
• Ein Supplement-Log führst und wissen willst, was von deinem Stack tatsächlich wirkt
• Datenhoheit relevant ist (Vendor-Lock-in-Sorgen, EU-Datenschutz, akademische Nutzung, wissenschaftliches Framework, was auch immer)
• Command-Line comfort hast oder bereit bist, es zu lernen

Nicht kaufen wenn du:

• Nur casual trackst und eine Vendor-App reicht
• Keine Lust auf Server-Setup hast (auch wenn das minimal ist)
• Erwartest, dass eine App dir sagt, was du tun sollst — biohub zeigt Daten und Korrelationen, keine Anweisungen
• Deine Daten in der Cloud haben willst (biohub ist absichtlich local-first)

Fazit

Ich habe biohub gebaut, weil ich selbst frustriert war von Datensilos. Der eigentliche Aha-Moment war nicht das Dashboard — sondern das erste Mal, als eine Supplement-Korrelation mir gezeigt hat, dass ich seit Jahren die falsche Kapsel schlucke. Das ist die Art Insight, die nur mit rohen, cross-verknüpften Daten möglich ist.

Wenn dir das nach etwas klingt: das Repo ist offen (github.com/maxnau89/openclaw-biohub), MIT-Lizenz, Contributions willkommen. Wenn du eines der non-WHOOP-Devices hast und mit-testen möchtest: gerne. Wenn du das Whole-Setup nur lesen willst, um Ideen für deine eigene Pipeline zu klauen: auch gerne.

Was hier nicht steht, weil es ein anderer Artikel wäre: warum ich Whoop und Oura parallel trage (HRV-Vergleich), was 21 Monate Whoop-Daten über Sleepmaxxing sagen (Sleepmaxxing-Analyse), oder wo Methylenblau in dem Ganzen einzuordnen ist (MB-Selbstversuch). Wenn dich Quantified Self ernsthaft interessiert, sind das die richtigen Nächsten-Reads.

Disclaimer: Keine medizinische Beratung. biohub ist eine Datenpipeline, kein Diagnostik-Tool. Für klinisch relevante Werte ist immer der Arzt zuständig, nicht dein Whoop und nicht meine Software. Der Code ist MIT-lizenziert — er kommt “as is”, keine Gewährleistung.

Stand: 14. Juli 2026 (Erst-Veröffentlichung)