Zum Inhalt

SNLO – Spittank.net Ladeorganisation – Validierungsbericht 0.5.12

Stand: 16. August 2026

In der Erstellungsumgebung ausgeführt

Der aktuelle Quellstand wurde mit Python 3.13 und Node.js 22 geprüft. Das Projekt selbst verlangt Python 3.12 oder neuer; die Forgejo-Workflows verwenden Python 3.12.

python -m compileall -q snlo migrations tests scripts
python -m pytest
node --check static/app.js
node --check static/sw.js
alembic upgrade head
alembic check
./scripts/validate-release.sh

Ergebnis der automatisierten Anwendungstests:

60 passed

Zusätzliche Regressionen in 0.5.12 prüfen den Live-Sperrstatus aus Authreq, den verifizierten dokumentierten stop-Pfad, den nur ohne aktive Ladung zulässigen Unknown-RFID-Fallback, die Beibehaltung des Sperrbuttons bis Authreq=1, direkte EVCC-Modusumschaltung im Dashboard, langlebige PWA-Sitzungen, Worker-Heartbeat-Healthcheck sowie mobile Scrollcontainer.

Zusätzlich wurden ausgeführt:

  • TOML-Parsing von pyproject.toml und zensical.toml,
  • Abgleich der gepinnten Zensical-Version in pyproject.toml und requirements-docs.txt,
  • Prüfung aller Zensical-Navigationsziele und lokalen Markdown-Verweise,
  • JSON- und SVG-Parsing von PWA-Manifest sowie App- und Dokumentationslogos,
  • YAML-Parsing von compose.yaml, .forgejo/workflows/ci.yml und .forgejo/workflows/release.yml,
  • Prüfung, dass migrate, api, worker und keba-gateway dasselbe konfigurierbare Image verwenden,
  • Prüfung, dass nur keba-gateway Host-Networking nutzt und die API UDP 7090 nicht mehr per Docker-NAT veröffentlicht,
  • KEBA-Gateway-Test mit dauerhaftem UDP-7090-Listener, report 1 und Antwort an den festen Controller-Port,
  • zusätzlicher KEBA-Regressionslauf unter uvloop, der Senden und Empfangen über den gemeinsamen Datagram-Transport und den festen Quellport prüft,
  • Prüfung, dass Gateway-Access-Logs nicht deaktiviert sind und die Netzwerkdiagnose verfügbar ist,
  • Prüfung der festen Repository-Pages-URL, der Registry-Schritte und des Multi-Arch-Releases,
  • Prüfung, dass der normale CI-Workflow keine Docker-, QEMU- oder Buildx-Schritte enthält,
  • Prüfung von AGPL-3.0-only, vollständigem Lizenztext, Dokumentationshinweis und OCI-Lizenzmetadaten,
  • Prüfung, dass Release-Tags exakt dem Schema vX.Y.Z folgen und zur Projektversion passen,
  • Suche nach dem ausgemusterten Produktnamen,
  • Branding-Prüfung auf SNLO, Laden organisiert. und den vollständigen Dokumentationsnamen,
  • FastAPI-/PWA-Smoke-Test für Healthcheck, Startseite, Manifest, Service Worker, OpenAPI und API-Dokumentation,
  • Frontend-Regressionsprüfung für kompakte, auf Mobilgeräten drehbare und bei dichten Reihen ausgedünnte Energieverlaufsbeschriftungen,
  • kontrollierter Test des Dokumentations-Wrappers einschließlich --clean, --strict und Fehlerbehandlung,
  • Upgrade-Prüfung realer Datenbankstände aus 0.1.1 und 0.3.0,
  • erneutes Entpacken und Manifestprüfung beider Releasearchive.

Abgedeckte Fachfälle

  • lokaler Login, Rollen und CSRF,
  • OIDC-Gruppenauflösung mit Administratorpriorität,
  • OIDC-Nutzeranlage und Rollensynchronisierung bei erneuter Anmeldung,
  • Authorization-Code-Start mit State, Nonce und PKCE S256,
  • RSA-Signaturprüfung einschließlich Issuer, Audience und Nonce,
  • OIDC-Webcallback mit normaler Browser-Anwendungssitzung,
  • langlebige installierte PWA-Sitzung mit separater Login-Markierung und Erneuerung beim App-Start,
  • Ablehnung eines Kontos ohne freigegebene Gruppe,
  • direkter OIDC-Redirect und lokaler Fallback /?local=1,
  • EVCC-Instanz anlegen, bearbeiten und löschen,
  • beliebig viele EVCC-Instanzen ohne feste Namen oder Anzahl,
  • benannte Tarife und nutzerbezogene Zeiträume,
  • Tarifwechsel am 1. April mit exklusivem technischem Periodenende,
  • Warnung vor Änderung eines verwendeten historischen Tarifs,
  • Neuberechnung vorhandener Sitzungen nach Bestätigung,
  • Batterieformel einschließlich Deckelung auf Sitzungsenergie,
  • zwei gleichzeitige Ladepunkte und proportionale Batterieaufteilung,
  • keine Batterieextrapolation über eine zu große Messlücke,
  • mehrere Familienmitglieder an einem Fahrzeug,
  • Ablehnung eines zweiten überlappenden Zahlers,
  • EVCC-Sitzungszuordnung über internen Fahrzeugnamen oder sichtbaren Titel,
  • rückwirkende Reparatur unzugeordneter Sitzungen,
  • Nutzerfilter nur zahlend,
  • Adminübersicht mit zahlendem Nutzer,
  • Admin-Druckansicht eines ausgewählten Nutzers,
  • verweigerter CSV-Export für normale Nutzer,
  • fremde aktive Sitzung liefert ausschließlich Belegt,
  • konkrete Batteriekilowattstunden in der Sitzungsserialisierung,
  • verschlüsselte RFID-Ablage und KEBA-App-Freigabe,
  • Live-KEBA-Sperrstatus über report 2/Authreq; Sperren versucht zuerst stop <echte RFID> und nutzt bei weiterhin entsperrter, nicht ladender Station den konfigurierten Unknown-RFID-start-Fallback,
  • EVCC-Modusumschaltung direkt aus dem aktiven Dashboard-Ladevorgang,
  • 8-stellige KEBA-RFID-UIDs werden unverändert zusammen mit dem internen Standard-RFID-Class-Wert gesendet; alte 0.5.9-Nullerweiterungen werden kompatibel erkannt,
  • Ver- und Entschlüsselung neuer Geheimnisse unter dem snlo-Kontext,
  • Lesekompatibilität vorhandener verschlüsselter Geheimnisse nach der Produktumstellung,
  • vollständiges App-/PWA-Branding,
  • Ablehnung schreibender Requests mit fremdem Origin.

Migrationsprüfung

Die Upgradepfade wurden mit den tatsächlich veröffentlichten Archiven geprüft:

  • 0.1.1 erzeugte f720b52d7094.
  • SNLO 0.5.9 führte darauf a9d4b6f278c1 und c4f8e2a1b7d9 aus.
  • 0.3.0 erzeugte bereits c4f8e2a1b7d9; SNLO 0.5.9 erkannte diesen Stand ohne weitere Schemaoperationen.
  • alembic check meldete nach beiden Upgrades keine offenen Änderungen.
  • Die Dokumentations- und CI/CD-Erweiterung benötigt keine zusätzliche Datenbankmigration.

Zensical-Renderlauf

In der Erstellungsumgebung konnte Zensical wegen gesperrter externer Namensauflösung nicht aus PyPI installiert werden. Deshalb wurde hier kein echter Zensical-HTML-Renderlauf ausgeführt.

Der normale validate-Job enthält bewusst keinerlei Dokumentationsprüfung. Nach erfolgreichem validate installiert der separate docs-Job Zensical wie in der funktionierenden Forgejo-Vorlage und führt ausschließlich aus:

pip install zensical
zensical build --config-file zensical.toml

Nur bei einem Push auf main wird das dabei erzeugte Verzeichnis site/ anschließend mit codeberg.org/git-pages/action@v2 nach https://daniel.snii.de/snlo/ veröffentlicht. Ein Zensical-Fehler lässt damit ausschließlich den docs-Job scheitern; er kann den vorherigen validate-Job nicht mehr beeinflussen.

Containerprüfung

In der Erstellungsumgebung steht weder Docker-CLI noch Docker-Daemon zur Verfügung. Deshalb konnten Image-Build, Multi-Arch-Build und Registry-Push nicht lokal ausgeführt werden. Der normale Forgejo-CI-Workflow enthält bewusst keinen Container-Build. Nur der Tag-Workflow baut und veröffentlicht linux/amd64 und linux/arm64.

Auf dem Zielsystem sollten zusätzlich ausgeführt werden:

docker compose config
docker compose build
docker compose up -d
docker compose ps

Danach folgen die praktischen Tests mit den realen EVCC-, KEBA- und OIDC-Systemen sowie Backup und Restore.