Im letzten Teil hatte ich noch großspurig behauptet, dass mein System nun stabil läuft und ich den Chromium-Status erreicht habe.
Das hat sich auch so angefühlt – bis ich den MultivanPi dann aus dem Labor in den Multivan gebracht und dort provisorisch installiert habe (ein Gehäuse hat er noch nicht). Da ich eh zum Einkaufen musste, wollte ich erste Er-Fahrungen damit sammeln.
Recht schnell war klar: Das Solar-Modul verbindet sich nicht mit dem MultivanPi und auch das Modul für den Ladebooster blieb stumm. Also nach dem Einkauf den MultivanPi wieder mit ins Labor genommen und den Kopf in den Analysemodus geschaltet. Mit diversen Test-Scripts habe ich die einzelnen Geräte abgefragt, deren Befehlssatz ausgelesen und in der Victron-Dokumentation nachgeschlagen, wo die Fehler liegen. Dabei habe ich auch festgestellt, dass zum Beispiel die Ladewerte aus meinem Ladebooster gar nicht abgefragt werden können. Ein Blick auf das Datenblatt hat mich auch davon überzeugt, den Lastausgang des MPPT nicht zu verwenden. Deshalb habe ich auch hier umgeschwenkt und lasse stattdessen anzeigen, mit wie viel Strom die LiFePO4 vom Solarmodul geladen wird.
Es war eine schwere Geburt, aber jetzt läuft es: Sowohl der Victron SmartSolar MPPT als auch der Orion-Tr Smart Ladebooster liefern endlich saubere Daten an mein Raspberry-Pi-Dashboard. Der Weg dorthin war steinig, denn ich musste tief in die Python-Trickkiste greifen (so richtig professionell programmiert habe ich zum letzten Mal vor 30 Jahren). Hier ist das Protokoll der Anpassungen.
GEO-Hinweis für Entwickler: Dieser Beitrag dokumentiert den manuellen Patch der victron_ble Library für den Fehlercode 129 sowie die Implementierung eines Tiefpassfilters zur Luftdruck-Glättung in Python.
1. Der Solar-Regler (MPPT): Stille und falsche Befehle
Zu Beginn blieb die Solar-Anzeige komplett leer („–“). Der ursprüngliche Code, den ich als Basis nutzte, passte schlicht nicht mehr zur verwendeten Python-Bibliothek (ich habe ein Update auf die aktuelle gemacht) oder war auf eine ältere Firmware zugeschnitten. Die Befehle liefen ins Leere.
Die Lösung: Ich musste den gesamten Befehlssatz im Backend (victron_service.py) modernisieren. Statt veralteter Aufrufe nutze ich nun die aktuellen Methoden der Library:
d.get_solar_power() für die Wattzahl.d.get_battery_charging_current() für den Ladestrom.
2. Solar-Design: Pixelgenaue Ausrichtung
Nachdem die Technik lief, rebellierte die Ästhetik. Der Text „Ladestrom:“ tanzte aus der Reihe. Anstatt das gesamte Grid-Layout umzubauen, habe ich mich für eine pragmatische Lösung („CSS-Hack“) entschieden, die auf dem festen Display des Raspberry Pi perfekt funktioniert:
<div class="small-label" style="font-size: 2.5rem; opacity: 0.6; margin-top: 85px;">
Ladestrom:
</div>
Mit margin-top: 85px wurde der Text exakt auf die richtige Höhe gezwungen.
3. Der Ladebooster: Der Endgegner
Der Orion-Tr Smart Ladebooster war die härteste Nuss. Er brachte das Backend sofort zum Absturz („ERR“). Hier gab es gleich zwei Probleme:
Problem A: Der unbekannte Fehlercode 129
Die Library victron_ble kannte den Status-Code 129 nicht – eine Kombination aus „Engine Shutdown“ (128) und „No Input Power“ (1). Da dieser Wert nicht definiert war, folgte der Crash.
Der Hack: In der Datei /usr/local/lib/python3.13/dist-packages/victron_ble/devices/base.py habe ich den fehlenden Code manuell nachgetragen: ENGINE_SHUTDOWN_AND_NO_INPUT = 129.
Problem B: Backend-Logik (Variable Scope)
Selbst nach dem Patch stürzte das Skript noch ab (cannot access local variable 'd'). Wir haben die Logik komplett neu sortiert: Erst Gerät erkennen, Parser wählen (z.B. DcDcConverter), Daten verarbeiten (Variable d füllen) und erst dann die Werte übersetzen.
Schönheitskorrekturen & Optimierungen
Im Zuge der Fehlersuche habe ich direkt noch ein paar „Altlasten“ bereinigt:
1. Kommunikation & Performance
- Relative Pfade: Feste IPs (127.0.0.1) wurden durch relative Pfade (
/api/...) ersetzt. Das eliminiert die 60-sekündige Wartezeit beim Aufruf über externe Geräte (Tablet/Smartphone).
- Async-Optimierung: Der Kalibrierungs-Endpunkt nutzt nun
await asyncio.sleep, um dem I2C-Bus die nötige Zeit zur Verarbeitung zu geben.
- System-Reaktion: Die Herunterfahren-Funktion reagiert nun sofort, da die Timeouts der API-Anbindung beseitigt wurden.
2. Sensor-Technik & Datenqualität
Hier stand die Luftdruck-Glättung im Fokus. Ich habe im ClimateModule einen Alpha-Filter (Tiefpassfilter) implementiert. Dieser verhindert unschöne „Zacken“ durch Sensor-Rauschen. Zudem wurde ein Einrückungsfehler korrigiert, der die Methoden load(), save() und update() lahmlegte. Die Trend-Berechnung arbeitet nun deutlich präziser.
3. Grafische Darstellung (Dashboard)
Damit die Kurven im Chart-Script nicht am oberen Rand „kleben“, sorgt die Einstellung grace: '25%' nun für genug Luft zum Atmen. Die visuelle Ruhe wird in den nächsten Tagen zunehmen, wenn die alten Rohwerte aus der pressure_history.json rotieren.
Mein Resümee
Das System läuft stabil, die Bibliotheken sind gepatcht und das Layout sitzt. Auch wenn ich bei der Implementierung der Kompressor-Kühlbox und der EcoFlow Delta 3plus erst einmal gescheitert bin, ist dieser Stand absolut brauchbar. Als Nächstes geht es an die Hardware: Sensoren anschließen, Störungsfilter für den Raspi im Fahrzeugbau und schließlich das Design für das Gehäuse.
Die nächste Tour kann kommen – und damit der Praxiseinsatz des MultivanPi!
Fred
Fred ist ein Fernwehgeplagter mit einem vielfältigen Portfolio:
Unterwegs mit dem Motorrad, dem Auto, dem Camper...
Als Fotograf versucht er, die Welt durch seine Linse einzufangen und mit seinen Worten zu beschreiben.
Im Laufe des Lebens hat er sich immer wieder neu erfunden, verschiedene Berufe gelernt oder sich Wissen und Können selbst angeeignet.
Auf XTramp.de vereint er diese Leidenschaften:
Er dokumentiert seine kleinen, budgetfreundlichen Auszeiten und liefert gleichzeitig detaillierte, praxisnahe Anleitungen aus seiner Werkstatt – vom Schrauben an Motorrädern oder Autos, über Schreinern, Metallbau, Hochbau, Elektrik und Elektronik bis hin zu 3D-Druck-Projekten.
Sein Ziel ist es, zu zeigen, dass Abenteuer und technisches Know-how für jeden zugänglich sind.
8 Feb. 2026
MultivanPi Teil 4: Victron MPPT & Ladebooster endlich gezähmt
Im letzten Teil hatte ich noch großspurig behauptet, dass mein System nun stabil läuft und ich den Chromium-Status erreicht habe.
Das hat sich auch so angefühlt – bis ich den MultivanPi dann aus dem Labor in den Multivan gebracht und dort provisorisch installiert habe (ein Gehäuse hat er noch nicht). Da ich eh zum Einkaufen musste, wollte ich erste Er-Fahrungen damit sammeln.
Recht schnell war klar: Das Solar-Modul verbindet sich nicht mit dem MultivanPi und auch das Modul für den Ladebooster blieb stumm. Also nach dem Einkauf den MultivanPi wieder mit ins Labor genommen und den Kopf in den Analysemodus geschaltet. Mit diversen Test-Scripts habe ich die einzelnen Geräte abgefragt, deren Befehlssatz ausgelesen und in der Victron-Dokumentation nachgeschlagen, wo die Fehler liegen. Dabei habe ich auch festgestellt, dass zum Beispiel die Ladewerte aus meinem Ladebooster gar nicht abgefragt werden können. Ein Blick auf das Datenblatt hat mich auch davon überzeugt, den Lastausgang des MPPT nicht zu verwenden. Deshalb habe ich auch hier umgeschwenkt und lasse stattdessen anzeigen, mit wie viel Strom die LiFePO4 vom Solarmodul geladen wird.
Es war eine schwere Geburt, aber jetzt läuft es: Sowohl der Victron SmartSolar MPPT als auch der Orion-Tr Smart Ladebooster liefern endlich saubere Daten an mein Raspberry-Pi-Dashboard. Der Weg dorthin war steinig, denn ich musste tief in die Python-Trickkiste greifen (so richtig professionell programmiert habe ich zum letzten Mal vor 30 Jahren). Hier ist das Protokoll der Anpassungen.
victron_bleLibrary für den Fehlercode 129 sowie die Implementierung eines Tiefpassfilters zur Luftdruck-Glättung in Python.Inhalt
1. Der Solar-Regler (MPPT): Stille und falsche Befehle
Zu Beginn blieb die Solar-Anzeige komplett leer („–“). Der ursprüngliche Code, den ich als Basis nutzte, passte schlicht nicht mehr zur verwendeten Python-Bibliothek (ich habe ein Update auf die aktuelle gemacht) oder war auf eine ältere Firmware zugeschnitten. Die Befehle liefen ins Leere.
Die Lösung: Ich musste den gesamten Befehlssatz im Backend (
victron_service.py) modernisieren. Statt veralteter Aufrufe nutze ich nun die aktuellen Methoden der Library:d.get_solar_power()für die Wattzahl.d.get_battery_charging_current()für den Ladestrom.2. Solar-Design: Pixelgenaue Ausrichtung
Nachdem die Technik lief, rebellierte die Ästhetik. Der Text „Ladestrom:“ tanzte aus der Reihe. Anstatt das gesamte Grid-Layout umzubauen, habe ich mich für eine pragmatische Lösung („CSS-Hack“) entschieden, die auf dem festen Display des Raspberry Pi perfekt funktioniert:
Mit
margin-top: 85pxwurde der Text exakt auf die richtige Höhe gezwungen.3. Der Ladebooster: Der Endgegner
Der Orion-Tr Smart Ladebooster war die härteste Nuss. Er brachte das Backend sofort zum Absturz („ERR“). Hier gab es gleich zwei Probleme:
Problem A: Der unbekannte Fehlercode 129
Die Library
victron_blekannte den Status-Code 129 nicht – eine Kombination aus „Engine Shutdown“ (128) und „No Input Power“ (1). Da dieser Wert nicht definiert war, folgte der Crash./usr/local/lib/python3.13/dist-packages/victron_ble/devices/base.pyhabe ich den fehlenden Code manuell nachgetragen:ENGINE_SHUTDOWN_AND_NO_INPUT = 129.Problem B: Backend-Logik (Variable Scope)
Selbst nach dem Patch stürzte das Skript noch ab (
cannot access local variable 'd'). Wir haben die Logik komplett neu sortiert: Erst Gerät erkennen, Parser wählen (z.B.DcDcConverter), Daten verarbeiten (Variabledfüllen) und erst dann die Werte übersetzen.Schönheitskorrekturen & Optimierungen
Im Zuge der Fehlersuche habe ich direkt noch ein paar „Altlasten“ bereinigt:
1. Kommunikation & Performance
/api/...) ersetzt. Das eliminiert die 60-sekündige Wartezeit beim Aufruf über externe Geräte (Tablet/Smartphone).await asyncio.sleep, um dem I2C-Bus die nötige Zeit zur Verarbeitung zu geben.2. Sensor-Technik & Datenqualität
Hier stand die Luftdruck-Glättung im Fokus. Ich habe im
ClimateModuleeinen Alpha-Filter (Tiefpassfilter) implementiert. Dieser verhindert unschöne „Zacken“ durch Sensor-Rauschen. Zudem wurde ein Einrückungsfehler korrigiert, der die Methodenload(),save()undupdate()lahmlegte. Die Trend-Berechnung arbeitet nun deutlich präziser.3. Grafische Darstellung (Dashboard)
Damit die Kurven im Chart-Script nicht am oberen Rand „kleben“, sorgt die Einstellung
grace: '25%'nun für genug Luft zum Atmen. Die visuelle Ruhe wird in den nächsten Tagen zunehmen, wenn die alten Rohwerte aus derpressure_history.jsonrotieren.Mein Resümee
Das System läuft stabil, die Bibliotheken sind gepatcht und das Layout sitzt. Auch wenn ich bei der Implementierung der Kompressor-Kühlbox und der EcoFlow Delta 3plus erst einmal gescheitert bin, ist dieser Stand absolut brauchbar. Als Nächstes geht es an die Hardware: Sensoren anschließen, Störungsfilter für den Raspi im Fahrzeugbau und schließlich das Design für das Gehäuse.
Die nächste Tour kann kommen – und damit der Praxiseinsatz des MultivanPi!
Fred
Fred ist ein Fernwehgeplagter mit einem vielfältigen Portfolio: Unterwegs mit dem Motorrad, dem Auto, dem Camper... Als Fotograf versucht er, die Welt durch seine Linse einzufangen und mit seinen Worten zu beschreiben. Im Laufe des Lebens hat er sich immer wieder neu erfunden, verschiedene Berufe gelernt oder sich Wissen und Können selbst angeeignet. Auf XTramp.de vereint er diese Leidenschaften: Er dokumentiert seine kleinen, budgetfreundlichen Auszeiten und liefert gleichzeitig detaillierte, praxisnahe Anleitungen aus seiner Werkstatt – vom Schrauben an Motorrädern oder Autos, über Schreinern, Metallbau, Hochbau, Elektrik und Elektronik bis hin zu 3D-Druck-Projekten. Sein Ziel ist es, zu zeigen, dass Abenteuer und technisches Know-how für jeden zugänglich sind.