Jou Mist da war ein Punkt in dem Link. Ist korrigiert
1 „Gefällt mir“
Pylontech über Konsole aufwecken
Bei mir versorgt ein Pylontech US2000C Akku einen Hoymiles HM-600 Wechselrichter zur Einspeisung. Sie Einspeisung wird gestoppt, indem ich das WR Limit auf 0% setze. Blöderweise zieht der Wechselrichter (und evtl das Ladegerät) dann immer noch Strom aus dem Akku - SoC -1,5% pro Tag. Ideal wäre es, wenn man die Batterie (jaja, ich weiß, es ist ein Akku) remote an- und ausschalten könnte.
Über die Konsole kann ich div. Status vom Akku auslesen und kann man das Pylontech Teil damit auch ausschalten.Siehe https://github.com/irekzielinski/Pylontech-Battery-Monitoring auf Basis ESP8266 / D1 MINI Microcontroller.
Logischerweise gibt es keinen Befehl, die Batterie anzuschalten, weil sie ja aus ist.
In der Betriebsanleitung steht aber, dass man Pin 4 mit 5-10 Volt (max. 15mA) und Pin 5 kurz mit GND verbindet, um die Batterie aufzuwecken.
Hat jemand Erfahrung damit? Wenn das geht, könnte man die o.a. Konsolenlösung entsprechend erweitern um via GPIO Pin und Optokoppler eine passende Spannung an die Pins 4 und 5 anzulegen.
Hat jemand schon mal so etwas probiert?
Danke, frohe Weihnachten und ein jutes neues Jahr 2024.
Chris
Du kannst die Leistung des HM-600 nicht mit dem Power Limit Befehl auf 0% herunter regeln. Die Mindestleistung für die Einspeisung ist etwa 2%. Zum ausschalten des WR gibt es einen anderen Befehl, der die Einspeisung komplett ausschaltet.
1 „Gefällt mir“
@telekatz: Danke für deine Antwort. Du hast natürlich recht! Und richtig, ich fahre den WR per MQTT mit serial/cmd/power = 0 runter. Hatte ich leider falsch beschrieben.
Trotzdem zieht der WR etwas Saft, openDTU läuft ja auch munter weiter (Status gelb). Um das zu verhindern, würde ich gerne die Batterie abschalten. Den Code von
irekzielinski habe ich schon angepasst. Jetzt muss ich noch die Schaltung erweitern, bevor ich das mache, wollte ich mich vergewissern, dass das Aufwecken per Consolestecker funktioniert. Nicht dass ich hinterher meinen Akku geschrottet habe.Ist schon komisch. Ich sehe das so nicht.
Mal irgendwas gemessen?
Den großen finanziellen Vorteil der Konfiguration sehe ich nicht.
Victron Multiplus II GX 48/3000/35-32 kostet derzeit 580 EUR. Z.B. bei Pandasolar. Wesentlich einfacher einzusetzen. Man braucht kein Huawei R4850G2 und keinen HM1500.
Aber natürlich kann das jeder so machen wie er will.
1 „Gefällt mir“
@wihz Danke fuer den Tipp. In der Tat, es ist ein sehr guter Preis.
Die OpenDTU hat ein paar Vorteile:
-
Sie gibt "Optionen" an Menschen die mit einem Balkonkraftwerk angefangen haben.
-
Man kann einiges installieren, OHNE das der teure Elektriker ins Haus kommen muss.
Bei mir zeigt der mit power=0 abgeschaltete HMS-500 via OpenDTU eine DC-Eingangsleistung von ungefähr 2W an. Nachgemessen habe ich es nicht. Mein Pylontech zeigt in diesem Aus-Modus eine Leerlaufstromentnahme von etwa 100 mA an, also rund 5W. Ich habe auch noch ein Cerbo am Akku hängen, der lebt ja auch nicht nur von Luft und Liebe. Auf 12h wären das mit den 5W also 60Wh, entsprechend etwa 1,2% SOC bei meinem Pylontech US5000. Das wird auch am dunkelsten Schlechtwetter-Wintertag wieder reingeladen, macht mir also keine Sorgen.
Das war preislich im Frühling noch deutlich schlechter. Ich bin aber letzten Endes bei dem Konzept gelandet weil mir der Wirkungsgrad des Multiplus zu schlecht war. Das stehen auch Daten auf dem ersten Seiten dieses Threads.
Für den Multiplus spricht die das das eine Lösung von der Stange ist.
In der Retrospektive habe ich einer Lösung mit einem Multiplus für das AC Laden und Einspeisen sowie einen Victron Solarladeregler für DC Laden zu wenig Beachtung geschenkt. Das hätte man auch berücksichtigen können.
@maltes Hallo, danke für deine Antwort. Gemessen habe ich das noch nicht, da ich nicht vor Ort bin und alles remote mache. So lange das Hoymiles Teil mit DC versorgt wird, ist es aktiv; es wechselt und richtet zwar nicht, hält aber die Funkverbindung zum openDTU aufrecht. So kann man es auch per MQTT wieder aufwecken.
Wie @lars72 schreibt, dürften das so ca. 1,5 bis 2W sein, weil: Grob gerechnet verliert mein Akku pro Tag 1,5%, bei einer Kapazität von ca. 2400Wh sind das ca. 36W/Tag bzw 1,5Wh.
Bei großen Akkus fällt das nicht weiter ins Gewicht, bei meiner relativ kleinen Experimentalanlage schon.
Weiß sonst jemand etwas zu meiner eigentlichen Frage? Hat schon mal jemand den Pylontech Akku remote aufgeweckt, indem er/sie an die Console Pins 4 und 5 kurzzeitig 5-10V Spannung angelegt hat?
Danke
Freundliche Grüße
Chris
Ein schönes neues Jahr allerseits!
Zur Ansteuerung des Huawei-Netzteils mit der OpenDTU-onBattery-Software habe ich ein paar Fragen.
Im Speziellen: Nutzung der Software zum Akku-Laden? Wann sollte SlotDetect schalten? Lebensdauer der CAN-Bus-Online/Offline-Limits?
1.) Ist es vorgesehen bzw. irgendwie möglich, die Software zum kontrollierten (d. h. unter Beachtung der unter 'AC-Ladegerät Einstellungen | Automatische Leistungssteuerung' eingestellten Limits, wie Ladeschlussspannung/-SoC und der maximalen Leistung, sowie des vom BMS gemeldeten aktuellen Ladestromlimits, etc.) Akku-Laden zu verwenden, auch wenn das Powermeter keinen Solarüberschuss meldet?
Nach meinem Verständnis beachtet die 'Automatische Leistungssteuerung' u. a. die o. g. Werte; allerdings nur bei 'Freigabe' durch das Powermeter (Solarüberschuss)?
Gibt es irgendwie die Möglichkeit, z. B. durch Eingabe eines Leistungsoffsets (bezogen auf den Netzbezug), die Software von Solarüberschuss mit eben diesem Wert zu überzeugen, so dass der Akku kontrolliert mit Netzstrom geladen wird?
Aktuell kann ich mit deaktivierter 'Automatischer Leistungssteuerung' 'manuell' laden und den Ladestrom dafür mit den 'Limit-Einstellungen' des Huaweis im 'Live-View' bestimmen. Das Stromlimit ist dann allerdings fix und es wird weder dem 'Wunsch' nach einem niedrigeren Wert (mit steigendem SoC) des BMS angeglichen, noch wird das Laden mit Überschreiten des oberen SoC-Limits beendet.
2.) Ist es richtig, dass die Software das Netzteil per SlotDetect aktiviert, indem der entsprechende GPIO des ESP high geschaltet wird? (Im Eingang eines angeschlossenen Optokopplers fließt dann Strom und der Ausgang schaltet den SlotDetect-Pin des Huawei auf DC-.)
3.) Ist es richtig, dass bei (in den 'AC-Ladegerät Einstellungen') deaktiviertem Netzteil, der unter 2.) genannte GPIO high ist, das Netzteil also weiterhin eingeschaltet bleibt? Jetzt allerdings ohne CAN-Bus-Verbindung zum ESP?
Bei mir ist es nun so, dass das Netzteil, wenn zunächst AC-seitig abgeschaltet, nach AC-seitiger Einschaltung, nach einiger Zeit (~min) beginnt, ohne Stromlimit, in den Akku zu 'ballern', so dass die Huawei-Ausgangstemperatur schnell auf ca. 100°C steigt…
Wäre es hier nicht sicherer, das Netzteil per SlotDetect nur dann einzuschalten, wenn dieses in den Einstellungen auch aktiviert ist?
4.) Sollte ein eingestelltes CAN-Bus-Offline-Stromlimit bei einem AC-seitigen Abschalten erhalten bleiben?
Ich habe den Eindruck, dass dies nicht der Fall ist.
5.) Bei in den Einstellungen aktiviertem Netzteil und deaktivierter Leistungssteuerung schaltet sich das Netzteil bei Eingabe eines CAN-Online-Stromlimits (z. B. 20A) zunächst per SlotDetect aus und nach ca. 1min mit dem eingestellten Strom wieder ein.
Das Netzteil wird allerdings nie wieder per SlotDetect ausgeschaltet. Ich hätte erwartet, dass dies bei Einstellung eines Online-Stromlimits von <1A oder 0A geschieht. Wie ist das bei Euch?
(Das Spannungslimit habe ich bisher nicht bedient.)
6.) Bei in den Einstellungen aktiviertem Netzteil und aktivierter Leistungssteuerung (aber ohne Solarüberschuss, da im Moment noch keine Module angeschlossen sind) ist das Netzteil permanent per SlotDetect eingeschaltet, obwohl es, mangels Solarüberschuss) nicht lädt. Sollte das Netzteil jetzt nicht deaktiviert werden?
7.) Erscheinen bei AC-seitig abgeschaltetem Netzteil geänderte CAN-Online-Stromlimitwerte im 'Ausgangs'-Block des Huawei im Live-View unter 'Maximaler Ausgangsstrom'?
Bei mir ist das nur bei AC-seitiger Verbindung zum Stromnetz der Fall.
Danke für’s Lesen.
Bei mir war der Multiplus eine Evolution der openDTU-OnBattery.
Die HM-300 hängt jetzt an AC-out von Multiplus und laden weiter den Akku, ebenso der MPPT DC-seitig. Den ESP32 mit openDTU kann ich in die Victron-Welt einbinden, ebenso den Shelly 3EM.
Das sind halt alles Ausbaustufen.
1 „Gefällt mir“
Viele Fragen.
Zu 1)
Du kannst manuell laden. Gesteuert wird das dann durch einen anderen Rechner über MQTT. Ich verwende das um die Batterie bei niedrigen Strompreisen zu laden. Link zu der Steuersoftware ist auf der Seite 28.
Über MQTT lässt sich Strom und Spannung einstellen
Es wird ein GPIO Pin geschaltet. Ob der jetzt High oder Low geht habe ich vergessen. 
Würde ich mal messen oder in src/huawei_can.cpp schauen
Wenn das Netzteil in den Einstellungen nicht aktiv ist wird der GPIO Pin nicht initialisiert. Keine Ahnung was dann passiert. Meins bleibt aus. Vermutlich ist aber der Pin auf Input geschaltet und der Pegel ziemlich undefiniert
Nein. Online und Offline limits greifen nur bei verbundenen / nicht verbundenen CAN bus. Das Netzteil verliert diese Werte beim abschalten
- und 6)
Klingt als wäre deine Logik zum Schalten negiert
Da kann ich nichts zu sagen
Kannst du diesen Satz nochmals näher erklären?
@maltes Ich habe die HM-300 an den AC-out Anschluss vom Multiplus angeschlossen, so das die durch den Multiplus über die Frequenz des Netzes gedrosselt werden können. Primär wird der erzeugte Strom direkt als AC verbraucht, nur wenn mehr erzeugt als verbraucht wird läd der Multiplus das in den Akku. Damit vermeide ich Umwandlungs- und Akkuverluste.
Jetzt in der dunklen Zeit lade ich den Akku auch mit einem BlueSmart Ladegerät zusätzlich, das wird über einen Shelly-Plug SOC gesteuert zugeschaltet.
Danke @maltes, dass Du Dich trotz der
dieser angenommen hast.
Ok, das Laden muss ich also über
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.
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.
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
- 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.
- 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.
- 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.
3 „Gefällt mir“
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 ist korrekt und gilt sich für den DPL und das Entladestromlimit glaube ich. Ist noch ein Todo von mir
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
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.
OK, das beantwortet meine Fragen dazu schon. Dann mache ich erstmal mit meiner Umsetzung weiter.
Die MQTT Befehle kannte ich in der Tat noch nicht, danke für den Tip. Die fehlen auch in der Doku auf MQTT Topics - OpenDTU Documentation. 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 Web API - OpenDTU Documentation 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
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: GitHub - hoylabs/OpenDTU-OnBattery: Software for ESP32 to talk to Hoymiles/TSUN/Solenso Inverters, VE.Direct devices, battery management systems, and related peripherals
Im dazugehörigen Wiki finden sich z.B. die MQTT Topics hier: MQTT · hoylabs/OpenDTU-OnBattery Wiki · GitHub
Die Doku zu dem Huawei Lader versteckt sich etwas unter Hardware: Huawei AC PSU · hoylabs/OpenDTU-OnBattery Wiki · GitHub 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.