BooxPlanner
Eine Handschrift-Schleife in beide Richtungen, zwischen einem E-Ink-Tablet und Notion.
- seit 2025
- in Arbeit
- Architekt & Umsetzer
- Python, WeasyPrint, Jinja2, n8n, Gemini Vision, Notion API, Google Fit
Das Problem
Ich schreibe seit jeher von Hand, Aufgaben, Pläne, Notizen, aber ab einer gewissen Last trägt das nicht mehr. Notion hielt die Struktur, eine App auf dem Telefon die Bequemlichkeit, das Papierheft das Einzige, worauf es wirklich ankam, nämlich den physischen Akt des Schreibens. Jede dieser Lösungen deckte einen Teil ab und brach einen anderen.
Die harte Randbedingung ist die Hierarchie. Ein Quartalsziel, das wortgleich auf der Monats-, Wochen- und Tagesseite steht, nimmt dem gedruckten Planer seinen Sinn. Ein Sprachmodell, das Ziele auf die jeweils passende Detailtiefe herunterbricht, macht deshalb die gedruckte Seite überhaupt erst lohnend.
Die Lösung
Jeden Morgen liest ein Dienst die Ziele aus Notion, lässt sie von einem Sprachmodell auf Monatsfokus, Wochenziele und Tagesfokus herunterbrechen und liefert den Planer als PDF auf ein E-Ink-Tablet. Geschrieben wird weiter mit dem Stift, führend bleibt Notion. Das abendliche Zurücklesen der Handschrift ist in Teilen gebaut, aber noch nicht in Betrieb.
- gerieten in Papiernotizen aus dem Blick
- stehen automatisch auf jeder Tagesseite
2026-05-12
Das Ergebnis
Die Morgenhälfte ist im Einsatz, erster Produktivlauf am 12.05.2026. Das abendliche Zurücklesen ist in Teilen gebaut, aber noch nicht verdrahtet, /process-annotations ist weiterhin ein Stub, und die OCR-Genauigkeit ist bislang ungemessen.
Das ehrliche offene Problem ist nicht der Code, sondern die Gewohnheit. Ob so etwas täglich benutzt wird, ist genauso eine Verhaltensfrage wie eine technische, und das ist der Teil, den ich nicht gelöst habe.
Die Technik dahinter
Die Architektur
Eine Morgenpipeline hinter einem FastAPI-Dienst, der in einem Docker-Container auf einem Heimserver läuft. Ein Cron schickt ein POST an /generate. Der Dienst liest die Notion-Datenbanken, lässt ein Sprachmodell die Quartalsziele in Monatsfokus, Wochenziele und Tagesfokus herunterbrechen, rendert ein Jinja2-Template, übergibt das HTML an WeasyPrint und legt ein Wochen-PDF in einen Cloud-Ordner, den das Tablet abholt. Das Herunterbrechen wird wöchentlich gecacht, also kostet der tägliche Lauf fast nichts.
Die Abendhälfte, geplant und noch nicht live, liest die handschriftlichen Ergänzungen zurück: ein Trigger auf Änderungen im Cloud-Ordner, ein Pixelvergleich, der nur die tatsächlich beschriebenen Seiten findet, dann Vision-OCR nach Notion. Darunter liegt ein rückentwickelter Parser für das .note-Format des Tablets: 16 Byte pro Strich hinter einem 80-Byte-Header, dazwischen ein Trenner, der die Ausrichtung verschiebt, und eine Resynchronisierung, sobald unmögliche Koordinaten auftauchen.
Entscheidungen und Abwägungen
Zwei Ordner statt einem. Erzeugte Seiten gehen über den einen Cloud-Ordner hinunter, beschriebene über den anderen hinauf. Sie können sich physisch nicht gegenseitig füttern, also liest der Generator seine eigene Ausgabe nie wieder ein. Es ist die einfachste denkbare Absicherung gegen eine Sync-Schleife.
Erst vergleichen, dann bezahlen. Bevor etwas an ein Vision-Modell geht, vergleicht das System das saubere und das beschriebene PDF Pixel für Pixel und schickt nur die geänderten Seiten, typischerweise eine bis drei von zwölf. Die Kosten folgen den Änderungen und nicht der Dokumentgröße.
Der größte Teil von KI-Entwicklung mit Budget besteht darin zu wissen, wo man das Modell nicht aufruft.
Der Abend wartet, bis der Morgen steht. Der Endpunkt /process-annotations ist mit Absicht ein 501-Stub. Beide Richtungen gleichzeitig live zu nehmen verdoppelt die Fläche für halb funktionierende Abhängigkeiten, und ein wackeliger OCR-Schritt würde einen wackeligen Generierungsschritt verdecken. Eine Richtung muss verlässlich laufen, bevor die andere sich auf sie stützt.
Was schiefging
Der Weg zu den Gesundheitsdaten brauchte zwei Anläufe: Ein direkter Geräte-Login verlangte einen MFA-Code, was am Terminal funktioniert, unter Cron aber nicht, weshalb der Abruf hinter eine REST-API wanderte.
Der Annotations-Speicher des Tablets erwies sich als überschreibungsfeindlich: Die App schreibt ihre Zwischenstände aus dem Arbeitsspeicher zurück, solange sie nicht geschlossen ist. Der sauberste Ausweg war, die Dateinamen wöchentlich zu rotieren.
Und der .note-Parser läuft vier Byte daneben, sobald der Trenner zwischen zwei Strichen zufällig wie ein Datensatzanfang aussieht. Deshalb resynchronisiert er bei Koordinaten, die gar nicht auf dem Bildschirm liegen können.
Ein ähnliches Problem im eigenen Betrieb?
Was ich für Unternehmen macheSie besetzen eine Rolle in angewandter KI oder Solutions-Architektur?
Der vollständige Werdegang