Victron Speicher Modul frei konfigurierbar (IP GX)

[liZErd]

Liebe openWB-Gemeinde,

da meine Anfrage im Victron Hauptthread untergegangen ist, hier nochmal meine Situation und Bitte:

Ich werde demnächst meine 11kW SolarEdge PV + 16kWh Speicher mit drei Multiplus II auf eine Backup-Lösung inkl. PV-Erweiterung umrüsten.
Zudem kommt im Laufe des Jahres eine IDM Wärmepumpe, die den Speicher nicht entladen, aber bei vollem Speicher mit PV Überschuss betrieben werden soll. Natürlich alles über die vorhandene openWB standard+ geregelt.

Zu diesem Zweck zweige ich die Wärmepumpe (und einen "Netz-Ladepunkt") zwischen EVU-Messung und (interner) Multiplus-Überschussmessung ab.
Ist der Speicher voll, wird eingespeist, der SDM 630 EVU Zähler erfasst den Überschuss, und openWB steuert die Wärmepumpe entsprechend an. So weit, so gut.
Darstellung und Erfassung erfolgt dann natürlich gesammelt über openWB, Victron VRM bekommt dann natürlich nicht alles mit, ist mir aber bewusst und egal.

Folgendes Problem: Für dieses Setup muss ich als EVU-Modul den SDM 630, als Speicher-Modul Victron konfigurieren. Jedoch ist offenbar das Victron Speicher Modul mit dem Victron EVU-Modul gekoppelt und übernimmt dessen Einstellungen ("Konfiguration im Bezug Victron Modul."). Heißt kein Victron EVU-Modul, kein Victron Speicher Modul.
Die Speicherleistung ist jedoch zur Berechnung des Gesamt-Überschusses und somit auch für eine funktionierende Auto-Laderegelung essentiell wichtig.

Es wäre wirklich Spitzenklasse, wenn jemand das Victron Speicher-Modul frei konfigurierbar machen könnte, sodass man dort wie bei den anderen Victron Modulen die IP Adresse des GX Geräts eintragen kann!

Liebe Grüße,
Bastian

[aiole]

Schon v2.0 probiert?
Da können dem Victron-Gerät diverse Komponenten zugeordnet werden (z.B. EVU, PV, Speicher). Der EVU-Zähler ist aber auch als ein eigenständiges Gerät konfigurierbar. Müsste von der Logik her also passen.

[liZErd]

Hallo aiole!

Danke für deine schnelle Antwort. oWB 2.0 hört sich definitiv gut an und muss in dem modularen Ansatz von openWB konsequenterweise der nächste Schritt sein.
Sobald alles komplett und stabil läuft werde ich auch definitiv auf openWB 2.0 wechseln - momentan fürchte ich noch, dass es mir mein gewachsenes und verhältnismäßig komplexes Setup zerschießt bzw. viele Inkompatibilitäten auftreten. Habe z.B. Smart Home 2.0 mit Heizstab und ein paar Steckdosen am Laufen, SDM630 EVU mit konfiguriertem Modbus TCP Wandler, externer Zähler für Wärmepumpe usw.

Ich hab vorhin schon mal einen Blick auf GitHub geworfen ob ich im 1.9er (?) Victron Speicher Modul die aus dem Objekt/Klasse übernommene IP schnell in eine Eingabemaske überführen kann wie bei allen anderen Victron Modulen außer Speicher; dazu bin ich allerdings aktuell zu stark aus der Implementierung und Python raus und hätte gehofft, dass jemand mit deutlich geringerem Aufwand diese kleine Anpassung für mich vornehmen kann.
Würde auch im 1.9er openWB zu noch mehr Modularität führen und ist hoffentlich nicht mit viel Aufwand verbunden.

Wäre auf jeden Fall toll und würde mich riesig freuen wenn sich jemand dessen annehmen kann!
Nicht dass meine Victron und Wärmepumpen Erweiterung am Speicher Modul in openWB scheitert

Viele Grüße

[aiole]

Ich verstehe Dich. Es ist nur so, dass wenn man ständig alte, nicht ausreichend strukturierte SW erweitert, immer mehr Fehleranfäligkeit entsteht. Das frisst dann auch den Support auf. Außerdem bremst es die Weiterentwicklung.

Okaegi ist dankenswerter Weise schon am Sichten, um auch eine SH2-Implementierung in oWB 2.x zu realisieren.

[liZErd]

Da bin ich absolut bei dir, größere neue Projekte und Funktionen natürlich gleich in openWB 2.0 umzusetzen!
Allerdings gehört zur Wahrheit ja auch, dass es für die 2.0 "noch keinen offiziellen Support" gibt und sicherlich ein Großteil der openWBs noch auf der stabilen und supporteten 1.9 läuft.

Entsprechend finden notwendigerweise in der 1.9 auch ständig kleinere Modulanpassungen statt, bis die 2.0 zur offiziellen Version wird (an dieser Stelle Shoutouts an okaegi, der openWB mit SH 2.0 gerade noch die Krone aufsetzt wie ich finde).
Bei meiner Anfrage handelt es sich auch um eine solche kleine Anpassung, nicht um die Implementierung einer neuen Funktion.

Es geht nur darum, eine Eingabezeile für die IP des GX Geräts zu schaffen, anstatt die IP Adresse hardzucoden bzw. vom EVU Modul zu übernehmen.
Da die Module wie von dir beschrieben in oWB 2.0 ohnehin anders implementiert sind, müsste die Eingabemöglichkeit nicht mal übertragen werden.

Soweit ich es im Forum mitbekomme, gibt es doch einige Nutzer, die wie ich bei ihren doch erheblichen Investitionen voll auf openWB setzen und sich dann natürlich auch auf die Pflege der vorhandenen Version verlassen. Im worst case hat man Summen jenseits der 30.000€ in die Hand genommen, und am Ende scheitert es am Batteriemodul - das ja vorhanden, aber eben nicht modular konfigurierbar ist.

Wenn sich jemand erbarmt - angesichts der geschilderten Summen bin ich jederzeit zu einer Spende bereit, um den Aufwand für die Anpassung zu kompensieren!

[aiole]

Da bin ich absolut bei dir, größere neue Projekte und Funktionen natürlich gleich in openWB 2.0 umzusetzen!
Allerdings gehört zur Wahrheit ja auch, dass es für die 2.0 "noch keinen offiziellen Support" gibt und sicherlich ein Großteil der openWBs noch auf der stabilen und supporteten 1.9 läuft.

2.0-Tester:innen bekommen hier im Forum inoffiziellen Support direkt von den Entwicklern. z.B. viewtopic.php?p=78900#p78900

Entsprechend finden notwendigerweise in der 1.9 auch ständig kleinere Modulanpassungen statt, bis die 2.0 zur offiziellen Version wird (an dieser Stelle Shoutouts an okaegi, der openWB mit SH 2.0 gerade noch die Krone aufsetzt wie ich finde).
Bei meiner Anfrage handelt es sich auch um eine solche kleine Anpassung, nicht um die Implementierung einer neuen Funktion.

Ich kenne mich da zu wenig aus. Für mich ist das etwas Größeres, aber ggf. sieht das die Entwicklung anders.

Es geht nur darum, eine Eingabezeile für die IP des GX Geräts zu schaffen, anstatt die IP Adresse hardzucoden bzw. vom EVU Modul zu übernehmen.

Aus Anwendersicht ist es immer einfacher als aus Sicht der Entwicklung. Gerade das Einbauen von Variablen statt Fixwerten hat Fehlerpotential.

Da die Module wie von dir beschrieben in oWB 2.0 ohnehin anders implementiert sind, müsste die Eingabemöglichkeit nicht mal übertragen werden.

Umso schlimmer - Doppelpflege, denn 1.9 wird noch eine gewisse Zeit neben 2.x nebenher laufen.

Soweit ich es im Forum mitbekomme, gibt es doch einige Nutzer, die wie ich bei ihren doch erheblichen Investitionen voll auf openWB setzen und sich dann natürlich auch auf die Pflege der vorhandenen Version verlassen. Im worst case hat man Summen jenseits der 30.000€ in die Hand genommen, und am Ende scheitert es am Batteriemodul - das ja vorhanden, aber eben nicht modular konfigurierbar ist.

Ich gehe fest davon aus, dass v2.x nahezu alles abdeckt, was auch 1.9 kann (Du hast noch nicht probiert und die Struktur scheint bereits gegeben.). Irgendwann muss man Zöpfe abschneiden und auf die nächste Stufe gehen, sonst frisst einen die suboptimale Struktur der 1.9 auf.

Wenn sich jemand erbarmt - angesichts der geschilderten Summen bin ich jederzeit zu einer Spende bereit, um den Aufwand für die Anpassung zu kompensieren!

Vielleicht hast Du Glück, dass es jemand programmiert, aber der PR muss auch vom core-Team geprüft werden, um den master-branch stabil zu halten. Kann also auch sein, dass so ein PR liegen bleibt.

Um die Investitionen muss man keine Sorge haben, denn openWB ist auf Nachhaltigkeit aus. Genau deshalb wurde v2.x ins Leben gerufen.