Seit dem letzten Update am 3. Februar 2026 hat sich am MultivanPi enorm viel getan. Was als Versuch begann, „einfach nur ein paar Daten anzuzeigen“, entwickelte sich zu einer tiefgreifenden Optimierung der Systemstabilität. Ich nenne es intern mittlerweile den „Chromium-Standard“ – ein System, das so robust läuft, dass man es wie ein kommerzielles Produkt im Van nutzen kann. Doch der Weg dahin war gepflastert mit I2C-Adresskonflikten, schweigenden Bluetooth-Geräten und API-Sackgassen.
Bevor ich zu den Erfolgen komme, möchte ich ehrlich darüber sprechen, was (noch) nicht geklappt hat. In der DIY-Entwicklung gehört das Scheitern dazu, um Ressourcen richtig zu priorisieren.
Das EcoFlow-Dilemma
Ich habe viel Zeit investiert, um die EcoFlow Delta 3+ direkt in das Dashboard zu integrieren. Das Ziel war, Ladezustand und Verbräuche ohne Cloud-Umweg auszulesen und die Ausgänge für 230V, für 12V und für USB zu schlaten. Trotz diverser Ansätze über lokale APIs und Reverse-Engineering-Bibliotheken erwies sich die Schnittstelle als extrem instabil („Moving Target“). Die ständigen Verbindungsabbrüche gefährdeten die Stabilität des gesamten MultivanPi. Entscheidung: Ich habe die EcoFlow-Integration vorerst auf Eis gelegt, bis eine dokumentierte oder stabile lokale Schnittstelle verfügbar ist.
Die stumme Kühlbox
Ähnlich erging es mir mit der Kompressorkühlbox (Vevor/Alpicool Modell). Während der Raspberry Pi die Box via Bluetooth zwar „sehen“ und sich verbinden konnte, blieb die Datenleitung tot. Ich vermute ein Challenge-Response-Verfahren oder eine Verschlüsselung, die ohne Hardware-Sniffer (Mitschneiden der Kommunikation zwischen Original-App und Box) nicht zu knacken ist. Entscheidung: Statt das System mit endlosen Verbindungsversuchen auszubremsen, habe ich dieses Feature vorerst deaktiviert. Stabilität geht vor Informationsfülle.
Der „Chromium-Standard“
Nachdem ich diese Entscheidungen getroffen hatte, habe ich mich wieder auf die Basiskomponenten konzentriert: Anbindung meiner Victron-Geräte, Anbindung der Umwelt-Sensoren und das härten des Betriebssystem. Hier habe ich massive Fortschritte erzielt.
1. Robustes Victron BLE Scanning
Ein großes Problem war der Empfang der Victron-Geräte (Solarregler, Ladebooster, Shunts, SmartSens), besonders wenn diese in den Energiesparmodus gehen.
Die Lösung war ein komplett neu geschriebener Bluetooth-Scanner (passives Scannen). Statt aktiv zu verbinden, „hört“ der Raspi nur noch auf die „Werbepakete“ (Advertisements) der Geräte. Das hat zwei Vorteile:
Die Reichweite ist besser, auch schwache Signale können ausgewertet werden.
Die VictronConnect App auf dem Handy kann parallel genutzt werden, da der Raspi den Kanal nicht blockiert.
2. Das I2C-Detektivspiel (Der Wasserwaagen-Krimi)
Die digitale Wasserwaage (Leveling) trieb mich fast in den Wahnsinn. Mal funktionierte sie, mal blockierte sie die Echtzeituhr (RTC).
Die Diagnose via i2cdetect brachte dann die Lösung: Warum auch immer war ein falscher Sensor in mein Script gerutscht. Zwischenzeitlich hatte ich mal getestet, ob der MPU6050 sich für mein Projekt besser eignet als der ADXL345. Problem dabei: Der wird auf Adresse 0x68 angesprochen. Dort sitzt aber bereits die RTC (Echtzeituhr) des Raspi, die vom Linux-Kernel blockiert wird.
Die Lösung war so simpel wie effektiv: Ich bin zurück auf den ADXL345 gewechselt. Der hat standartmäßig die Adresse 0x53. Nach dem Treiberwechsel und der Implementierung eines Tiefpass-Filters (für die Beruhigung) laufen die „Libellen“ im Dashboard nun absolut flüssig und ohne Zittern.
Technik-Tipp für Nachbauer:
Prüft eure I2C-Adressen immer mit sudo i2cdetect -y 1. Wenn bei einer Adresse „UU“ steht, hat der Kernel die Hand drauf. Versucht niemals, diese Adresse mit Python-Skripten direkt anzusprechen – das führt zu Systeminstabilität.
sudo i2cdetect -y 1
3. Kiosk-Mode und Energiemanagement
Ein Computer im Camper sollte so wenig an der Batterie nuckeln wie möglich. Ich habe das Start-Skript (start_kiosk.sh) dahingehend erweitert:
Auto-Sleep: Das Display schaltet sich nach 15 Minuten Inaktivität hart ab (DPMS), um Strom zu sparen.
Wakeup-on-Touch: Eine Berührung des Touchscreens weckt das System sofort wieder auf.
Selbstheilung: Sollte der Browser abstürzen, startet ihn das Skript automatisch neu, ohne Fehlermeldungen („Möchten Sie die Sitzung wiederherstellen?“) anzuzeigen.
4. Hardware Wake-Up Taster
Mit einem eigenen Menüpunkt kann der Pi komplett herunterfahren werden. Sinnvoll, wenn man länger steht und das Display nicht braucht. Deshalb brauchte ich eine Möglichkeit, ihn ohne Stecker-Ziehen wieder zu starten.
Ich nutze dafür eine Hardware-Funktion des Broadcom-Chips auf dem Raspberry Pi. Ein Edelstahl-Taster verbindet Pin 5 (GPIO 3) kurz mit Pin 6 (GND). Das weckt den Pi zuverlässig aus dem Tiefschlaf (Halt-State).
Das Ergebnis: Dashboard V3.2
Das System läuft nun in Version 3.2. ich habe das Layout finalisiert:
System-Info: Rechts werden nun CPU-Temperatur, RTC-Temperatur und die aktuelle WLAN-SSID angezeigt- oder eben, wenn man nicht mit einem WLAN verbunden ist.
Luftdruck-Historie: Dank korrigierter Kalibrierungs-Mathematik (Bosch-Formel) zeichne ich den Luftdruck über 3 Tage auf – perfekt zur Wettervorhersage unterwegs.
Das Energie-Modul: Ist nun endgültig fertig.
Das Ausrichten-Modul: Ist ebenfalls fertig.
Versionsausgabe: Klingt erstmal als Spielerei, war aber hilfreich beim Scripten und Testen. Angezeigt wird die Frontend-Version und die Backend-Version des Python-Scriptes.
Fazit:
Ich habe mich dafür entschieden, dass weniger manchmal mehr ist. Die Komponenten Kühlbox und EcoFlow – Integration wären interessante Informationen für mich. Aber ohne eine dokumentierte Bibliothek fließt unglaublich viel Zeit in Testen, umbauen, testen … Alleine Für die EcoFlow Tests ist die Versionsnummer des Backend von 2.4 auf 19.1 gewachsen. Ich habe das Modul drin gelassen, um es nicht aus den Augen zu verlieren. Hab aber alle aktiven Abfragen herausgenommen, um das System stabil zu machen. Die Kernfunktionen – Strom, Solar, Klima, Ausrichtung – die das Grundkonzept geformt haben, konnte ich alle implementieren . Der „Chromium-Standard“ steht für ein System, auf das man sich verlassen kann.
Ausblick
Das System ist nun hardware- und softwareseitig stabil (deshalb nenne ich es „Platinum Status“). Die nächsten Schritte werden sich eher um das Gehäuse, die feste Verkabelung im Multivan und Langzeittests auf der nächsten Tour drehen. Der Code ist sauber, dokumentiert und bereit für den Praxiseinsatz.
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.
6 Feb. 2026
MultivanPi Teil 3: Der Weg zum „Chromium-Standard“ – Victron, Sensoren und harte Lektionen
Seit dem letzten Update am 3. Februar 2026 hat sich am MultivanPi enorm viel getan. Was als Versuch begann, „einfach nur ein paar Daten anzuzeigen“, entwickelte sich zu einer tiefgreifenden Optimierung der Systemstabilität. Ich nenne es intern mittlerweile den „Chromium-Standard“ – ein System, das so robust läuft, dass man es wie ein kommerzielles Produkt im Van nutzen kann. Doch der Weg dahin war gepflastert mit I2C-Adresskonflikten, schweigenden Bluetooth-Geräten und API-Sackgassen.
Inhalt
Die Rückschläge: Wenn Hardware schweigt
Bevor ich zu den Erfolgen komme, möchte ich ehrlich darüber sprechen, was (noch) nicht geklappt hat. In der DIY-Entwicklung gehört das Scheitern dazu, um Ressourcen richtig zu priorisieren.
Das EcoFlow-Dilemma
Ich habe viel Zeit investiert, um die EcoFlow Delta 3+ direkt in das Dashboard zu integrieren. Das Ziel war, Ladezustand und Verbräuche ohne Cloud-Umweg auszulesen und die Ausgänge für 230V, für 12V und für USB zu schlaten. Trotz diverser Ansätze über lokale APIs und Reverse-Engineering-Bibliotheken erwies sich die Schnittstelle als extrem instabil („Moving Target“). Die ständigen Verbindungsabbrüche gefährdeten die Stabilität des gesamten MultivanPi.
Entscheidung: Ich habe die EcoFlow-Integration vorerst auf Eis gelegt, bis eine dokumentierte oder stabile lokale Schnittstelle verfügbar ist.
Die stumme Kühlbox
Ähnlich erging es mir mit der Kompressorkühlbox (Vevor/Alpicool Modell). Während der Raspberry Pi die Box via Bluetooth zwar „sehen“ und sich verbinden konnte, blieb die Datenleitung tot. Ich vermute ein Challenge-Response-Verfahren oder eine Verschlüsselung, die ohne Hardware-Sniffer (Mitschneiden der Kommunikation zwischen Original-App und Box) nicht zu knacken ist.
Entscheidung: Statt das System mit endlosen Verbindungsversuchen auszubremsen, habe ich dieses Feature vorerst deaktiviert. Stabilität geht vor Informationsfülle.
Der „Chromium-Standard“
Nachdem ich diese Entscheidungen getroffen hatte, habe ich mich wieder auf die Basiskomponenten konzentriert: Anbindung meiner Victron-Geräte, Anbindung der Umwelt-Sensoren und das härten des Betriebssystem. Hier habe ich massive Fortschritte erzielt.
1. Robustes Victron BLE Scanning
Ein großes Problem war der Empfang der Victron-Geräte (Solarregler, Ladebooster, Shunts, SmartSens), besonders wenn diese in den Energiesparmodus gehen.
Die Lösung war ein komplett neu geschriebener Bluetooth-Scanner (passives Scannen). Statt aktiv zu verbinden, „hört“ der Raspi nur noch auf die „Werbepakete“ (Advertisements) der Geräte. Das hat zwei Vorteile:
2. Das I2C-Detektivspiel (Der Wasserwaagen-Krimi)
Die digitale Wasserwaage (Leveling) trieb mich fast in den Wahnsinn. Mal funktionierte sie, mal blockierte sie die Echtzeituhr (RTC).
Die Diagnose via
i2cdetectbrachte dann die Lösung: Warum auch immer war ein falscher Sensor in mein Script gerutscht. Zwischenzeitlich hatte ich mal getestet, ob der MPU6050 sich für mein Projekt besser eignet als der ADXL345. Problem dabei: Der wird auf Adresse 0x68 angesprochen. Dort sitzt aber bereits die RTC (Echtzeituhr) des Raspi, die vom Linux-Kernel blockiert wird.Die Lösung war so simpel wie effektiv: Ich bin zurück auf den ADXL345 gewechselt. Der hat standartmäßig die Adresse 0x53. Nach dem Treiberwechsel und der Implementierung eines Tiefpass-Filters (für die Beruhigung) laufen die „Libellen“ im Dashboard nun absolut flüssig und ohne Zittern.
Prüft eure I2C-Adressen immer mit
sudo i2cdetect -y 1. Wenn bei einer Adresse „UU“ steht, hat der Kernel die Hand drauf. Versucht niemals, diese Adresse mit Python-Skripten direkt anzusprechen – das führt zu Systeminstabilität.3. Kiosk-Mode und Energiemanagement
Ein Computer im Camper sollte so wenig an der Batterie nuckeln wie möglich. Ich habe das Start-Skript (
start_kiosk.sh) dahingehend erweitert:4. Hardware Wake-Up Taster
Mit einem eigenen Menüpunkt kann der Pi komplett herunterfahren werden. Sinnvoll, wenn man länger steht und das Display nicht braucht. Deshalb brauchte ich eine Möglichkeit, ihn ohne Stecker-Ziehen wieder zu starten.
Ich nutze dafür eine Hardware-Funktion des Broadcom-Chips auf dem Raspberry Pi. Ein Edelstahl-Taster verbindet Pin 5 (GPIO 3) kurz mit Pin 6 (GND). Das weckt den Pi zuverlässig aus dem Tiefschlaf (Halt-State).
Das Ergebnis: Dashboard V3.2
Das System läuft nun in Version 3.2. ich habe das Layout finalisiert:
Ich habe mich dafür entschieden, dass weniger manchmal mehr ist. Die Komponenten Kühlbox und EcoFlow – Integration wären interessante Informationen für mich. Aber ohne eine dokumentierte Bibliothek fließt unglaublich viel Zeit in Testen, umbauen, testen … Alleine Für die EcoFlow Tests ist die Versionsnummer des Backend von 2.4 auf 19.1 gewachsen. Ich habe das Modul drin gelassen, um es nicht aus den Augen zu verlieren. Hab aber alle aktiven Abfragen herausgenommen, um das System stabil zu machen. Die Kernfunktionen – Strom, Solar, Klima, Ausrichtung – die das Grundkonzept geformt haben, konnte ich alle implementieren . Der „Chromium-Standard“ steht für ein System, auf das man sich verlassen kann.
Ausblick
Das System ist nun hardware- und softwareseitig stabil (deshalb nenne ich es „Platinum Status“). Die nächsten Schritte werden sich eher um das Gehäuse, die feste Verkabelung im Multivan und Langzeittests auf der nächsten Tour drehen. Der Code ist sauber, dokumentiert und bereit für den Praxiseinsatz.
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.