AC/DC Speicherlösung mit Victron MPPT, Pylontech, Hoymiles, Huawei und openDTU-OnBattery

[maltes]

@arch86

Ich betreibe das mit dem US5000 und dem HM 1500 so.

Ladehub zwischen 15 und 90%.

Gelegentlich lade ich mal auf 100% damit Balancing laufen kann. Mache ich dann manuell über die Node Red Kontrolle

[arch86]

Laut Victron ist 52.4V geeignet. "For this reason we opted to override the BMS and cap the voltage at 52.4V. This sacrifices almost none of the capacity and greatly improves the stability of the system."

Ich finde auf der schnelle keinen Voltageschwellwert für den Pylontech, ab wann der balancer ausreichend für die 15S genug Zeit und Voltage hat den Ausgleich zu machen. @maltes wie häufig fährst Du den auf 100%? Wie viel Volt setzt Du da an? 52.4? (dann mach ich dass manuell über den webinterface von OpenDTU-oB).

@arch86

Ich habe als "Charge voltage limit" 52V entsprechend der Empfehlung von VICTRON für den Pylontech. Wenn man auf 52V lädt, dann wird der Akku auch zu 100% voll und die Belastung für den Akku ist kleiner als bei höherer Spannung.

[maltes]

@arch86

Vielleicht 52V?

Ist nicht akademisch. Die Spannung steigt bei Lifepo am Ende so schnell das das glaube ich egal ist.

Der Punkt ist das man in einem Bereich ist wo das der Fall ist damit der balancer diese Unterschiede sieht und sein Ding machen kann

Müsste mir mal diese Einzelspannungsmessung bauen

[maltes]

@arch86

Vielleicht 52V?

Ist nicht akademisch. Die Spannung steigt bei Lifepo am Ende so schnell das das glaube ich egal ist.

Der Punkt ist das man in einem Bereich ist wo das der Fall ist damit der balancer diese Unterschiede sieht und sein Ding machen kann

Müsste mir mal diese Einzelspannungsmessung bauen

[arch86]

@maltes Ja, mir geht es nur drum dass der balancer arbeiten kann. Da braucht man natürlich ein bißchen Puffer... wenn der voltage spread zwischen die 15 Zellen größer ist, ist die Gesamtspannung vielleicht X aber die einzelne Zellen brauchen relative lange vor sie gebalanced sind...
Kann man in OpenDTU die einzelne Zellspannungen sehen von den Pylontech, oder irgendwie anders? (meine kommt in Februar... :-))

[tobi0171]

@arch86 zum auslesen für die Pylontech gibts ja die "Batterie View" Software und einen Kabelsatz, notfalls gibts aber auch bei GiitHub ein Propjekt um dort über den Consolen-Port dran zu kommen... GitHub - irekzielinski/Pylontech-Battery-Monitoring: Adding WiFi monitoring to US2000B and US2000C batteries. (vielleicht meinte @maltes das sogar oben). Irgendwo gab es auch mal eine Tasmota Version, aber die konnte m.W nur Batteriespannung, Ladeleistung, Ladezustand in % ausgeben, nicht aber die Einzelspannungen der einzelnen Zellen anzeigen. Optisch etwas einfacher/schöner, dafür aber weniger ggf wichtige Daten)

Differenzsspannung zwischen den Zellen gibt leider auch die openDTUonBBattery nicht aus (zumindest bei mir nicht... ist aber noch nicht fertig umgebaut)

[cacu15]

Genau, ich lese auch die Zellzustände über Console aus. Ich nutze aber nur die HW wie unter dem Link beschrieben, dazu dann einen TCP Stream Server in ESPHome. Auf den greife ich dann aus NodeRed zu, wo ich einen Flow habe, der die Kommunikation umsetzt und die Daten nach InfluxDB schreibt. In Node Red ist man viel flexibler, was man aus dem Akku ausliest und wie man das auswertet und Aktionen auslöst.

Bei mir haben 52V für das Balancieren gut funktioniert: nachdem ich den Akku 1-2 mal nach dem eigentlichen Laden für 30min bei 52V gehalten habe war der Abstand der Zellspannungen minimal und das BMS hat dann auch wieder einen SoC von 100% erreicht, vorher nur 97%.

[alex_s]

@cacu15 welche Daten bekommst du mit dieser Methode aus dem Akku, die dir Open DTU on battery nicht als mqtt value bereitstellt?

[arch86]

@tobi0171 OK, alles klar.

Was meinst Du mit "zumindest bei mir nicht... ist aber noch nicht fertig umgebaut", mit umgebaut? Wird dran gearbeitet? Oder gibt Pylontech solche info nur über den console port raus?

Das Github Projekt ist cool. Aber verflixt, dass ist wieder eine Platine...
Aber ich denke ich werde es machen... hat jemand es hier schon gemacht?
BTW: der link ist für den 5000er nicht geeignet, aber dieser fork schon.

[tobi0171]

@arch86 mit "umgebaut" mein ich, ich hab noch keinen "Echtzeitbetrieb mit allen Komponenten" ...die beiden US2000C sind bislang nur angeschlossen, in ein Rack gebaut, Verkabelung und Sicherungen eingebaut, verbunden, initial geladen und balancieren lassen und bischen Peripherie drum rum geschraubt, aber noch nicht weiter angeschlossen ... viel weiter bin ich noch nicht gekommen (aktuell wenig Zeit). Habe, dabei aber kurz diie beiden Versionen (GitHub und Tasmota) getestet, da ich wissen wollte, was der Kerl so treibt. Eine Erkentniss daraus(...bei mir 2xUS2000C als 4,8kWh) fällt z.B. täglich der Ladezustand um ca.1 % im Stand-By ohne einen Verbraucher, ob`s irgendwie mit der Console und der kleinen Platine zusammenhäng weiß ich noch nicht.... mein DIY 24V 205Ah 8S mit Daly ist da deutlich sparsamer unterwegs.

Die Tasmota Version hatte ich hier gefunden https://forum.creationx.de/forum/index.php?thread/3526-pylontech-us2000-mit-tasmota-auslesen/ .

Da ich von dieser Art von Programmierung usw leider keine Ahnung habe, muss ich mich an fertigen und veröffentlichten Lösungen anderer schlauer Köpfe bedienen und nutze daher gerne solche. Wie gesagt... es fehlen dort halt ein paar Werte, daher ist die GitHub-Version was die Zellenüberwachung angeht dann doch besser, Mir ging`s hierbei (initialladen und balancen) vorerst, um die Spannung, Ladestrom und den Ladezustand im Auge zu behalten.... Zellendrift/Differenz wäre noch schön gewesen, ist aber scheinbar nicht berücksichtigt.

Ich möchte aber jetzt ungern MalteS Beitrag weiter mit Fremd-Links zumüllen ...wollte es aber der Vollständigkeit halber zu oben noch mit erwähnt / verlinkt haben...falls es doch jmd suchen/nutzen wollte.

Vielleicht findet es ja irgendwann noch einen Weg in die OpenDTUonBattery "Zellendifferenz/Zellendrift", falls das jmd aufgreift? ... dann könnte man sich das ebenfalls noch einsparen.

[lars72]

BTW: der link ist für den 5000er nicht geeignet, aber dieser fork schon.

Ich habe einen Pylontech US5000 und lese ihn seit 8 Monaten erfolgreich mit der "ungeforkten" Variante aus. Ich finde es auch komisch, dass beim Fork nur der Text und die Bilder 1:1 kopiert wurden und nirgends steht, wo die Unterschiede liegen.

Edit: habe den Changelog gefunden, demnach geht um die Möglichkeit, sicheren Zugriff einzuschalten, und um getrennte MQTT-Übertragung verschiedener Akkus (wenn ich das richtig verstanden habe). Im Quellcode habe ich nichts gefunden, was auf nach einer Erweiterung in Richtung US5000 klingt (habe da aber natürlich auch nicht alles verstanden).

[maltes]

Mein Verständnis ist das die CAN Schnittstelle die einzelnen Spannungen nicht ausgibt. Das geht nur über die serielle Verbindung.

Ich wollte dieses Projekt aus GitHub bauen

[arch86]

@lars72

Hatte folgendes gelesen, aber gut zu wissen das beide anscheinend funktionieren...

BTW: der link ist für den 5000er nicht geeignet, aber dieser fork schon.

Ich habe einen Pylontech US5000 und lese ihn seit 8 Monaten erfolgreich mit der "ungeforkten" Variante aus. Ich finde es auch komisch, dass beim Fork nur der Text und die Bilder 1:1 kopiert wurden und nirgends steht, wo die Unterschiede liegen.

Edit: habe den Changelog gefunden, demnach geht um die Möglichkeit, sicheren Zugriff einzuschalten, und um getrennte MQTT-Übertragung verschiedener Akkus (wenn ich das richtig verstanden habe). Im Quellcode habe ich nichts gefunden, was auf nach einer Erweiterung in Richtung US5000 klingt (habe da aber natürlich auch nicht alles verstanden).

[cacu15]

@alex_s
Ich kann im Prinzip alles auslesen, was man über die Pylontech Console auslesen kann. Dazu findet sich viel Info hier: https://www.photovoltaikforum.com/thread/118958-pylontech-us2000b-daten-%C3%BCber-konsole-rs232-auslesen/?pageNo=1, gleich auf der ersten Seite des Threads sind viele grundlegende INfos zusammengestellt, u.a. die Doku der Konsolenbefehle: https://www.photovoltaikforum.com/thread/130061-pylontech-us2000b-daten-protokolle-programme/

Ich nutze das wie folgt:

Von https://github.com/irekzielinski/Pylontech-Battery-Monitoring nutze ich nur den HW-Aufbau mit dem MAX3232 Transceiver.
Auf einem ESP, an dieser Aufbau an einem UART hängt, läuft ESPHome, darin dann der Stream-Server von https://github.com/mletenay/esphome-stream-server, über den ich den UART, an dem der MAX3232 hängt per TCP ansprechen kann.

Die Auswertung der Konsole in ESPHome war mir zu fummelig, daher habe ich das in Node Red gebaut. In Node-Red kann ich den Stream Server über TCP ansprechen und so Befehle an die Pylontech Konsole absetzen und die Antwort auslesen.

z.B. liefert der Konsolenbefehl "pwr" für jede Zelle des Akkus folgende Werte:

... und "bat 1"

So kann ich für jede einzelne Zelle die Spannung sehen und die maximale und minimale Spannung berechnen (und damit den Bedarf für ein Balancing)

[cerise]

Ich habe eine Frage zum 'Oberen Leistungslimit' in den Dynamic Power Limiter Settings:
Kann man diesen Wert via MQTT oder API setzen/verändern?
Ich habe versucht, das 'UpperPowerLimit' im Code zu verfolgen, blicke da aber nicht durch, bzw. sehe nicht, dass das von 'aussen' gesetzt werden könnte.
Hintergrund ist, dass ich den Wert am Ende des Tages, sobald das Haus aus dem Akku 'lebt', so anpassen möchte, dass die vorhandene Akkukapazität, gleichmäßig verteilt, bis zum nächsten Sonnenstrahl/Morgen, aufgebraucht wird (anstatt sie z. B. konzentriert für das abendliche Kochen/Backen zu verballern, was ja mit heftigen, ungewollten Einspeise-Überschwingern einhergeht).
Die im Live View beim Inverter setzbaren Limits (temp. und dauerhaft) sind hierfür ungeeignet, da sie vom Dynamic Power Limiter immer wieder überschrieben werden(!?)

Diese wirken wohl nur bei deaktiviertem Dynamic Power Limiter und sind dann keine Obergrenzen, sondern fixe Leistungswerte, die der Wechselrichter dann stur liefert(!?)

Die Funktion des Dynamic Power Limiters würde ich gerne erhalten, um nicht unnötig Energie einzuspeisen - deshalb die Änderung des oberen Limits.

[cacu15]

@cerise
Über die Web-API geht das definitiv per HTTP POST an die URL /api/powerlimiter/config. Dazu

HTTP Header wie folgt setzen:

Authorization: Basic <base64 encoded password>

Content-Type: application/x-www-form-urlencoded

im Body ein JSON wie es von GET /api/powerlimiter/config geliefert wird. Das JSON muss "form encoded" im Body stehen, also data='<stringified JSON>', siehe auch Dokuz zur WebAPI. In dem JSON dann den Wert mit dem Key "upper_power_limit" auf den gewünschten Wert setzen. Habe den Endpunkt zwar noch nicht verwendet, um die Grenzwerte zu ändern, aber um den DPL per API zu aktivieren/deaktivieren.

Siehe dazu im Code: https://github.com/helgeerbe/OpenDTU-OnBattery/blob/development/src/WebApi_powerlimiter.cpp in der Methode

void WebApiPowerLimiterClass::onAdminPost(AsyncWebServerRequest* request)

[cerise]

@cacu15

Vielen Dank für die Anleitung.

Ich muss also die gesamte powerlimiter/config auslesen und mit geändertem value beim key 'upper_power_limit' wieder posten.

Mal sehen, wie ich das in openHAB bewerkstelligt bekomme…

[cerise]

Dank der Anleitung von @cacu15 ist es nun auch

in openHAB bewerkstelligt

Hier der Code für eine Rule, die morgens und abends das Limit in der Power Limiter Config ändert (falls mal jemand via openHAB die API bedienen will):

(irgendetwas am folgenden Code-Block verhindert wohl, dass die Foren-Software diesen überhaupt anzeigt, deshalb als quote-Block…)

configuration: {}
triggers:

• id: "1"
  configuration:
  itemName: Generic_MQTT_Thing_Solar_Victron_PPV
  state: "0"
  type: core.ItemStateChangeTrigger
• id: "3"
  configuration:
  itemName: Generic_MQTT_Thing_Solar_Victron_PPV
  state: "20"
  type: core.ItemStateChangeTrigger
  conditions:
  actions:
• inputs: {}
  id: "2"
  configuration:
  type: application/javascript
  script: >
  //DPL upper_power_limit nach Sonnenuntergang neu setzen, so dass im Akku
  verfügbare Energie gleichmäßig bis zum Sonnenaufgang (SA)
  // eingespeist wird; nach SA Limit auf 600W setzen
  var HashMap = Java.type("java.util.HashMap");
  var HTTP = Java.type("org.openhab.core.model.script.actions.HTTP");
  var logger = Java.type('org.slf4j.LoggerFactory').getLogger('org.openhab.rule.' + ctx.ruleUID);
  var ZonedDateTime = Java.type("java.time.ZonedDateTime");
  var dtuCfgGetUrl = "http://192.168.178.241/api/powerlimiter/status";
  var dtuCfgPostUrl = "http://192.168.178.241/api/powerlimiter/config";
  var authStr = "admin:xxxxx"
  var ppv = itemRegistry.getItem('Generic_MQTT_Thing_Solar_Victron_PPV').getState(); //PV-Leistung
  var soc = itemRegistry.getItem('Generic_MQTT_Thing_Solar_Akku_SoC').getState(); //Akku-SoC
  var restSoc = 15; //nur bis 15% entladen
  var zeit_h = ZonedDateTime.now().getHour(); //aktuelle Stunde
  var zeit_sa_h = items["Lokale_Sonnendaten_Endzeit"].getZonedDateTime().getHour(); //Stunde des SA (heute~morgen)
  var hBisSA = 24 - zeit_h + zeit_sa_h; //Stunden bis SA
  var uplneu = parseInt((soc-restSoc)/100 * 4800 / hBisSA); //neues Limit: (verfügbarer Anteil von 4.8kWh)/(Stunden bis SA)
  var uplneu = (uplneu > 40) ? uplneu : 0; //wenn nicht mind. 40W eingespeist werden kann, dann gar nicht einspeisen
  if (ppv > 10) {uplneu = 600;} //Rule-Aufruf nach SA
  var cfgstr = HTTP.sendHttpGetRequest(dtuCfgGetUrl, 51000);
  var uplalt;
  cfgmod = JSON.parse(cfgstr, function (key, value) { //beim Parsen des gelesenen Strings mit reviver-Function upl-value speichern und ersetzen
  if (key == "upper_power_limit") {
  uplalt = value;
  return uplneu;
  } else {
  return value;
  }
  });
  var cfgmodstr = "data="+JSON.stringify(cfgmod); //config mit geändertem Limit als String mit 'data=' -Präfix
  //Authorization: Basic <base64 encoded password>
  //Content-Type: application/x-www-form-urlencoded
  var encodeAuth = function(){ //user:password codieren
  var Base64 = Java.type("java.util.Base64");
  var Encoder = Base64.getEncoder();
  var authEncoded = Encoder.encodeToString(authStr.getBytes("UTF-8"));
  return authEncoded;
  };
  var authEncoded = encodeAuth();
  var header = new HashMap(); //header für Post
  header.put("Authorization", "Basic " + authEncoded);
  header.put("Accept", "application/json");
  logger.info("openDTU_config_neu: {}", cfgmodstr);
  logger.info("SOC: {}", soc);
  logger.info("SOC lower limit: {}", restSoc);
  logger.info("Stunde SA: {}",zeit_sa_h);
  logger.info("hBisSA: {}", hBisSA);
  logger.info("upper_power_limit alt: {}", uplalt);
  logger.info("upper_power_limit neu: {}", uplneu);
  if (parseInt(uplalt) !== parseInt(uplneu)) { //config nur bei geändertem upper_power_limit posten
  var result = HTTP.sendHttpPostRequest(dtuCfgPostUrl, "application/x-www-form-urlencoded", cfgmodstr, header, 51000);
  logger.info("PostResult: {}",result);
  events.postUpdate('openDTU_config_neu', cfgmodstr); //geänderten String zur Kontrolle in item schreiben
  events.postUpdate('openDTU_config_neu_ok', result); //Post-Rückgabe zur Kontrolle in Item schreiben
  }
  type: script.ScriptAction

[cerise]

--

[arch86]

Ich muss meinen Pylontech noch bestellen, daher folgende Frage, sonst würde ich es selber messen. Setup OpenDTU-onBattery: Huawei R4850G2, HM1500 und einen Pylontech 5000. Was ist der gesamt Standbyverbrauch von diesen drei? Ich trenne nichts AC und DC seitig.

1. Huawei mit slot-detect aktiv: 5W?
2. HM1500: keine 50mW oder so, da ja DC Spannung anliegt: 5W?
3. Pylontech selber: 5W?

Also etwa 7.5% Entladung pro 24 Stunden für den 5000'er Pylontech? Ich überlege gerade folgendes Szenario: Pylontech ist auf der unteren Grenze von zB 20% SoC und es einige Tage wo keinen Überschuss da ist. Dan ist man in 2 Tage ja schon von 20% SoC auf 5% SoC. Wann greift der BMS vom Pylontech ein, bei welchem SoC?

Oder versorgen sich der Huawei und Hoymiles sich in standby über AC?

Wäre es nicht eine Verbesserung dass OpenDTU-onBattery einen absolute SoC Untergrenze anbietet, wo ab dann der Akku wieder aufgeladen wird (mittels Huawei zB) bis zu SoC Untergrenze. zB Untergrenze 20% SoC, ab 10% SoC aufladen auf 20% bis wieder Überschuss vorhanden ist. Oder könnte ich dass in NodeRed implementieren und über MQTT dann steuern? (hat jemand schon so was programmiert?)