SNLO – Spittank.net Ladeorganisation auf TrueNAS SCALE¶
SNLO wird auf TrueNAS SCALE als Custom App betrieben. Für PostgreSQL empfiehlt sich ein eigenes Child-Dataset:
Die fertige Compose-Datei liegt im Repository unter deploy/truenas/compose.yaml; eine Vorlage für die Umgebung unter deploy/truenas/snlo.env.example.
Reverse Proxy¶
Die interne IP des api-Containers ist absichtlich nicht Teil der öffentlichen Schnittstelle und darf bei einem Recreate wechseln. Die Compose veröffentlicht stattdessen Port 8080 stabil auf dem TrueNAS-Host:
Der Reverse Proxy muss daher auf die feste LAN-IP des TrueNAS-Servers und Port 8080 zeigen, nicht auf die Docker-IP des API-Containers.
Datenbank¶
DATABASE_URL muss in /mnt/Apps/snlo/snlo.env explizit gesetzt sein:
Mit SCHEMA_AUTO_CREATE=false verweigert SNLO ab 0.5.10 den Start, wenn DATABASE_URL fehlt. Dadurch kann eine Produktionsinstallation nicht mehr unbemerkt auf eine lokale SQLite-Datei zurückfallen.
Healthchecks¶
Die Dienste besitzen getrennte Healthchecks:
db:pg_isreadyapi:/readyz, prüft die Datenbankverbindung, aber nicht den Workerworker: prüft den aktuellen Eintrag inworker_heartbeatkeba-gateway:/healthz, einschließlich aktivem UDP-7090-Listenermigrate: One-Shot-Dienst ohne Healthcheck
KEBA¶
Der KEBA-Gateway nutzt network_mode: host, damit die Wallbox UDP-Pakete von und zu Port 7090 unverändert sieht. Auf Docker Desktop für macOS ist dies nicht äquivalent zu echtem Linux-Host-Networking; auf TrueNAS/Linux wird der Gateway deshalb produktiv betrieben.
PWA-Sitzung¶
Für persönliche Mobilgeräte kann PWA_SESSION_TTL_DAYS=3650 in /mnt/Apps/snlo/snlo.env verwendet werden. Die installierte PWA startet mit einer eigenen Login-Markierung und erneuert ihre SNLO-Sitzung beim App-Start; normale Browser-Aufrufe bleiben bei SESSION_TTL_HOURS. Bei Browser und installierter PWA derselben Origin wird der HTTP-Cookie-Speicher je nach Plattform geteilt; nach einer PWA-Anmeldung kann die langlebige Sitzung deshalb auch im normalen Browser derselben Geräte-/Browserumgebung gelten.