Venus OS Large auf dem Raspberry Pi installieren und Grundeinstellungen vornehmen

Loxone im Einsatz? Dann schau dir unseren LoxKurs an und profitiere von unserem Wissen!

Heute geht es um die Grundinstallation des Victron OS Betriebssystems auf dem Raspberry Pi. Ich erkläre im Sprinttempo, wie man in weniger als zehn Minuten alle relevanten Schritte durchführt, um das System so vorzubereiten, dass später alle wichtigen Grundvoraussetzungen vorhanden sind.

Dazu gehört ein lauffähiges NodeRED für die spätere Weitergabe von MQTT-Nachrichten sowie die Installation der Erweiterung DBUS-serialbattery, damit das BMS alle relevanten Batterieinformationen an das Victron-System übermitteln kann. Im Blogpost finden sich zudem alle relevanten Links und weitere Informationen zur verwendeten Hardware – soweit notwendig.

YouTube-Direktlink (externer Link)

Links aus dem Video:

00:06 balenaEtcher (externer Link)
00:33 raspberry pi install venus image (Github-Link)
01:57 Victron Connect App (externer Link)
05:28 Venus OS Large images (Dropbox-Link)
07:45 dbus-serialbattery (Github-Link)
08:26 dbus-serialbattery Config-Datei -> nano /data/etc/dbus-serialbattery/utils.py (Zum Speichern der Datei am Ende „STRG + s“ drücken und mit „Enter“ bestätigen)

Welche Raspberry Pi-Version ist geeignet?

Ich verwende hier einen „uralt“ Raspberry Pi 2 aus der Bastelschublade mit einem 2A Micro-USB-Netzteil (Affiliate-Link) einer 8GB Industiral MicroSD-Karte (Affiliate-Link), welche extra für hohe Schreizyklen ausgelegt ist, wodurch die Lebensdauer steigt.

In anderen Installationen nutze ich auch den Raspberry Pi 3 – läuft im Grunde genauso gut wie mit einem Raspberry Pi 2, da Venus OS einfach fast keine Leistung benötigt.

Wer noch einen Raspberry Pi für den Einsatz von Venus OS sucht, kann natürlich auch einen neueren Raspberry Pi einsetzen, wobei die zusätzliche Geschwindigkeit der neuen Modelle eigentlich nie gebraucht wird. Mit den neueren Venus-OS-Images scheint auch endlich das Bootproblem adressiert worden zu sein, sodass auch neue Hardwarerevisionen (board rev 1.4 and 1.5) des – derzeit schweineteuren – Rapsberry Pi 4 (Affiliate-Link) genutzt werden können. Das habe ich jedoch noch nicht selbst getestet, da ich nur „ältere“ Modelle besitze, bei denen es dieses Problem nicht gab.

Loxone im Einsatz? Dann schau dir unseren LoxKurs an und profitiere von unserem Wissen!

Verpasse keine Inhalte mehr! Trage dich in den Newsletter ein und folge uns auf Facebook.

Was ist ein Affiliate-Link? Wenn du auf einen Affiliate-Link klickst und über diesen Link einkaufst, bekomme ich vom betreffenden Online-Shop oder Anbieter eine Provision, was mich u.A. bei den laufenden Kosten den Blogs unterstützt. Für dich verändert sich der Preis nicht.

Jörg

hat meintechblog.de ins Leben gerufen, um seine Technikbegeisterung und Erkenntnisse zu teilen. Er veröffentlicht regelmäßig Howtos in den Bereichen Smart Home und Home Entertainment. Mehr Infos

57 Gedanken zu „Venus OS Large auf dem Raspberry Pi installieren und Grundeinstellungen vornehmen“

    1. Hi Gerhard,
      ich würde nach „Last modified“ sortieren und das aktuellste Image nehmen.

      „Large“ brauchst du primär nur dann, wenn du zusätzliche Funktionen über NodeRED umsetzen möchtest.

      Viele Grüße
      Jörg

    2. Hallo

      Habe auch einen RPI4 zugelegt Rev 1.4 damit läuft die neuesten Version V2.89 bootet nicht.
      Jetzt suche ich einen RPI4 mit Rev. V1.2 oder V1.3…

      Danke

    3. Moin Gerhard, hab gerade auch meine neue Hardware in Betrieb genommen und mit der Version v2.89 Probleme gehabt. Hierfür habe ich ein Fixup für die Boot Partition zusammen gestellt, welches unter https://cloud.w4systems.de/index.php/s/BGbAAYQWRmQ2aw3 zu finden ist. Das Kennwort lautet und „VenusOS-v2.89“. Für alle, die das zu gewagt ist ;-). Können auch die aktuelle Version v2.90 nutzen. Mit dieser klappt es auch und fix.
      Gruß, Mario

    4. Hallo Mario

      Ich habe eine RPI gefunden mit genau dieser Version läuft soweit auch.
      Hast du auch ein ESS System mit Pylontech Batterien US3000C oder sowas?

      Danke dir

    5. Hallo Gerhard,
      ja ich hab auch ein ESS System. Hab aber ein DIY Akku mit ca. 15kWh Speicher mit DALY BMS und so Spielereien halt. Für eine externe Steuerung hatte ich bisher noch keine Zeit – daher wird das ESS nur durch das Venus OS realisiert. Auf der AC Seite hängt noch ein Fronius. Die DC Seite ist nächstes Jahr dran. Hoffe, dass ich mit den 3 MultiPlus II 5000 nicht so schnell an meine Grenzen komme. Aber zur Not kann ich ja die Last auf die Phasen besser verteilen.
      Gruß, Mario

    6. Hallo Mario

      Ok verstehe ja ich bin gerade beim aufbauen Raspberry 4 wo Venus drauf läuft Multiplus 2 48V3000VA/35A-32A
      MPPT 150/45 -> ESS System
      Mach das zuerst mal einphasig zum Schauen wies funktioniert aber alles wird 3 phasig ausgeführt!

    7. Hi Gerhard,
      zum Schauen, wie es funktioniert, hab ich meinen DIY CamperVan genutzt. Elgris Smart Meter nach dem Zähler und ein MutliPlus II 48/3000 im Bus und ein MPPT 100/200 mit 800 Watt und 5KW Speicher über die Landstromseite angeschlossen (Netzparallelbetrieb). Dann noch ein kleines Venus OS auf dem Raspberry und die Sache lief super. Nur meine Frau fragt dann sowas wie: Warum läuft das erst jetzt? ;-).
      Gruß, Mario

  1. Vielen Dank! Das kommt wie gerufen da ich dein Setup mit dem Batteriespeicher gerade nachbaue (allerdings etwas kleiner und erst mal als USV ausgelegt.
    So wie ich es gerade rausgelesen habe aus deinen Blogposts wird die Batterie (bei mir 8S) am Multiplus (24V) angeschlossen. Per Venus OS gebe ich dem Multiplus die Ladeschlussspannung vor. Gleichzeitig kommuniziert das BMS per RS485-USB-Adapter mit dem Venus OS auf dem RPi.
    Heißt am RPi schließe ich einmal den VE.Direct Adapter zum Multiplus hin an und einmal den RS485-USB-Adapter zum BMS hin an.
    Optional soll später noch ein Solarladegerät angeschlossen werden. Auch an diesem stelle ich die Ladeschlussspannung ein und schließe es parallel zu der Batterie Multiplus Leitung an.
    Stimmen meine Aussagen soweit? Vielen Dank für deine Anleitungen.

  2. Hallo Jörg,
    vielen Dank für deine Mühen und das Teilen deines Wissens!
    Toll aufbereitet und ich bin auch sehr interessiert an der MQTT Anbindung an die Loxone.
    Nebenbei recherchiere ich noch die ganze Zeit, wie man aktuell gängige BMS für den ESS sauber an das System bekommt.
    Ist hier das DALI BMS auf vermutlich RS485 die aktuell sauberste Lösung?
    Für Tipps bin ich sehr dankbar.

  3. Hallo Jörg,
    würde denn das Ganze auch funktionieren, wenn man (nur) den CERBO benutzen will?
    Wenn ja, kannst du vielleicht mal die Unterschiede im Vorgehen skizzieren? Oder hast du die Raspberry-Lösung gewählt, weil sie mehr Möglichkeiten eröffnet, die ein CERBO gar nicht hat?
    Wäre schön, wenn du da mal Licht ins Dunkel bei mir bringst.

    1. Hi Martin,
      das Large-Image kannst du auf diversesten „Venus-OS-Devices“ installieren, auch auf einem Cerbo GX. Siehe hier im Kapitel „Step 1. Preparations“: https://www.victronenergy.com/live/venus-os:large

      Meiner Meinung nach ist es ziemlich wumpe, auf welcher Hardware schlussendlich Venus-OS läuft. Ich habe mehrere alte RPI ungenutzt rumfliegen, deshalb ist das für mich einfach am naheliegendsten. „Kostenfreie“ Hardware nutzen VS paar hundert Euro ausgeben -> das ist dann keine wirkliche Frage…

      Die Victron-Hardware hat eben den Vorteil, dass je nach Gerät direkt zig Victron-Schnittstellen verbaut sind, um Laderegler, Multiplus etc anzuschließen. Da muss man sich bei der Nutzung des RPI mit passenden Adaptern behelfen. Im meinem Fall hätte ich den recht teuren MK3-USB-Adapter zum Betrieb des Multiplus aber so oder so gebraucht, um ihm per PC ein manuelles Firmwareupdate zu verpassen.

      Hoffe das beantwortet deine Frage einigermaßen…

      Viele Grüße
      Jörg

      PS: Ach ein Vorteil des RPI wäre evtl. noch, dass man recht günstig ein Touchscreen anschließen kann, um die Venus-OS-Oberfläche direkt „on device“ nutzen zu können. Das werde ich evtl. demnächst auch mal vorstellen…

  4. Hallo Männer
    Hat jemand von euch schon mal überlegt, solch eine VenusOS Instanz auf einem intelbasierten Server laufen zu lassen?
    Weit verbreitet ist z.B. Proxmox. Würdet ihr eher ARM Emulation fahren oder versuchen Venus auf einem vanilla debian für amd64 zu kompilieren?
    Ich denke das ist ein Thema, welches viele interessiert.

    Ansonsten weiter so und weiterhin VIEL ERFOLG

    1. Klar. Das Hauptproblem bei einer solchen Virtualisierung ist inmer das Durchreichen der Hardware – also bspw. per USB angeschlossene Devices. Da geht aus meiner Erfahrung immer mal irgendwas schief und man muss Anpassungen vornehmen. Das ist inakzeptabel bei einer Lösung, die 100% der Zeit laufen MUSS. Da setze ich lieber auf ein dediziertes System auf Basis eine (alten) RPi…

      Viele Grüße
      Jörg

    2. Compilieren geht schonmal nicht ohne Weiteres. Du hast vom Venuskram nicht alle Sourcen. Und die ARM-Emulation via qemu-arm-static funktioniert meiner Erfahrung nach nicht immer zuverlässig.

      Dazu kommt der ganze DBus-Kram und die Tatsache, dass Venus das Starten diverser Programme via svc erledigt, wohingegen so gut wie jedes andere „brauchbare“ Linuxsystem mittlerweile aus guten Gründen auf systemd umgestellt hat.

      Folgerung: nimm einen Raspberry Pi. Den Aufwand, in so nem Konglomerat dann die Fehler zu suchen, ist es nicht wert.

      @Jörg: Die Idee von Fabio ist ja, die ARM-Programme direkt auf dem Intel-System laufen zu lassen. Prinzipiell geht das (via qemu-arm-static). Da muss keine Hardware an einen Emulator durchgereicht werden. Das Problem ist eher, dass der qemu unvollständig programmiert ist, nicht alle Feinheiten kennt, und bestimmt irgendeinen USB-Parameter nicht von 64-bit auf 32-bit übersetzt.

    3. Hi Matthias,
      danke für deine fundierte Einschätzung!

      Also habe Venus OS jetzt schon ne geraume Zeit auf einem steinalten Raspberry Pi 2 im Einsatz. Läuft perfekt, sogar in der Large-Variante inkl. NodeRed. Denke das ist langfristig mit Abstand die beste und zugleich preiswerteste Lösung. Da würde ich niemals eine Virtualisierung/Emulation anstreben…

      Viele Grüße
      Jörg

  5. Hallo Jörg

    ich habe seit kanpp zwei wochen das gleiche Setup (bis auf zwei EM24eth für Grid und PV) am laufen.
    Funktioniert soweit, bis auf ein Problem, wo ich nciht weiß ob ich zwei Batteriezellen umtauschen sollte weil zwei Zellen immer zuerst leer und zuletzt voll werden, mit einer Zelldifferenz von bis zu 0,115 (!) Volt.
    Auch ein runtersetzen der max balancing differeren von 30mV auf 10mV in der BMS config hat nicht geholfen.
    Selbst bei redizierten Laden/Entladen mit max 1000W schaltet irgendwann das BMS ab, bevor die gesamt max./min. Spannung erreicht wird, weil vorher eine Zelle leer oder eine zu voll ist. Bei Laden „balancen 10“ Zellen (abwechseld) die ganze Zeit, bevor die beiden anderen Zellen nach mehreren Stunden endlich die Ladung nachgeholt haben. Das derweilen „verbrennen“ der Energie von 10 Zellen ist der Effizienz wohl auch nicht erträglich.

    Anbei die Daten aus der BMS app in textform um zu zeigen wie unterschiedlich die batterieladestände selbst der 100% ladung sind.

    Laden AUS
    100 % 54.31 V
    285,58 von 285,60 Ah
    Leistung: O W
    Entladen
    Alarme [1]
    Temperatur
    Sensor 10 29,3°C
    Sensor 20 31,1°C
    Sensor 3 32.5°C

    Zellen A: 0,115, min[1]: 3,335, max[5]: 3,450

    01 3,335 V
    02 3,356 V
    03 3,423 V
    04 3,382 V
    05 3,450 V
    06 3,428 V [BALANCING]
    07 3,377 V
    08 3.342 V
    09 3,411 V
    10 3,439 V [BALANCING]
    11 3,400 V
    12 3,420 V [BALANCING]
    13 3,345 V
    14 3,387 V
    15 3,398 V
    16 3,422 V [BALANCING]

    Irgendeine Idee was man tun kann? Ich atte auch schon zweimal die Batterie über 3 Tage balancen lassen, wo der Victron nur nachladen durfte, aber das Ergebis sah nach dem nächsten Zyklus wieder genauso aus. Laut Batteriebeschriftungen haben alle die gleichen Werte.

    VG
    // Dirk

    1. sortierung nach Volt sieht wie foldend aus:
      3,335
      3,342
      3,345
      3,356
      3,377 [BALANCING]
      3,382 [BALANCING]
      3,387 [BALANCING]
      3,398 [BALANCING]
      3,400 [BALANCING]
      3,411 [BALANCING]
      3,420 [BALANCING]
      3,422 [BALANCING]
      3,423 [BALANCING]
      3,428 [BALANCING]
      3,439 [BALANCING]
      3,450 [BALANCING]

    2. Hi Dirk,
      das sind krasse Unterschiede. Hast du ein initiales Top-Balancing durchgeführt? So wie du es beschreibst („weil zwei Zellen immer zuerst leer und zuletzt voll werden“) -> Wohl eher nicht… Diese Zellen sind einfach im Vergleich zu den anderen Zellen immer ein gutes Stück weniger geladen. Dann ist da Fehlverhalten ganz normal.

      Also alle Zellen parallel schalten und auf 3,65V laden und danach für 1-2 Tage am Ladegerät „stehen“ lassen, bis alle Ausgleichsströme gleich 0 sind.

      Wenn das nicht hilft mal den Innenwiderstand der Zellen checken mit dem KAIWEETS Digital Multimeter (Affiliate-Link). Evtl. sieht man hier Unterschiede bei den einzelnen Zellen – aber ich tippe einfach mal auf das fehlende/unzureichende Top-Balancing. Werde ich demnächst auch näher darauf eingehen…

      Viele Grüße
      Jörg

      PS: Die passive Balancing-Funktion der meisten BMS ist „ein Witz“. Damit bekommst du solche krassen Ausreißer niemals in den Griff. Das ist eher für ein geringfügiges Nachjustieren der Zellspannungen über die Zeit sinnvoll.

  6. Danke Jörg
    Ich habe zu beginn alle Zellen auf die gleiche Spannung geprüft (die sie alle (ohne Last) hatten), aber nachdem ich die Batterien dann nach der erstmaligen Beladung dann mittels balancing auf 0,020 unterschied gebracht hatte (durch temp. top balancing im BMS auf 10mV diff.), dachte ich das das damit erledigt wäre.
    Ok, dann werde ich mich mal der 3.65V annähern und die Zellen erst einzel auf die gleiche Spannung bringen und dann erst gemeinsam um hohe Ausgleichströme zu verhindern.
    PS: ich sehe nirgends was deine max. Ladespannung im DVCC Menü ist (16*3,3) 52,8V oder 55 wie default?

    VG
    // Dirk

    1. Nenene, das reicht niemals. Die Spannung ist absolut kein valider Indikator im „mittleren“ Spanunngsbereich, was den aktuellen Ladestand angeht. Wenn die Zelle 2,8V hat, kannst du sagen, dass sie ziemlich am Ende ist. Wenn sie 3,6V hat, kannst du sagen, dass sie ziemlich ziemlich voll ist. Alles dazwischen ist Rätselraten. Deshalb muss der Shunt des BMS auch mittracken, wieviel „Arbeit“ in die bzw. aus den Zellen fließt. Nur so kann er errechnen, wie in etwa der aktuelle SoC ist. Auch kann sich die Zellspannung „schlagartig“ ändern, wenn du hohe Lade- oder Entladeströme hast, da sind die LiFePo4-Zellen echt nicht einfach zu monitoren. Nur so als Randinfo…

      Du kannst ruhig alle Zellen direkt parallel klemmen, sofern nicht eine komplett leer und eine komplett voll ist. Am besten vernünftige Zellkontaktierungen verwenden. Nen „Popeldraht“ ist da fehl am Platz. Habe mir dazu extra passende 10qm Leitungen mit M6 Kabelschuhen gebastelt, da ich zu wenige Busbars hatte. Das ist kritisch, damit man keine großen Übergangswiderstände und damit Spannungsunterschiede zwischen den Zellen aufbaut.

      Das Labornetzteil auf 3,65V einstellen und dann erst verbinden. Und dann brav warten bis die Ampere-Anzeige am Labornetzteil gegen 0 geht. Erst dann sind die Zellen „saturiert“ – also voll. Danach noch 1-2 Tage so lassen und dann wieder zurückbauen ins Batteriecase. Wenn du gaaanz auf „Nummer Sicher“ gehen willst die Zellen abklemmen und nochmal einige Tage einfach so rumliegen lassen und dann nochmal die Spannungen prüfen. Dies sollten dann alle ziemlich gleich sein bei 3,4x V. Das hat mir persönlich aber bisher immer zu lange gedauert und es hat mir in den Fingern gejuckt.. :D

      Ladespannung ist bei mir 54,4V, sodass jede Zelle im besten Fall bei 3,4V landet.

      Viele Grüße und Erfolg
      Jörg

  7. Ich halte diese Methode („aufpumpen“ der (neuen) Zellen auf 3,65 V und dort 2 Tage halten), die im Internet weithin propagiert wird, für ziemlich kontraproduktiv.
    3,65 V sind schon eine Spannung, bei der LiFePos anfangen, ziemlich zu ächzen. Wenn es dann noch eine Messungenauigkeit gibt oder das verwendete Labornetzteil nicht exakt regelt, hat man die Lebensdauer der nagelneuen Zellen schnell mal um ein paar hundert Zyklen verkürzt.
    Ich habe in meine Batterie (8s, 280 Ah, 250 A Daly BMS ) einen aktiven Balancer für 22,80 (AliExpress) eingebaut. Das Teil ist mit Elkos vollgestopft und transferiert bei größeren Differenzen bis zu 5,5A (!) von der höchsten zur niedrigsten Zelle im Verbund.
    Beim ersten Laden habe ich, als die Zellen anfingen, auseindanderzulaufen, den Ladestrom reduziert (auf das, was mein 160WP Solarpanel gerade so brachte) und konnte zusehen, wie der Balancer die Spannungsunterschiede innerhalb weniger Stunden restlos beseitigt hat.
    Das ganze bei max. 3,5V Zellenspannung, also in einem Bereich, in dem sich LiFePos noch wohl fühlen.
    Der Balancer bleibt drin, die paar mA, die er im Normalbetrieb verbrät, kratzen mich nicht und ich kann sicher sein, dass die Zellen nie wieder auseinander laufen können.
    Wie Jörg schon ganz richtig schreibt – die Balancing-Funktion der meisten BMS ist wirklich ein Witz (30-50mA, passiv). Wenn die Kapazität der Zellen sich nur um wenige Ah unterscheidet und relativ schnell hintereinander Zyklen gefahren werden, dann laufen die Zellen unweigerlich immer weiter auseinander, zumal ein „natürliches“ Balancing im Bereich zwischen 5% und 95% SOC aufgrund der flachen Spannungskurve und der fast 100% Wirkungsgrad der LiFePos praktisch nicht stattfindet.
    VG
    Thomas

  8. Mit dem Raspberry habe ich nur ein Problem. Nach dem Flashen auf dem SD-Card, tut sich bei mir auf einem Raspberry pi 2 1.2 nichts. Es leuchtet nur einmal auf und dann wars das, da bewegt sich nichts. Egal welches Venus OS ich nehme! Kann mir da wer weiterhelfen?

  9. So einfach ist es nicht, hab alle möglichen Karten ausprobiert… Bin zum Schluss gekommen, das RPI 2 – V.1.2 nicht funktioniert, stattdessen wieder den RPI 2 V1.1 rausgesucht und mit dem gehts!

    Nochmal Danke für deine Beiträge! SIND SUPER UND HIFLREICH!!!!

    1. Ok, danke für dein Feedback. Evtl. hilft ja ein Firmwareupdate des betreffenden RPI oder vielleicht hat er auch das Zeitliche gesegnet. Spannend wäre z.B. auch zu wissen, ob ein „Standardimage“ Raspberry Pi OS funktioniert…

    2. Alternativ kann man Venus problemlos auf einem Debian-RaspberryPi-Kernel betreiben und spart sich den alten, von Victron irgendwie gepatchten Kernel, der nichtmal I²C oder USB-GPIO-Pins oder was-auch-immer kann. (Nein, Victron weigert sich, das zu ändern.)

      Ich habe dazu mal ein Skript geschrieben. Getestet auf Pi3, muss für Pi2 ggf leicht angepasst werden. Ein Debian-Dateisystem, das man alternativ booten kann wenn was repariert werden muss, wird der Einfachheit halber auch mit aufs Image geschrieben.

      https://github.com/M-o-a-T/moat-victron/tree/main/scripts/build_image

  10. Herzlichen Dank für die ganzen Infos, die hier geboten werden. Ich bin noch fleißig am Lesen. Alles ist mir noch nicht ganz klar. Dennoch möchte ich eine generelle Frage stellen: hat irgendwer (erfolgreich) probiert Venus OS auf einem „normalen“ x86 Rechner zu kompilieren? Geht das irgendwie? Mir wäre es das Liebste, wenn ich einen NUC oder anderen x86 ThinClient verwenden könnte. Die Zuverlässigkeit scheint mir höher als beim Raspi. Hatte da oft Probleme (ja es kann sein, dass die SD Karte das Problem war. Ich hatte keine hier beschriebene Industrial Karte zur Hand).

    1. Hi Stephan,
      unabhängig davon, ob es technisch möglich ist, ist es meiner Meinung nach nicht wirklich zielführend. Habe auch lange hin- und herüberlegt, aber die „Victron-Logik“ in einen schlanken RaspberryPi auszulagern, ist meiner Ansicht nach auch langfristig die beste Lösung.

      Das System läuft nach dem Booten komplett im Ram (wie ich das verstehe) und wenn man dann noch alle Loggings deaktiviert, sollte da mit der SD-Karte nicht viel passieren. Ausserdem kann man für paar Euro auch einfach einen SD-Karten-Clone neben den RaspberryPi legen und im Bedarfsfall in 10s switchen. Wenn man es ganz „redundant“ auslegen möchte, kann man auch einen zweiten RPI danebenlegen für „Notfälle“. Insgesamt reicht hier auch ein gebrauchter RPI2/3 locker aus, den man selbst in diesen verrückten Zeiten recht günstig über eBay schießen kann.

      Was ich selbst noch nicht mit Venus OS versucht habe, aber was eigentlich mit den neueren Versionen auch gehen sollte: RPI4 mit USB-SSD als Systempartition (inkl. Boot) – dann sollte auch dieses Thema mit der SD-Karte gegessen sein, wenn es überhaupt real eines war.

      Viele Grüße
      Jörg

    2. Venus ist für einen Pi gebaut und läuft auch nur da drauf. Ein paar der beteiligten Programme haben keinen öffentlichen Quellcode. Außerdem ist das Venus-System ein einheitliches System, das kann man nicht mal eben stückchenweise auf eine „normale“ Distribution portieren, egal ob das jetzt ARM oder x86 ist. System-DBus-Rechtevergabe, udev-Regeln, etc.pp. unterscheiden sich ziemlich von einer „normalen“ Linuxdistro.

      Man *könnte* natürlich mit Emulator, VM, und weiterem Spielkram arbeiten, aber qemu für ARM ist nicht besonders stabil. So einem Konstrukt würde ich meine Energieversorgung nicht anvertrauen wollen.

  11. Hallo Jörg,

    inspiriert von deinem Blog baue ich gerade selbst zwei 16s MP2 ESSe auf. Nun rätsel ich, ob es wirklich den 90 € „PC Victron MK3-USB Schnittstelle (VE.Bus auf USB)“ benötigt oder auch das „Victron Energy USB-Interface Kabel“ (https://www.amazon.de/Kabel-Schnittstelle-VE-Direct-Victron/dp/B01LZ6WTLW/ref=dp_prsubs_2?pd_rd_i=B01LZ6WTLW&th=1) für knapp 30 € genügt. Soweit ich das aus den Bewertungen lese, haben die Leute auch damit den MP2 an Raspberries angeschlossen. Vielen Dank schonmal für deine Rückmeldung!

    Liebe Grüße
    Stefan

  12. Hallo zusammen,

    ich habe die 2.89 auf meinen Pi 3 geflasht. Jetzt möchte ich die OS Large per USB Stick installieren. Es wird aber kein USB Speicher gefunden? Hat hier jemand eine Ahnung?

    Grüße Oliver

  13. Hallo,

    erstmal vielen Dank für die Top Anleitung.

    Ich habe leider momentan das Problem, dass das Venus OS die
    venus-swu-2-raspberrypi2-20220208150229-v2.82-large-30.swu
    auf dem USB-Stick nicht als Firmware erkennt.

    Der Stick ist mit FAT32 formatiert, komplett leer und von Win10 beschrieben worden.

    Irgendjemand eine Idee, woran das liegen könnte?

    1. Servus. Habe den USB Stick mit „sd card formatter 5.0.2“ formatiert (quick format) und anschließend die gleiche .swu wie du auf den Stick kopiert. Danach wurde die Firmware erkannt und ich konnte es installieren.

  14. Thema hat sich erledigt. Ich habe nicht gesehen, dass ich bereits die V2.9 als large Version direkt installiert hatte. D.h. ich brauchte die Large Version gar nicht per USB Stick nachinstallieren.

    Man kann direkt per balenaEtcher die Large-Version installieren.

    Venus OS gefällt mir!

    1. Klar gibt es den. Suche nach „Victron MK3-USB VE.Bus zu USB Interface“ im Onlineshop deiner Wahl.

  15. Hallo Jörg
    Auch wenn meine Batterien noch nicht da sind, fange ich schon mit den Vorbereitungen an. Ich habe mich an dein Video gehalten und bis 8:19 min lief alles gut. Einen FAT32 USB stick habe ich für die venus-daten-tar.gz Datei verwand und wie von dir beschrieben in den PI gesteckt und neu gestartet. Da passiert aber nichts weiter. Den Bildschirm mit dem Root Verzeichnis sehe ich nicht. Ob die Daten übertragen wurden, weiß ich auch nicht.
    Ich bitte um Hilfe. Danke im Voraus.

    1. Hi Ewdin,
      was meinst du mit Root-Verzeichnis? Bitte konkrete ssh-Befehle angeben, die du versucht hat und was das Ergebnis (Antwort des Systems) war.

      Viele Grüße
      Jörg

  16. Hallo Jörg
    Wenn ich den PI neu starte kommt automatisch die Victron Software, keine Fehlermeldung. Das, was Du im Video als Schwarz mit weißer Schrift hast (SSH root…….Einstellungen Dbus), kommt bei mir nicht und damit kann ich auch dort nichts einstellen. SSH Befehle?? Wie kommt man dahin?
    VG
    Edwin

  17. Hallo Matthias
    Mit dem Programm Putty konnte ich mich einloogen und nach einigen Stunden waren die Daten auch drin. Offensichtlich mochte der PI mein USB Stick trotz mehrmaligem Formatieren nicht.
    Übrigens….meine Accus sind vor 3 Tagen aus Singapore weitergeschippert……grrr

  18. Hallo Matthias,
    tolles Video! Vielen Dank.
    Da ich grade Stück für Stück mein System aufbaue und noch auf die restlichen Zellen aus China warte, eine willkommen Ergänzung und Alternative. Dachte schon ich benötige noch einen Cerbo….
    Also den ausrangierten Pi4 raus geholt und Venus OS plus die Erweiterung für das BMS installiert. Soweit, so gut. Funktioniert.

    Allerdings scheitere ich an der Zuordnung einer festen IP. Es scheint, dass sich beim Einstellen Venus OS aufhängt. Ich kann dann nur über das ESS in der Victron APP auf dem iPhone wieder auf automatische IP das OS erreichen.

    Momentan hängt der Pi in meinem „Hauptnetzwerk“, wo ich ihn aber nicht haben möchte.
    Ich habe für meine PV und Hausautomation ein Subnetz, wo jetzt auch der Pi rein soll.
    Hat noch wer solche Probleme?
    Wie muss ich korrekt vorgehen? Ab dem Zeitpunkt, bei dem ich die neue IP eintrage, zeigt Venus OS keine Reaktion mehr. Auch nach mehrminütigem warten ist es unter der neuen Adresse nicht erreichbar.

    Vielen Dank und Gruß
    Joachim

    1. Hi Joachim,
      das ist echt komisch. Hat bei mir bisher immer geklappt… Der Pi hängt bei dir schon per Netzwerkkabel im LAN, oder?

      Viele Grüße
      Jörg

    2. Hallo Jörg,
      ja. Der Pi hängt per Kabel an meinem LAN aktuell per DHCP. Da bezieht er auch eine IP und ich erreiche über diese das Venus OS und kann alle Einstellungen wie von dir im Video beschrieben vornehmen.
      Wenn ich allerdings unter Ethernet auf manuell gehe und dann die IP sowie Gateway auf das Sub-Netz eintrage geht nichts mehr….
      Gruß Joachim

    3. Hallo Jörg,
      einen kleinen Schritt bin ich weiter, allerdings nicht über das Venus OS sondern dadurch, dass ich dem Port, an dem der Pi hängt, nur das Sub-Netz zugewiesen habe. Dadurch erhält der Pi bzw. das OS jetzt zumindest per DHCP. Löst aber das Problem mit der festen Zuweisung weiterhin nicht.

      Kann ich nicht auch einfach dem Pi per SSH die feste IP geben und Venus OS erkennt das dann?
      Oder geht das nur über die Oberfläche von Venus OS.

      Gruß Joachim

  19. Nach langem hin und her probieren hat es jetzt tatsächlich die neue IP direkt geschluckt….
    Sorry für´s zuspammen hier und danke für deine schnelle Rückmeldung!

    Gruß Joachim
    (und weiter so!!!! Mega toller Blog!)

    1. Hallo Jörg,

      nähere mich dem Ende der ersten Ausbauphase – demnächst sollte die Inbetriebnahme starten.

      Ich habe zwar einen MP2 GX, würde aber aufgrund der Möglichkeit einen externen Display anzuschließen doch lieber einen Raspi nutzen.

      Beisst sich das mit dem GX bzw. welches System überlagert oder muss/kann GX ausgeschaltet werden.

      Danke & Grüsse

      Vjeko

    2. @Vjeko
      Man kann den GX drinlassen, muss ihm halt verbieten irgendwas mit seiner eingebauten vebus-Schnittstelle zu tun.

      Den laufenden vebus-Prozess abklemmen geht mit diesem Shell-Befehl:

      svc -d /service/mk2-dbus.*

      Um zu verhindern, dass der Prozess nach einem Reboot / Hotplug wiederkommt, fasse /opt/victronenergy/service-templates/mk2-dbus/run mit dem Editor an und schreibe sowas wie „while sleep 99999 ; do sleep 99999; done“ in die zweite Zeile.

  20. Hallo,
    Ich baue bei nem Bekannten auch eine PV aufs Dach, da werde ich 3x Victron Multiplus 2 48/3000 + 3x Laderegler Victron 150/45 + 1x Victron Smart Shunt + 2x Daly BMS 16s/250 verbauen.

    Kann ich das ganze mit einem Rasp 4 steuern?
    Bisher hab ich mit so einer grossen PV keine Erfahrung, hab es nur im Gartenhaus über nen esmart3 und nen Smart Shunt mit Grafsna am laufen.
    Sorry für die Anfänger Fragen 😩

    Mit freundlichen Grüßen
    Robert

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert