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).
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
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).
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-serve r" target="_blank" rel="noopener"> 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)
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.
Über die Web-API geht das definitiv per HTTP POST an die URL /api/powerlimiter/config. Dazu
HTTP Header wie folgt setzen:
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)
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, 5*1000);
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, 5*1000);
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
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?)
Standby-Verbrauch habe ich nicht gemessen.
Der Pylontech entleert sich nicht. Ich schalte auch nichts ab und das lief den Winter durch. Der Akku bleibt bei 20%. Es gibt da m.E. kein Problem das man Software seitig lösen müsste
Bzgl. HM 1500 möchte ich auf den anderen Hoymiles Thread und die Infos hier verweisen:
https://github.com/helgeerbe/OpenDTU-OnBattery/wiki/HOYMILES
Sollte man zumindest kennen
Ich habe einen HM600 statt eines HM1500. Aber sonst vergleichbar. ICh habe nicht gemessen, aber auf keinen Fall ist der Akku in 2 Tagen von 20% SoC auf 5% SoC runter. Ich schalte allerdings das Huawei AC seitig ab, der Inverter ist aber immer an. Bei mir verliert der Akku über 2 Tage ca. 1%-Punkt an SoC.
@MalteS: Du hast doch bei Dir auch das Laden über einen SmartSolar im Einsatz, richtig? Vermutlich produzieren die daranhängenden Module selbst in der dunkelsten Zeit genug, um wenigstens den Eigenverbrauch der Anlage zu decken und darum hast Du das Problem nie?
Was aber etwas gefährlich ist: Bei mir ist der SoC Verlauf bei < 15 % nicht mehr wirklich linear. Da war der Akku sehr plötzlich (innerhalb von 1h) von 10 oder 12% auf nur noch 5% und forderte sofortiges Laden an. Die "Notladung" realiere ich gerade auf ESPHome, was ich eh' auf einem separaten ESP habe. Dort frage ich dann alle paar Minuten den Akkuzustand ab. Wenn darin sofortiges Laden anfordert wird, dann lade ich unabhängig von PV Überschuss auf einen vorher festgelegten SoC-Zielwert. Ist fast fertig, aber wegen anderer Projekte komme ich gerade nicht dazu, das fertig zu programmieren.
Das kann man aber genau so gut in Node Red oder so jeder anderen Umgebung implementieren, die REST oder MQTT kann.
@MalteS: Du hast doch bei Dir auch das Laden über einen SmartSolar im Einsatz, richtig? Vermutlich produzieren die daranhängenden Module selbst in der dunkelsten Zeit genug, um wenigstens den Eigenverbrauch der Anlage zu decken und darum hast Du das Problem nie?
Möglich. Aber viel kommt da an Tagen wo Schnee auf den Modulen liegt nicht 😉
Ich habe selbst da keine Entladung beobachtet und gelegentlich auf mein Node Red Dashboard geschaut. Das zeigt mir die letzten 6h an. Da gab es nichts zu sehen.
Ich versuche eine Steuerung in PHP für einen Huawei AC zu programmieren. Dabei stelle ich mir die Frage, wie richtig geladen werden muss. Der Huawei lässt sich dynamisch mit V und A ansteuern. Als Ladespannung arbeite ich mit 55,2 V.
Je nach PV Überschuss steuere ich dann die Ladeleistung dynamisch, von etwa 3 A bis 20 A, bei konstant 55,2 V. Der Überschuss kann zwischenzeitlich durch Wolken/Sonne stark schwanken. Sind solche Spitzen schädlich für den LiFePo4 Akku, wenn es also zum Beispiel einen Sprung von 3 A auf 20 A gibt (Sonne kommt hervor) oder anders herum 20 A auf 3 A runter (Wolken)? Sollte man die Spitzen besser abfedern, in dem man zum Beispiel von 3 A auf 20 A in mehreren Schritten hochregelt bzw. abregelt?
Gleiche Fragestellung für den Huawei 4850G2: Sind solche (kurzen) Ladesprünge für die Ladeelektronik o.ä. schädlich?
Wie steht es mit dem Entladen des Akkus? Klassiker wie Kochherd oder Bügeleisen, die zwischendurch immer wieder kurzzeitig hohe Leistung für einige Sekunden anfordern, um die Temperatur zu halten, und dann wieder stark abfallen. Wenn der Akku dann per OpenDTU immer wieder kurzzeitig Lastspitzen gegenregeln muss - ist das für LifePo4 Akkus und/oder Hoymiles WR schädlich?
Wäre prima, wenn dazu jemand relativ leicht verständliche Erklärungen parat hätte. Danke schon mal!
