Danke @maltes, dass Du Dich trotz der
Vielen Fragen
dieser angenommen hast.
Ok, das Laden muss ich also über
einen anderen Rechner über MQTT
steuern. Den Link zu Deinen Node Red Flows hatte ich gesehen.
Ich dachte, man könnte die openDTU-OnBattery-Software vielleicht irgendwie zum kontrollierten Laden überreden.
mal messen oder in src/huawei_can.cpp schauen
Gemessen habe ich, dass der Huawei-Power-Pin high geht, wenn der bei mir angeschlossene Optokoppler den SlotDetect des Huawei auf DC- zieht.
Im Quellcode sehe ich, dass das aber der Zustand ist, wenn das Netzteil ausgeschaltet werden soll. — Ok, ich habe also eine Invertierung im Signalpfad.
Klingt, als wäre deine Logik zum Schalten negiert
Genau; so lösen sich etliche meiner Fragen auf und nach Entfernen der Invertierung (Eingangsstrom des Optokopplers von VDD in den Huawei-Power-Pin, statt vom Power-Pin in GND) verhält sich das Ein-/Ausschalten des Netzteils vermutlich deutlich logischer…
Hallo @cerise,
ich denke, da kommen verschiedene Aspekte zusammen.
Vor allem gibt es wirklich sehr viele verschiedene Situationen bei den verschiedenen Benutzern, wie der Akku geladen wird. Und es ist recht schwierig allen diesen Situationen gerecht zu werden. OpenDTU hat den Schwerpunkt m.E. eher bei der dynamischen Steuerung des Inverters (also Einspeisung), weniger bei der Steuerung des Ladevorgangs. Bin auch nicht sicher, ob das in Zukunft ein Schwerpunkt sein soll/wird.
- Viele laden aussschließlich über Victron SolarCharger
- Manche laden über SolarCharger und Huawei
- Ich hingegen lade ausschließlich über das Huawei, weil ich aktuell noch gar keinen SolarCharger habe, nur eine große Dach-PV an einem WR
- Laden über Netz abhängi von günstigem Stromtarif (siehe Implementierung von @MalteS, die ich sehr spannend finde)
Zusätzlich noch verschiedene Ansätze für das Ansteuern des Chargers:
- Aktivierung/Deaktivierung über Slot-Detect
- AC seitige Schaltung
- Kombination von beidem?
Aus meiner Sicht hätte ich folgende Erweiterungs- bzw. Änderungswünsche:
- Das vom Akku gemeldete Ladestromlimit sollte berücksichtigt werden. Das ist aktuell nicht der Fall, sollte aber m.E. recht einfach realisierbar sein, da die Information eh' schon vorliegt.
- Warnungen des Akkus bei zu niedriger Spannung sollten ggf. zu einem automatischen Laden des Akkus führen, um Akku Schäden zu vermeiden
- Die aktuelle Logik für Ein-/Ausschalten des Netzteils wenn bei einer Zielspannung eine minimale Stromstärke unterschritten wird, ist m.E. für manche Szenarien nicht optimal. Da werden verschiedene Sachen vermischt, die ich gerne unabhängig steuern würde:
- Zum einen eine minimale Ladestromstärke, um möglichst effizient zu laden.
- Zum anderen die Aktivierung/Deaktivierung des Ladevorgangs.
- Ein-/Ausschalten des Netzteils
Das führt z.B. zu Problemen in folgenden Szenarien:
- Ich würde gerne ab und zu eine "Absorbtionsphase" zum Top-Balancing des Akkus durchführen. Dazu muss ich denn Akku aber bis zu einer Absorbtionsspannung (bei Pylontech sind 52V empfohlen) laden und dann für eine Zeit diese Spanung anliegen lassen, auch wenn während dessen ein sehr kleiner Strom fließt. Während dieser Zeit ist mir die Effizienz der Ladung nicht so wichtig, es geht um Akku-Pflege. Und wenn man das nur alle 1-2 Wochen macht, dann ist das von der Effizienz her auch nicht so relevant. Das geht aktuell nicht, weil die Automatik hier wegen der geringen Stromstärke immer abschaltet.
- Wenn der Akku eine Unterspannung meldet (Warnung/Alarm), dann würde ich gerne den Akku auch dann auf einen Ziel-SoC/Spannung laden, wenn ich das mit Netzstrom tun muss. Gerade bei dem Mist-Wetter aktuell kommt es vor, dass der Akku mehrere Tage gar nicht geladen wird und dann irgendwann durch den WR und Netzteil, die bei mir immer an sind, zu stark entladen würde. Das geht aktuell nur manuell: Automatik deaktivieren, Huwei auf festes Limit setzen und damit Laden. Dann bei Ziel-SoC wieder ausschalten und Automatik wieder aktivieren.
Ich habe daher angefangen, mir meine eigene Ladelogik auf einem 2. ESP zu bauen, der diese Fälle abdeckt und den ich eh' in Betrieb habe, um darauf eine Pylontech-Konsole und das PowerMeter (IR Lesekopf) zu betreiben. Die Logik auf ESPHome nutzt die HTTP API von OpenDTU sowie meines Shelly, über das ich meinen Inverter und Huawei Charger AC seitig schalte. Ich baue das auf dem ESP und nur über die HTTP-API der OpenDTU, um Abhängigkeiten von MQTT-Brokern, Node Red etc. zu vermeiden.
Aber eigentlich würde ich das lieber in OpenDTU on Battery einbringen, weil es dann allen Nutzern zur Verfügung steht. Wenn das nicht möglich ist, dann kann ich wenigstens mal meine ESPHome Umsetzung zur Verfügung stellen, sofern sie wenigstens etwas getestet ist.
Meine Ansätze aktuell sind:
- Schalten des Netzteils in separatem Thread, der das Netzteil abhängig von der angeforderten Leistung/Stromstärke aktiviert und deaktiviert. Netzteil wird eingeschaltet, wenn Stromlimit > 0 und es wird ausgeschaltet, wenn Stromlimit längere Zeit (Konfiguration) == 0 ist. WARUM eine Anforderung für eine bestimmte Leistung vorhanden ist, ist hier egal.
Evtl. könnte man das in 2 Stufen machen: Bei Leistungs == 0 wird direkt der SlotDetect abgeschaltet, nach einer Weile dann das Netzteil AC seitig getrennt. Aktuell kann man aber üer OpenDTU API das SlotDetect nicht separat ansteuern, daher geht das aktuell nicht - außer, wenn man das Slot Detect über ein Relais am 2. ESP steuert. - Verschiedene Lade-Algorithmen:
- Laden mit PV-Überschuss bis Ziel-Spannung/SoC. Das entspricht der aktuellen Automatik in OpenDTU. Allerdings mit dem Unterschied, dass man die minimale Ladeleistung und das Abschaltkriterium (Soc/Spannung) unabhängig konfigurieren kann. Wenn der Ziel SoC oder Ziel-Spannung erreicht werden, dann wird Laden beendet. Wenn man die Zielspannung entsprechend hoch ansetzt, dann wird durch die abfallende Ladestrom-Kurve des Akkus ggf. auch mit sehr kleiner Leistung weiter geladen. Was dann aber ja ggf. gewünscht ist.
Wenn zu einem Zeitpunkt die minimale Ladeleistung unterschritten wird, dann wird erstmal die Ladeleistung auf 0 gesetzt, aber der Ladevorgang läuft weiter. Wenn die Ladeleistung über einen konfigurierbaren Zeitraum 0 ist, dann wird das Netzteil über den Mechanismus 1 abgeschaltet. - Laden unabhängig von PV-Überschuss (mit fester Leistung). Hier wird einfach eine feste Leistung vorgegeben und bis zu einem Ziel-Soc/Spannung geladen. Das kann man z.B. gebrauchen für Notfall-Laden, Laden bei günstigem Strom (Tibber-Szenario) etc.
- Laden mit PV-Überschuss bis Ziel-Spannung/SoC. Das entspricht der aktuellen Automatik in OpenDTU. Allerdings mit dem Unterschied, dass man die minimale Ladeleistung und das Abschaltkriterium (Soc/Spannung) unabhängig konfigurieren kann. Wenn der Ziel SoC oder Ziel-Spannung erreicht werden, dann wird Laden beendet. Wenn man die Zielspannung entsprechend hoch ansetzt, dann wird durch die abfallende Ladestrom-Kurve des Akkus ggf. auch mit sehr kleiner Leistung weiter geladen. Was dann aber ja ggf. gewünscht ist.
- Für Absorbtion kann man einen Zeitplan (z.B. alle X Tage) angeben. Dann wird in diesem Rythmus der Akku auf die Absorbtionsspannung geladen und nach Erreichen der Spannung diese noch für einen definierten Zeitraum gehalten, um dem Akku die Gelegenheit zum Top-Balancing zu geben. Dazu wird dann auch der DPL deaktiviert, damit das Balancing zu Ende durchläuft.
Vermutlich macht es Sinn, den Rythmus so zu konfigurieren, dass man bei Erreichen des Stcihtags erstmal für einige Tage versucht, den Akku mit PV-Überschuss zu laden und die Absorbtion zu machen. Erst wenn das z.B. über X Tage nicht klappt, weil keine Sonne scheint, dann ggf. mit Netzstrom durchführen.
Vor allem gibt es wirklich sehr viele verschiedene Situationen bei den verschiedenen Benutzern, wie der Akku geladen wird.
Das war auch mein Gedanke. Deshalb gibt es die Option alles von außen zu steuern. Es ist glaube ich nicht praktikabel jeden Fall in openDTU einzubauen.
Das vom Akku gemeldete Ladestromlimit sollte berücksichtigt werden. Das ist aktuell nicht der Fall, sollte aber m.E. recht einfach realisierbar sein, da die Information eh' schon vorliegt.
Das ist korrekt und gilt sich für den DPL und das Entladestromlimit glaube ich. Ist noch ein Todo von mir
Warnungen des Akkus bei zu niedriger Spannung sollten ggf. zu einem automatischen Laden des Akkus führen, um Akku Schäden zu vermeiden
Ja, mein Gedanke dazu war in den Node Red controller mal Warnungen zu erkennen und dann eine Nachricht über einen Messenger zu schicken (z.B. Telegramm). Ist aber nicht implementiert. Erfordert dann zwar manuelles eingreifen deckt aber auch jeden Fehlerfall erst mal ab
Die aktuelle Logik für Ein-/Ausschalten des Netzteils wenn bei einer Zielspannung eine minimale Stromstärke unterschritten wird, ist m.E. für manche Szenarien nicht optimal
Ja, das es auch die Option gibt das alles extrem zu steuern weißt du aber oder? Da gibt es MQTT Befehle für Power on/off
@MalteS, vielen Dank für die Hinweise.
Das war auch mein Gedanke. Deshalb gibt es die Option alles von außen zu steuern. Es ist glaube ich nicht praktikabel jeden Fall in openDTU einzubauen.
OK, das beantwortet meine Fragen dazu schon. Dann mache ich erstmal mit meiner Umsetzung weiter.
Ja, das es auch die Option gibt das alles extrem zu steuern weißt du aber oder? Da gibt es MQTT Befehle für Power on/off
Die MQTT Befehle kannte ich in der Tat noch nicht, danke für den Tip. Die fehlen auch in der Doku auf https://tbnobody.github.io/OpenDTU-docs/firmware/mqtt_topics/. Da ich aktuell versuche, das alles über die WebAPI zu lösen, habe ich da noch nicht nachgesehen. Ich gucke aber meist direkt in den Code, wenn ich in der Doku nichts finde. Im Code ist die Wahrheit 😉 und da habe ich jetzt gefunden:
Topic:
/huawei/mode
mit den Payloads:
HUAWEI_MODE_OFF 0 HUAWEI_MODE_ON 1 HUAWEI_MODE_AUTO_EXT 2 HUAWEI_MODE_AUTO_INT 3
Etwas ähnliches gbt es für die WebAPI m.W. nicht. Ist für mich aber nicht so schlimm, mein Slot Detect funktioniert aktuell eh' immer noch nicht und ich schalte mein Huwei daher immer über das Shelly AC seitig über die Shelly RPC API. Das kann sich ja ggf. auch ergänzen: ich wollte einen Modus bauen, bei dem man die OpenDTU Ladelogik weitgehend für das normale Laden nutzt, nur für die genannten Sonderfälle baue ich eigene Lösungen. Und dann kann man dann ja die SlotDetect Steuerung von OpenDTU nutzen, ggf. dann in Kombination mit der AC seitigen Abschaltung.
P.S: Wenn ich mal mit meiner Enwicklung durch bin, dann aktualisiere ich auch mal Doku mit dem, was ich herausgefunden habe. Ich wühle mich da ja eh' durch viele API-Funktionen und setze die in ESPHome um.
In der aktuellen Doku der WebApi auf https://tbnobody.github.io/OpenDTU-docs/firmware/web_api/#list-of-urls fehlt z.B. das Huawei komplett. Dabei gibt es folgende funktionierende Calls für das Huwaei, die ich alle in meiner ESPHome Implementierung schon verwende:
- GET api/huawei/status - Status (Spannungen, Temperaturen, Leistung, Stromsärke etc.)
- GET api/huawei/config - Konfiguration lesen
- POST api/huawei/config - Konfiguration schreiben
- POST api/huawei/limit/config - setzen der Online und Offline Limits
Um das analog zu MQTT nutzen zu können müsste man ja entweder die Konfig um ein Attribut für den Modus erweitern oder einen eigenen Endpunkt für dem Mode (/api/huawei/mode ?) etablieren. Aber vermutlich einfacher, dass einfach in das JSON der config aufzunehmen.
In der aktuellen Doku der WebApi auf https://tbnobody.github.io/OpenDTU-docs/firmware/web_api/#list-of-urls /a> fehlt z.B. das Huawei komplett. Dabei gibt es folgende funktionierende Calls für das Huwaei, die ich alle in meiner ESPHome Implementierung schon verwende:
Da schaust du an der verkehrten Stelle. Das Projekt von tbnobody ist das originale OpenDTU Projekt. Das enthält nichts bzgl. Batterie. Du solltest da typischerweise nicht drauf schauen.
OpenDTU-onBattery ist hier: https://github.com/helgeerbe/OpenDTU-OnBattery
Im dazugehörigen Wiki finden sich z.B. die MQTT Topics hier: https://github.com/helgeerbe/OpenDTU-OnBattery/wiki/MQTT
Die Doku zu dem Huawei Lader versteckt sich etwas unter Hardware: https://github.com/helgeerbe/OpenDTU-OnBattery/wiki/Huawei-AC-PSU beschreibt aber auch die Modi über die ich sprach.
Die WebAPI calls sind zumindest in der WebAPI erwähnt. Aber gut Dokumentiert ist anders. Als ich das damals gemacht habe bin ich nicht wirklich davon ausgegangen das jemand die WebAPI verwendet... Und wenn ist er vermutlich in der Lage die Details herauszufinden. Sonderlich schwer ist das ja alles nicht.
Laden über Netz abhängi von günstigem Stromtarif (siehe Implementierung von @MalteS, die ich sehr spannend finde)
Auch das ein/ausschalten der Speichers. Es ist ja so das jeder Weg durch den Speicher Verluste zur Folge hat und auch eine Abnutzung der Batterie darstellt. Jetzt im Winter kommt nur das Scenario vor das der Strompreis durch die Windkraft nachts niedrig ist (ca. 16ct / kwh bei mir). Wenn man also das an Stromkosten ansetzt, die Wirkungsgradverluste des Netzteils und des Inverters berücksichtigt und die Abnutzung der Batterie noch ansetzt komme ich so auf ca 24ct wo man break even hat. Der RPI / Node Red schalte diese ganze Sache daher erst wieder ab 27ct / kwh ein.
Ich glaube die Batterie ist jetzt seit der Woche vor Weihnachten voll und wird nicht entladen. Es macht bei diesen Preisen viel mehr Sinn einfach Strom zu kaufen (*). Es war seit dem 20. Dez. selten teurerer als 20ct. Morgen steigt der Strompreis bis auf 34ct dann springt der Kram wieder an.
Dezember waren das 908kwh zu 221€. Sprich 24.3ct / kwh im Schnitt. Ich habe aber heute mit einem Nachbarn gesprochen. Der sagte das Stromtarife mittlerweile ab 27ct / kwh zu haben sind. Bei diesem Preis würde ich mir das gut überlegen. Ich habe jetzt seit April glaube ich 24.5 ct erreicht. Das E-Auto macht aber da viel aus weil es ein grosser steuerbarer Verbraucher ist.
@cacu15 Danke für die ausführliche Darstellung der Thematik 'Laden per Huawei'.
Es wäre zwar schön, wenn OpenDTU-onBattery die Funktionalität Deiner ESPHome-Add-On-Lösung schon eingebaut hätte, ich sehe aber auch, wie Malte schon sagte, dass das vermutlich immer noch nicht alle Use Cases abdecken würde...
Wenn die Huawei-Lade-Steuerung per ESPHome publikumsreif ist, würde ich das gerne mal testen. Es scheinen da ja schon etliche Überlegungen eingeflossen zu sein, auf die man beim Rad-Neuerfinden ggf. gar nicht oder erst spät kommt...
Auch Maltes Node-Red-Erweiterung versuche ich mal zum Laufen zu bringen (allerdings muss ich mich da bzgl. der hard- und softwaremäßigen Voraussetzungen erst einlesen...)
Hallo, hab ne Frage zu openDTU-OnBattery. Ist damit direkt die Nulleinspeisungs-Regelung mit meheren Hoymiles möglich? Konnte weder hier noch im Git was dazu finden, ist immer nur von 1 WR am Akku die Rede.
Hab momentan ein System mit 3x Soyosource WR mit dem Controller von KlausLi am laufen, RS485 parallel. Aktuelle AC-Leistung kommt vom Stromzähler via Tasmota, wird im IOBroker verarbeitet (Offset und durch 3 geteilt) und dann zum WR Controller geschickt. Läuft soweit recht ordentlich, spiele jedoch mit dem Gedanken die Soyosource durch 3x HM 1200 zu ersetzen (mehr Power, wohl besserer Wirkungsgrad, höchstwahrscheinlich langlebiger). Da wär natürlich fein wenn sich dann der ganze Regelkreis nur noch zwischen Zähler(Tasmota) und dem openDTU-OnBattery abspielt. Kommunikation mit den beiden vorhandenen JK-BMS wär natürlich auch schön, zurzeit fahr ich über die Spannungsgrenzwerte in den Soyosource, imho vollkommen ausreichend aber über SOC ist halt noch schöner.
Hallo, hab ne Frage zu openDTU-OnBattery. Ist damit direkt die Nulleinspeisungs-Regelung mit meheren Hoymiles möglich? Konnte weder hier noch im Git was dazu finden, ist immer nur von 1 WR am Akku die Rede.
Hab momentan ein System mit 3x Soyosource WR mit dem Controller von KlausLi am laufen, RS485 parallel. Aktuelle AC-Leistung kommt vom Stromzähler via Tasmota, wird im IOBroker verarbeitet (Offset und durch 3 geteilt) und dann zum WR Controller geschickt. Läuft soweit recht ordentlich, spiele jedoch mit dem Gedanken die Soyosource durch 3x HM 1200 zu ersetzen (mehr Power, wohl besserer Wirkungsgrad, höchstwahrscheinlich langlebiger). Da wär natürlich fein wenn sich dann der ganze Regelkreis nur noch zwischen Zähler(Tasmota) und dem openDTU-OnBattery abspielt. Kommunikation mit den beiden vorhandenen JK-BMS wär natürlich auch schön, zurzeit fahr ich über die Spannungsgrenzwerte in den Soyosource, imho vollkommen ausreichend aber über SOC ist halt noch schöner.
Hallo Andreas,
nach meinem Verständnis kannst Du mit einer OpenDTU on Battery Instanz nur die Einspeisung über 1 WR steuern. In der Konfiguration des "Dynamic Power Limiter" DPL, der die Einspeiseleistung regelt, muss/kann man nur genau 1 WR auswählen, der gesteuert werden soll. Auch die ganze Logik im Source des DPL sieht nicht so aus, als dass sie mit mehreren WR umgehen könnte.
Man könnte natürlich auf die Idee kommen, für jeden WR eine eigene OpenDTU Instanz verwenden. Aber ich könnte mir vorstellen, dass es Probleme gibt, wenn 3 DPL parallel arbeiten, die nichts voneinander wissen und ja jeder für sich versuchen würden, Abweichungen vom angestrebten Zielwert auszureglen. Das führt vermutlich nicht zu einem stabilen Zustand.
JK-BMS über serielle Schnittstelle ist seit einer der letzten Versionen unterstützt, das wurde im 2. Halbjahr 2023 eingebaut. Details kenne ich nicht, da ich einen Pylontech nutze.
In der Konfiguration des "Dynamic Power Limiter" DPL, der die Einspeiseleistung regelt, muss/kann man nur genau 1 WR auswählen, der gesteuert werden soll.
So in der Richtung hab ich die Doku auch verstanden. Wenns so ist dann schade, die DTU kann ja durchaus mehrere Hoymiles WR gleichzeitig steuern...
Das mit dem BMS hab ich gesehen, aber so wie es aussieht auch nur eines. Zum Daten auslesen benutz ich da zur Zeit das hier https://github.com/syssi/esphome-jk-bms über BT. Funzt nur leider bei einem der beiden nicht stabil genug um damit zuverlässig was zu steuern, wird deshalb demnächst auf UART umgebaut. Zusammen mit einer openDTU oder AhoiDTU krigt man damit sicher auch ne brauchbare Nulleinspeisungssteuerung hin. Logic läuft halt dann wieder im IOBroker (Script oder NodeRed). Hätt halt gern was aus einem Guss.
Muss mir mal den Quäl-Kot reinziehen ob ich da halbwegs durchsteig und wenn ja wieviel Act das wär den entsprechend anzupassen.
Hab mir jetzt mal die PowerLimiter.cpp angesehen. Wenn ich das richtig verstanden hab dann wird die Soll AC Leistung mit dem Wirkungsgrad und den angenommenen Leitungsverlusten verrechnet um auf die Soll DC Leistung zu kommen. Die wird dann durch die Anzahl der DC Anschlüsse des WR geteilt und diesen Wert kriegt dannn der WR gesetzt. Ziemlich wüster Hack, Aufteilung auf mehrere WR relativ komplex vor allem wenn da dann auch unterschiedliche Typen zulässig sein sollen.
Was ich auch nicht ganz blicke ist die Kommunikation zum WR. Wird da jedes mal die Verbindung zu einem WR aufgebaut werden, Daten senden, Verbindung abbauen, neue Verbindung zum nächsten WR? Das könnte natürlich ein Zeitproblem sein, Leistung sollte bei allen beteiligten WR ja möglichst gleichzeitig geändert werden.
In der PowerMeter.cpp hab ich gesehen das bei SOURCE_SML scheinbar ne Verbindung zu einem IR Lesekopf für Stromzähler aufgebaut wird, bisher nirgends in der Doku was dazu gesehen. Das ist sehr interessant, damit könnte ich den ESP8266 mit Tasmota am Zähler auch eliminieren. Funkverbindung zu den WR hat ja scheinbar ziemlich Reichweite.
Hab mir jetzt mal die PowerLimiter.cpp angesehen. Wenn ich das richtig verstanden hab dann wird die Soll AC Leistung mit dem Wirkungsgrad und den angenommenen Leitungsverlusten verrechnet um auf die Soll DC Leistung zu kommen. Die wird dann durch die Anzahl der DC Anschlüsse des WR geteilt und diesen Wert kriegt dannn der WR gesetzt. Ziemlich wüster Hack, Aufteilung auf mehrere WR relativ komplex vor allem wenn da dann auch unterschiedliche Typen zulässig sein sollen.
Ja das liegt daran dass einige die Batterie nur an einzelne Anschlüsse anschließen wollten. Macht halt alles komplexer
Was ich auch nicht ganz blicke ist die Kommunikation zum WR. Wird da jedes mal die Verbindung zu einem WR aufgebaut werden, Daten senden, Verbindung abbauen, neue Verbindung zum nächsten WR? Das könnte natürlich ein Zeitproblem sein, Leistung sollte bei allen beteiligten WR ja möglichst gleichzeitig geändert werden.
Das wird nötig sein. Ob die Leistung bei allen WR gleichzeitig geändert werden muss ließe sich diskutieren. Die Leistung muss auch nicht gleich sein
Das wird nötig sein. Ob die Leistung bei allen WR gleichzeitig geändert werden muss ließe sich diskutieren. Die Leistung muss auch nicht gleich sein
Nö, muss natürlich nicht. Dann sollte man das aber durchwechseln welcher die Anpassung macht damit alle über die Zeit etwa gleich beansprucht werden.
Hallo,
wen's interessiert: Ich habe die Pylontech Aufweck-Lösung gebaut und sie funktioniert mit minimalem HW und Programmieraufwand. Wie, steht in meinem Blog: https://rustimation.eu . Funktioniert - so wie ich es sehe - leider nur mit der "C" Serie von Pylontech. Nur dort ist der Console Port als 8 Polige RJ45 Buchse ausgeführt und hat die Kontakte fürs Aufwecken.
Macht's gut
Grüße
Chris
@andreash @maltes ich bin gerade auch auf dem Thema zwei power limit geregelte HM gestossen...
Ideal wäre zB 2x HM1500 (3000W peak) oder zB 1x HM1500 und 1xHM800 (2300W peak) an der Batterie anzuschliessen (US5000C liefert >3000W peak). Wie ich verstehe ist es momentan nicht in der software vorgesehen. Wie kompliziert wäre das denn? Die liveview zeigt schon bis zu 5 inverters, richtig? Ist der power limit zu setzen so viel aufwendiger als "nur" die Daten auszulesen? Kann ich mir schon vorstellen, das eine ist "lesen" und das andere "schreiben". Ich hätte gesagt dass sequentiell dann die zwei Inverters gesetzt werden, zB erstmal mit dem gleichen Wert, zB 80%, wenn die Gesamteinspeisung 80% sein soll.
Hier ist sogar vor kurzem ein topic geöffnet. @andreash kannst Du da mal was reinschreiben? Ich muss mal ein account machen und werde da auch mal reinschreiben, je mehr Bedarf angemeldet wird, desto besser denke ich mal 🙂