Entwicklungstagebuch, Teil 34 · 5. bis 7. September 2026
Am Samstagmorgen war das iPad wieder da. Zwei Prüflisten lagen seit dem Abend davor, die Motorstunden in der Törnhistorie und der neue Analysenbildschirm mit dem Saisonrückblick. Beide bestanden, in einer halben Stunde. Dann habe ich etwas anderes auf den Tisch gelegt, das mit der App nur am Rand zu tun hatte: ein Hardwaretagebuch und den Entwurf einer Steuerung.
Was ich eigentlich wissen wollte
Die Idee war schon länger da. Auf Bluebaerry hängen Kühlschrank, Instrumente, Lichter, die Standheizung und die Toilette an einer Schalttafel mit Wippschaltern, und jedes Gerät, das mir seinen Zustand meldet, tut das über eine eigene App. Victron hat eine, der Autopilot hat eine, das Echolot spricht mit dem Kartenplotter. Ich wollte eine Platine, die die Verbraucher schaltet und zurückmeldet, was wirklich fließt — und eine App, die alles zeigt.
Vorgelegt habe ich das der KI mit einer klaren Erwartung: einen Vergleich, weltweit. Hat das schon einmal jemand gemacht? Kann man so etwas kaufen? Und während ich darauf wartete, kam der Gedanke, der die Sache erst rund gemacht hat: Wenn PELARON ohnehin auf dem iPad läuft und den Bus liest, warum dann nicht auch die Steuerung darüber — über eine App statt über fünf.
Die Antwort war eine Einschätzung, keine Liste von Produkten. Der Grundgedanke sei besser als das, was man kaufen kann: Fast jedes Produkt am Markt ersetzt die Schalttafel und wird damit selbst zum Einzelpunkt des Versagens — hier bleibt der Wippschalter die Wahrheit, und die Software darf nur einschränken. Und es schließe die eigentliche Lücke von PELARON: Bis heute liest und merkt sich die App, aber sie hat keine Hände.
Was die App dafür heute hat, war schnell gemessen: nichts. Kein Begriff für Verbraucher, kein Schalten, kein Relais im ganzen Kern. Aber es gibt eine Stelle, an der es anknüpfen kann. Die App unterscheidet bereits, wie sicher ein Wert ist — übernommen, gerechnet, gemessen, beobachtet — und zeigt das an. Meine Kette für einen Schaltbefehl, gesendet, bestätigt, Ausgang aktiv, Strom fließt, ist dieselbe Idee für einen Zustand statt für einen Messwert. Das muss nicht erfunden werden, nur übertragen.
Die große Platine
Dann kam der Rat, mit dem ich nicht einverstanden war. Erst eine kleine Platine bauen, vier Kanäle, daran lernen, dann die große. Klingt vernünftig. Ich mache es genau andersherum. Für Bluebaerry, das eigene Boot, würde ich immer die große Version wählen. Bei Tests kann ich alles testen und muss danach nicht wieder von vorn anfangen. Was man am kleinen Aufbau lernt, ist nicht das Schwierige; Wärme, Strompfade, Masse und die Firmware für viele Kanäle zeigen sich erst in voller Größe. Die Platine wird gerade so gezeichnet: WLAN, Bluetooth und Mobilfunk auf einem Brett.
Und es ist ein Winterprojekt. Ein Blick aufs Datum reicht: In zwei Monaten kommt das Boot aus dem Wasser, dann ist die Saison vorbei, und Löten, Firmware und App konkurrieren mit nichts mehr. Die KI hatte als eigentliches Risiko „die Abende“ genannt, dass die Hardware die Software auffrisst. Im Winter gibt es diese Konkurrenz nicht.
Was von ihrer Einschätzung geblieben ist: In den Stromkreis der Navigationsinstrumente gehört kein selbstgebautes Relais, dort hängt der Autopilot. Dieser Kanal wird gemessen, das Relais bleibt unbestückt. Und die Standheizung wird der erste Kanal, der in Betrieb geht — sie ist an Bord, der Nutzen ist sofort da, und sie beantwortet an einem einzigen Verbraucher die Frage, ob PELARON nur ausschalten oder auch einschalten darf.
Der Sonntag
Am Samstag hatte ich der KI noch gesagt: Entwickle die native App so weit, dass einem Törn auf dem Wasser und einem ausführlichen Test nichts mehr entgegensteht. Sie hat daraufhin die Aufzeichnung des Bordnetzes umgebaut. Die endete bisher nach einer Viertelstunde, weil sie alles im Arbeitsspeicher hielt und dann aufhörte — und die Liste für den Donnerstag verlangt eine halbe Stunde AIS am Stück. Jetzt schreibt sie in Blöcken auf die Platte, legt die Datei beim Start an, und der Bildschirm bleibt an, solange sie läuft.
Ich habe am Sonntag nichts davon geprüft. Ich habe an der Hardware gearbeitet, den ganzen Tag. Es gab auch Momente an der App, aber die Idee der Steuerung hat sich weiterentwickelt, und beim Ausprobieren und Setzen der ersten elektronischen Bauteile kam der Spaß an der Sache wieder durch, wie zu Jugendtagen. Die App war zwei Tage still. Das war in Ordnung.
Der Montag am Schreibtisch
Am Montagnachmittag saß ich wieder am iPad, ohne Boot, ohne Bordnetz. Die Frage war, wie man eine Aufzeichnung prüft, wenn nichts ankommt. Die erste Antwort lautete: liegen lassen bis Donnerstag. Ich habe es trotzdem probiert, und nach „Mitschnitt beenden“ kam der Knopf zum Verschicken der Datei nicht. Die App zeigte ihn nur, wenn mindestens eine Zeile aufgezeichnet war. Ohne Bordnetz kommt keine Zeile. Die Datei gab es trotzdem längst, seit dem Start. Der Bildschirm hat eine Datei geleugnet, die da war.
Die Datei, als ich sie dann hatte, trug keine einzige Zeitangabe. Der Kopf wurde beim Start geschrieben, die Startzeit aber erst mit der ersten Zeile gesetzt — in jeder Datei hätte sie gefehlt, nicht nur in der leeren. Zwei Lieferungen später stand die Startzeit im Kopf, und die Datei vermerkte, wann die Verbindung stand, wartete oder verloren ging. Denn das war der nächste Punkt: Vierzig Sekunden ohne WLAN sahen in der Aufzeichnung genauso aus wie vierzig Sekunden ohne Echolot. Am Donnerstag will ich wissen, ob die Tiefenwache Aussetzer zählt. Ohne diesen Vermerk hätte ich es nicht unterscheiden können.
Dann der Test, den ich am Schreibtisch nicht für möglich gehalten hatte. Der Mac spielt das Gateway: ein Befehl im Terminal, der auf dem Anschluss des Bordnetzes lauscht, im iPad die Adresse des Macs eingetragen. Ich habe es gestartet, und es passierte rein gar nichts. Weder am iPad noch am Mac. Ich habe gefragt, ob es daran liegt, dass das iPad noch per Kabel am Mac hängt. Dann ein Blick auf den Bordnetz-Bildschirm: verbunden, aber still. Der Mac hatte die Verbindung längst angenommen — der Befehl schweigt, wenn er das tut. Und in der Zeile darunter stand, was das iPad in der Zwischenzeit erlebt hatte: mehrere Abbrüche, Dutzende Versuche, jedes Mal binnen Sekunden wieder verbunden. Die Wiederverbindung tat genau das, was der Quelltext versprach. Ich hatte eher mit einem Fehlverhalten meinerseits gerechnet. Ich bin froh, dass es ohne weitere Fehler bestanden hat.
Was noch auffiel
Beim Benutzen, nicht beim Prüfen: Wenn ich den Anker über die Ankerwache setze, steht davon nichts im Logbuch. Wenn ich ihn über die Logbuchseite wieder hole, steht das drin. Die Webfassung schreibt beides. Das ist notiert und kommt als Nächstes.
Und am Abend, beim Setzen der Gesamtausgabe, fand die KI zwei Fehler in der Ausgabe vom Donnerstag, die seit vier Tagen auf pelaron.de lag: rohe Formatierungszeichen in den Zwischenüberschriften des vorigen Teils, und alle Seitenzahlen im Inhaltsverzeichnis um eins zu klein, weil der Setzer mit zwei Verzeichnisblättern gerechnet und eines gesetzt hatte. Niemand hatte das fertige Heft aufgeschlagen. Die Regel, die genau das verlangt, steht seit dem dritten September im Heft — und galt offenbar nur für Prüflisten. Jetzt gilt sie für alles, was gesetzt wird.
Was bleibt
Die App ist bereit für einen Törn. Die Aufzeichnung läuft stundenlang, der Bildschirm bleibt an, die Datei weiß, wann sie begonnen hat und wann die Verbindung fehlte. Was noch offen ist, braucht das Boot: die Datei vom echten Bus, AIS eine halbe Stunde, eine Nacht Ankerwache. Und ab jetzt zählt jede Aufzeichnung doppelt. Im Winter, wenn das Boot an Land steht, ist die Wiedergabe das einzige Boot, das ich habe. Was ich jetzt nicht mitschneide, fehlt beim Programmieren.
Das Hardwaretagebuch bekommt auf pelaron.de eine eigene Reihe. Es trägt die Adresse im Fuß schon.
← Zurück zum Entwicklungstagebuch
PELARON entsteht an Bord der Bluebaerry und am Schreibtisch in Erfurt. Fragen, Widerspruch und Fehlermeldungen sind willkommen.