Ein Ankern, ein Eintrag

Entwicklungstagebuch, Teil 35 · 8. September 2026, abends

Tagsüber war Arbeit. Die Vision PELARON ist momentan eher Privatsache als Haupterwerb, und so bleibt für sie der Abend. Heute waren es gut anderthalb Stunden am Schreibtisch, und es war ein guter Fluss: viele Dinge abgearbeitet, Lieferung auf Lieferung, Prüfliste auf Prüfliste, und am Ende war die Liste dessen, was am Schreibtisch noch zu prüfen wäre, leer bis auf einen einzigen Schritt.

Was gestern Abend aufgefallen war

Gestern hatte ich beim Benutzen gemerkt, dass der Anker, den ich über die Ankerwache setze, nicht im Logbuch steht — während „Anker auf" über die Logbuchseite drinsteht. Heute Nachmittag hat die KI das nachgemessen, bevor sie gebaut hat, und das Ergebnis war deutlicher, als ich es vermutet hatte: Die Wache hatte den Logbuchdienst der App noch nie aufgerufen. Nicht beim Setzen, nicht beim Alarm um drei, nicht beim Aufholen. Kein Vorgang der Wache stand je im Logbuch.

Und unter der Korrektur des Ankermittelpunkts stand seit sechs Tagen der Satz: „Der vorherige Punkt steht im Logbuch." Er stand dort nicht. Ein Satz auf dem Bildschirm ist eine Behauptung — die Regel dazu gibt es seit dem dritten September, und genau so ein Satz hatte sich trotzdem gehalten.

Jetzt schreibt die Wache dieselben neun Ereignisse ins Logbuch wie die Webfassung, wortgleich: Anker gesetzt, Anker geborgen, Ankerposition korrigiert, die Alarme, die Tiefenwache. Aus einer Wiedergabe kommt weiterhin nichts ins Logbuch — eine abgespielte Nacht darf nicht mit dem heutigen Datum im Logbuch landen.

Im Wachstand der App gab es bisher acht Stellen, die einen Vorgang in die Tafel schrieben, und jede einzelne hatte das Logbuch vergessen. Jetzt gibt es eine Stelle, durch die alles geht.

Zwei Einträge für ein Manöver

Beim Bauen fiel das Nächste auf. Wer auf der Logbuchseite „Ankern" tippt, bekam einen Handeintrag „Anker gesetzt" und wurde zur Wache geführt; setzt er dort den Anker, schrieb jetzt auch die Wache einen Eintrag. Zwei Zeilen für ein Ankern, und der Saisonrückblick zählte zweimal. Die Webfassung hat dieselben zwei Einträge, zählt aber nur die von Hand — dort geht die Rechnung zufällig auf.

Ich hatte zwei Fassungen zur Wahl: Entweder schreibt der Knopf im Logbuch nichts mehr und führt nur zur Wache, oder der Rückblick zählt zwei Einträge binnen zehn Minuten als einen. Ich habe die erste genommen. Ausschlaggebend war, dass der Nutzer bei Betätigung der Schnellauswahl trotzdem zur Eingabe der sicherheitsrelevanten Daten gezwungen wird — die passende Kettenlänge bei der jeweiligen Wassertiefe, der Ankergrund, der Alarmradius. Ein Knopf, der das alles überspringt und trotzdem „Anker gesetzt" schreibt, wäre eine Einladung, es zu überspringen.

Das Gegenstück kam gleich danach: Wer nachts im Logbuch „Anker auf" drückt, beendet damit jetzt auch die Wache, und die Wache schreibt den Eintrag — mit Dauer, Radius und Grund. Bisher lief sie einfach weiter, und morgens fand man den Handeintrag neben einer Wache, die noch wachte. Läuft keine, schreibt der Knopf wie bisher von Hand; wer ohne Wache geankert hat, soll es weiter eintragen können.

Elf Zeilen für einen Ausfall

Dann der Test, der gestern offen geblieben war: die Aufzeichnung des Bordnetzes soll vermerken, wann die Verbindung weg war und wann sie wieder da war. Der Mac spielte wieder das Gateway. Ich habe die Verbindung gekappt, eine knappe Minute gewartet, wieder verbunden, die Datei verschickt.

In der Datei standen für diesen einen Ausfall elf Vermerkzeilen. „Verloren", „wartet", „verloren", „wartet" — je ein Paar für jeden gescheiterten Wiederholungsversuch, und die Versuche kommen in immer längeren Abständen. Eine Nacht mit wackligem WLAN hätte Hunderte solcher Zeilen erzeugt. Die Prüfliste hatte etwas anderes versprochen: eine Zeile für weg, eine für wieder da, keine doppelt. Die KI hatte nicht nachgerechnet, was ein Wiederholungsversuch in der Datei hinterlässt, und es aufgeschrieben, als wüsste sie es.

Dabei stand das Wichtige drin: Der Ausfall dauerte 48 Sekunden, und die Wiederholung lief genau so, wie der Quelltext es sagt. Nur die Form war falsch. Jetzt ist ein Ausfall zwei Zeilen — „Verbindung verloren" mit Uhrzeit, „Verbindung steht" mit Uhrzeit, Dauer und Zahl der Fehlversuche. Ob ein Wechsel eine Zeile wert ist, entscheidet der Kern; „wartet" gibt es in der Datei nicht mehr.

Beim zweiten Lauf spielte der Mac die alte Aufzeichnung vom Ankerplatz Zeile für Zeile ein, und die Datei sah aus, wie sie soll: Kopf, Datenzeilen, verloren, steht, Ende. Damit waren zugleich die letzten beiden Schritte erledigt, die seit Tagen auf einen laufenden Bus gewartet hatten.

Die Analysen sind vollständig

Als aus der Wache nichts mehr offen war, hat die KI sich das Nächste genommen, was die Webfassung hat und die native App nicht: die drei Reiter unter Analysen. Saison gab es seit letzter Woche. Heute kamen Kosten und Motor dazu, und die Kachel „Noch nicht gebaut" ist von dem Blatt verschwunden.

Kosten ist aus der Bordkasse: gesamt, Buchungen, Schnitt, Ausgabenarten, darunter Balken nach Art, nach Monat und danach, wer gezahlt hat — die letzten beiden nur, wenn es mehr als einen gibt. Ohne Ausgaben steht da, dass keine da sind, und nicht null Euro.

Motor war die interessantere Sache, weil hier die Lehre von letzter Woche durchschlägt: In der Webfassung ist die Motorstunde im Logbuch eine Laufzeit, in der nativen App ein Zählerstand. Also wird nichts addiert. Betriebsstunden im Jahr sind letzter minus erster Stand des Jahres, und die Stunden zwischen dem letzten Stand eines Jahres und dem ersten des nächsten zählen zu keinem — das steht so auf dem Schirm. Einen „längsten Motorlauf", wie die Webfassung ihn zeigt, gibt es nicht, weil kein Eintrag eine Dauer trägt; was es gibt, ist der größte Zuwachs zwischen zwei Einträgen, und so heißt er auch. Der Zählerstand kommt von Hand, sonst vom Bus, sonst aus dem Logbuch, und die Kachel sagt, woher. Die Wartungsfrist rechnet mit dem Stand, der gilt — auch dann, wenn unter „Mein Boot" keiner steht.

Was bleibt

Der Kern hat heute 39 Prüffälle dazubekommen und jeden Lauf mit der Zeile bestanden, die seit letzter Woche Pflicht ist: die des Läufers selbst, mit Zahl und null Fehlern. Die App ist damit an dem Punkt, an dem ich sie vor dem Törn haben wollte. Was noch offen ist, braucht das Boot — oder, für den letzten Schritt, eine Aufzeichnung auf dem iPad.

Ein guter Fluss. Viele Dinge abgearbeitet.

← Zurück zum Entwicklungstagebuch

PELARON entsteht an Bord der Bluebaerry und am Schreibtisch in Erfurt. Fragen, Widerspruch und Fehlermeldungen sind willkommen.