Zentrale Verwaltung mehrerer openWB an mehreren EVU-Zählern / "Multi-Site"?

[346L3]

Ich habe einen Vorschlag bzw. Frage, ob ggf. bereits möglich:

Ausgangspunkt:
2 seperate PV-Anlagen mit Speicher (Solaredge + Sonnenbatterie 10 performance) auf 2 Gebäuden.
Es ist jeweils eine openWB Pro+ je Anlage/Gebäude installiert. Software 2.2.0 (2026-04-23 07:44:31 +0200 [d6f0f2d])
Es gibt ein gemeinsames Netzwerk.

Ich hatte nun vor, die openWB gemeinsam zu verwalten, da die berechtigten Fahrzeuge Gebäudeübergreifend an beliebiger WB laden dürfen, ich ggf. Transponderberechtigungen, Ladeprofile und Abfrage des Fahrzeug-SOC per API nur 1x machen möchte (BMW mit begrenzten API-Calls/Tag).
Zudem würde das mir monitoring + konfiguration vereinfachen.

An sich ließ sich alles problemlos einrichten, eine openWB als primary, die andere als secondary, beide Sonnenbatterien in der Primary eingebunden und bei Lastmanagement die reale Struktur nachgebaut (2x EVU-Zähler, darunter jeweils Speicher, WR, Verbrauchszähler m. Ladepunkt) - nun lässt sich aber für den Hausverbrauch nur 1 Zähler hinterlegen und openWB summiert SoC Speicher, Überschuss & PV-Leistung zumindest auf dem Dashboard von beiden Häusern.
Zudem sieht es so aus, als ob der Ladestart sich jeweils nach den Summen richtet.

Hier nun die Frage:
Ist das, was ich vorhabe, generell möglich und ich mache ggf. etwas falsch? Oder trügt ggf. nur das Dashboard, die Logik funktioniert aber?
Oder gibt es die gewünschte Funktionalität nicht, openWB zentral verwaltet hinter separaten Netzübergabepunkten zu nutzen?
Da ich 2 separate EVU-Zähler-Strukturen einrichten konnte, dachte ich, dass sich ggf. nicht nur Lastmanagement, sondern auch die Logik f. PV-Ladung, Ladung nach Speicher-SoC usw. hiernach richtet - ist das eine Fehlannahme?

Wäre hier für kurzes Input oder Diskussion dankbar!

VG

[Gerolein]

Wenn du mit beiden PV-Anlagen (ich nehme mal an, die sind jeweils hinter "ihrem" EVU-Zähler) den überschuss ins Auto laden möchtest, brauchst du zwei openWB-Instanzen: für jeden EVU-Zähler eine eigene. Denn du hast ja auch zwei unterschiedliche Überschüsse, je nach EVU-Punkt.

Die openWB nimmt den überschuss von dort. So funktioniert überschussladen auch ohne PV-Ablesemodul.

Ich kann mir auch nicht vorstellen, dass da irgendwas in diese Richtung umgebaut wird. Es sind halt auch abrechnungatechnisch zwei überschüsse. Und auch physisch bekommst du Strom von PV-Anlage 1 nicht hinter EVU 2. Außer du gehst über den Zähler, womit der Überschuss ja zum Netzbezug wird.

[Claus-BEV]

So ein sehr ähnliches Setup habe ich auch geplant. Zwei Einheiten an zwei verschiedenen Orten, per VPN verbunden (aus Sicht der openWB ein Netzwerk unterteilt in Segmente). Jeweils mehrere openWBs, beide Standorte verfügen über Solaranlage und Speicher. Ich würde das auch gerne so realisieren, dass ich nur einen Konfigurationspunkt mit einer Primary habe und alle anderen als Secondary laufen lasse. Die Fahrzeuge wechseln teilweise den Standort. Lastmanagement ist hier auch notwendig. Ist das so prinzipiell überhaupt möglich?

@Gerolein Was ist bei dir eine openWB-Instanz? Hardware-Primary mit verbundenen Secondaries oder ist das in der Software abbildbar?

[346L3]

Vermutlich PV Regelung/Lastmanagement je Zähler = 1 Instanz.
So wie es aussieht momentan nicht möglich, habe beide openWB nun (leider) als Standalone Master und klicke mich bei allen Änderungen durch 2 Tabs.

Wäre hier sehr interessiert, entweder zentrale Verwaltung mehrerer Instanzen oder 1 Master und Slaves nicht unbedingt hinter selbem EVU / Zähler / HAK

[Gerolein]

Eine Instanz in meinem Sinne ist eine Primary mit ihrem EVU-Zähler. Daraus ergibt sich eine Überschussmenge, die auf diverse Secondaries oder smarthome-Geräte / Verbraucher verteilt wird. Alle diese Geräte hängen hinter dem EVU-Punkt.

Aus dem Anfangspost ging nicht so recht hervor, ob da die auch noch die Überschüsse von zwei PV-Anlagen gemeinsam in Autos hinter dem jeweilig anderen Zähler geladen werden sollen. Das ist aber nun klarer: Eine Primary steuert mehrere Regelkreise, teilt sich aber die Stammdaten für die Fahrzeuge. Das geht aktuell nicht.

Der 10s-Takt der openWB ergibt sich auch aus den Latenzen bei der Abfrage der diversen Teilnehmer im Regelkreis. Die sind je nach genutzten Komponenten so knapp bemessen, dass man die auf 20s oder noch länger ausweiten können musste. Von daher ist es fraglich, ob man in einer Regelschleife zwei (oder mehr) Regelkreise abarbeiten können wollen muss.

Eine Stammdatenreplikation der Fahrzeugdaten mit ihren Profilen hielte ich da für den erfolgsversprechenderen Weg.

[kevinwieland]

Gerade über Standorte hinweg sind mehrere Primarys unbedingt erforderlich.
Auch im WEG Kontext haben wir dafür einen übergeordneten Lastmanager. Der kümmert sich um den ganzen Blick.
Jeder Punkt für sich hat dann ihre individuelle Konfiguration.

Der Punkt mit Fahrzeugprofile exportieren/importen wäre da wahrlich sinniger.
Vielleicht mag sich jemand von euch dadran machen?
Es würde ja ein JSON Export/Import reichen der die Felder vorgelegt mit allen werten.

[Gerolein]

Ganz so simpel ist es wahrscheinlich nicht. Zumindest nicht, wenn man in der Stammdaten-empfangenden Primary schon mal was konfiguriert hat. Dann sind ja die IDs auf einem ganz anderen Stand als auf der Stammdaten-sendenden. Wenn die empfangende neu aufgesetzt ist, könnte man die Fahrzeug-etc IDs der sendenden übernehmen. Dann sollte man aber auch darauf achten, dass man auf der empfangenden nicht mal eben ein neues Fahrzeug oder Profil anlegt, dann geht ja wieder alles durcheinander.

Also: Den Fahrzeug-Bereich besser als nur per Schnittstelle beschreibbar markieren. Dann kann man aber auch gleich die IP-Adresse der Stammdaten-Primary hinkonfigurieren und statt der Export-Import-Schleife einen Abgleich-Knopf bauen. Und wenn der dann remote von gedrückt werden kann, sind wir ja eigentlich schon am Ziel... ;)