Withings: mehr als Gewicht — Körperzusammensetzung und Gefäßalter

Eine smarte Personenwaage Foto: Ernest F · Wikimedia Commons (BY-SA 3.0), via Openverse

Eine Personenwaage misst Gewicht. So haben wir es gelernt, und so denken die meisten Menschen über das Gerät im Badezimmer. Man steht drauf, eine Zahl erscheint, man freut sich oder ärgert sich. Aber Gewicht allein ist eine erstaunlich arme Kennzahl. Zwei Menschen mit identischem Gewicht können völlig unterschiedliche Körper haben — der eine muskulös, der andere nicht. Und was das Gewicht überhaupt nicht verrät, ist der Zustand der Gefäße.

Genau an diesem Punkt setzt die Withings-Integration an, an der ich diese Woche gearbeitet habe. Moderne Withings-Geräte sind längst keine Waagen im klassischen Sinn mehr, sondern kleine Messstationen. Sie zu integrieren hieß für mich, die Datenmodelle in Xircuit so zu erweitern, dass sie diesem Anspruch gerecht werden — statt eine reiche Messung auf eine einzige Zahl einzudampfen.

Was eine Withings-Waage wirklich misst

Wer sich auf eine aktuelle Withings-Waage stellt, bekommt weit mehr als Gewicht. Über bioelektrische Impedanzanalyse ermittelt das Gerät die Zusammensetzung des Körpers: Körperfettanteil, Muskelmasse und Körperwasser. Das ist der Unterschied zwischen "78 Kilogramm" und "78 Kilogramm, davon 22 Prozent Fett, mit einer soliden Muskelbasis". Die erste Zahl schwankt mit dem Wasserhaushalt und sagt wenig. Die zweite erzählt eine Geschichte über Training, Ernährung und Fortschritt.

Für Xircuit ist das der eigentliche Wert. Unsere Nutzer wollen nicht nur wissen, ob die Zahl heute höher oder niedriger ist als gestern, sondern ob sich etwas an der Substanz geändert hat. Muskelmasse, die über Wochen steigt, während das Gewicht stabil bleibt, ist ein Erfolg — den eine reine Gewichtskurve niemals sichtbar machen würde. Körperwasser wiederum erklärt einen Teil der täglichen Schwankungen, die sonst wie unerklärliche Sprünge wirken. Deshalb war klar: Wenn wir Withings anbinden, dann nehmen wir alle diese Werte auf, nicht nur den offensichtlichsten. Jede Messung, die das Gerät liefert, ist ein Datenpunkt, den wir später in einer Kurve, einem Trend oder einem Vergleich sinnvoll einsetzen können.

Pulswellengeschwindigkeit und Gefäßalter

Der Teil, der mich technisch am meisten gereizt hat, ist ein anderer. Bestimmte Withings-Geräte messen die Pulswellengeschwindigkeit, kurz PWV. Das ist die Geschwindigkeit, mit der sich die Druckwelle eines Herzschlags durch die Arterien fortpflanzt. Je steifer die Gefäße, desto schneller läuft diese Welle — und Gefäßsteifigkeit ist ein etablierter Indikator für die kardiovaskuläre Gesundheit. Aus der PWV lässt sich ein sogenanntes Gefäßalter ableiten, also eine Einordnung, wie "alt" die Gefäße im Vergleich zum kalendarischen Alter erscheinen.

Diese Werte passen in keine Gewichtsspalte. Also habe ich eine eigene Datenstruktur eingeführt, WithingsBodyComposition, die neben Körperfett, Muskelmasse und Körperwasser eben auch PWV und Gefäßalter erfasst. Das ist bewusst als eigenständiges Modell angelegt und nicht als Anhängsel an einen generischen Gewichtseintrag. Gesundheitsdaten dieser Art haben ihre eigene Semantik, ihre eigene Herkunft und ihre eigenen Datenschutzimplikationen, und sie verdienen ein Modell, das das respektiert. Wer die Werte nicht hat, weil sein Gerät sie nicht misst, bekommt schlicht leere Felder — die Struktur zwingt niemandem eine Messung auf, die es nicht gab.

Ein Maßband als Sinnbild für Körpermaße Foto: Rawpixel (CC0 1.0), via Openverse

Das immer gleiche Muster: Library, Sync, Worker

Wer die letzten Wochen mitgelesen hat, kennt die Architektur schon. Withings folgt exakt demselben Muster wie die Glukose-Anbindung und die anderen Integrationen: eine eigene Provider-Library, ein eigener Sync und ein eigener Worker. Diese Dreiteilung ist keine Formalie, sondern hat sich als tragfähig erwiesen, weil sie jede Anbindung sauber isoliert.

Die Library kapselt alles, was spezifisch für Withings ist — das Datenmodell, die Abbildung der API-Antworten auf unsere internen Typen, die Eigenheiten des Anbieters. Der Sync kümmert sich darum, Daten von außen nach innen zu holen und mit dem abzugleichen, was wir schon haben, ohne Dubletten zu erzeugen, wenn eine Messung zweimal abgefragt wird. Der Worker schließlich läuft im Hintergrund und stößt diese Synchronisation regelmäßig an. Jede neue Integration bekommt ihre eigene Ausprägung dieser drei Bausteine, und keine kann eine andere versehentlich mitreißen. Wenn Withings morgen sein API-Format ändert, bleibt das ein lokales Problem der Withings-Library — der Rest von Xircuit merkt davon nichts. Diese Wiederholung derselben Form über alle Anbieter hinweg macht neue Integrationen berechenbar: Ich weiß vorher, welche drei Teile ich schreibe.

Serverseitiges Polling per OAuth

Bei der Frage, wie die Daten hereinkommen, orientiert sich Withings an der Google-Health-Cloud-Anbindung. Es ist kein Modell, bei dem ein Gerät direkt mit dem Telefon spricht und die App die Werte einsammelt. Stattdessen setzen wir auf einen serverseitigen OAuth-Poller: Der Nutzer autorisiert Xircuit einmalig über OAuth gegenüber Withings, und danach fragt unser Worker in regelmäßigen Abständen die Withings-Cloud nach neuen Messungen ab.

Dieser Ansatz hat handfeste Vorteile. Die Synchronisation funktioniert auch dann, wenn das Telefon des Nutzers gerade aus ist oder die App seit Tagen nicht geöffnet wurde — der Poller läuft serverseitig weiter. Die Autorisierung ist an ein Token gebunden, das erneuert wird, statt an eine ständige Gerätekopplung. Und weil derselbe Denkansatz bereits bei Google Health funktioniert, konnten wir uns an einer erprobten Struktur orientieren, statt jedes Detail neu zu erfinden. Cloud-zu-Cloud statt Gerät-zu-Gerät: für einen Anbieter wie Withings, der ohnehin alles in seiner eigenen Cloud sammelt, ist das der natürliche Weg.

Gebaut, aber noch hinter einem Flag

An dieser Stelle die ehrliche Einordnung, die in einem Dev-Log dazugehört: Die Integration ist gebaut, aber sie ist standardmäßig hinter einem Flag ausgeschaltet. Sie ist noch nicht scharf. Bevor wir sie freischalten, müssen mehrere Dinge stehen, die nichts mit dem Code zu tun haben, aber trotzdem unverzichtbar sind.

Wir brauchen eine registrierte App bei Withings, wir brauchen die zugehörigen Credentials, und wir brauchen eine funktionierende Redirect-URL für den OAuth-Rückkanal. Ohne diese drei läuft der Autorisierungsfluss ins Leere. Genauso wichtig: Wir wollen die Anbindung an einem echten Gerät verifizieren, bevor irgendein Nutzer sich darauf verlässt. Datenstrukturen und Poller sind das eine — aber ob die PWV-Werte, die tatsächlich aus einer echten Waage kommen, korrekt bei uns ankommen und richtig interpretiert werden, zeigt sich erst am Gerät. Solange das nicht bestätigt ist, bleibt das Flag aus. Das ist bei uns kein Zeichen von Unfertigkeit, sondern die bewusste Reihenfolge: erst bauen, dann verifizieren, dann freischalten.