Cyberdeck überwachen: Wie ich den Stale-Status meines Telemetrie-Displays behoben habe

**Status: DRAFT, nicht zur Veröffentlichung.** Fehlerhilfe nach unserem Buddy-Telemetrieprotokoll vom 29.10.2026. Redaktioneller Stand: 03.11.2026. Der Titel bezeichnet den behobenen serverseitigen Stale-Befund, keinen unabhängig bestätigten Erfolg am physischen Display. Dessen Sichtprüfung steht offen; laut Abschlussbericht prüft Marcel parallel.

Wer sein Cyberdeck überwachen will, erwartet eine einfache Antwort: Läuft es gerade? Unser Buddy-Aufbau lieferte stattdessen einen scheinbaren Widerspruch. Telemetriedaten kamen an, eine Quelle erschien online, trotzdem tauchte der Zustand `stale` auf. Im Alltag klingt das nach einem Displayfehler. Für die Diagnose war diese Kurzbeschreibung aber zu ungenau.

Belegt ist die serverseitige Anzeige, nicht eine von mir beobachtete Darstellung auf dem Gerät. Der Vorbericht dokumentiert wechselnde Zustände der Quellen; der Abschlussbericht beschreibt den Intervallkonflikt und die anschließende GET-Prüfung. Deshalb schreibe ich hier bewusst nicht, ich hätte ein flackerndes Display gesehen. Die Beobachtung lautet enger: Erfolgreiche Übertragung und ein stabiler Frischestatus fielen auseinander. [Q1, Q2]

`Stale` bedeutet in diesem Zusammenhang nicht automatisch „Sender aus“. Es bezeichnet einen vom Empfänger als überaltert behandelten Datenstand. Alte Messwerte können weiterhin plausibel aussehen. Gerade das macht den Fehler tückisch: Ein glaubwürdiger RAM-Wert erzählt noch nicht, wann er zuletzt angekommen ist.

**Sender läuft.** Ein aktiver Dienst zeigt zunächst nur, dass der Prozess vorhanden ist. Er kann weiterlaufen, obwohl sein Ziel unerreichbar ist, die Authentifizierung scheitert oder die Übertragung länger dauert als gedacht. Prozesszustand und erfolgreicher Versand gehören deshalb in getrennte Prüfungen.

**Server nimmt Daten an.** Dafür brauche ich die Antwort auf den tatsächlichen Telemetrieaufruf. Unsere ausgewählten Logzeilen enthalten `code=200 body=ok`. Das belegt erfolgreiche Antworten auf diese Aufrufe, aber weder die Aktualität bei einer späteren Abfrage noch die sichtbare Ausgabe am Display. [Q3, Q4; 29.10.2026]

**Daten sind frisch.** Diesen Zustand muss ich am lesenden Ende prüfen. Eine erfolgreiche Annahme kann längst zurückliegen. Entscheidend ist, ob die betreffende Quelle beim Abruf noch als aktuell geführt wird und ob neue Übertragungen diesen Zustand zuverlässig erhalten.

**Display zeigt sie wirklich.** Dafür reicht kein Dienststatus, kein POST-Log und keine Browserantwort. Erst eine unabhängige Sichtprüfung am physischen Gerät kann bestätigen, dass Darstellung, Quellenzuordnung und Aktualisierung stimmen. Diese Prüfung fehlt in unserem Abschluss. Die Trennung verhindert, dass wir einen funktionierenden Transport versehentlich als reparierte Hardwaredarstellung verkaufen. [Q1]

Der Abschlussbericht hält den konkreten Konflikt fest: `buddy-pulse.service` war aktiv, der letzte Puls lag weniger als 30 Sekunden zurück, trotzdem ließ das konfigurierte Intervall von 30 Sekunden den Status auf `stale` fallen. Als Änderung ist die Verkürzung auf 10 Sekunden dokumentiert. Alle Intervallangaben stammen aus dem Bericht vom 29.10.2026. [Q1]

Eine exakte Stale-Grenze nennt dieser Bericht nicht. Ich kann daraus weder einen bestimmten Firmware-Schwellwert noch eine genaue Grenzsekunde ableiten. Die belastbare Diagnose ist: Das bisherige Sendetiming reichte im beobachteten Aufbau nicht aus, und nach der Änderung blieb der serverseitige Status während der protokollierten Kontrolle online. Ein vollständig isolierter Kausaltest ist das nicht, denn gleichzeitig wurde eine weitere Quelle dauerhaft versorgt. [Q1]

Die Original-Logs machen die Übertragung greifbar. Hier stehen bereinigte Ausschnitte ohne interne Adressen oder Zugangsdaten. Die Uhrzeiten sind UTC, die Datumsbasis ist jeweils der 29.10.2026; sämtliche Zahlen der folgenden Blöcke stammen aus den bezeichneten Originaldateien. [Q3, Q4]

```text
buddy_pulse.log [Q3]
05:55:38,048432560 code=200 body=ok cpu=26.25 ram=24.76 ram_mb=692 ping=30.6 sess=1
05:55:50,498621715 code=200 body=ok cpu=28.0 ram=24.43 ram_mb=695 ping=2.87 sess=1

buddy_pulse_deck.log [Q4]
05:55:38,183626218 code=200 body=ok cpu=26.25 ram=24.76 rx=0.000000 tx=0.000000 ping=92.3 ram_mb=693 sess=1
05:55:50,342651562 code=200 body=ok cpu=28.00 ram=24.38 rx=0.000000 tx=0.000000 ping=9.39 ram_mb=696 sess=1
```

Die Feldnamen verdienen Misstrauen im besten Sinn. `cpu` ist hier ein aus Load und Prozessorzahl abgeleiteter Indikator, keine direkt gemessene CPU-Auslastung. `ram` bezeichnet einen prozentualen Speicherwert; die Sender berechnen ihn nicht identisch. `ram_mb` steht für verfügbaren Speicher, nicht automatisch für den Speicherverbrauch eines Agenten. `ping` wird als Laufzeit in Millisekunden ermittelt. Die Skripte enthalten Fallbacks, daher sind insbesondere Nullwerte kein zuverlässiger Beleg für gemessene Inaktivität. [Q5]

Warum also nicht zuerst die Registrierung reparieren? Weil der Vorbericht bereits zeigt, dass eine Quelle nach einem angenommenen POST online erscheinen konnte, während die andere stale blieb. Das spricht gegen eine pauschale Erklärung durch fehlende Registrierung. Es beweist aber nicht die umgekehrte Behauptung, alle Quellen müssten gleichzeitig frisch sein, damit das Display funktioniert. Für diese Aussage fehlt uns die belegte Entscheidungslogik. Genau hier hilft die Trennung von Beobachtung und Erklärung: Eine wechselnde Statusseite liefert einen Ansatz für die Untersuchung, aber noch keine vollständige Spezifikation der Firmware. [Q2]

Auch das Timing ist aufschlussreich: Die Zeitstempel markieren den Schleifenbeginn, nicht einen unabhängig protokollierten Empfangszeitpunkt. Messwerterfassung und Anfrage brauchen zusätzlich Zeit. Das konfigurierte Schlafintervall ist deshalb nicht identisch mit dem tatsächlichen Abstand erfolgreicher Empfangsvorgänge. [Q3 bis Q5]

Laut Abschlussbericht änderten wir die Wartezeit in `/usr/local/bin/buddy_pulse.sh` von 30 auf 10 Sekunden und starteten den Dienst neu. Zusätzlich kam `/usr/local/bin/buddy_pulse_deck.sh` mit ebenfalls 10 Sekunden Wartezeit hinzu. Die zugehörige Unit heißt `/etc/systemd/system/buddy-pulse-deck.service`; sie war beim Abschluss aktiviert und aktiv. Auch der ursprüngliche Dienst lief bei der Verifikation. [Q1; 29.10.2026]

Dabei ist eine Grenze besonders wichtig: Der zusätzliche Daemon lief auf dem Pi und sendete unter `source=deck`. Diese Kennung beweist keine Messung auf dem Pixel-Cyberdeck. Wir haben damit die Verarbeitung verschiedener Quellennamen und ihre fortlaufende Versorgung geprüft, nicht unabhängig die Gesundheit verschiedener physischer Rechner. Der Termux-Entwurf blieb als gesonderte Datei erhalten. [Q1, Q5]

Systemd hilft hier bei einem klaren Betriebsmodell: Ein Dienst startet ein benanntes Skript, und sein Zustand lässt sich getrennt von der Empfangsseite prüfen. Für einen eigenen Aufbau würde ich zunächst Unit, tatsächlichen Skriptpfad und Konfiguration abgleichen. Eine Dienstbeschreibung ist kein Beweis für das wirksame Intervall. Vor Änderungen sichere ich die bisherige Konfiguration; bei Problemen stelle ich diese wieder her und dokumentiere den Rückweg.

Die folgenden Befehle sind eine Prüfschablone für passende eigene Systeme, kein neuer Testlauf dieses Artikels:

```sh
systemctl status buddy-pulse.service buddy-pulse-deck.service
systemctl cat buddy-pulse.service buddy-pulse-deck.service
journalctl -u buddy-pulse.service -u buddy-pulse-deck.service
```

Für die laufende Fehlersuche würde ich außerdem die Quelle stets neben dem Antwortstatus notieren. Sonst kann ein erfolgreicher Puls des ursprünglichen Dienstes verdecken, dass der zusätzliche Sender gar nicht ankommt. Ebenso sollte ein Neustart nicht nur mit einem aktiven Prozess quittiert werden: Erst der nächste passende Logeintrag und die nachfolgende Empfängerabfrage schließen diesen Prüfschritt ab. Das ist eine übertragbare Arbeitsweise, keine zusätzliche historische Messung aus unserem Versuch.

Zugangstokens gehören nicht in veröffentlichte Skripte oder Bildschirmfotos. Für die Fehlersuche genügen bereinigte Antwortcodes, Zeitstempel und Quellennamen.

Die Kontrolle fragte die Empfängerseite wiederholt ab. Der Bericht dokumentiert fünf aufeinanderfolgende GET-Antworten mit `Registered devices: 2` sowie `kali-raspberrypi online` und `deck online`. Die vollständige protokollierte Folge lautet: [Q1; 29.10.2026, UTC]

| Zeitpunkt | Registrierte Kennungen | Status |
|---|---|---|
| 05:55:41 | 2 | beide online |
| 05:55:51 | 2 | beide online |
| 05:56:01 | 2 | beide online |
| 05:56:12 | 2 | beide online |
| 05:56:22 | 2 | beide online |

Das ist stärker als eine einzelne erfolgreiche Antwort: Innerhalb dieser Folge blieb der gelesene Zustand stabil. Es ist aber kein Langzeittest und keine Garantie für spätere Netzwerkstörungen. Auch `Registered devices: 2` belegt hier registrierte Quellenkennungen, nicht die Herkunft der Messungen von getrennten Geräten. [Q1]

Das physische Display wurde nicht unabhängig visuell geprüft. Marcel prüft laut Abschlussbericht parallel; ein dokumentiertes Ergebnis dieser Prüfung liegt diesem Draft nicht zugrunde. Der nachgewiesene Erfolg endet daher an der abgefragten Empfängerseite. [Q1]

Offen bleiben außerdem der genaue Firmware-Schwellwert und die vollständige Bedingung für `NO LINK`. Der Vorbericht warnt ausdrücklich davor, diese Logik allein aus Firmware-Strings zu rekonstruieren. Auch einen kontrollierten Ausfall mit anschließendem Wiederanlauf dokumentiert unser Abschluss nicht. Diese Lücken gehören zum Ergebnis, nicht ins Kleingedruckte. [Q1, Q2]

Beginne beim Sender: Wo läuft er wirklich, und woher stammen seine Werte? Prüfe anschließend die tatsächlichen Antworten des Empfängers. Vergleiche dann den realen Übertragungstakt mit der dokumentierten Stale-Regel, einschließlich Messdauer, Netzlaufzeit und möglichen Verzögerungen. Fehlt die Regel, notiere diese Wissenslücke statt einen Schwellwert zu erfinden.

Lies den Status anschließend wiederholt zurück. Halte Zeitpunkte und Quellen einzeln fest; ein Gesamtstatus kann eine veraltete Quelle verdecken. Ein Vergleich verschiedener Quellen hilft bei der Eingrenzung, sofern Herkunft und unabhängige Messung nachgewiesen sind. Eine zusätzliche Kennung auf demselben Rechner ist dafür nur ein begrenzter Test.

Prüfe schließlich die sichtbare Ausgabe direkt und dokumentiere, was du tatsächlich beobachtet hast. Ein kontrollierter Ausfall und Wiederanlauf im eigenen Labor wäre der nächste sinnvolle Test, nicht eine hier bereits erbrachte Leistung. Mein wichtigster Fix war damit auch methodisch: Sender, Annahme, Frische und Darstellung nicht länger als denselben Beweis behandeln.