Big openWB Update 2026

[Xerolux]

Zusammenfassung

Umfassendes Update für open WB (Bookworm & Trixie), moderne Python-Versionen (3.10+) und aktualisierte Abhängigkeiten t. Außerdem wird Apache durch Caddy als Webserver ersetzt.

211 Dateien geändert, +2185 / -1579 Zeilen

---

Neuerungen

Debian 13 Trixie & Python 3.13 Unterstützung

openWB läuft jetzt auf aktuellen Debian-Versionen, statt an Bullseye gebunden zu sein.

• Debian 12 (Bookworm) und Debian 13 (Trixie) werden vollständig unterstützt
• Python 3.10, 3.11, 3.12, 3.13 unterstützt (Empfehlung: 3.13)
• Ein Python Virtual Environment wird automatisch unter /opt/openwb-venv erstellt, um Konflikte mit PEP 668 (System-Python) zu vermeiden
• Plattformerkennung über runs/platform_detect.sh (Architektur, Virtualisierung, Raspberry Pi, Debian-Version)
• Automatische Migration von Bullseye/Bookworm über runs/upgrade_stack.sh (Python-Installation, venv, Paketmigration, Services)

---

Apache ersetzt durch Caddy + PHP-FPM

Der Webserver-Stack wurde komplett modernisiert:

• Caddy 2.x ersetzt Apache2 (einfachere Konfiguration, automatisches HTTPS, bessere Performance)
• PHP-FPM ersetzt libapache2-mod-php (standardisierter PHP-Interpreter, versionsunabhängig)
• Dynamische Caddy-Konfiguration über runs/setup_caddy.sh (inkl. MQTT-Settings)
• Caddy wird nur neu gestartet, wenn sich die Konfiguration tatsächlich ändert (idempotent)
• Prüfung des PHP-FPM-Sockets verhindert 502-Fehler
• Alle Apache-Reste entfernt (setup_apache2.sh, .htaccess, etc.)

---

Aktualisierte Abhängigkeiten

Paket	Alt	Neu	Hinweise
pymodbus	2.5.2	3.13.0	API komplett angepasst, Kompatibilitätsschicht vorhanden
paho-mqtt	1.6.1	2.1.0	Rückwärtskompatibel via CallbackAPIVersion.VERSION1
ocpp	1.0	2.1.0	Antworthandling angepasst
websockets	12.0	16.0	Für ocpp 2.x aktualisiert
evdev	—	1.9.3	Neu: RFID-Unterstützung

Testabhängigkeiten (pytest, requests-mock) wurden in requirements-dev.txt ausgelagert.

---

Raspberry Pi Optimierungen

Speziell für Raspberry Pi 3B/3B+:

• zram Swap (50 % RAM, komprimiert, keine SD-Karten-Abnutzung)
• 512 MB Swapfile auf x86/VM-Systemen
• tmpfs für /var/log (64 MB, keine Schreibzugriffe auf SD-Karte)
• noatime reduziert Schreibzugriffe
• journald nur im RAM (volatile Speicherung)

Alle Optimierungen werden nur auf Raspberry Pi angewendet.

---

Zeit & System

• Chrony ersetzt systemd-timesyncd (präzisere Zeitsynchronisation)
• Login-MOTD (Infobanner bei SSH-Login)
• usbutils als neue Pflichtabhängigkeit (für USB-Netzwerkerkennung)

---

CI/CD

• GitHub Actions erweitert: Python 3.10, 3.12, 3.13
• Trennung von Test- und Produktionsabhängigkeiten

---

Funktionsweise

Auf bestehenden Bookworm-Systemen

Beim Booten wird runs/upgrade_stack.sh über atreboot.sh ausgeführt:

1. Aktiviert bookworm-backports
2. Installiert Python ≥ 3.10 (bevorzugt 3.13)
3. Erstellt/aktualisiert das venv (/opt/openwb-venv)
4. Installiert Caddy + PHP-FPM, deaktiviert Apache
5. Installiert Systempakete
6. Konfiguriert Chrony, MOTD, sudoers, Services
7. Richtet Swap ein (zram oder Swapfile)
8. Aktiviert SD-Karten-Schutz (Raspberry Pi)
9. Installiert Python-Abhängigkeiten ins venv
10. Generiert die Caddy-Konfiguration (MQTT-basiert)
11. Entfernt Apache vollständig
12. Erstellt .stack-version (verhindert doppelte Ausführung)

---

Auf frischen Trixie-Installationen

Python 3.13 ist bereits vorhanden:

• venv wird erstellt
• Caddy + PHP-FPM werden installiert
• Setup läuft direkt durch

---

Idempotenz

• upgrade_stack.sh läuft nur bei Versionsänderung (.stack-version)
• setup_caddy.sh startet Caddy nur bei Konfigurationsänderung neu
• Konfigdateien werden nur bei Versionsabweichung ersetzt
• Service-Dateien sind Symlinks (Updates greifen automatisch)

---

Geänderte Dateien

Neue Dateien

• runs/platform_detect.sh – Systemerkennung
• runs/upgrade_stack.sh – Upgrade-/Migrationslogik
• runs/setup_caddy.sh – ersetzt Apache-Setup
• Caddy-, PHP-, Chrony- und MOTD-Konfigurationen
• pymodbus_compat.py – Kompatibilität für pymodbus 3.x
• requirements-dev.txt – Testabhängigkeiten

Entfernt

• Apache-Setup und Konfigurationen
• .htaccess

Wichtige Anpassungen

• Migration auf pymodbus 3.x, ocpp 2.x, paho-mqtt 2.x
• Anpassung von Install-, Backup- und Boot-Skripten
• Aktualisierte CI-Pipeline und Dokumentation

---

Abwärtskompatibilität

• Bestehende MQTT-Callbacks bleiben kompatibel
• pymodbus wird über eigene Kompatibilitätsschicht abgefangen
• System-Python bleibt unangetastet
• Python < 3.10 wird nicht mehr unterstützt

---

Getestet auf

• Debian 13 (Trixie) – KVM/x86_64, Python 3.13
• Debian 12 (Bookworm) – Docker, Python 3.11 (venv)
• Alle Dienste stabil (openWB, Caddy, PHP-FPM, Chrony, Mosquitto)
• Idempotenz bestätigt („up to date“ bei erneutem Lauf)

[kevinwieland]

Danke für den PR.
Was würde mit einer Bestands openWB nach Merge passieren?

[benderl]

Danke für den PR. Was würde mit einer Bestands openWB nach Merge passieren?

Steht bei dem Punkt "Abwärtskompatibilität":

Python < 3.10 wird nicht mehr unterstützt

Aktuell wird in Debian 11 Bullseye Python 3.9 verwendet.

[benderl]

@Xerolux
Danke für die Arbeit, welche Du in diesen PR gesteckt hast.

Ein Merge ist jedoch leider aus mehreren Gründen fast komplett unmöglich:

• bestehende Systeme würden unbrauchbar (Debian 11 mit Python 3.9, kein Venv)
• sehr starke Vermischung von Anpassungen in software2 und Systemkomponenten

Dass ein Upgrade des Betagten Debian 11 dringend notwendig ist, steht außer Frage. Um diesen sehr komplexen Sprung zu entzerren, sollten einzelne, kleinere Schritte gemacht werden. Schließlich haben wir ein paar Tausend Installationen, die nicht mal eben mit Debian 12/13 versorgt werden können.

Wir sind intern bereits dabei, eine Roadmap für die Migration zu entwerfen. Dabei werden sicher auch einige der von Dir umgesetzten Themen/Techniken berücksichtigt.

[Xerolux]

@kevinwieland @benderl

Der Merge berücksichtigt auch ältere Installationen ( Buster siehe weiter unten kann ich einfügen ) und stellt sicher, dass die Funktionalität weiterhin auf bestehenden Systemen gewährleistet bleibt. Dafür habe ich entsprechende Skripte integriert, die den jeweiligen Fall automatisch erkennen und feststellen, welches System bzw. welche Plattform verwendet wird.

Auf älteren Systemen ( Bookworm) wird Python 3.9 durch eine Backport-Version von Python 3.11 ersetzt. Anschließend wird automatisch eine virtuelle Umgebung (venv) erstellt und die aktuellen Requirements installiert. Dadurch ist sichergestellt, dass auf allen Systemen identische Abhängigkeiten verwendet werden und keine Unterschiede hinsichtlich Wartbarkeit oder Verhalten entstehen.

Auf Wunsch kann ich zusätzlich auch eine Kompatibilität für Debian Buster integrieren ( dachte das ist nicht mehr oft in Betrieb ). In diesem Fall würden wir Python 3.11 direkt auf dem Raspberry Pi kompilieren und anschließend ebenfalls eine venv erstellen. Das lässt sich vollständig per Skript automatisieren und dauert für den Endkunden etwa 20–30 Minuten. Damit wären auch sehr alte Installationen weiterhin problemlos nutzbar und der User hat kein Todo.

Alternative: Ich erstelle precompiled python Pakete für Buster, dann gehts fix und alles bleibt bestehen!

Dieser Upgrade-Pfad kann in einigen Monaten wieder entfernt werden, sobald der Support für Buster / Bookworm entfällt. Alternativ kann er dauerhaft bestehen bleiben, da es technisch keinen Unterschied macht, auf welchem System die venv betrieben wird.

Zusätzlich habe ich sämtliche Komponenten auf die neuesten Versionen aktualisiert und eure Skripte an die neuen Methoden sowie APIs angepasst. Außerdem habe ich Caddy aufgrund der besseren Performance integriert.

Testet das Ganze gerne selbst – ich habe sowohl den Upgrade-Prozess als auch sämtliche Funktionen geprüft. Dabei lief alles sauber und ohne Probleme.

Natürlich ist mir bewusst, dass der PR aktuell mehrere Themen gleichzeitig zusammenfasst. Ursprünglich wollte ich dafür mehrere kleinere PRs erstellen, habe mich dann aber entschieden, ein größeres Update mit allen zusammenhängenden Features bereitzustellen. Wie gesagt: Es war auch einiges an Legacy-Code dabei 😉

Am Ende entscheidet natürlich ihr, wie ihr damit umgehen möchtet.

[Xerolux]

Eine andere Alternative für alle Installationen – unabhängig vom verwendeten System – wäre pyenv:
https://github.com/pyenv/pyenv