Dieses Blog durchsuchen

 

Wer eine Photovoltaik-Anlage hat, kennt das Thema nur zu gut: Tagsüber liefert die Sonne oft mehr Strom, als gerade verbraucht wird – der Überschuss fließt ins Netz. Abends oder bei trübem Wetter wird wieder aus dem Netz bezogen. Ein Batteriespeicher kann genau in diese Lücke springen: Überschuss speichern und bei Bedarf wieder abgeben. Damit sinkt der Netzbezug und man nutzt den eigenen Solarstrom besser.
In dem Blog Beitrag geht es um die Steuerung des Marstek-Venus-E3 Speichers mittels Home Assistant. Ich beschreibe wie man ihn per Modbus-Integration in sein Netzwerk anbinden kann und wie eine Automation die Lade- und Entladeleistung anhand von Einspeisung und Bezug automatisch regelt – inklusive Blueprint zum direkten Einsatz.
 
Der Marstek Venus E3 ist ein AC-seitiger Batteriespeicher, der sich einfach in bestehende PV-Anlagen (besonders kleine Balkonkraftwerke) integrieren lässt. Der Speicher nimmt überschüssigen Solarstrom auf und gibt ihn bei Bedarf wieder ab.
Für die Steuerung gibt es eine Vielzahl von Möglichkeiten. Der Marstek unsterstützt auch, über die Marstek-Smartphone APP kofigurierbar, Smartmeter von Shelly und div. anderen Herstellern.
Ich benutze aber die Informationen die mir das EVU-Smartmeter ohnehin schon zur Verfügung stellt und die ich im Homeassistant als ESP-Home Entitäten zur Verfügung habe. ( siehe Projekt: https://blog.fh-kaernten.at/ingmarsretro/2024/03/21/evu-smartmeter-mit-esp32-und-esphome-auslesen-und-in-homeassistant-verwenden/)
 
Um den Marstek  an den Homeassistant anzubinden, gibt es einige Möglichkeiten. Für mich immer interessant ist natürlich eine cloudfreie offline Anbindung.  Hierfür stellt der Speicher den Modbus über zwei Anschlüsse bereit. Über RS485 und als ModbusTCP auch über den LAN-Port des Geräts. Also ideale Bedingungen. Da bei mir soviel wie möglich kabelgebunden abläuft, hängt mein Marstek ohnehin über LAN am Router. Modbus TCP kommuniuziert über den Port 502. Es gilt nur noch die IP Adresse des Marstek herauszufinden. Die ist am schnellsten über den Router oder eine IP-Scanner Software herauszubekommen. Hat man diese Info, dann gehts schon im Homeassistant weiter. Hier gibt es ein super github-repository: https://github.com/ViperRNMC/marstek_venus_modbus das die Integration des Marstek über ModbusTCP bereitstellt. Installiert wird die Integration über ein  custom-repo in HACS und schon kann man die Marstek IP eingeben und sollte danach folgende Entitäten zur Verfügung haben:
 
 
  •  Ladeleistung einstellen:   Wie viel Watt die Batterie maximal aus dem Überschuss laden soll (z. B. 0–2500 W).
  •  Entladeleistung einstellen: Wie viel Watt aus der Batterie abgegeben werden soll, um den Hausbezug zu decken (z. B. 0–2500W).
  • Maximale Ladeleistung: Die Obergrenze für die Ladeleistung
  • Maximale Entladeleistung: Die Obergrenze für die Entladeleistung
  • Batterie-Ladezustand (SOC): State of Charge in Prozent – wichtig, um z. B. bei vollem Speicher das Laden zu stoppen oder unter einem Mindest-SOC nicht mehr zu entladen.
  •  Steuermodus (RS485): Muss aktiv sein, damit externe Befehle (z. B. von Home Assistant) angenommen werden.
  • Force-Mode :** Optionen wie „Laden“, „Stopp“, „Entladen“ für manuelle  Betriebsarten.

Ist der Marstek Speicher vom Homeassistant aus erreichbar, kann mit der Automation begonnen werden. Die Idee ist ganz einfach: Das Smartmeter liefert der Automation den Istzustand in welche Richtung die Energie fließt und wieviel davon. (also ob Leistung vom Netz bezogen wird oder in Netz eingespeist wird).  Mit dieser Information kann dann ein Stellwert für den Marstek berechnet werden, der zum Ziel hat, die eingespeiste Leistung zum Laden zu nutzen und bei Bezug aus dem Netz diesen mit Entladen zu kompensieren. Sprich: "den Nullpunkt halten".  Das geht nur im Bereich der vom Marstek bereitgestellten Arbeitsbereiche.

Ist beispielsweise gerade das Backrohr, Kochplatte und Spülmaschine ein, dann ziehen diese Verbraucher schnell mal 6kW aus dem Netz. Da kann der Marstek auch nur mit max. 2.5kW entgegenwirken. Das bedeutet 3.5kW müssen weiterhin vom EVU geliefert werden. Und die zweite Bedingung: Der Akku soll auch voll genug sein. D.h. die Automation überwacht auch den SOC des Akkus und beendet den Entladevorgang wenn die eingestellte SOC-Reserve erreicht ist.

Was die Automation macht

  • Einspeisung ins Netz (Export) → Es gibt Überschuss → Batterie soll laden (bis zu einem einstellbaren Limit und maximalen SOC).
  • Bezug aus dem Netz (Import) → Haus braucht Strom → Batterie soll entladen (bis zu einem Mindest-SOC, um Tiefentladung zu vermeiden und eine Reserve zu behalten).
  • Weder nennenswerter Export noch Import→ Lade- und Entladeleistung werden schrittweise zurückgefahren, damit der Speicher nicht „gegen das Netz“ arbeitet.
  • Damit keine Dauer-Schalterei entsteht, arbeitet die Logik mit Hysterese (Deadband) und Schrittweiten: Die Leistung wird nicht sprungartig auf einen Zielwert gesetzt, sondern in festen Schritten (z. B. 70 W beim Laden, 100 W beim Entladen) pro Ausführung angepasst. Zusätzlich wird eine kleine  Soll-Reserve (Deadband) abgezogen, sodass die Regelung nicht auf kleinsten Schwankungen reagiert.

Ablauf in Kurzform

1. Steuermodus RS485: Ist er aus, schaltet die Automation ihn wieder ein (damit die Befehle ankommen).
2. SOC-Obergrenze: Ist der Ladezustand ≥ Max.-SOC, wird die Ladeleistung auf 0 gesetzt.
3. Konflikt Laden/Entladen: Sind gleichzeitig Lade- und Entladeleistung > 0, wird je nach Netzsituation eine Richtung auf 0 gesetzt.
4. Überschuss:  Export > Schwellwert, SOC < Max.-SOC → Ladeleistung schrittweise erhöhen (mit Limit und Deadband).
5. Bezug: Import > Schwellwert, SOC > Min.-SOC → Entladeleistung schrittweise erhöhen (mit Max.-Entladeleistung).
6. Export hoch, Entladung an: Entladeleistung schrittweise reduzieren.
7. Bezug oder kein Überschuss  Ladeleistung schrittweise reduzieren.
8. Force-Mode: Je nach Netzsituation und aktueller Leistung wird „Entladen“, „Laden“ oder „Stopp“ gesetzt, um das Gerät in die passende Betriebsart zu bringen.
Alle Schwellwerte, Schrittweiten und Verzögerungszeiten sind im Blueprint über die GUI einstellbar.
Den Blueprint  habe ich auf meinem GitHub-account zur Verfügung gestellt:
 
 
Im Homeassistant sind drei Helfer anzulegen. Die genaue Liste und kurze Erklärungen stehen in der Helfer-Anleitung im Projekt (HELPER_ANLEITUNG.md).
 

Tipps für den Einsatz

1. Modbus-Register zuerst prüfen:  Nur mit der richtigen Modbus-Konfiguration (Adressen, Skalierung) liefern die Entitäten plausible Werte.
2. Zähler-Einheit im Blueprint: Wenn der Zähler in kW liefert, Kilowatt (kW) wählen – dann wird intern mit 1000 multipliziert. Bei Watt-Sensoren „Watt (W)“ wählen.
3. Helfer vor der Automation anlegen: Die drei input_number-Helfer müssen existieren und sinnvolle Min/Max-Werte haben, bevor man die Automation (oder den Blueprint) aktiviert.
4. Force-Mode optional: Wenn das Gerät keinen Force-Mode hat, trotzdem eine Select-Entity auswählen (z. B. eine Dummy-Select), oder den Blueprint ggf. so anpassen, dass der Force-Mode-Block weggelassen werden kann – je nach Blueprint-Version.
 
Wenn ihr einen Marstek- oder Venus-Speicher per Modbus und Home Assistant nutzt, könnt ihr die beschriebene Automation und den Blueprint als Basis nehmen und bei Bedarf an eure Zähler und Geräte anpassen. Die genaue Modbus-Registerliste bleibt dabei eure erste Quelle – ohne sie läuft die Anbindung nicht sauber.
Viel Erfolg beim Nachbauen und Optimieren eures Überschuss-Speichers!
 

Hinweis:
Die beschriebene Steuerung setzt eine funktionierende Modbus-Anbindung und eine sichere elektrische Installation voraus. Änderungen an der Speichersteuerung erfolgen auf eigene Verantwortung; bei Unsicherheit einen Fachbetrieb hinzuziehen.

ESP32 Video Pong – Retrogaming trifft moderne Mikrocontroller-Technik

Es ist schon eine Weile her, dass ich mir Zeit genommen habe, über eines meiner letzten Projekte zu berichten. Diesmal geht es um ein Thema, das zwei meiner großen Leidenschaften vereint: Die Faszination für Retro-Gaming aus meiner Jugend und die Möglichkeiten moderner Mikrocontroller-Technik.

Wer in den 1970er Jahren aufgewachsen ist, kennt es noch: Pong, eines der ersten kommerziell erfolgreichen Videospiele überhaupt. Zwei Paddles, ein Ball, ein Bildschirm – mehr brauchte es nicht für stundenlangen Spielspaß. Was damals mit dedizierter Analog-Schaltungstechnik realisiert wurde, lässt sich heute elegant mit einem einzigen Mikrocontroller umsetzen.

Die Herausforderung dabei: Ein echtes analoges PAL-Videosignal direkt aus einem ESP32 zu erzeugen. Kein HDMI, kein VGA – sondern gutes altes Composite-Video (FBAS), wie es ein guter alter Röhrenfernseher versteht.

Ursprünglich habe ich das Projekt für den FH-Day an der Fachhochschule Kärnten entwickelt. Die Idee war, Studierenden und Besuchern zu zeigen, was mit moderner Embedded-Hardware möglich ist – und gleichzeitig eine Brücke zur Technikgeschichte zu schlagen.

Das Vectorgameboard V1.0 – Hardware nach Maß

Für dieses Projekt habe ich nicht nur Software gebastelt, sondern auch eine dedizierte Platine entwickelt: Das Vectorgameboard V1.0. Diese Platine soll ein echtes "All-in-One"-Design sein (oder in künftigen Revisionen werden) und alle notwendigen Komponenten auf einem Board vereinen:

die Platine mit ESP32 als Rechenknecht

Hardware-Features im Überblick:
  • ESP32 als Herzstück
  • Zwei Potentiometer für die Paddle-Steuerung (analoges Spielgefühl!)
  • Zwei Taster für Modusauswahl und Spielstart
  • Video-Ausgang über RCA-Buchse (Composite/FBAS)
  • Audio-System mit integriertem Verstärker und kleinem Lautsprecher
  • Externer DAC für hochpräzise Vektordarstellung (X-Y-Modus)

Was das Board besonders macht: Es ist nicht nur für PAL/NTSC-Composite-Video ausgelegt, sondern auch für den X-Y-Modus. Das bedeutet, man kann es auch an ein Oszilloskop anschließen und damit klassische Vektor-Grafiken darstellen – ganz wie bei den alten Vektor-Spielautomaten der 1980er Jahre.

Die kompletten Schaltpläne und Eagle-Layouts sind im GitHub-Repository verfügbar. Open Hardware eben.

Schaltplan
https://github.com/ingmarsretro/ESP32_VideoPong
https://github.com/ingmarsretro/ESP32_vectorgame

Die Software: PAL-Signale erzeugen

Die Software-Seite des Projekts war mindestens genauso spannend wie die Hardware. Das Erzeugen eines PAL-Videosignals ist etwas zeitkritisch. Jede Bildzeile muss exakt getimed sein, sonst wird das Bild instabil oder gar nicht angezeigt. Hier habe ich auf die Arbeit von bitluni.net zurückgegriffen. Er hat hier ein tolles Projekt realisiert und eine eigene library erstellt. Die Grundlagen des PAL Videosignals und die Erzeugung mittels ESP32 hat er in seinem Blog ausführlich erklärt.

 

Videoausgabe auf PAL – Bildschirm

Technische Details:

  • Das Videosignal wird auf GPIO 25  ausgegeben (GPIO26 ist auch möglich)
  • Verwendung der bitluni ESP32Lib (Version 0.3.1)
  • Zwei Spielmodi: Singleplayer (gegen "Computer") und lokaler Multiplayer (Spieler gegen Spieler)
  • Sound-Feedback bei Ballkontakt, Punkten und Spielende über GPIO 27
  • Integration von Bitmaps für Logos und Spielergrafiken
Arduino IDE und Kompatibilität der Libraries

Ein wichtiger Hinweis für alle, die das Projekt nachbauen möchten: Die Video-Generierung funktioniert nur mit ganz bestimmten Library-Versionen! Ich habe viel Zeit damit verbracht, das herauszufinden und eine stabile Ausgabe zu erreichen. Die 3.x.x Versionen der ESP32-Bibliotheken sind aktuell nicht kompatibel.

Folgende Versionen müssen zwingend verwendet werden:

KomponenteVersion
ESP32 by Espressif Systems2.0.0
Arduino ESP32 Boards2.0.11
bitluni ESP32Lib0.3.1

Die Compiler-Warnungen, die dabei auftreten, können ignoriert werden. 

Der Spielspaß: Analoges Feeling im digitalen Zeitalter

Wenn man das fertige Board in Betrieb nimmt und den ersten Ball über den Bildschirm fliegen sieht, ist das ein besonderer Moment. Die Potentiometer sorgen für ein echtes analoges Spielgefühl – ganz anders als mit digitalen Gamepads. Und der kleine Lautsprecher auf dem Board gibt bei jedem Ballkontakt einen authentischen "Piep" von sich.

Im Startbildschirm kann man zwischen Singleplayer (gegen den Computer) und lokalem Multiplayer wechseln. Gerade der Zwei-Spieler-Modus macht richtig Spaß – man sitzt nebeneinander am Board, jeder an seinem Potentiometer, genau wie damals auf den alten Pong-Konsolen.

Pin-Belegung

Für alle, die das Projekt nachbauen möchten, hier die komplette Pin-Belegung:

KomponenteGPIOBeschreibung
Video Out25Composite Signal
Buzzer/Audio27Soundausgabe
Poti 135Spieler 1 (Links)
Poti 234Spieler 2 (Rechts)
Button 132Modus wechseln
Button 233Start / Aktion
Von PAL bis Vektor: Die Dual-Mode-Fähigkeit
 
PONG als X-Y Vectorausgabe am Oszilloskop

Auswahlmenue

Was das Vectorgameboard wirklich einzigartig macht, ist seine Dual-Mode-Fähigkeit. Während die hier beschriebene Pong-Software für PAL-Composite-Video entwickelt wurde, kann das gleiche Board auch für Vektor-Software genutzt werden.

Der interne DAC und auch ein  externer DAC (MCP4922 Dual 12 bit SPI DAC) ermöglicht es, präzise X-Y-Signale auszugeben. Damit kann man das Board an ein Oszilloskop anschließen und klassische Vektor-Grafiken darstellen – wie bei den legendären Spielautomaten “Asteroids” etc… Das ist ein Projekt, das ich definitiv noch weiterverfolgen werde.

Open Source und Open Hardware

Wie bei vielen meiner Projekte liegt mir auch hier die Reproduzierbarkeit am Herzen. Die Quellcodes der bisherigen Versionen sind auf GitHub verfügbar:

https://github.com/ingmarsretro/ESP32_VideoPong

Jeder ist eingeladen, das Projekt nachzubauen, zu modifizieren oder weiterzuentwickeln. Besonders freuen würde ich mich über Feedback von anderen Retro-Enthusiasten oder über Weiterentwicklungen der Software.

Ein besonderer Dank geht an bitluni für die hervorragende ESP32Lib, ohne die dieses Projekt in dieser Form nicht möglich gewesen wäre. Die Library ist ein Paradebeispiel dafür, wie gut durchdachte Open-Source-Software komplexe Projekte erst ermöglicht.

Brücke zwischen den Welten

Das ESP32 Video Pong Projekt zeigt eindrucksvoll, wie man mit modernen Mikrocontrollern die Technik vergangener Jahrzehnte nachbilden kann. Es ist mehr als nur ein nostalgisches Spielzeug – es ist eine funktionierende Demonstration dessen, wie Videosignale aufgebaut sind und wie zeitkritische Embedded-Programmierung funktioniert.

Für mich persönlich war es auch eine Reise in meine eigene Vergangenheit. Als Kind habe ich stundenlang auf verschiedenen Konsolen gespielt, ohne zu verstehen, was technisch dahintersteckt. Jetzt, Jahrzehnte später, kann ich nicht nur die Technik nachvollziehen, sondern sie auch selbst nachbauen und verbessern.

Vielleicht inspiriert dieses Projekt ja den einen oder anderen, selbst aktiv zu werden. Die Kombination aus Retro-Flair und moderner Mikrocontroller-Technik hat definitiv ihren Reiz.

Viel Spaß beim Nachbauen – und beim Spielen auf dem guten alten Röhrenfernseher oder Oszilloskop!