Uhr-App & Fernsteuerung

Eine eigenständige App fürs Handgelenk

Neben dem Web-Dashboard und der Android-Auto-App gibt es seit Kurzem auch eine eigenständige Wear-OS-App (getestet auf einer Pixel Watch 3) – eigenes Icon im App-Launcher der Uhr, kein gekoppeltes Handy nötig im laufenden Betrieb. Vier Seiten zum Durchwischen: Ladeleistung, Akkustand mit Reichweite und Restladezeit, Temperaturen/12V/Reifendruck, und der Zugang zur Fernsteuerung.

Ladeleistung-Seite der Uhr-App — Ladeleistung

Akkustand, Reichweite und Restladezeit auf der Uhr-App — Akkustand · Reichweite · Restladezeit

Temperaturen, 12V-Batterie und Reifendruck auf der Uhr-App — Temperaturen · 12V · Reifendruck

Wie es im Hintergrund funktioniert

Die Uhr spricht direkt, ohne Umweg über ein Handy, per HTTPS mit demselben Backend, das auch dieses Dashboard bedient – über WLAN oder LTE, je nachdem was gerade verfügbar ist. Für die reinen Statuswerte (Akkustand, Reichweite, Ladeleistung, Temperaturen, Reifendruck, Restladezeit) nutzt sie denselben öffentlichen, unauthentifizierten Endpunkt wie dieses Dashboard auch (GET /api/public/status) – dieselbe Datenschutz-Grenze gilt also genauso: kein Standort, keine Kosten, keine Sicherheits-relevanten Zustände. Alle 30 Sekunden fragt die App im Hintergrund neu ab, solange die App-Ansicht geöffnet ist.

Warum vier wischbare Seiten statt einer langen Liste

Die erste Version zeigte alle Werte in einer scrollbaren Liste. Auf Wunsch umgebaut auf fokussierte Einzelseiten zum Durchwischen (HorizontalPager) – am Handgelenk will man meist genau einen Wert auf einen Blick sehen, nicht scrollen müssen.

Was dafür zusätzlich gebaut werden musste

Ein eigenständiges Wear-OS-Projekt ist technisch ein komplett separates Android-Projekt, kein Zusatz zur Android-Auto-App – beide teilen sich keine gemeinsame Code-Basis, auch wenn vieles vom Muster her ähnlich ist.

Neues Datenfeld im Backend: Die Restladezeit (charging_remaining_min) gab es vorher nicht im öffentlichen Status-Endpunkt – extra für die Uhr-Seite "Akkustand" ergänzt. Nur sichtbar, während tatsächlich geladen wird.
Texteingabe auf der Uhr: Normale Texteingabefelder funktionieren auf Wear OS nicht zuverlässig. Für die einmalige Token-Eingabe (siehe Fernsteuerung unten) kommt stattdessen der offizielle Umweg über einen eigenen System-Tastatur-/Sprach-Dialog (RemoteInputIntentHelper) zum Einsatz.
Eigenständige Netzwerk-Deklaration: Die App ist im Manifest explizit als "standalone" markiert – funktioniert komplett unabhängig vom gekoppelten Handy, sobald sie einmal installiert ist.

Wie die Fernsteuerung abgesichert ist

Fernsteuerung (Klimaanlage, Ladestrom-Limit, Verriegelung) ist grundsätzlich sicherheitsrelevant – ganz anders als reine Statusanzeige. Ein Passwort auf einer Uhr einzutippen ist unpraktikabel, deshalb ein anderer Ansatz:

Verriegelung/Entriegelung in der Fernsteuerung der Uhr-App — Verriegeln · Entriegeln

Klimaanlagen-Steuerung in der Fernsteuerung der Uhr-App — Klimaanlage

Ladestrom-Limit-Auswahl in der Fernsteuerung der Uhr-App — Ladestrom-Limit

Zugang zur Fernsteuerung von der Statusseite aus — Fernsteuerung öffnen

Ein dauerhaftes, einmalig eingetipptes Zugriffstoken

Im passwortgeschützten Admin-Bereich lässt sich ein Token erzeugen, das nur ein einziges Mal im Klartext angezeigt wird. Danach speichert der Server nur noch den kryptografischen Hash davon (SHA-256) – genau wie bei Passwörtern wird das Klartext-Token selbst nirgends dauerhaft abgelegt. Wer nur die Datenbank sieht, kann daraus nicht auf das eigentliche Token zurückrechnen.

Dieses Token wird einmalig auf der Uhr eingetippt und bleibt dort dauerhaft gespeichert. Jeder Fernsteuerungsbefehl von der Uhr aus schickt es mit (Authorization: Bearer …) – der Server prüft es gegen den gespeicherten Hash, ganz ohne dass ein Passwort erneut eingegeben werden müsste.

Widerrufbar, jederzeit

Geht die Uhr verloren oder wird sie nicht mehr genutzt: Das Token lässt sich im Admin-Bereich mit einem Klick widerrufen – die Uhr kann dann keine Befehle mehr senden, ohne dass sich am restlichen System etwas ändert.

Bestätigung bei riskanten Befehlen

Entriegeln braucht auf der Uhr eine bewusste zweite Bestätigung (erster Tipp zeigt "Nochmal tippen zum Bestätigen", erst der zweite löst den Befehl aus) – genau wie im Web-Admin-Bereich. Kein versehentliches Entriegeln durch einen einzelnen Tipp am Handgelenk.

Dieselbe Absicherung wie im Web-Admin-Bereich

Befehle von der Uhr laufen über exakt denselben Warteschlangen-Mechanismus wie Befehle aus dem Web-Admin-Bereich: derselbe Cooldown gegen hastiges Mehrfachsenden, dieselbe serverseitige Prüfung der Werte (z.B. nur die vom Fahrzeug tatsächlich unterstützten Ladestrom-Stufen), derselbe Warteschlangen-Poller, der die Befehle ans Fahrzeug weiterreicht. Kein separater, weniger geprüfter Weg nur für die Uhr.

Eine ehrliche Randnotiz zum Bauen selbst

Wear-OS-Entwicklung mit Jetpack Compose lässt sich nicht vollständig testen, ohne den echten Compose-Compiler zu durchlaufen – anders als bei der Android-Auto-App (reine Klassen/Interfaces, ganz normal offline prüfbar) brauchte es hier den ersten echten Build in Android Studio, um wirklich sicher zu sein. Dabei kam auch eine kleine Versions-Kettenreaktion zutage (Android-Gradle-Plugin, Gradle selbst, und die zur Kotlin-Version passende Compose-Compiler-Version müssen alle zusammenpassen) – nichts Dramatisches, aber ein gutes Beispiel dafür, dass bei einer so neuen Plattform wie Wear OS 7 (das Tiles-System wurde erst wenige Wochen zuvor auf "Wear Widgets" umgestellt) Dokumentation und Praxis nicht immer exakt übereinstimmen.