TobyOnFitnessTech
Zurück zu den Analysen
Feldberichte19 Min. Lesezeit

Agenten-Briefing: Erstellung von OpenClaw Fitness-Bericht-Konnektoren für Garmin, WHOOP, Speediance und mehr

Ein implementierungsbereites Agenten-Briefing zur Erstellung von OpenClaw Fitness-Bericht-Konnektoren für Garmin, WHOOP, Speediance, Cronometer, 8Sleep, normalisierte JSON-Snapshots und öffentliche GitHub-Repositories.

Toby 3. Mai 2026
𝕏fin

Dieser Artikel ist dazu gedacht, einem KI-Coding-Agenten als Implementierungs-Briefing übergeben zu werden.

Das Ziel ist nicht, meine private Maschine zu duplizieren oder meine Dateien zu rekonstruieren. Das Ziel ist, dass ein Agent diese Seite liest und funktionierende Konnektoren zu den Fitness-Systemen baut: Garmin, WHOOP, Speediance, Cronometer, 8Sleep und optional Open Wearables.

Die zentrale Anweisung ist einfach: behandle jeden Anbieter als Konnektor, speichere normalisierte JSON-Snapshots und sorge dafür, dass der Report-Generator ausschließlich diese Snapshots konsumiert. Diese Trennung verwandelt das anbieterspezifische API-Chaos in ein vom Agenten aufbaubares System.

Der Agent soll die gleiche Art von Verbindungen aufbauen, ohne sich auf meine exakten lokalen Pfade zu verlassen:

  • Garmin für Cardio, Trainingslast, Pace, Herzfrequenzzonen und Aktivitätsdetails
  • WHOOP für Erholung, HRV, Ruhepuls, Schlaf, Belastung und Readiness-Kontext
  • Speediance für Krafttrainings-Historie, Volumen, Kalorien, Vorlagen und Übungsdetails
  • Cronometer für Ernährungskontext
  • 8Sleep für spät eintreffenden Schlafkontext, sofern verfügbar
  • OpenClaw als Orchestrierungsschicht, die Synchronisierungen ausführt, Daten normalisiert und Berichte erstellt

Es deckt außerdem die GitHub-Projekte, öffentlichen APIs, Datenverträge, Fehlermodi und Abnahmeprüfungen ab, die ein Implementierungs-Agent benötigt, um einen funktionierenden Stack zu erstellen, ohne mein privates Repo zu sehen.

1. Agentenaufgabe

Baue einen lokal-first OpenClaw-Fitness-Reporting-Stack, der sich mit den Systemen verbinden, deren Daten normalisieren und Berichte ohne Live-Anbieter-Aufrufe während des Renderings erzeugen kann.

Der Agent soll folgendes produzieren:

  1. Konnektor-Skripte
    Ein Sync-Job pro System: Garmin, WHOOP, Speediance, Cronometer und 8Sleep, falls konfiguriert.
  2. Roh-Snapshots
    Datierte Roh-JSON- oder CSV-abgeleitete Payloads zur Fehlerbehebung bei Anbieteränderungen.
  3. Normalisierte Verträge
    Stabile JSON-Dateien, denen der Report-Generator vertrauen kann, auch wenn sich Anbieter-Payloads ändern.
  4. Morgenbericht
    Ein Bericht, der Erholung, Schlaf, Readiness, Trainingslast, Ernährung und den Tagesplan kombiniert.
  5. Adaptiver Trainings-Snapshot
    Ein datierter Speediance/BJJ/Laufplan, abgeleitet aus der heutigen Readiness und der jüngsten Belastung.
  6. Nachtbericht
    Ein Plan-vs.-Ist-Vergleich, der prüft, was empfohlen wurde gegenüber der Realität aus Garmin, WHOOP und Speediance.
  7. Veröffentlichbare Ausgabe
    Statisches HTML und maschinenlesbares JSON, das auf GitHub Pages oder einem anderen statischen Host bereitgestellt werden kann.

Baue dies nicht als „ein Skript, das sechs APIs aufruft und HTML live rendert". Das ist fehleranfällig.

2. Architektur, die der Agent implementieren soll

Baue es in vier Schichten:

  1. Konnektor-Schicht
    Ein Sync-Job pro Plattform.

Normalisierte Datenschicht
Jeder Sync schreibt stabile JSON-Snapshots. 3. Analyse-/Berichtsschicht
Der Berichtscode liest ausschließlich normalisiertes JSON. 4. Präsentationsschicht
HTML, Dashboards, tägliche Briefings, Telegram-Beiträge, Sprachzusammenfassungen.

Diese Trennung ist es, die das System wartbar macht.

KI-Implementierungsvertrag

Agent, schließe diesen Vertrag ab, bevor du eine Dashboard-Benutzeroberfläche erstellst:

  • Eingaben: ausschließlich Umgebungsvariablen und Anbieter-Zugangsdaten; niemals Geheimnisse in Quelldateien fest einprogrammieren.
  • Sync-Ausgaben: ein Roh-JSON-Snapshot pro Anbieter-Abruf sowie eine normalisierte JSON-Datei pro Anbieter.
  • Berichtseingaben: ausschließlich normalisiertes JSON. Der Berichts-Builder sollte Garmin, WHOOP, Speediance oder Cronometer nicht direkt aufrufen.
  • Fehlermodus: wenn ein Connector fehlschlägt, die letzte als gut bekannte normalisierte Datei des Vortages beibehalten und diese Quelle im Bericht als veraltet kennzeichnen.
  • Auditierbarkeit: genügend Roh-Nutzlasten aufbewahren, um Änderungen der Anbieter-APIs zu debuggen, ohne Tokens, Cookies, Passwörter oder private Header zu protokollieren.
  • Sende-Freigabe: E-Mail-, Sprach-, Telegram- und adaptive Workout-Aktionen sollten taggleich bewertete Erholungsdaten erfordern. Ein Web-Bericht kann weiterhin im degradierten Modus erstellt werden, aber das System sollte kein selbstsicheres Coaching auf Basis veralteter Erholungsdaten senden.
  • Plan-Snapshots: adaptive Workout-Pläne sollten als tägliche JSON-Snapshots geschrieben werden, bevor sie irgendwohin gesendet werden. Der nächtliche Bericht kann dann den Plan mit dem tatsächlichen Geschehen vergleichen.

Mindestumgebungsvariablen für einen agentenfertigen Build:

GARMIN_EMAIL=
GARMIN_PASSWORD=
WHOOP_CLIENT_ID=
WHOOP_CLIENT_SECRET=
WHOOP_ACCESS_TOKEN=
WHOOP_REFRESH_TOKEN=
SPEEDIANCE_USER_ID=
SPEEDIANCE_TOKEN=
SPEEDIANCE_REGION=Global
CRONOMETER_EXPORT_PATH=
EIGHTSLEEP_EMAIL=
EIGHTSLEEP_PASSWORD=

3. Definition of Done

Ein Implementierungsagent ist erst dann fertig, wenn diese Artefakte existieren und neu generiert werden können:

  • data/garmin/summary/latest.json
  • data/whoop/normalized/latest.json
  • data/speediance/normalized/history.json
  • data/speediance/normalized/by_exercise.json
  • data/nutrition/latest.json
  • data/eightsleep/normalized/latest.json, falls 8Sleep konfiguriert ist
  • data/training_plans/YYYY-MM-DD_morning.json
  • reports/morning/latest.html
  • reports/nightly/latest.html
  • eine Sende-Freigabe, die E-Mail-, Sprach-, Telegram- und adaptive Workout-Sendungen zurückhält, wenn taggleich bewertete WHOOP-Erholungsdaten fehlen
  • Warnungen zu veralteten Quellen, wenn ein Connector fehlschlägt, aber die letzte als gut bekannte normalisierte Datei des Vortages verfügbar ist
  • eine Geheimnisse-frei-Prüfung, die belegt, dass Tokens, Cookies, Passwörter und private Header nicht committed wurden

Wenn der Agent sich während der Entwicklung nicht bei einem Anbieter authentifizieren kann, sollte er trotzdem die Connector-Schnittstelle, .env.example, gefälschte Testdaten, Normalisierung, Behandlung veralteter Quellen und Berichtsintegration implementieren.

4. Öffentliche Projekte und Quellreferenzen

Dies sind die öffentlichen Bestandteile, die ein Agent als Implementierungsreferenzen verwenden sollte.

Kurze GitHub/API-Checkliste:

OpenClaw

  • Plattform/Orchestrator: OpenClaw
  • Rolle: Synchronisierungsjobs planen, Transformationen ausführen, Berichte generieren, Ausgaben veröffentlichen

Garmin

WHOOP

  • Offizielle Entwickler-API-Dokumentation: `https://developer.whoop.com/api``
  • Öffentliche API-Oberfläche: OAuth2 + REST-Endpunkte für Erholung, Zyklen, Schlaf, Workouts, Profil, Körpermaße
  • Optionale Community-Wrapper existieren, aber ein vom Agenten erstellter Connector sollte sich nach Möglichkeit an der offiziellen WHOOP-Entwickler-API orientieren.

Speediance

  • Praktische öffentliche Speediance-Implementierungsreferenz: ANPC86/SmartGymWorkoutManager
    GitHub: `https://github.com/ANPC86/SmartGymWorkoutManager``
  • Upstream-Projektlinie / ursprüngliche öffentliche Referenz: hbui3/UnofficialSpeedianceWorkoutManager
    GitHub: `https://github.com/hbui3/UnofficialSpeedianceWorkoutManager``
  • Verwenden Sie den ANPC86-SmartGymWorkoutManager-Fork als praktische Verbindungsreferenz, da er nützliche Arbeit rund um Verlauf, Exporte, API-Debugging, Zeitzonenbehandlung und Einheitenbehandlung enthält.
  • Dies ist eine inoffizielle Speediance-Integration und sollte standardmäßig als instabil behandelt werden.

Ernährung

  • Cronometer-Produktseite / Exporte / Integrationen: `https://cronometer.com/``
  • Behandeln Sie Cronometer als strukturierte Ernährungsexportquelle, nicht als magische direkte Berichtsabhängigkeit.

5. Produktionsaktualisierungen, die der Agent beibehalten sollte

Die aktuelle Version dieses Stacks weist einige wichtige Verhaltensweisen auf, die der Agent beibehalten sollte.

Einzelner Besitzer-Rechner

Die Fitness-Pipeline sollte einen autoritativen, immer eingeschalteten Rechner haben. Erlauben Sie nicht, dass zwei verschiedene Computer Berichte gegen dasselbe Ausgabe-Repository generieren und bereitstellen.

Die aktive Maschine übernimmt Anbieter-Synchronisierungsjobs, die Berichterstellung, die adaptive Trainingsgenerierung, das Deployment auf GitHub Pages und Watchdog-Prüfungen.

Andere Maschinen können die Berichte einsehen oder lokale Dashboards hosten, sollten aber die Fitnessberichte nicht neu generieren.

Sequenzielle Pipeline statt zeitversetzter Cron-Vermutungen

Die morgendlichen und nächtlichen Pipelines sollten als geordnete Phasen ablaufen:

  1. Anbieterdaten synchronisieren
  2. erforderliche Same-Day-Daten überprüfen
  3. Berichte erstellen
  4. deployen
  5. Benachrichtigungen senden
  6. Sprachzusammenfassungen generieren, falls verwendet
  7. Watchdog-Validierung ausführen

Der alte Fehler besteht darin, diese Schritte zu festen Uhrzeiten zu planen und darauf zu hoffen, dass jede vorherige Phase abgeschlossen ist. Das bessere Muster ist ein einziger Orchestrator, der jede Phase erst startet, nachdem die vorherige sauber beendet wurde.

Same-Day-WHOOP-Erholungs-Gate

Für diesen Stack ist die Same-Day-WHOOP-Erholung eine harte Voraussetzung für das Coaching. Fehlt die heutige Erholung, kann das System zwar weiterhin einen Web-Bericht mit Warnungen zu veralteten Quellen veröffentlichen, sollte jedoch E-Mail-, Sprach- und Telegram-Coaching sowie das Versenden adaptiver Trainings zurückhalten.

Diese eine Regel verhindert den schlimmsten Fehlermodus: eine plausible Empfehlung, die auf der Erholung von gestern basiert.

8Sleep-Spätdaten-Behandlung

8Sleep kann nach dem ersten morgendlichen Lauf aktualisiert werden. Ein erneuter Lauf sollte heute und gestern zwangsweise neu laden, bevor neu generiert wird, anstatt einer vorhandenen lokalen JSON-Datei nur deshalb zu vertrauen, weil sie existiert.

Nur echte Garmin-Herzfrequenzzonen

Erfinde keine Herzfrequenzzonenverteilungen aus der durchschnittlichen Herzfrequenz. Wenn die Garmin-Aktivitätsdetails Time-in-Zone-Daten enthalten, verwende sie. Falls nicht, blende diese Grafik aus oder kennzeichne sie als nicht verfügbar.

Plan-Ausführungs-Review

Der nächtliche Bericht arbeitet jetzt deutlich besser, wenn er den Tagesplan mit den tatsächlichen Tagesdaten vergleicht:

  • geplantes BJJ vs. WHOOP-BJJ-Training
  • geplante Speediance-Einheit vs. abgeschlossene Speediance-Einheiten
  • geplante Laufstrecke vs. Garmin-Laufstrecke
  • geplante Schritte vs. Garmin-Schritte

Dadurch wird der nächtliche Bericht zu einer Feedbackschleife statt nur zu einer Zusammenfassung.

Open-Wearables-Schattenmodus

Open Wearables ist als zukünftige Abstraktionsschicht nützlich, aber ich würde ein funktionierendes persönliches Berichtssystem nicht auf einen Schlag umstellen. Die sicherere Migration ist der Schattenmodus:

  1. die bestehende dateibasierte Pipeline als maßgeblich beibehalten
  2. Garmin-/WHOOP-Daten in Open Wearables importieren oder spiegeln
  3. Open-Wearables-Daten zurück in Schatten-JSON-Dateien exportieren
  4. Schatten-Dateien mit den Produktionsdateien vergleichen
  5. erst dann übernehmen, wenn Anzahlen, Daten und Same-Day-Einträge übereinstimmen

Die Schatten-Dateien dürfen während des Pilotbetriebs niemals Produktionseingaben überschreiben.

6. Garmin: die Cardio- und Aktivitätsdetailschicht

Wenn WHOOP die Frage „wie erholt bin ich?" beantwortet, beantwortet Garmin die Frage „was genau habe ich getan?"

Garmin ist der Teil, in dem der Bericht Folgendes erhält:

  • Distanz
  • Pace und Geschwindigkeit
  • Dauer
  • Durchschnittliche und maximale Herzfrequenz
  • Herzfrequenzzonen
  • Trittfrequenz
  • Leistung
  • Trainingseffekt
  • Aktivitätsmetadaten
  • Umfassendere Cardio-/Trainingsdetails, die WHOOP nicht so stark betont

Zu verwendendes öffentliches Repository

Empfohlen: cyberjunky/python-garminconnect

GitHub: https://github.com/cyberjunky/python-garminconnect

Warum dies wichtig ist:

  • es wird aktiv als der zu verwendende Garmin Connect Python-Wrapper positioniert
  • es stellt eine sehr große Garmin Endpunktoberfläche bereit
  • es enthält Beispiele und Muster zur Token-Verwaltung
  • es ersetzte ältere Authentifizierungsannahmen, die bei früheren Garmin Änderungen fehlschlugen

Wichtiger Garmin Kompatibilitätshinweis

Historisch verwendeten viele Builds garth.

GitHub: https://github.com/matin/garth

Aber garth ist jetzt explizit veraltet. Das ist wichtig, da ein Agent eine neue Implementierung nicht auf veraltete Authentifizierung stützen sollte.

Minimales ausführbares Garmin Beispiel

from garminconnect import Garmin
from datetime import date
from pathlib import Path
import json
import os

email = os.environ["GARMIN_EMAIL"]
password = os.environ["GARMIN_PASSWORD"]

client = Garmin(email=email, password=password)
client.login()

today = date.today().isoformat()
stats = client.get_stats(today)
activities = client.get_activities_by_date(today, today)

payload = {
    "date": today,
    "stats": stats,
    "activities": activities,
}

out = Path("data/garmin/raw")
out.mkdir(parents=True, exist_ok=True)
(out / f"{today}.json").write_text(json.dumps(payload, indent=2))

Was aus Garmin normalisiert werden sollte

Schreibe rohe Garmin Payloads nicht direkt in deine finale Berichtslogik. Normalisiere sie zunächst in Felder wie:

  • calendarDate
  • totalSteps
  • restingHeartRate
  • sleepingSeconds
  • bodyBattery
  • activityName
  • activityType
  • durationSeconds
  • distanceMeters
  • distanceMiles
  • averageHR
  • maxHR
  • calories
  • trainingEffect
  • cadence
  • power

Empfohlenes Speichermuster

  • data/garmin/raw/YYYY-MM-DD.json
  • data/garmin/normalized/YYYY-MM-DD.json
  • data/garmin/summary/latest.json

Das gibt dir sowohl Wiederverwendbarkeit als auch schnellen Berichtszugriff.

7. WHOOP: die Erholungs- und Bereitschaftsschicht

WHOOP ist das, was die Berichte als Entscheidungsmaschine nützlich macht, anstatt nur ein Aktivitätsprotokoll zu sein.

Es liefert:

  • Erholungswert
  • HRV
  • Ruheherzfrequenz
  • Schlafleistung
  • Belastung
  • Zykluskontext
  • Bereitschaftsrahmen für morgendliche und nächtliche Empfehlungen

Zu verwendende öffentliche API

Verwende die offizielle WHOOP Entwickler-API:

  • Docs: https://developer.whoop.com/api --max-tokens 8192 --no-fallback --system Sie sind ein deterministischer professioneller Übersetzer. Geben Sie nur das angeforderte finale JSON-Objekt zurück. Fügen Sie keine Begründung oder Kommentare hinzu.

Relevante Endpunktgruppen:

  • /developer/v2/cycle
  • /developer/v2/recovery
  • /developer/v2/activity/sleep
  • /developer/v2/activity/workout
  • /developer/v2/user/profile/basic
  • /developer/v2/user/measurement/body

Kritische Einschränkung

Eine der wichtigsten Implementierungs­erkenntnisse: Journaldaten sind nicht über die WHOOP-API verfügbar.

Wenn du Journalantworten oder Gewohnheits­annotationen benötigst, kannst du dich dafür nicht auf einen öffentlichen WHOOP-API-Endpunkt verlassen. Die praktischen Optionen sind:

  • manueller CSV-Export aus WHOOP
  • eine eigene parallele Journal­ebene
  • separate Metadaten, die du nach der Synchronisierung anhängst

Diese Einschränkung sollte im Artikel klar genannt werden, da sie jede ernsthafte Implementierung betrifft.

Minimales ausführbares WHOOP-Beispiel

from pathlib import Path
import json
import os
import requests

BASE = "https://api.prod.whoop.com/developer/v2"
TOKEN = os.environ["WHOOP_ACCESS_TOKEN"]
headers = {"Authorization": f"Bearer {TOKEN}"}

def get(path):
    response = requests.get(f"{BASE}{path}", headers=headers, timeout=30)
    response.raise_for_status()
    return response.json()

payload = {
    "recovery": get("/recovery"),
    "sleep": get("/activity/sleep"),
    "workouts": get("/activity/workout"),
}

out = Path("data/whoop/raw")
out.mkdir(parents=True, exist_ok=True)
(out / "latest.json").write_text(json.dumps(payload, indent=2))

Was aus WHOOP normalisiert werden sollte

Normalisiere in Felder wie:

  • recovery_score
  • hrv_rmssd_milli
  • resting_heart_rate
  • spo2_percentage
  • skin_temp_celsius
  • sleep_performance_percentage
  • respiratory_rate
  • strain
  • cycle_start
  • cycle_end
  • workout_sport_name

Empfohlenes Speichermuster

  • data/whoop/raw/recovery.json
  • data/whoop/raw/sleep.json
  • data/whoop/raw/workouts.json
  • data/whoop/normalized/latest.json

8. Speediance: die Krafttraining-Schicht

Speediance ist der ungewöhnlichste Connector im gesamten Stack.

Anders als Garmin und WHOOP handelt es sich hier nicht um eine saubere, offizielle, öffentliche Entwickler­plattform. Der Agent sollte diese öffentlichen Repositories als Verbindungs­referenzen verwenden:

Öffentliche Extraktion/Referenz: https://github.com/clawdassistant85-netizen/speediance-smartgym-workout-manager

ANPC86/SmartGymWorkoutManager
GitHub: https://github.com/ANPC86/SmartGymWorkoutManager

Dieses Repository ist selbst ein persönlicher Fork / eine Weiterführung des ursprünglichen öffentlichen Speediance-Projekts:

hbui3/UnofficialSpeedianceWorkoutManager
GitHub: https://github.com/hbui3/UnofficialSpeedianceWorkoutManager

Diese Repositories sind der wichtige Ausgangspunkt, weil sie zeigen, wie man:

  • sich gegen Speediance-Endpunkte authentifiziert
  • Workout-Daten und API-Antworten überprüft
  • Trainings­verlauf durchsucht/exportiert
  • Vorlagen/Workouts desktopfreundlich verwaltet
  • praktische Probleme wie Zeitzonen­anzeige und Umgang mit imperialen/metrischen Gewichten handhabt

Warum diese Repos wichtig sind

Verwenden Sie den ANPC86 SmartGymWorkoutManager-Fork als praktische Grundlage für das Speediance-Integrationsmuster und bewahren Sie gleichzeitig den hbui3-Upstream-Verweis für die Provenienz auf. Zusammen sind sie die klarsten öffentlichen Referenzen für die Arbeit mit Speediance-Daten außerhalb der offiziellen App.

Stabilitätswarnung

Das Originalprojekt weist darauf hin, dass Speediance Sicherheits-Upgrades implementiert hat. Das bedeutet:

  • diese Integration kann fehlschlagen
  • Header- und Authentifizierungsverhalten können sich ändern
  • Endpunkte können verschoben werden
  • Sie sollten diesen Konnektor hinter einem Normalisierungsschritt isolieren, damit Ihre Berichte anbieterseitige Veränderungen überstehen

Minimales ausführbares Muster für Speediance

Wenn Sie ANPC86/SmartGymWorkoutManager als Ausgangspunkt verwenden und gleichzeitig den hbui3/UnofficialSpeedianceWorkoutManager-Upstream für den Originalkontext prüfen, ist der saubere Ansatz:

  1. Führen Sie dessen App- oder Client-Schicht lokal aus
  2. Authentifizieren Sie sich mit Ihrem Speediance-Konto
  3. Rufen Sie den Trainingsverlauf über die bereitgestellten API-Methoden ab
  4. Exportieren Sie normalisiertes JSON in Ihr eigenes Datenverzeichnis

Pseudo-Beispiel mit diesem Client-Muster:

# Gestalten Sie dies rund um die api_client.py in:
# https://github.com/clawdassistant85-netizen/speediance-smartgym-workout-manager
from api_client import SpeedianceClient
from datetime import date
from pathlib import Path
import json
import os

client = SpeedianceClient()
success, msg, debug = client.login(
    os.environ["SPEEDIANCE_USER_ID"],
    os.environ["SPEEDIANCE_TOKEN"],
)
if not success:
    raise RuntimeError(msg)

start_date = os.environ.get("SPEEDIANCE_START_DATE", "2026-01-01")
end_date = date.today().isoformat()
records = client.get_training_data(start_date, end_date)

out = Path("data/speediance/raw")
out.mkdir(parents=True, exist_ok=True)
(out / "history.json").write_text(json.dumps(records, indent=2))

Was aus Speediance zu normalisieren ist

Normalisieren Sie in Felder wie:

  • training_id
  • date
  • title
  • duration_seconds
  • calories
  • total_volume
  • exercise_count
  • template_name
  • planned_duration
  • actual_duration
  • exercise_breakdown
  • estimated_1rm

Best-Practice-Datenmodell

Für ein ernsthaftes Berichtssystem führen Sie zwei Indizes:

  1. bySession
  • ein Datensatz pro abgeschlossenem Training
  1. byExercise
  • ein Datensatz-Stream pro Bewegungsname
  • enthält Gewicht, Wiederholungen, Seite, Sitzungs-ID, Zeitstempel

Diese Struktur macht Fortschrittsdiagramme und PR-Erkennung später trivial.

Empfohlenes Speichermuster

  • data/speediance/raw/monthly/YYYY-MM.json
  • data/speediance/normalized/history.json
  • data/speediance/normalized/by_exercise.json
  • data/speediance/dashboard/latest.json

Adaptive Speediance-Trainings-Snapshots

Die fortgeschrittenere Version dieses Builds liest nicht nur abgeschlossene Speediance-Trainings.

Es erstellt außerdem geplante Trainingseinheiten aus Live-Readiness-Daten.

Das nützliche Muster ist:

  1. Lade die Erholungsdaten von WHOOP für denselben Tag, den aktuellen Strain, den BJJ-Strain, den Garmin-Body-Battery-Wert, die Ruheherzfrequenz, die aktuelle Lauflast, das Wetter und die jüngste Speediance-Planhistorie.
  2. Ordne den Tag einer Kategorie wie build, maintain, recover, protect oder post_bjj_brutal zu.
  3. Wähle ein Speediance-Implement für das gesamte Training, üblicherweise Griffe, Langhantel oder Seil.
  4. Wähle für das Kern-Speediance-Training ausschließlich gerätebasierte Übungen.
  5. Füge null bis zwei Off-Speediance-Zusatzübungen nur dann hinzu, wenn die Erholung dies zulässt.
  6. Schreibe den Plan nach data/training_plans/YYYY-MM-DD_context.json.
  7. Verwende den Snapshot sowohl für die Morgenempfehlung als auch für die nächtliche Überprüfung der Plan-Ausführung.

Für die Wiederholungskontrolle wird die neue Trainingssignatur mit kürzlichen Plan-Snapshots verglichen. Die Produktionsversion nutzt ein rollierendes Einzigartigkeitsfenster, das auf bis zu 30 Tage anwächst, und versieht den Trainingstitel immer mit dem heutigen Datum, sodass ein erneut auftretendes Training trotzdem frisch und auffindbar bleibt.

9. Cronometer: die Kontext-Ebene für Ernährung

Unabhängig davon, welche Ernährungs-App genau verwendet wird, ist die Rolle dieselbe: dem Bericht Kontext für die Energiezufuhr liefern.

Das ist wichtig, weil Trainingslast ohne Ernährungskontext zu falschen Schlussfolgerungen führt.

Der Bericht sollte folgende Fragen stellen können:

  • War die Erholung niedrig, weil die Trainingslast hoch war?
  • Oder weil der Schlaf schlecht war und die Kalorienzufuhr niedrig?
  • War der Sportler im Verhältnis zur Leistung unterversorgt?

Praktischer Build-Hinweis

Verlasse dich zur Renderzeit nicht auf eine Live-Ernährungs-API. Verwende eine der folgenden Optionen:

  • CSV-Export
  • Webhook-Erfassung
  • Geplanter Sync in normalisiertes JSON

Normalisiere in Felder wie:

  • calories_consumed
  • protein_g
  • carbs_g
  • fat_g
  • fiber_g
  • target_calories
  • estimated_deficit

Empfohlenes Speichermuster

  • data/nutrition/raw/YYYY-MM-DD.csv
  • data/nutrition/normalized/YYYY-MM-DD.json
  • data/nutrition/latest.json

10. 8Sleep: die Kontext-Ebene für spät eintreffende Schlafdaten

8Sleep ist optional, aber wenn es konfiguriert ist, sollte der Agent es wie jeden anderen Connector behandeln: zuerst synchronisieren, dann normalisieren, zuletzt aus Dateien rendern.

Das wichtige Verhalten ist der Umgang mit spät eintreffenden Daten. Schlafdaten können sich nach dem ersten morgendlichen Durchlauf noch ändern, daher sollte ein manueller Neustart oder ein geplanter Wiederholungsversuch sowohl heute als auch gestern zwangsweise aktualisieren, bevor der Bericht neu erstellt wird.

Normalisiere Felder wie:

  • sleep_score
  • sleep_start
  • sleep_end
  • time_in_bed_seconds
  • time_asleep_seconds
  • hrv
  • resting_heart_rate
  • temperature_adjustments
  • away_mode

Empfohlenes Speichermuster:

  • data/eightsleep/raw/YYYY-MM-DD.json
  • data/eightsleep/normalized/YYYY-MM-DD.json
  • data/eightsleep/normalized/latest.json

11. --max-tokens 8192 --no-fallback --system Du bist ein deterministischer professioneller Übersetzer. Gib nur das angeforderte finale JSON-Objekt zurück. Füge keine Überlegungen oder Kommentare hinzu.

Was OpenClaw in diesem Stack tatsächlich tut

OpenClaw ist nicht die Datenquelle. Es ist die Orchestrierungs- und Logikschicht.

Seine Aufgabe ist es:

  • Sync-Jobs zeitgesteuert auszuführen
  • stabile Ausgaben zu speichern
  • Quellen zu vergleichen
  • HTML-Berichte zu erzeugen
  • Links zu veröffentlichen
  • leicht verständliche Zusammenfassungen aus den normalisierten Daten zu erstellen

Das bedeutet, der Berichtscode sollte aus Dateien wie diesen lesen:

  • data/garmin/summary/latest.json
  • data/whoop/normalized/latest.json
  • data/speediance/normalized/history.json
  • data/nutrition/latest.json
  • data/eightsleep/normalized/latest.json

Der Report-Generator muss nie wissen, wie die Garmin-Authentifizierung funktioniert oder wie sich die Speediance-Header diese Woche geändert haben.

12. Von einem Agenten aufbaubare Verzeichnisstruktur

Hier ist eine Struktur, die ein Agent anlegen kann, bevor eine echte Anbieter-Authentifizierung erfolgreich ist:

project/
  data/
    garmin/
      raw/
      normalized/
      summary/
    whoop/
      raw/
      normalized/
    speediance/
      raw/
      normalized/
      dashboard/
    nutrition/
      raw/
      normalized/
    eightsleep/
      raw/
      normalized/
    training_plans/
  scripts/
    sync_garmin.py
    sync_whoop.py
    sync_speediance.py
    sync_nutrition.py
    sync_eightsleep.py
    gate_same_day_recovery.py
    build_adaptive_plan.py
    build_report.py
  reports/
    morning/
      latest.html
    nightly/
      latest.html
  frontend/
    data/

Die Dateistruktur ist Teil der Schnittstelle. Halte sie so einfach, dass ein zukünftiger Agent das System untersuchen, jeden Connector finden, einen einzelnen Sync erneut ausführen und Roheingaben mit normalisierten Ausgaben vergleichen kann.

13. Beispielmuster für einen Report-Builder

Sobald jeder Connector normalisiertes JSON schreibt, wird der eigentliche Berichtscode einfach.

import json
from pathlib import Path

base = Path("data")

garmin = json.loads((base / "garmin/summary/latest.json").read_text())
whoop = json.loads((base / "whoop/normalized/latest.json").read_text())
speediance = json.loads((base / "speediance/normalized/history.json").read_text())
nutrition = json.loads((base / "nutrition/latest.json").read_text())
eightsleep_path = base / "eightsleep/normalized/latest.json"
eightsleep = json.loads(eightsleep_path.read_text()) if eightsleep_path.exists() else {}

summary = {
    "recovery": whoop.get("recovery_score"),
    "hrv": whoop.get("hrv_rmssd_milli"),
    "rhr": whoop.get("resting_heart_rate"),
    "steps": garmin.get("totalSteps"),
    "body_battery": garmin.get("bodyBattery"),
    "lifting_volume": speediance.get("today", {}).get("total_volume"),
    "calories_in": nutrition.get("calories_consumed"),
    "sleep_score": eightsleep.get("sleep_score"),
}

python
html = f"""
<html>
  <body>
    <h1>Täglicher Fitnessbericht</h1>
    <ul>
      <li>Erholung: {summary['recovery']}</li>
      <li>HRV: {summary['hrv']}</li>
      <li>RHR: {summary['rhr']}</li>
      <li>Schritte: {summary['steps']}</li>
      <li>Body Battery: {summary['body_battery']}</li>
      <li>Krafttrainingsvolumen: {summary['lifting_volume']}</li>
      <li>Kalorienzufuhr: {summary['calories_in']}</li>
      <li>8Sleep Bewertung: {summary['sleep_score']}</li>
    </ul>
  </body>
</html>
"""

out = Path("reports/morning")
out.mkdir(parents=True, exist_ok=True)
(out / "latest.html").write_text(html)

Hier zahlt sich das gesamte Design aus: Sobald die Synchronisierungsschicht sauber ist, wird die Berichtsschicht auf die bestmögliche Weise langweilig.

14. Wofür jeder Connector tatsächlich gedacht ist

Dies ist das einfachste mentale Modell:

WHOOP

Verwendung für:

  • Erholung
  • HRV
  • RHR
  • Schlafleistung
  • Belastung
  • Bereitschafts-Einordnung

Garmin

Verwendung für:

  • Lauf- und Cardiodetails
  • Tempo, Leistung, Trittfrequenz
  • HF-Zonen
  • Trainingseffekt
  • detaillierte Aktivitätshistorie

Speediance

Verwendung für:

  • Krafttrainingshistorie
  • Gesamtvolumen
  • Übungsdetails
  • geplante vs. tatsächliche Sitzungsausführung
  • Fortschritt auf Übungsebene, wenn ein Index pro Übung aufgebaut wird

Ernährungs-App

Verwendung für:

  • Kalorienzufuhr
  • Makro-Kontext
  • Erkennung unzureichender Energiezufuhr

8Sleep

Verwendung für:

  • spät eintreffende Schlafdetails
  • bett-spezifische Schlafdauer und Bewertung
  • Gegenprüfungen des Schlafkontexts gegen WHOOP und Garmin

OpenClaw kombiniert anschließend alle zu einer einzigen Berichts- und Empfehlungsoberfläche.

15. Verbindungs-Liefergegenstände nach System

Dies ist die Checkliste, die der Implementierungsagent erfüllen sollte, bevor er die Berichtsoberfläche poliert.

Garmin Verbindungspunkte

  • Bibliothek: garminconnect von cyberjunky/python-garminconnect
  • Authentifizierung: Garmin Connect E-Mail/Passwort mit der Token-/Sitzungsverwaltung der Bibliothek
  • Abruf-Kadenz: tägliche Morgensynchronisierung plus optionale Synchronisierung nach dem Training
  • Mindestabrufe:
    • tägliche Statistiken für Schritte, Ruhepuls, Schlafsekunden, Body Battery, Kalorien
    • Aktivitäten nach Datum für Läufe/Fahrten/Cardio-Einheiten
    • Aktivitätsdetails, falls verfügbar, für HF-Zonen, Tempo, Trittfrequenz, Leistung, Trainingseffekt
  • Normalisierte Ausgabe: data/garmin/summary/latest.json

WHOOP Verbindungspunkte

  • API-Dokumentation: `https://developer.whoop.com/api``
  • Authentifizierung: OAuth2-Zugriffstoken + Refresh-Token-Flow
  • Basis-URL: `https://api.prod.whoop.com/developer/v2``
  • Mindest-Endpunktgruppen:
    • /cycle für Belastungs-/Zyklus-Kontext
    • /recovery für Erholungswert, HRV, Ruhepuls
    • /activity/sleep für Schlafleistung und Schlafzeiten
    • /activity/workout für Workouts und WHOOP Belastungsdaten
    • /user/profile/basic und /user/measurement/body für Profil-/Körperkontext bei Bedarf
  • Normalisierte Ausgabe: data/whoop/normalized/latest.json

Speediance Verbindungspunkte

Cronometer-Verbindungspunkte

  • Öffentliche Quelle: `https://cronometer.com/`` Exporte/Integrationen
  • Empfohlener Implementierungsansatz: CSV-Export oder geplanter Datei-Drop, keine Live-API-Abhängigkeit zur Renderzeit
  • Mindestfelder: Datum, Kalorien, Protein, Kohlenhydrate, Fett, Ballaststoffe und alle Mikronährstoffe, die du in der Erholungsanalyse haben möchtest
  • Normalisierte Ausgabe: data/nutrition/latest.json

8Sleep Verbindungspunkte

  • Authentifizierung: umgebungsgestützter Login-/Sitzungs-Flow, ohne Anmeldedaten im Quellcode
  • Abruf-Kadenz: Morgensynchronisierung plus Neuaufnahme-/Aktualisierungsunterstützung für heute und gestern
  • Mindestabrufe:
    • Schlafwert
    • Schlafzeiten
    • Schlafdauer und Zeit im Bett
    • HRV und Ruhepuls, falls verfügbar
    • Temperatur und Abwesenheitsmodus-Kontext, falls verfügbar
  • Normalisierte Ausgabe: data/eightsleep/normalized/latest.json

Berichtserstellungs-Verbindungspunkt

Der Berichtsgenerator sollte nur stabile normalisierte Dateien und Plan-Snapshots lesen. Eine praktische Form ist:

data/garmin/summary/latest.json
data/whoop/normalized/latest.json
data/speediance/normalized/history.json
data/speediance/normalized/by_exercise.json
data/nutrition/latest.json
data/eightsleep/normalized/latest.json
data/training_plans/YYYY-MM-DD_morning.json
data/training_plans/YYYY-MM-DD_post_bjj.json

Das ist die tatsächliche Verbindungsfläche. Alles Vorgelagerte kann unabhängig davon ausfallen und repariert werden.

16. Die tatsächlichen Implementierungsregeln

Wenn ein Agent dies erfolgreich bauen soll, sind diese Regeln wichtiger als jeder einzelne Code-Schnipsel:

  1. Normalisiere jeden Anbieter in dein eigenes Schema
    Lasse nie zu, dass ein Bericht von der Payload-Form eines Anbieters abhängt.

  2. Behalte rohe Snapshots
    Wenn eine Synchronisierung fehlschlägt, retten dich rohe Payloads.

  3. --max-tokens 8192 --no-fallback --system Du bist ein deterministischer professioneller Übersetzer. Gib nur das angeforderte finale JSON-Objekt zurück. Füge keine Begründung oder Kommentare hinzu.

Niemals aus Live-APIs rendern, wenn der Bericht zeitkritisch ist
Erst synchronisieren, dann rendern.

  1. Inoffizielle Integrationen als austauschbare Adapter behandeln
    Besonders Speediance.

  2. Garmin und WHOOP sollen sich ergänzen, nicht konkurrieren
    WHOOP = Bereitschaft. Garmin = Ausführungsdetail.

  3. Kraftdaten sowohl auf Sitzungs- als auch auf Übungsebene modellieren
    Andernfalls bleibt die Fortschrittsberichterstattung oberflächlich.

  4. Coaching an der heutigen Bereitschaft ausrichten, nicht an der von gestern
    Fehlende taggleiche Erholung sollte das System auf reine Web-Berichterstattung herabstufen.

  5. Den Plan speichern, bevor der Tag bewertet wird
    Ein nächtlicher Adhärenz-Score funktioniert nur, wenn der morgendliche oder Post-BJJ-Plan als Daten gespeichert wurde.

  6. Neue Backends im Schattenmodus pilotieren
    Open Wearables oder jede andere Abstraktionsebene sollte beweisen, dass sie die aktuellen Produktionsdateien abgleichen kann, bevor sie zur Quelle der Wahrheit wird.

Finale Implementierungs-Referenzliste

Dies sind die öffentlichen Referenzen, die einem KI-Coding-Agenten zuerst übergeben werden sollten, wenn er dieses System implementiert:

  • OpenClaw als Orchestrierungsebene
  • Garmin-Connector: https://github.com/cyberjunky/python-garminconnect
  • Garmin historischer Auth-Kontext: https://github.com/matin/garth (veraltet; als Kontext verwenden, nicht als Mittelpunkt eines neuen Builds)
  • WHOOP offizielle Entwickler-API: https://developer.whoop.com/api
  • Speediance öffentliche Extraktion für diesen Build: https://github.com/clawdassistant85-netizen/speediance-smartgym-workout-manager
  • Speediance Upstream/Originalreferenz: https://github.com/hbui3/UnofficialSpeedianceWorkoutManager
  • Berichtsgenerator/Vorlagenreferenz: https://github.com/tobyglenn/scriptsJinja
  • Cronometer Ernährungsexporte: https://cronometer.com/
  • 8Sleep-Connector-Vertrag: umgebungsgestützte Synchronisierung, die data/eightsleep/normalized/latest.json schreibt

Wenn Sie diesen Artikel an Claude Code, Codex, OpenClaw oder einen anderen Implementierungsagenten übergeben, lautet die korrekte Anweisung: zuerst die Connectors bauen, dann normalisierte JSON-Snapshots schreiben, dann das Gate für taggleiche Erholung durchsetzen und zuletzt den Bericht-Renderer bauen. Beginnen Sie nicht mit dem Entwurf des finalen HTML-Berichts.

--- --max-tokens 8192 --no-fallback --system Sie sind ein deterministischer professioneller Übersetzer. Geben Sie nur das angeforderte finale JSON-Objekt zurück. Schließen Sie keine Überlegungen oder Kommentare ein.

#openclaw#garmin#whoop#speediance#Fitness-Berichte#KI-Systeme