VE.direct Aggregator

Aus "purer Not" heraus :wink: habe ich dieses Projektchen gestartet, direkt zur vollständigen deutschen Beschreibung

VE.Direct Aggregator — Kurzübersicht

Firmware · Arduino Mega 2560 / Teensy 4.1 · v1.6 · 2026, Kurzform von claude.ai


Überblick

Liest mehrere Victron VE.Direct-Geräte gleichzeitig und führt die Datenströme zu einem seriellen Ausgang zusammen. Unterstützt alle VE.Direct-Textgeräte: MPPT, BMV, SmartShunt, Phoenix-Wechselrichter, Blue Smart Charger, Orion.

Ausgang: normaler VE.Direct-Textstrom. Geräte werden per PID + SER# identifiziert. Nicht direkt kompatibel mit Cerbo GX / Venus GX.

Fertige Blöcke werden sofort in eine zirkuläre TX-Queue (12 Slots) eingereiht — kein Block geht durch Sendedruck verloren, auch bei gleichzeitigen Blöcken oder Upstream-Bursts.


Firmware-Varianten

Datei Hardware Eingänge Ausgang Funktion
vedirect_readtext.ino Mega 2560 3 TX0 / USB Text-Aggregation
vedirect_readtext_sendhex.ino Mega 2560 3 TX0 / USB Text + SET + HEX
vedirect_readtext_teensy41.ino Teensy 4.1 7 TX8 / USB Text-Aggregation
vedirect_readtext_sendhex_teensy41.ino Teensy 4.1 7 TX8 / USB Text + SET + HEX

Ausgabeformat

Blockende: Checksum\t-Zeile — kein doppeltes \n. Nächster Block folgt sofort. ALIVE-Signal (ALIVE\r\n) nach 10s Inaktivität wenn Queue leer.


Topologien

Direkt (Mega):    3 Geräte  → 1 Mega   → Ausgang
Direkt (Teensy):  7 Geräte  → 1 Teensy → Ausgang
Stern:            9 Geräte  → 3 Mega   → 1 Mega  → Ausgang
Kaskade:         12 Geräte  → 4 Mega             → Ausgang (115200 Baud)
Gemischt:        13 Geräte  → 1 Teensy + 2 Mega  → 1 Mega  → Ausgang (115200 Baud)
Teensy-Stern:    21 Geräte  → 3 Teensy → 1 Teensy → Ausgang (115200 Baud)

Leistungssteuerung (readtext_sendhex)

SET <pid> <watt>\n      einzelnen MPPT-Regler begrenzen
SET ALL <watt>\n        alle MPPT-Regler gleichzeitig
HEX <pid> <string>\n   beliebigen HEX-Befehl senden

Antworten: OK <pid> <watt>W <ampere>A\n / ERR <pid> timeout\n / HEX_REPLY <pid> :<antwort>\n

Register 0x2015 (Charge Current Limit, 0.1A, volatil). Vbat wird aus dem Text-Stream gelernt, Fallback: VBAT_FALLBACK (24V). Nur betroffener Port pausiert (~50–100 ms).


Python-Tools

Datei Zweck
ve_aggregator.py Client-Modul — Blöcke lesen, SET/HEX senden
mppt_read_example.py Daten anzeigen mit Intervall pro Gerät
block_monitor.py Block-Timing, Gap-Messung
sendhex_test.py SET/HEX Befehle testen
powerset_example.py Leistungsregelung mit Spannungsrampe
vedirect_simulator.py Upstream-Aggregator simulieren
from ve_aggregator import VEDirect

with VEDirect('/dev/ttyUSB0') as vd:
    data = vd.get_all()        # {'PID:SER#': {Felder...}}
    c    = vd.combined()       # Vbat gemittelt, PPV/I summiert
    alive = vd.is_alive()      # True wenn MCU innerhalb 15s gemeldet

    vd.set_watts('ALL', 1500)  # Leistung begrenzen (sendhex)
    for r in vd.get_replies():
        print(r)

Die Integration in GitHub - E-t0m/zeroinput: Set power input to zero with gti inverter and charge controller. · GitHub ist obligatorisch. :wink:

1 „Gefällt mir“

Interessantes Projekt dazu hätte ich noch ein paar Fragen / Anmerkungen:

Galvanische Trennung findet die statt?
Wie geht man damit um das manche Geräte auf dem VE-Bus 5V und andere 3.3V haben?
Und 100mA scheint deutlich mehr zu sein als Victron als zulässig angibt.

Generell versuche ich zu verstehen für welchen Anwendungszwecke das Projekt gedacht ist.

Für ESS-System wo die Leistung der Laderegler gesteuert werden muss, braucht es den HEX-Modus.

Zum Auslesen der Daten gibt auch die 4xVE-Direct zu USB Hubs und/oder esp32 bzw. BLE Beacons.

MEGA TTL -> RS485 -> galvanische Trennung -> USB -> RPi, durch den RS485 Konverter, ansonsten wird angenommen, dass alle Regler auf dem gleichen Potential arbeiten. Wichtiger Punkt, Danke für den Hinweis.

Man geht strickt davon aus, das alle MPPT Regler auf 5V arbeiten, an andere VE.direct Geräte wurde nicht gedacht. :wink:

Victron gibt 100 mA an, man könnte natürlich einen DC/DC nehmen, oder eben zwei Regler parallel anzapfen.

Die Leistungssteuerung ist tatsächlich schon in Arbeit, aber noch nicht im Code.
(mehr brauche ich einfach nicht)

Wofür? Um auf einer einzelnen seriellen Leitung (über RS485) mehrere Regler zu lesen. (bisher)

Hast du noch andere Ideen, was fehlt?

PS: Die Victron-Welt kann mit dem aggregierten Stream natürlich nichts anfangen!

1 „Gefällt mir“

das hier 10mA stehen hast du gesehen?

Wenn es nur darum geht ein paar Monitoring Daten ins Smart Home etc. zu bringen ist BLE Beacons auslesen deutlich bequemer.

Du verwendest das aber vermutlich um deine soyosource nulleinspeisung zu regeln und ggfs wenn die Batterie langsam voll wird anhand den MPPT Leistungsdaten mehr als null einzuspeisen?

Steuerung über den Hex Modus um z.B. Temperatur gesteuert den ladestrom zu begrenze wäre vermutlich sehr praktisch.

Ich mache so etwas über ESP32 und ESP-Home um den Speicher, der draußen steht, im Hochsommer ehh immer voll wird, prognosegesteuert langsamer laden zu lassen bzw. bei zu hohen Temperaturen (HEX Modus gibt die interne Temperatur vom MPPT Laderegler aus) auch zu drosseln.

Ich habe da aber auch noch nen ADUM1201 dazwischen.

Nein, ich hatte falsche 100 mA im Kopf! Gut zu wissen, ich werde alle MEGA(s) immer an einen stepdown hängen.

Ich verwende keine Funkstrecken in meinen Regelungen: kein BLE

Der Grund, wozu ich einen Rückkanal haben wollen würde, ist ziemlich krude:
ich will an der Anlage nichts grundlegend verändern, aber trotzdem mehr PV-Leistung.
Um die volle Batterie zu "schonen" reicht mir die Regelkurve der Regler.
Aber der Strom in die Batterie (und die Kabel dahin) machen mir Sorgen: Schönwetterprobleme

Übrigens werden es mehr Regler, weil ich mehr Tracker verwenden will.
(Parallele Strings mit unterschiedlicher Ausrichtung trennen.)
Da das VE.direct Protokoll reichlich Luft in der Leitung hat, kam mir der Gedanke zu aggregieren, da ich die Daten ohnehin selbst parse.

1 „Gefällt mir“

In der aktuellen Version gibt es jetzt auch einen Rückkanal zu den Reglern.
Ausserdem noch eine Version für den teensy 4.1, der bietet 7+1 serielle Ports.

Freue mich auf euer feedback!

Danke schon mal fürs teilen, das klingt richtig interessant.

Ich habe meine neue Hardware (mppt) noch nicht, wird auch noch dauern. Aber ich könnte mir vorstellen, deine projekt zu nutzen und einen dbus Treiber zu schreiben, dann könnte man den auch in venusos nutzen

Freut mich, wenn es auch jemand anderes gebrauchen kann!

Aktueller Stand:
die readtext variante ist durchgetestet und absolut stabil. (mangels teensy nur mit mega getestet)
sendtext ist noch nicht ganz durchgetestet

Für dich interessant: ein de-aggregator für venus os ist auch schon fast fertig: auf basis virtueller ports.
Denkst du, dbus wäre besser?

Wenn du das auf virtuelle ports aufteilst, ist das wahrscheinlich der bessere Weg, denn dann ist man unabhängiger von Änderungen im Venus os, fall sich da mal was ändert, denn der virtuelle ports wird sich ja annähernd so verhalten, wie ein physikalischer port.

Daher finde ich den Weg wesentlich besser:)

Ich hatte erst gedacht, man könnte mqtt als bridge nehmen, denn da gibt es schon was fertiges, fand den Umweg aber unnötig, weil es dann ja auch 2 mal im mqtt erscheint. Daher hatte ich an eine direkte multiplexer bridge auf dbus gedacht, aber wie geschrieben, deine Idee ist viel besser

So, mein mega ist jetzt auch da, die mppt’s sind unterwegs..

Dummerweise habe ich einen dc dc wandler auf 5v gekauft, braucht aber lt. Doku 7v. Aber ich fange erst mal mit usb spannung vom raspi an. Für die ersten Schritte sollte das reichen.

Nochmal zur verkabelung, du schreibst oben was von rs485, da reichen dann doch rx auf tx und tx auf rx, oder nicht?

DeIn de-aggregator, baust du den in python oder ist das in der firmware und der mega verhält sich dann wie ein usb hub?

Gruß

Dirk