1. Pebble Time 2

Pebble ist wieder da. Die ursprünglichen Pebble-Uhren gehörten schon vor mehr als zehn Jahren zu den ersten Smartwatches, die nicht versuchten, ein komplettes Smartphone ans Handgelenk zu bringen. Im Mittelpunkt standen ein dauerhaft sichtbares Display, lange Akkulaufzeit, physische Tasten, Benachrichtigungen und kleine Apps. Wer die Geschichte von Pebble nicht mehr ganz präsent hat, findet bei Wikipedia einen guten Überblick.

Mit der Pebble Time 2 und Pebble Round 2 ist dieses Konzept zurück. Ich nutze die Pebble Time 2 inzwischen im Alltag und habe dabei zunächst die offizielle Pebble-App ausprobiert. Die hat mich allerdings nicht lange überzeugt, weshalb ich auf meinem Smartphone mit GrapheneOS inzwischen Gravel verwende. Nebenher sind außerdem ein eigenes Watchface und eine Timer-App entstanden.

Dieser Beitrag ist kein klassischer Test der Pebble Time 2. Mich interessiert weniger, ob der Pulssensor gegenüber einem Brustgurt ein paar Schläge danebenliegt oder wie viele Sportarten sich aufzeichnen lassen. Viel spannender finde ich die Fragen dahinter: Wie viel Hersteller-Cloud braucht die Pebble? Welche Rolle spielt die Smartphone-App? Welche Daten verlassen das Gerät? Was bringt Open Source in der Praxis? Und wie weit kommt man mit Gravel als Alternative zur offiziellen App?

Bei modernen Smartwatches stehen Fitness und Gesundheit häufig im Mittelpunkt. Schlafphasen, Stress, Trainingsbereitschaft, Sauerstoffsättigung, Erholung und diverse daraus berechnete Scores füllen ganze Dashboards. Die Pebble Time 2 kann ebenfalls Schritte und Schlaf aufzeichnen, besitzt einen Herzfrequenzsensor und stellt inzwischen auch eine Schnittstelle für Herzfrequenzvariabilität (HRV) zur Verfügung. Daraus sollte man aber nicht den falschen Schluss ziehen: Die Pebble ist keine Sportuhr und möchte auch keine sein.

Pebble selbst formuliert die Abgrenzung erfreulich deutlich. Das Gesundheits-Tracking sei okay, wer aber vollständiges Fitness- und Sporttracking mit GPS und entsprechenden Auswertungen suche, solle sich eine Garmin oder etwas Vergleichbares kaufen. Auf der Produktseite heißt es ausdrücklich:

You’re looking for a fitness or sports watch. That’s not what we’re making. From what we hear, Garmin watches are great for runners/cyclists/triathletes!

Genau so sehe ich die Funktionen auch. Schritte, Schlaf, Herzfrequenz und HRV nehme ich gerne mit, aber sie sind für mich nicht der Grund, die Pebble zu tragen. Wenn ich detaillierte Trainingsbelastung, GPS-Strecken, Leistungswerte und umfangreiche Gesundheitsanalysen möchte, ist eine Garmin oder Apple Watch dafür besser geeignet.

Noch deutlicher wird diese Ausrichtung bei der Pebble Round 2. Sie verzichtet sogar vollständig auf einen Herzfrequenzsensor und beschränkt das Gesundheitstracking auf Schritte und Schlaf. Wer also vor allem eine klassische Smartwatch mit Benachrichtigungen, Apps, langer Akkulaufzeit und dauerhaft sichtbarem Display sucht, bekommt das Pebble-Konzept dort noch konsequenter umgesetzt.

Das merkt man bereits beim Bedienkonzept. Die Pebble Time 2 besitzt ein 1,5 Zoll großes Display mit 200 × 228 Pixeln und 64 Farben. Bedient wird sie über vier physische Tasten und zusätzlich über einen Touchscreen. Pebble nennt das Display auf der Produktseite »e-paper«. Technisch handelt es sich allerdings nicht um ein E-Ink-Panel wie bei einem E-Book-Reader, sondern um ein transflektives Memory-LCD. Das Display bleibt ohne Hintergrundbeleuchtung dauerhaft sichtbar und benötigt nur wenig Energie, solange sich der Bildinhalt nicht ändert.

Wer sich grundsätzlich für die verschiedenen Techniken hinter solchen stromsparenden Displays interessiert, findet einen Einstieg unter Elektronisches Papier bei Wikipedia. Für die Pebble ist vor allem entscheidend, dass man die Uhrzeit jederzeit sehen kann. Das Display muss nicht erst durch eine Armbewegung aufgeweckt werden – die Hintergrundbeleuchtung wird nur benötigt, wenn das Umgebungslicht nicht ausreicht.

Pebble nennt für die Time 2 eine geschätzte Akkulaufzeit von bis zu 30 Tagen. In einem Update vom Juli 2026 meldete Pebble allerdings einen Median von rund 21 Tagen. Wie lange sie tatsächlich durchhält, hängt von der Nutzung und der verwendeten Software ab. In der Pebble-Entwicklerdokumentation wird ausdrücklich darauf hingewiesen, dass häufige Animationen, Sensorzugriffe, Bluetooth-Kommunikation, Vibrationen und die Hintergrundbeleuchtung den Energieverbrauch erhöhen. Auch beim Watchface macht die Aktualisierungsrate einen Unterschied:

A watchface that plays a half-second Animation for every second that ticks by will drain the battery faster than one that does so only once per minute.

Pebble empfiehlt deshalb, ein Watchface nur einmal pro Minute zu aktualisieren, sofern keine Sekundenanzeige benötigt wird.

Im Alltag liegt der Nutzen der Pebble für mich vor allem darin, Informationen schnell erfassen zu können, ohne jedes Mal das Smartphone herauszuholen. Eine Nachricht kommt herein, die Uhr vibriert und ein kurzer Blick aufs Handgelenk reicht meist aus, um zu entscheiden, ob sie wichtig ist. Dasselbe gilt für Anrufe, Kalendertermine, Wetter oder die Musiksteuerung. In vielen Fällen bleibt das Smartphone danach einfach dort, wo es gerade ist.

Genau das erwarte ich von einer klassischen Smartwatch. Sie soll nicht noch ein Gerät sein, das um Aufmerksamkeit kämpft, sondern im besten Fall dafür sorgen, dass ich das Smartphone seltener herausnehme. Die Pebble wirkt deshalb an manchen Stellen fast altmodisch, aber gerade diese Reduktion gefällt mir. Ich brauche auf der Uhr keinen zweiten App-Kosmos mit unzähligen Funktionen, wenn der wichtigste Anwendungsfall lautet: kurz hinsehen, Information erfassen und weitermachen.

Die Pebble Time 2 besitzt keine eigene Internetverbindung. Sie kommuniziert über Bluetooth Low Energy (BLE) mit dem Smartphone. Die Pebble-App hält diese Verbindung im Hintergrund und übernimmt unter anderem Benachrichtigungen, Synchronisierung von Zeit, Wetter, Kalender und Gesundheitsdaten, die Installation von Watchapps sowie Netzwerkzugriffe im Auftrag der Uhr. Core Devices beschreibt die App selbst als

companion and gateway to the world.

Der Datenweg sieht damit zunächst relativ übersichtlich aus: Pebble Time 2 -> Bluetooth -> Smartphone

Erst auf dem Smartphone entscheidet sich, ob anschließend überhaupt eine Internetverbindung benötigt wird. Wetter muss natürlich irgendwoher kommen, ebenso Firmware, Apps oder Inhalte aus dem Appstore. Das ist aber etwas anderes als eine Architektur, bei der die grundlegende Nutzung des Geräts zwingend an ein Herstellerkonto und eine Cloud gekoppelt ist.

Schon bei der Einrichtung zeigt sich ein Unterschied zu vielen anderen Smartwatches. Die Anmeldung an einem Pebble-Konto ist laut offizieller Anleitung optional. Die Uhr lässt sich also mit dem Smartphone verbinden und grundsätzlich nutzen, ohne zuvor ein Konto bei Core Devices anzulegen. Pebble nennt das Konto bei der Einrichtung unter anderem für die Sicherung von Apps und Einstellungen.

»Optional« bedeutet allerdings nicht, dass sämtliche Funktionen der offiziellen Pebble-App ohne Anmeldung verfügbar sind. Für einige Zusatz- und Onlinedienste wird ein Konto benötigt. Dazu gehört beispielsweise die cloudbasierte Spracherkennung – die lokale Spracherkennung kann dagegen ohne diesen Cloud-Dienst genutzt werden. Auch für bestimmte Ansichten wie die detaillierte Akkustatistik verlangt die App eine Anmeldung. Der Grundbetrieb der Uhr ist also kontofrei möglich, alle Funktionen der offiziellen Companion-App sind es nicht.

Weniger überzeugend ist die Anmeldung selbst. Core Devices setzt dafür ausschließlich auf externe Identitätsanbieter: Zur Auswahl stehen derzeit Google, Apple oder GitHub (Microsoft). Eine Registrierung mit E-Mail-Adresse und eigenem Passwort gibt es nicht. Eric Migicovsky begründet das unter anderem damit, dass Core Devices keinen Support für vergessene Passwörter oder verlorenen Zugriff auf E-Mail-Konten leisten möchte. Ausgerechnet bei einem offenen Ökosystem, das ansonsten viel Wert auf Unabhängigkeit legt, halte ich die zwingende Abhängigkeit von Google, Apple oder GitHub (Microsoft) für einen ziemlich unnötigen Fremdkörper.

Auch bei den Gesundheitsfunktionen verfolgt Pebble einen vergleichsweise zurückhaltenden Ansatz. Die Uhr zeichnet unter anderem Schritte, Schlaf und auf der Time 2 Herzfrequenz auf. Laut Pebble liegen diese Daten auf der Uhr und auf dem Smartphone – standardmäßig wird nichts davon hochgeladen. Wer möchte, kann die Werte anschließend unter Android an Health Connect weiterreichen. Das geschieht jedoch erst nach Aktivierung und entsprechender Berechtigung.

Das passt gut zur Rolle dieser Funktionen. Pebble baut um Schritte, Schlaf und Puls keine große Gesundheitsplattform auf, sondern behandelt sie eher wie zusätzliche lokale Daten der Uhr. Gerade weil Gesundheitstracking bei diesem Gerät ohnehin nicht das zentrale Verkaufsargument ist, gibt es aus meiner Sicht wenig Grund, daraus beim Hersteller eine langfristige Gesundheitshistorie aufzubauen.

Der für mich interessanteste Punkt an Pebble ist deshalb nicht die Sensorik, sondern das Softwaremodell. Open Source bedeutet zunächst einmal, dass der Quellcode öffentlich einsehbar, veränderbar und unter den jeweiligen Lizenzbedingungen weiterverwendbar ist. Bei Pebble gilt das sowohl für PebbleOS als auch für die offizielle Smartphone-App. Core Devices wirbt selbst damit, dass die neuen Pebble-Uhren vollständig mit quelloffener Software betrieben werden und eigene Versionen kompiliert und auf die Uhr geladen werden können.

Ganz ohne proprietäre Bestandteile kommt die ausgelieferte Software allerdings nicht aus. Core Devices nennt selbst unter anderem Software für den Herzfrequenzsensor der Time 2, die Memfault-Bibliothek und optionale Onlinedienste als nicht freie Komponenten. Entscheidend ist aber: Diese Bestandteile sollen nicht für den grundlegenden Betrieb der Pebble erforderlich sein. Die Uhr lässt sich also auch ohne sie mit einem vollständig quelloffenen Software-Stack betreiben – gegebenenfalls fehlen dann einzelne Zusatzfunktionen wie die entsprechende Herzfrequenzmessung.

Open Source macht ein Produkt allerdings nicht automatisch datenschutzfreundlich oder sicher. Es schafft aber eine völlig andere Ausgangslage. Entscheidungen des Herstellers sind überprüfbar, Schnittstellen können nachvollzogen werden und andere Entwickler können auf dem vorhandenen Code aufbauen. Fehlt eine Funktion oder wird eine App nicht weiterentwickelt, kann der vorhandene Code von anderen weitergeführt werden.

Beim genaueren Blick auf die Smartphone-App gibt es allerdings eine interessante Einschränkung. Core Devices bezeichnet sie zwar als vollständig Open Source, entwickelt aber nicht direkt im öffentlichen GitHub-Repository. Im README steht ausdrücklich:

this is a public copy of our internal repo, where we do active development

Die öffentliche Kopie werde regelmäßig, aber manuell synchronisiert und könne deshalb hinter dem internen Entwicklungsstand zurückliegen. Quelloffenheit bedeutet hier also nicht automatisch, dass auch der komplette Entwicklungsprozess öffentlich stattfindet oder sich jeder veröffentlichte App-Build unmittelbar einem sichtbaren Commit zuordnen lässt.

Der Quellcode kann geprüft und selbst kompiliert werden. Die öffentliche Repository-Historie bildet die interne Entwicklung aber nicht zwingend lückenlos und in Echtzeit ab.

Auch KI-Unterstützung ist bei Pebble sichtbar Teil des Entwicklungsprozesses. In der Datei AGENTS.md, die Regeln für Coding-Agents festlegt, findet sich unter anderem die Vorgabe:

Always indicate commit is co-authored by the current AI model

Auch die Smartphone-App enthält mit CLAUDE.md ausführliche Vorgaben für einen Coding-Agenten – von Architektur und Build-Prozess bis hin zu Tests und Coding-Regeln. Wie groß der Anteil von KI-generiertem Code tatsächlich ist, bleibt offen. Klar ist aber: Coding-Agents sind sichtbar in den Entwicklungsworkflow integriert.

Gerade bei Firmware und einer Companion-App mit Zugriff auf Benachrichtigungen und andere sensible Daten sehe ich den Einsatz von Coding-Agents kritisch. Sprachmodelle können fehlerhaften, unnötig komplexen oder sicherheitsrelevanten Code erzeugen, ohne die Folgen zuverlässig einschätzen zu können. Umso wichtiger sind nachvollziehbare Änderungen, gründliche Code-Reviews und automatisierte Tests. Dass Pebble den KI-Einsatz offen dokumentiert, ist positiv – die eigentliche Frage bleibt aber, wie zuverlässig der damit erzeugte Code anschließend geprüft wird.

Ein weiterer Vorteil des offenen Pebble-Ökosystems sind eigene Watchfaces und Apps. Pebble stellt dafür ein SDK bereit, mit dem sich Anwendungen und Watchfaces unter anderem in C entwickeln lassen. Mit CloudPebble existiert zudem wieder eine Entwicklungsumgebung im Browser, in der Code geschrieben, kompiliert, im Emulator getestet und anschließend auf die Uhr installiert werden kann. Wer lieber lokal arbeitet, kann das Pebble SDK installieren.

Bei vielen Smartwatches bedeutet Anpassung letztlich, aus dem auszuwählen, was Hersteller und Appstore vorgeben. Bei Pebble kann man dagegen selbst festlegen, welche Informationen ein Watchface zeigt, wie eine Anwendung funktioniert und welche Daten sie dafür benötigt. Schon mit einer kleinen Watchapp lässt sich die Uhr ziemlich weit an die eigenen Wünsche anpassen.

Bei dieser Offenheit darf man allerdings einen wichtigen Punkt nicht übersehen. Pebble-Anwendungen laufen nicht zwingend ausschließlich auf der Uhr. Über PebbleKit JS kann eine Watchapp oder ein Watchface einen JavaScript-Teil mitbringen, der innerhalb der Smartphone-App ausgeführt wird. Dieser Teil kann unter anderem auf Speicher, Standortdaten und das Internet zugreifen – Netzwerkzugriffe sind beispielsweise über XMLHttpRequest möglich.

Damit ist ein Watchface nicht nur ein Stück Code, das lokal ein paar Pixel zeichnet. Ein Wetter-Watchface kann zum Beispiel über PebbleKit JS den Standort des Smartphones abfragen, damit Wetterdaten für den aktuellen Ort von einem Webdienst laden und diese anschließend auf der Uhr anzeigen. Technisch könnte derselbe Mechanismus aber auch genutzt werden, um Informationen vom Smartphone nach außen zu übertragen. Aus Datenschutzsicht erweitert das den Kreis der Software, der man vertrauen muss. Nicht nur Pebble beziehungsweise Core Devices spielen eine Rolle, sondern auch die Entwickler der installierten Watchapps.

Genau an diesem Punkt wird später Gravel noch einmal interessant.

Ein wichtiger Teil des Pebble-Ökosystems ist der Pebble-Appstore. Dort werden Watchfaces und Anwendungen getrennt angeboten. Gerade bei der Pebble Time 2 ist hilfreich, dass sich die Auswahl unter anderem nach »Made for PT2«, funktionierenden Einträgen, verfügbarem Quellcode oder vorhandener Einstellungsseite filtern lässt. Das macht es deutlich einfacher, aus dem großen Bestand diejenigen Watchfaces und Apps herauszufiltern, die für die aktuelle Hardware tatsächlich interessant sind.

Ich nutze inzwischen nur eine kleine Auswahl davon regelmäßig. Dazu gehören beispielsweise:

• Abfahrt! für die nächsten Abfahrten des öffentlichen Nahverkehrs in der Umgebung
• Rain Radar für einen schnellen Blick auf den Regenradar direkt am Handgelenk
• Calculator als brauchbarer Taschenrechner, der den Touchscreen der Time 2 nutzt
• Wristotle für Sprachbefehle direkt von der Uhr, etwa für Erinnerungen, Notizen oder kleinere Abfragen

Der Appstore ist dabei vor allem Katalog und bequemer Vertriebsweg, nicht die einzige Möglichkeit, Software auf die Uhr zu bekommen. Pebble-Apps und Watchfaces lassen sich auch unabhängig davon als PBW-Dateien installieren. Gerade diese Kombination aus zentralem Appstore und der Möglichkeit zum Sideloading gefällt mir: Man bekommt den Komfort eines normalen Appstores, ohne vollständig von ihm abhängig zu sein.

Die Pebble-App hat zunächst eine ziemlich klare Aufgabe. Sie hält die Bluetooth-Verbindung zur Uhr aufrecht, leitet Benachrichtigungen weiter, synchronisiert Daten, installiert Apps und Watchfaces und dient als Netzwerk-Gateway. Der überwiegende Teil dieser Arbeit ist funktional notwendig, wenn eine Smartwatch ohne eigene Internetverbindung trotzdem Wetter, Kalender oder Onlinefunktionen anbieten soll.

Core Devices hat die App als plattformübergreifendes Open-Source-Projekt aufgebaut. Damit lässt sich zumindest nachvollziehen, welche Komponenten enthalten sind und welche Aufgaben sie übernehmen. Genau deshalb fällt aber auch auf, dass neben den eigentlichen Pebble-Funktionen weitere Dienste und Abhängigkeiten vorgesehen sind.

Im README der offiziellen App nennt Core Devices selbst mehrere Funktionen, für die beim Erstellen der App zusätzliche API-Schlüssel oder andere Zugangsdaten in gradle.properties hinterlegt werden müssen. Dazu gehören Bug-Reporting, Google-Login, Memfault, Online-Transkription und die GitHub-Verbindung für Entwickler. Laut Core Devices funktionieren die Kernfunktionen der App jedoch auch ohne diese zusätzlichen Integrationen. Für einen Android-Build wird außerdem eine google-services.json erwartet.

Firebase ist eine umfangreiche Plattform von Google, die unterschiedliche Dienste für Apps bereitstellt. Welche Firebase-Komponenten eine konkrete Anwendung tatsächlich verwendet und welche Daten darüber verarbeitet werden, muss jeweils einzeln betrachtet werden. Allein das Vorhandensein von Firebase ist deshalb noch kein Beweis für Tracking. Für eine Smartwatch-App, deren Kernfunktionen nach eigener Aussage auch ohne diese Komponenten arbeiten, stellt sich aus meiner Sicht trotzdem die Frage, warum der Unterbau überhaupt notwendig ist.

Ähnlich verhält es sich mit Memfault. Der Dienst ist für Diagnose und Überwachung eingebetteter Geräte gedacht und kann unter anderem Absturzberichte, Logs, Reboot-Gründe und Gerätemetriken sammeln und über eine Cloud-Infrastruktur auswerten. Für Entwickler kann so etwas sehr hilfreich sein, weil Fehler auf Geräten im Feld deutlich einfacher untersucht werden können. Aus Sicht des Nutzers bedeutet es aber gleichzeitig eine weitere Datenverbindung, die für die eigentliche Funktion der Smartwatch nicht zwingend erforderlich ist.

Auch die Datenschutzerklärung von Core Devices ist an dieser Stelle interessant. Das Unternehmen betont dort ausdrücklich, mit Nutzerdaten kein Geld verdienen zu wollen und gegen Werbung und Tracking einzutreten. Positiv ist außerdem, dass genaue Standortdaten der mobilen App nach eigener Darstellung nicht hochgeladen werden und Kontakte nur lokal auf dem Gerät gespeichert werden.

Gleichzeitig nennt die Datenschutzerklärung eine ganze Reihe von Daten, die bei der Nutzung der Dienste anfallen können. Dazu gehören IP-Adresse, eindeutige Gerätekennungen, Betriebssystem, Mobilfunkinformationen, Nutzungs- und Leistungsdaten sowie Fehler- und Absturzinformationen. Aus der IP-Adresse wird ein ungefährer Standort abgeleitet. Core Devices beschreibt außerdem, aus der Nutzung bestimmte Rückschlüsse zu bilden, beispielsweise zur Wahrscheinlichkeit, dass ein Nutzer dem Produkt treu bleibt oder abspringt.

Das ist weit entfernt von einer Fitnessplattform, die sämtliche Körper- und Bewegungsdaten in die Cloud lädt. Es zeigt aber, dass »kein Cloud-Zwang« nicht automatisch »keine Datenverarbeitung« bedeutet. Gerade deshalb lohnt sich ein genauer Blick auf die Companion-App.

Ein eigener Netzwerk-Test zeigt bereits beim ersten Start der Pebble-App ein interessantes Bild. Ohne weitere Nutzerinteraktion kontaktierte die App neben der eigenen Appstore-Infrastruktur mehrere Google-/Firebase-Dienste, GitHub sowie Mixpanel. In meinem DNS-Mitschnitt tauchten unter anderem

• appstore-api.repebble.com
• firebase-settings.crashlytics.com
• firebaseinstallations.googleapis.com
• firebaselogging-pa.googleapis.com
• www.googleapis.com
• raw.githubusercontent.com
• api.mixpanel.com

auf.

Ein Teil davon lässt sich eindeutig zuordnen. firebase-settings.crashlytics.com gehört zu Firebase Crashlytics und dient unter anderem dem Abruf der Crashlytics-Konfiguration. Über firebaseinstallations.googleapis.com stellt Firebase für eine installierte App-Instanz eine eigene Firebase Installation ID bereit. Google beschreibt diese Kennung als eindeutige ID einer Firebase-App-Installation, die unter anderem von Crashlytics und weiteren Firebase-Diensten verwendet wird. api.mixpanel.com gehört dagegen zu Mixpanel, einer Plattform für Produkt- und Nutzungsanalyse.

Bei www.googleapis.com und raw.githubusercontent.com lässt sich allein aus dem DNS-Log nicht sicher bestimmen, welche konkrete Ressource abgerufen wurde. Letzteres wird allgemein für rohe Dateien aus GitHub-Repositories verwendet. appstore-api.repebble.com ist die API des Pebble-Appstores.

Der Netzwerk-Test zeigt lediglich, welche Verbindungen beziehungsweise DNS-Anfragen die App aufbaut, nicht jedoch den konkreten Inhalt der übertragenen Daten. Interessant ist vor allem der Zeitpunkt: Firebase/Crashlytics, Firebase Installations und Mixpanel werden bereits beim ersten Start der App angesprochen, bevor ich die Uhr aktiv genutzt oder weitere Funktionen aufgerufen habe.

Gerade Mixpanel zeigt, dass es dabei nicht nur um technische Diagnose geht. Die Plattform ist für Produkt- und Nutzungsanalyse gedacht. Zusammen mit Firebase Installations und Crashlytics bringt die offizielle Pebble-App damit bereits beim Start einen zusätzlichen Analyse-, Telemetrie- und Tracking-Unterbau mit. Genau hier wird der Unterschied zu Gravel deutlich. Der Fork entfernt nicht nur Google Play Services und Firebase, sondern auch Telemetrie, Analytics, automatisches Crash-Reporting und damit einen großen Teil dieses zusätzlichen Analyse- und Tracking-Unterbaus. Für die eigentlichen Pebble-Funktionen wie Verbindung zur Uhr, Benachrichtigungen, Apps und Watchfaces ist das nicht erforderlich.

Nach meinen ersten Erfahrungen mit der offiziellen App bin ich auf Gravel gewechselt. Dabei handelt es sich nicht um eine vollständig neu entwickelte Pebble-App, sondern um einen unabhängigen Android-Fork des offiziellen Quellcodes. Ziel ist die vollständige Pebble-Funktionalität ohne Google Play Services, Firebase und Telemetrie. Analytics, automatisches Crash-Reporting und das Firmware-Diagnose-Relay wurden entfernt. Gravel richtet sich ausdrücklich auch an Nutzer von GrapheneOS, LineageOS und vergleichbaren Android-Systemen.

Absturzberichte werden nicht automatisch hochgeladen. Bei Bedarf lässt sich stattdessen manuell ein Log-Archiv erzeugen, das vor dem Teilen geprüft werden kann. Gravel ist inzwischen auch im regulären F-Droid-Repository verfügbar.

Für meinen Einsatzzweck passt das wesentlich besser zur Idee hinter der Pebble. Die Uhr selbst kommt im Grundbetrieb ohne Hersteller-Cloud aus – entsprechend möchte ich auch bei der Companion-App auf Analyse-, Telemetrie- und Diagnosedienste verzichten, die für die eigentlichen Funktionen nicht benötigt werden.

Besonders interessant finde ich eine Änderung, die mit »De-Googling« zunächst gar nichts zu tun hat. Gravel beschränkt den Code von Watchapps, der auf dem Smartphone ausgeführt wird. Internet- und Standortzugriff sind standardmäßig gesperrt und müssen pro App freigegeben werden. Wird eine Berechtigung wieder entzogen, gilt das unmittelbar auch für bereits laufende Watchapps.

Auch Classic PebbleKit ist standardmäßig deaktiviert. Über diese ältere Schnittstelle können Android-Apps auf dem Smartphone mit Watchapps kommunizieren. Gravel lässt die neuere, enger zuordenbare Variante aktiviert, während die klassische Broadcast-Schnittstelle bei Bedarf manuell eingeschaltet werden muss. Zusätzlich blockiert Gravel unverschlüsselten HTTP-Verkehr innerhalb der App.

Das ist für mich ein ziemlich sinnvoller Ansatz. Eine offene App-Plattform lebt davon, dass Software von vielen unterschiedlichen Entwicklern installiert werden kann. Daraus sollte aber nicht automatisch folgen, dass jedes Watchface uneingeschränkt Standort und Internetzugriff über das Smartphone bekommt. Gerade bei einer Uhr, deren Stärke in lokaler Verarbeitung und Herstellerunabhängigkeit liegt, passt »deny by default« wesentlich besser.

Auch bei Firmware-Updates geht Gravel einen anderen Weg. Für aktuelle Pebble-Uhren stammen die Firmware-Dateien aus den öffentlichen PebbleOS-Releases bei GitHub. Die Release-Liste wird laut Gravel anonym und ohne Gerätedaten abgerufen. Die passende Firmware wird auf dem Smartphone ausgewählt und vor der Weitergabe an die Uhr anhand der von GitHub veröffentlichten SHA-256-Prüfsumme und Dateigröße überprüft. Zusätzlich kontrolliert Gravel das Manifest und die CRC-Prüfsummen des Firmware-Pakets.

Auch Memfault spielt bei Gravel keine Rolle. Die App enthält keinen Memfault-Token und stellt keine Verbindungen zu Memfault her. Bei der offiziellen Pebble-App kann dagegen ein optionaler memfaultToken dafür sorgen, dass die Update-Prüfung aktueller Pebble-Uhren über api.memfault.com läuft. Dabei werden laut Gravel regelmäßig die Gerätekennung der Uhr, ihre Hardware-Revision und die installierte Firmware-Version übertragen. Je nach Modell ist die Gerätekennung die Seriennummer oder eine aus der MAC-Adresse abgeleitete Kennung.

Die Prüfung durch Gravel ist nur ein Teil der Update-Kette. Interessant ist auch, was anschließend auf der Uhr passiert. Core Devices veröffentlicht mit pblboot den Bootloader der neuen Pebble-Generation. Dieser arbeitet mit zwei Firmware-Slots und einem Recovery-System. Vor dem Start prüft er unter anderem den Firmware-Header sowie eine CRC32-Prüfsumme über das eigentliche Firmware-Image. Der Header selbst ist laut Dokumentation nicht durch diese CRC abgesichert.

Interessant ist, was im öffentlich dokumentierten Validierungsprozess nicht auftaucht: eine kryptografische Signatur der Firmware. CRC32 kann Übertragungsfehler oder beschädigte Images erkennen, bietet aber keinen Schutz gegen gezielte Manipulation und weist auch nicht nach, von wem eine Firmware stammt. Selbst gebaute Development-Firmwares sind ausdrücklich vorgesehen und erhalten eine höhere Boot-Priorität als reguläre Releases.

Das zeigt einen interessanten Zielkonflikt. Ein herstellerkontrollierter Secure-Boot-Mechanismus, der ausschließlich vom Hersteller signierte Firmware akzeptiert, kann die Herkunft des gestarteten Codes absichern, erschwert aber gleichzeitig eigene oder unabhängig weiterentwickelte Firmware. Der öffentlich dokumentierte Pebble-Bootprozess setzt hier stärker auf Offenheit: Gravel prüft ein heruntergeladenes Release zuvor per SHA-256, während pblboot auf der Uhr selbst Header und CRC32 kontrolliert. Eine kryptografische Signaturprüfung ist in diesem dokumentierten Ablauf nicht vorgesehen.

Die Pebble Time 2 besitzt ein Mikrofon und ermöglicht Spracheingaben direkt an der Uhr. Der naheliegendste Anwendungsfall ist das Antworten auf Benachrichtigungen: Nachricht öffnen, Antworten und anschließend Stimme auswählen, Antwort einsprechen, die Transkription prüfen und absenden. Die Diktierfunktion steht aber auch Watchapps über die Pebble Dictation API zur Verfügung. Damit können Entwickler Sprache beispielsweise für Notizen, Befehle oder andere Texteingaben verwenden.

Gravel ersetzt die proprietäre Sprachkomponente der offiziellen App durch whisper.cpp. Dabei handelt es sich um eine freie C/C++-Implementierung der Whisper-Spracherkennung, die vollständig lokal auf Android ausgeführt werden kann. Das auf der Uhr aufgenommene Audio wird zum Smartphone übertragen und dort in Text umgewandelt, ohne dafür zwingend einen externen Transkriptionsdienst zu benötigen.

Das Sprachmodell wird bei Gravel optional heruntergeladen und auf seine Integrität geprüft. Die Erkennung läuft anschließend in einem isolierten Android-Prozess ohne eigene Berechtigungen oder Zugriff auf die App-Dateien. Alternativ lässt sich ein eigener Transkriptionsserver konfigurieren. Gravel unterstützt dafür unter anderem den mit whisper.cpp mitgelieferten Server sowie OpenAI-kompatible Alternativen. Audiodaten werden dorthin nur übertragen, wenn diese Funktion ausdrücklich eingerichtet wurde.

Mit Gravel gibt es bereits eine datenschutzfreundlichere Alternative zur offiziellen Pebble-App. Es gibt aber noch einen dritten Weg: Gadgetbridge. Das freie Android-Projekt unterstützt zahlreiche Smartwatches und inzwischen auch die Pebble Time 2, die dort als »Highly supported« eingestuft wird. Anders als Gravel ist Gadgetbridge kein Fork der offiziellen Pebble-App, sondern eine vollständig eigenständige Implementierung.

Aus Datenschutzsicht verfolgt Gadgetbridge dabei einen besonders konsequenten Ansatz. Die eigentliche App besitzt bewusst keine Android-Berechtigung für den Internetzugriff und kann daher selbst keine Verbindung ins Netz aufbauen. Für Funktionen, die eine Internetverbindung benötigen, gibt es inzwischen einen optionalen Internet Helper. Darüber lassen sich beispielsweise der Pebble-Appstore, Updates von Watchapps und Internetzugriffe von Watchapps ermöglichen. Ohne dieses Zusatzmodul bleibt die Companion-App offline.

Farbenblind-Modus

Unterm Strich liegen Gravel und Gadgetbridge konzeptionell deutlich näher an dem, was ich mir von einer offenen Smartwatch wünsche. Gravel bietet dabei den bequemeren Mittelweg: Appstore, Firmware-Updates und lokale Spracherkennung funktionieren weitgehend wie bei der offiziellen App, gleichzeitig entfallen Telemetrie und Google-Komponenten und die Rechte einzelner Watchapps auf Internet und Standort lassen sich kontrollieren.

Gadgetbridge geht beim Netzwerkzugriff noch konsequenter vor und hält die eigentliche Companion-App vollständig offline. Dafür ist manches, etwa ein Firmware-Update, manueller.

Auch beim Thema KI gibt es einen Unterschied. Bei Pebble ist KI sichtbar in den Entwicklungsworkflow integriert: Sowohl für PebbleOS als auch für die Companion-App existieren entsprechende Anweisungen für Coding-Agents. Gravel erklärt ebenfalls ausdrücklich, KI-Unterstützung bei der Entwicklung einzusetzen. Gadgetbridge erlaubt zwar ebenfalls KI-unterstützte Beiträge, einen vergleichbaren projektweiten KI-Einsatz dokumentiert das Projekt derzeit jedoch nicht. Beiträge bleiben dort ausdrücklich in der Verantwortung eines menschlichen Autors und müssen unter anderem auf echter Hardware getestet werden.

Für meinen Einsatzzweck ist Gravel derzeit deshalb der passendere Mittelweg. Wer dagegen möglichst wenig Netzwerkzugriff der Companion-App möchte und mit etwas mehr Handarbeit leben kann, sollte sich Gadgetbridge genauer ansehen.

Ein großer Teil des Reizes der Pebble wurde mir erst klar, als ich angefangen habe, selbst etwas dafür zu bauen. Es gibt im Appstore zahlreiche Watchfaces, aber keines entsprach vollständig dem, was ich haben wollte. Optisch orientiert sich mein Entwurf am Redux-Watchface, dessen klare Aufteilung mit großer Uhrzeit und seitlicher Informationsleiste mir gut gefällt. Daraus entstand mit Readout ein eigenes Watchface für die Pebble Time 2, das diese Grundidee aufgreift und funktional deutlich erweitert.

Readout soll dabei möglichst viel direkt auf der Uhr erledigen. Die angezeigten Datenfelder lassen sich frei zusammenstellen, Einstellungen bleiben lokal und für Werte wie Schritte, Schlaf oder Herzfrequenz greift das Watchface direkt auf Pebble Health zurück. Auch Funktionen wie Mondphase, Sonnenauf- und -untergang oder Tageslänge benötigen keinen dauerhaft erreichbaren Webdienst. Falls dafür eine Position benötigt wird, kann sie vom Smartphone höchstens einmal täglich übernommen oder als fester Standort hinterlegt werden. Eine Remote-Konfiguration, Tracking oder regelmäßige Hintergrundabfragen gibt es nicht. Gleichzeitig habe ich darauf geachtet, das Watchface möglichst schlank und akkuschonend zu halten.

Je nach Konfiguration können beispielsweise Akku, Datum, Schritte, Distanz, Herzfrequenz, Schlaf, HRV, Sonnenauf- und -untergang, Tageslänge oder Mondinformationen angezeigt werden. Neben der Belegung der Felder lassen sich unter anderem Darstellung, Schriftgrößen, Einheiten und die Ausrichtung der Informationsleiste anpassen.

Daneben ist eine kleine Timer-App entstanden. Auch das ist kein spektakuläres Projekt: vordefinierte Timer, mehrere gleichzeitig laufende Timer, Vibration beim Ablauf und eine Oberfläche, die optisch zum Watchface passt. Genau solche Kleinigkeiten zeigen für mich aber, warum die Pebble Spaß macht.

Wenn mir bei einer geschlossenen Smartwatch eine Funktion fehlt, kann ich entweder hoffen, dass der Hersteller sie irgendwann einbaut, oder im Appstore nach einer halbwegs passenden Lösung suchen. Bei Pebble kann ich mir die Funktion selbst bauen und anschließend direkt als PBW-Datei auf die Uhr laden. Für den Einstieg gibt es sogar ein offizielles Watchface-Tutorial, sodass man sich nicht erst durch das komplette SDK arbeiten muss.

Readout und meine Timer-App wird man vorerst nicht im Pebble-Appstore finden. Der Grund ist nicht technischer Natur, sondern hängt mit der bereits erwähnten Kontoregistrierung zusammen. Für die Veröffentlichung ist ein Entwickleraccount erforderlich und das Pebble-Entwicklerportal verwendet dieselbe Anmeldung wie die offizielle Companion-App: Google, Apple oder GitHub (Microsoft). Eine Registrierung nur mit E-Mail-Adresse und eigenem Passwort gibt es nicht.

Genau darauf habe ich wenig Lust. Eine offene Smartwatch, ein quelloffenes Betriebssystem und ein frei verfügbares SDK passen für mich schlecht dazu, dass ich ausgerechnet für die Veröffentlichung einer kleinen Watchapp ein Konto bei Google, Apple oder GitHub (Microsoft) benötigen soll. Technisch wäre die Veröffentlichung kein Problem – an dieser Stelle ziehe ich aber die Grenze.

Installieren lassen sich beide Anwendungen trotzdem. Pebble-Apps und Watchfaces werden als PBW-Dateien verteilt und können auch ohne Appstore direkt installiert werden. Readout und der Timer bleiben damit vollständig nutzbar. Lediglich der bequeme Vertriebsweg über den Appstore fällt weg.

Bei aller Begeisterung für die Pebble sollte man allerdings nicht übersehen, dass sich die Plattform noch sichtbar in Entwicklung befindet. Pebble selbst macht daraus keinen Hehl und sagt ziemlich deutlich, dass man keine perfekt polierte Smartwatch erwarten sollte. Das Projekt sei eher eine »labour of love« als der Versuch, Millionen Geräte zu verkaufen. Funktionen könnten verspätet kommen, Fehler auftreten und manches werde erst nach und nach fertiggestellt.

Das merkt man derzeit durchaus. PebbleOS entwickelt sich schnell und bekommt laufend neue Funktionen und Fehlerkorrekturen. Die Touch-Bedienung im gesamten System wurde beispielsweise erst im August 2026 aktiviert, ungefähr im gleichen Zeitraum kam auch die HRV-Schnittstelle hinzu. Spätere Updates korrigierten wiederum unter anderem Probleme mit der Akkumessung und Hintergrundbeleuchtung sowie einen Fehler, durch den Herzfrequenz-Abonnenten den Sensor unnötig aktiv halten konnten. Die Entwicklung ist also deutlich in Bewegung – mit dem Vorteil, dass neue Funktionen vergleichsweise schnell hinzukommen, aber eben auch mit den typischen Begleiterscheinungen eines noch jungen Systems.

Auch Gravel entwickelt sich sichtbar weiter. Für mich ist das derzeit kein Ausschlusskriterium, weil die grundlegenden Funktionen funktionieren und ich ohnehin Spaß daran habe, das System zu beobachten und daran herumzubauen. Wer dagegen eine Smartwatch auspacken und anschließend möglichst wenig über Firmware, App-Updates oder kleinere Baustellen nachdenken möchte, dürfte mit einer stärker ausgereiften Plattform von Apple, Garmin oder Samsung bequemer fahren.

Nach meiner bisherigen Zeit mit der Pebble Time 2 sind Pulssensor, Schrittzähler oder HRV für mich nur Zugaben. Wer vor allem Sport- und Fitnessfunktionen sucht, ist mit einer Garmin besser bedient – Pebble sagt im Grunde selbst nichts anderes. Die eigentliche Stärke liegt im einfacheren Konzept: dauerhaft sichtbares Display, lange Akkulaufzeit, Benachrichtigungen am Handgelenk und ein kurzer Blick, der oft schon entscheidet, ob das Smartphone überhaupt aus der Tasche muss.

Aus Datenschutzsicht gefällt mir, dass für den grundlegenden Betrieb weder Konto noch Hersteller-Cloud zwingend notwendig sind und Gesundheitsdaten standardmäßig auf Uhr und Smartphone bleiben. PebbleOS und die Companion-App sind Open Source, eigene Watchfaces und Apps ausdrücklich vorgesehen. Ganz ohne Netzwerkdienste kommt das Ökosystem natürlich nicht aus, aber die Uhr hängt nicht grundsätzlich davon ab, ständig Daten an den Hersteller zu übertragen.

Mit der offiziellen Android-App bin ich trotzdem nicht warm geworden. Firebase, Memfault, Mixpanel und weitere Online-Komponenten passen für mich nicht besonders gut zu diesem Ansatz. Gravel zeigt, was die offene Plattform ermöglicht: Google Play Services, Firebase und Telemetrie fliegen raus, Netzwerk- und Standortzugriffe von Watchapps lassen sich kontrollieren, Firmware kommt transparent aus den öffentlichen Releases und Sprache kann lokal verarbeitet werden.

Einen Punkt sehe ich allerdings kritisch: KI-gestützte Entwicklung ist bei Pebble sichtbar Teil des Entwicklungsprozesses – sowohl bei PebbleOS als auch bei der Smartphone-App. Dass Core Devices das offen dokumentiert, ist besser als ein versteckter Einsatz, ändert für mich aber nichts am grundsätzlichen Problem. Wer Software, bei deren Entwicklung Coding-Agents eingesetzt werden, grundsätzlich nicht nutzen möchte, für den ist Pebble derzeit schlicht nicht die richtige Plattform.

Für mich überwiegen trotzdem die Vorteile. Mit Gravel, einem eigenen Watchface und meiner Timer-App fühlt sich die Pebble Time 2 weniger wie ein Dienst an, der nur so lange funktioniert, wie der Hersteller seine Plattform betreibt. Sie fühlt sich wieder mehr wie ein Gerät an, das mir gehört.

Über den Autor | Kuketz

Als freiberuflicher Pentester und Sicherheitsforscher bei Kuketz IT-Security untersuche ich IT-Systeme, Webanwendungen sowie Android- und iOS-Apps auf Schwachstellen. Darüber hinaus lehre ich IT-Sicherheit an der DHBW Karlsruhe, gebe Workshops und Schulungen und halte Vorträge auf Fachveranstaltungen. Als Autor schreibe ich unter anderem für c’t. Meine Arbeit und der Kuketz-Blog werden regelmäßig in Medien wie heise online, Spiegel Online und der Süddeutschen Zeitung aufgegriffen.

Mehr Erfahren ➡

Unterstützen

Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leser ermöglicht. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.

Folge dem Blog

Neue Beiträge bekommst du per Mastodon, RSS oder E-Mail.