Coding

Scripts, Tools ...

Next.js · PocketBase · Docker

2026

Das Kullikson-Ökosystem

Vier selbst gehostete Apps, eine konsolidierte Datenbank-Instanz, ein Docker-Netz. Erfassung per iPhone-Shortcut, Auswertung im Browser.

Details ansehen →

Next.js · PocketBase · Docker · 2026

Das Kullikson-Ökosystem

Screenshots

finapi – Historie: Ausgaben der letzten Monate nach EC- und Kreditkarte

Jede kleine App bekam anfangs ihre eigene PocketBase, ihren eigenen Container, ihre eigene Backup-Routine. Vier Apps später war das vier Mal Wartung für dieselbe Sache.

Lösung

Eine gemeinsame Instanz pocketbase-core im Docker-Netz pb-core. Jede App bringt nur ihre eigenen Collections mit, teilt sich aber Datenbank, Backups und Auth-Schicht. Neue App = neuer Port, neue Collections, fertig. Frontend jeweils Next.js mit /api/pb-Proxy, weil PocketBase kein Cloudflare-Auth versteht.

Apps im Ökosystem

finapi

Haushaltsausgaben im Kreditkarten-Zyklus (24.–23.), Donut- und Balkendiagramme, Monatshistorie und Year-over-Year-Vergleich.

fuel-tracker

Tankkosten für zwei Autos – Auto, Strecke, Menge, Literpreis per Shortcut; Verbrauchstrend und direkter Vergleich Thor vs. Oskar.

energy-tracker

Zählerstände für Strom, Einspeisung und Wasser – Jahresvergleich, witterungsbereinigt nach VDI 3807 mit Heizgradtagen aus der Open-Meteo-API.

vacapi

Urlaubsausgaben in Fremdwährung – tagesaktueller EZB-Kurs, sofortige EUR-Umrechnung inklusive erwarteter Kartengebühr.

Was es kann

—Eine PocketBase-Instanz für alle vier Apps – ein Backup, ein Auth-Modell

—Gemeinsames externes Docker-Netz pb-core, jede App auf eigenem Host-Port

—Alle öffentlichen Domains über Cloudflare Zero Trust (Access) abgesichert

—Einheitliches Muster: iPhone-Shortcut → /api/pb-Proxy → PocketBase → Dashboard

Gebaut mit

Next.jsPocketBaseDockeriOS ShortcutsRechartsCloudflare Zero TrustRaspberry PiClaude Code

Vanilla JS · PocketBase

2026

Rezepte Buch

Digitales Familienkochbuch – 187 Rezepte aus dem Obsidian-Vault, migriert nach PocketBase, von jedem Gerät im Haus abrufbar.

Details ansehen →

Vanilla JS · PocketBase · 2026

Rezepte Buch

Screenshots

Rezept-Detail: Zutaten, Zubereitungsschritte, Portionen und Quelle

„Was essen wir heute?“ – die Frage, die sich bei uns täglich stellt. 187 Familienrezepte lagen verstreut in Notizbüchern und Markdown-Dateien.

Lösung

Ein einmaliges Migrationsskript hat die Markdown-Rezepte aus dem Obsidian-Vault nach PocketBase überführt. Seitdem ein schlankes Vanilla-JS-Frontend – Galerie, Spotlight-Suche, Anlegen und Bearbeiten direkt im Browser – ausgeliefert von einem zero-dependency Node-Server, selbst gehostet auf dem Raspberry Pi. Der ursprüngliche Chat-Assistent ist wieder rausgeflogen: Die Suche allein reicht.

Was es kann

—Spotlight-Volltextsuche über Titel, Zutaten und Tags

—Kategorie-Filter: Frühstück, Mittag, Abend, Snacks

—Rezepte anlegen, bearbeiten und löschen direkt im Browser

—Foto-Upload pro Rezept (JPG/PNG/WebP/AVIF)

—Zutatenbezogene Farbthemen – Fisch blau, Hähnchen gelb-orange

Gebaut mit

Vanilla JSPocketBaseNode.jsDockerWoodpecker CIRaspberry PiObsidianClaude Code

React

2025

school eLearning

Interaktives Lernquiz für Kinder – Wissen aus echten Schularbeitsblättern, spielerisch und mit Metriken wo noch Lücken sind.

Details ansehen →

React · 2025

school eLearning

Screenshots

Profilauswahl – jedes Kind hat ein eigenes Profil mit separaten Statistiken

Schularbeitsblätter stapeln sich – aber ob der Stoff wirklich sitzt, merkt man erst in der Prüfung. Wir wollten Lernen einfacher und messbarer machen.

Lösung

Ein interaktives Quiz direkt aus dem Schulstoff – 4 Fragetypen, didaktische Erklärungen bei Fehlern, und ein Admin-Bereich der zeigt wo noch Lücken sind.

Was es kann

—Wissen aus echten Schularbeitsblättern – 52 Fragen, 10 Kapitel

—Erklärung bei falscher Antwort: "Merke Dir..." statt einfach weiter

—4 Fragetypen: Multiple Choice, Lückentext, Reihenfolge, Zahleneingabe

—Bonus-Runde: falsch beantwortete Fragen kommen nochmals

—Admin-Bereich mit Metriken – sichtbar wo noch Lücken sind

—Multi-Profil: beide Kinder nutzen dasselbe Gerät, Statistiken getrennt

Gebaut mit

ReactPocketBaseDockerRaspberry PinginxClaude Code

GitHub ↗

Next.js · PocketBase

2026

energy-tracker

Zählerstände für Strom, Einspeisung und Wasser per Ablesung erfassen, im Jahresvergleich auswerten – witterungsbereinigt nach VDI 3807.

Details ansehen →

Next.js · PocketBase · 2026

energy-tracker

Screenshots

Jahresvergleich Strombezug 2023–2026 mit Modus-Umschalter – Bezug, Einspeisung, Gesamtverbrauch, Wetterbereinigt

Seit der PV-Anlage ist der Netzbezug allein kein guter Verbrauchsindikator – ein dunkler Monat heißt mehr Bezug, egal ob geheizt wurde. Und Ablesungen passieren unregelmäßig, fast nie am Monatsletzten.

Lösung

Ablesungen landen per Apple-Shortcut in PocketBase. Ein Monat bekommt nur dann einen Wert, wenn eine echte Ablesung ±4 Tage um den Monatsletzten liegt – sonst bleibt eine ehrliche Lücke im Chart statt interpoliertem Rauschen. Der Gesamtverbrauch (Bezug + PV-Erzeugung − Einspeisung) wird nach VDI 3807 um die Heizwitterung bereinigt: 30-Jahres-Mittel der Heizgradtage aus der Open-Meteo-Archive-API, Grundlast je Jahr aus den Sommermonaten geschätzt.

Was es kann

—Vier Modi im Jahresvergleich: Bezug, Einspeisung, Gesamtverbrauch, Wetterbereinigt

—Witterungsbereinigung nach VDI 3807 – der Außentemperatur-Effekt rausgerechnet, Vorjahre echt vergleichbar

—Heizgradtage und Globalstrahlung aus der Open-Meteo-Archive-API (ERA5, kein API-Key)

—PV-Erzeugung aus der Home-Assistant-Langzeitstatistik, für die Zeit davor modelliert

—Keine Interpolation: Monate ohne qualifizierende Ablesung bleiben eine Lücke

—Eingabe per Apple-Shortcut, das Browser-Dashboard ist read-only

Gebaut mit

Next.jsReactTypeScriptTailwind CSSPocketBaseRechartsOpen-Meteo APIHome AssistantPythonDockerWoodpecker CI

Home Assistant

2026

Home Assistant Energie-Automatisierung

Anker Solix BKW und Fronius PV kennen sich nicht — Home Assistant koordiniert beide per API und sorgt dafür, dass die Batterie abends voll ist.

Details ansehen →

Home Assistant · 2026

Home Assistant Energie-Automatisierung

Screenshots

HA Solar-Dashboard: 896W PV-Leistung, Akkustand 39% – unten die Moduswechsel-Timeline (Custom → Self consumption)

Die große Fronius-PV deckt tagsüber den Haushalt – aber der Anker Solix BKW weiß das nicht und würde sich unnötig entladen. Abends, wenn die PV nichts mehr liefert, wäre die Batterie leer.

Lösung

Zwei zeitbasierte Automatisierungen via Home Assistant: um 08:00 wechselt der BKW per direktem API-Call in den Lademodus (0 W Output) – um 18:00 zurück in Eigenverbrauch mit Smart Meter-Steuerung. Beide Systeme kommunizieren nicht miteinander, Home Assistant ist die Brücke.

Was es kann

—08:00 → BKW lädt nur (mode_type=3, 0 W) – große PV versorgt den Haushalt

—18:00 → BKW wechselt auf Eigenverbrauch (mode_type=1) – Smart Meter steuert Entladung bedarfsgerecht

—Direkter API-Call an Anker Solix – kein offizielles HA-Feature, selbst herausgefunden

—Weitere Automationen: Licht (Garagentor, Haustür, Sonnenuntergang), Klima Kinderzimmer, MQTT-Watchdog

Gebaut mit

Home AssistantYAMLAnker Solix APIFroniusSmart MeterMQTTDocker

TypeScript · Next.js

2026

Küstenwetter-Kompass

Urlaubsorte nach persönlich gewichteten 10-Jahres-Klimamitteln vergleichen – und für einen Ort das statistisch beste Reisefenster finden.

Details ansehen →

TypeScript · Next.js · 2026

Küstenwetter-Kompass

Screenshots

Vergleichsmodus – Orte wählen, Monat wählen, Wärme, Trockenheit und Windstille gewichten

Wann ist statistisch das beste Wetter an der dänischen Nordseeküste? Klima-Nachschlageseiten zeigen einen Ort pro Seite, ohne Gewichtung nach dem was mir wichtig ist – und beantworten die eigentliche Frage nie.

Lösung

Acht Orte, 24 Halbmonatsperioden, zur Build-Zeit aus der Open-Meteo-Archive-API vorberechnet und als JSON mitgeliefert. Wärme, Regen und Wind werden nach eigener Gewichtung zu einem Score verrechnet. Read-only, keine Nutzerdaten, kein PocketBase.

Was es kann

—Zwei Modi: Ort gegen Ort für einen Zeitraum, oder bestes Fenster für einen Ort

—Persönliche Gewichtung von Wärme, Regen und Wind zu einem Score

—14-Tage-Auflösung übers ganze Jahr

—Freie Ortssuche zusätzlich zu den acht vorberechneten Orten

—Vollständig statisch – kein CRUD, keine Persistenz, In-Memory-Cache für freie Orte

Gebaut mit

Next.jsTypeScriptOpen-Meteo APIDockerCloudflare Zero Trust

TypeScript · Next.js

2026

Diese Website

Von der scharfkantigen Dark-Site zum hellen „Japandi“-Design-System – Apple-Motion-Prinzipien, ein geteilter Radius- und Schatten-Maßstab, zwei Themes.

Details ansehen →

TypeScript · Next.js · 2026

Diese Website

Die erste Version war komplett dunkel, 100 % scharfe Ecken, jede Komponente mit eigenen Abständen. Das sah zusammengesteckt aus, nicht entworfen.

Lösung

Ein durchgezogenes Design-System statt Einzelentscheidungen: warmes Linen als Standard, das originale Dark-Theme wortgleich als Toggle erhalten – gleiche CSS-Variablennamen, nichts downstream muss wissen welches Theme läuft. Ein gemeinsamer Radius- (10 / 16 / 24) und Schatten-Maßstab. Typografie nach Apples Optical-Sizing-Regel: großer Text enger getrackt, nicht loser. Bewegung nach dem „Designing Fluid Interfaces“-Playbook.

Was es kann

—Zwei Themes: helles Japandi (Standard) plus das originale Dark als Toggle

—Geteilter Maßstab für Radius und Elevation statt Einzelwerte pro Komponente

—Hero: rotierendes Foto-Karussell mit Kamera-Fokus-Reveal – Blur und Zoom, ein Nicken an die eigene Fotografie

—Scroll-getriebene Motion: Inhalt fadet und hebt sich – vollständig reduced-motion-fest

—Press-Feedback auf Pointer-Down statt erst beim Loslassen

—E2E-Tests mit Cypress, Playwright-Workshop, Woodpecker CI bei jedem Push

Gebaut mit

Next.jsTypeScriptTailwind CSSCSS Custom PropertiesCypressPlaywrightWoodpecker CIRaspberry PiClaude Code