Closed fu-zhou closed 3 years ago
You mean what I get as a "common" response from the inverter should I write in a "common" channel and what I get as "home" in a home channel. The "Common" also contains data which are contained in the "Home".
Benefits: The program is simpler. Transparency is given when what is updated
Disadvantage: Data points with the same information are available several times
Did I get it right?
schnell auf deutsch, können wir dann ja wieder löschen:
In der Adapterkonfiguration kann man 2 Zeiten einstellen (was auch gut so ist): 1x common, 1x home. "common" und "home" findet man aber nicht in den Objekten, d.h. man weiß nicht, welche Objekte zu "common" und zu "home" gehören und welche Update-Zeiten damit je Objekt zur Anwendung kommen. Ja, es gibt Redundanzen zwischen den "common"- und "home"-Datenpunkten im Wechselrichter, dafür hat LG die Verantwortung, das sollte nicht der Adapter ausbügeln, oder was meinst du? Ich habe auch festgestellt, dass LG die Datenpunkte bei dem einen oder anderen Firmware-Update leicht verändert, es kommen mal 1-2 dazu oder verschwinden wieder. Das soll der Adapter ja auch automatisch abfangen können, oder? Ggf. muss man einen Datenpunkt in den iobroker-Objekten dann manuell löschen (weil er seit Wochen nicht aktualisiert wurde und demnach nicht mehr im Wechselrichter existiert. Das hatte ich im Frühjahr/ Sommer schon einmal). Unter MQTT sieht der Objektbaum so aus: Das entspricht wohl 1:1 der Struktur, wie sie aus dem Wechselrichter gelesen wird. Ich finde das eigentlich ganz übersichtlich...
Übrigens sind jetzt alle Datenpunkte aktualisiert worden, die Aussage aus Post#1 ist damit überholt.
was ich gut finde: Die Umrechnung in kW bzw kWh im Adapter und die Einheiten in den Messwerten...
Danke für die Rückmeldung. Je mehr ich darüber Nachdenke um so mehr komm ich auch auf die Lösung das ich die Struktur generisch erstelle. Ich mach mich an die Arbeit, sobald ich was habe melde ich mich.
was ich gut finde: Die Umrechnung in kW bzw kWh im Adapter und die Einheiten in den Messwerten...
also natürlich neben der Existenz des Adapters ;-)
Mir ist gerade noch was aufgefallen: lg-ess-home.0 - load - today_load_consumption_sum zeigt "0" an, müsste aber "20.164" sein. 20.164 taucht beim Aktualisieren (alle 60 Sek) ganz kurz auf und springt dann wieder auf 0. Oben im Bild sind die skalierten und mit Einheiten versehenen Werte von deinem LG-ESS-Adapter, unten die unskalierten Werte von MQTT,
Ich habe den Adapter nochmals komplett überarbeitet. Am besten vorher alle Datenpunkte löschen. Die Struktur ist jetzt komplett geändert.
Wirklich beeindruckend, vielen Dank! Für mich ergeben sich noch folgende Fragen:
Wie funktioniert das mit den Commands bzw. mit deren zyklischer Aktualisierung? Ich kann den Lademodus ändern (z.B. von 1 nach 2) und in der Enervu App auch sehen, dass der Modus geändert wurde (ohne, wie in der App verriegelt, zuerst das System zu stoppen = echt gut). Bestätigt wird die Änderung im Adapter aber nicht und das Objekt ist dann rot, nicht grün, wie die anderen nach zyklischem Update, was etwas irritiert: Beim Backup- und Wintermode wurde bei mir zunächst der Status nicht angezeigt, kann aber bedient werden, schaltet in der App auch um, zeigt nach erstmaligem Bedienen den Status an, bleibt aber dann auch "rot".
Warum hast du dich dafür entschieden, noch die Ebene "user" einzuführen? Auf den ersten Blick könnte "essinfo" und "setting" ohne "user" direkt unter "lg-ess-home" hängen. "setting" würde ich evtl. zu "settings" (Plural) machen. Für "info" gibt es im Englischen keinen Plural, daher passt aus meiner Sicht "essinfo".
"common" und "home" sind ja nur unter "essinfo". In welchem Zyklus wird "setting" aktualisiert/ gelesen? In den letzten 85 Minuten ist nichts passiert:
Die Leistungen gibst du in W(att) an, aus meiner Sicht wären hier auch k(ilo)W(att) sinnvoll, was meinst du? Das sind alle Objekte, die auf "_power" enden, z.B.: lg-ess-home.0.user.essinfo.common.LOAD.load_power lg-ess-home.0.user.essinfo.common.PV.pv1_power Ich habe insgesamt 16 Objekte gezählt, die auf _power enden und in W(att) angegeben sind.
Ab und zu werden Werte, die irgendwo weit hinten im Nachkommabereich >0 haben sehr umfangreich dargestellt. Lässt sich das abfangen/ runden?
Zum Thema Objekte/ Zustand aktualisieren noch mal: Es sieht danach aus, dass der Zeitstempel immer der letzten Änderung entspricht, daher kommt auch meine Frage, in welchem Zyklus "setting" aktualisiert wird. Hier verändert sich nichts an den Objekt-Werten, außer man bekommt eine neue Firmware oder ändert die IP-Adresse => der Zeitstempel ändert sich im Moment nicht.
Unter "home" bleibt der Zeitstempel auch immer gleich, wenn sich der Wert nicht ändert. Eigentlich müsste hier bei sich nicht änderndem Wert der Zeitstempel aktualisiert werden (abhängig vom eingestellten "Update Intervall"), die letzte Änderung bleibt aber, bis sich der Wert geändert hat. Im Moment sieht das Ganze so aus (Zeitstempel=letzte Änderung): Sollte für mein Verständnis aber so aussehen (Zeitstempel ist abhängig vom Update Intervall, letzte Änderung zeigt die letzte Änderung des Wertes an. Hat sich der Wert innerhalb des Update Intervalls geändert, ist Zeitstempel natürlich gleich letzte Änderung):
Jetzt habe ich es verstanden. Ich schreibe die Werte nur bei Änderungen in den Adapter. Das habe ich gemacht da sich die Kommandos sonst bei sehr kurzen Änderungs Intervall fast nicht bedienen lassen. Home und Common wird im eingestellt Intervall abgefragt, und nur wenn sich Werte ändern in den Adapter geschrieben. Settings werden alle 15 Minuten angefragt. Soll ich immer schreiben, und nur bei den Kommandos bei Änderungen?
Soll ich immer schreiben, und nur bei den Kommandos bei Änderungen?
Wäre für mich irgendwie logisch, aber ich kann nicht abschätzen, wie hoch dann die Last auf das System ist/ wird. Ich probiere das aber gerne bei mir aus.
Hast du schon eine Meinung zu "user" und "kW" vs."W"?
Die Kommandos werden mittels der Abfragen aktualisiert. backup_status => BackupMode, winter_status => WinterMode, operation.status => Operation. Nur für den Lademodus gibt es leider kein Datum in der Common oder Home Struktur. => diese wird dann leider nur alle 15 Minuten mittels dem Settings update aktualisiert. Das mit dem bestätigen muss ich mir noch ansehen, was ich da machen muss damit das grün wird.
Der Aufbau der Struktur entspricht jetzt der Antwort des Wechselrichters. Das heißt z.B. die Antwort für die Settings des Batterie kommen von /v1/user/setting/batt.... Das v1 habe ich heraus gefiltert und den Rest einfach generisch aufgebaut. User habe ich drin gelassen da ich auch auf die Installateur Einstellungen hinkomme, und die sind dann z.B /v1/installer/setting/batt. (Kommt dann später hinzu)
W stelle ich noch auf KW um, die habe ich übersehen.
Probiere mal bitte die Version 0.0.4. Das runden habe ich übersehen, kommt mit der nächsten Version.
Ah, jetzt habe ich "user" auch kapiert und "setting". Ja, da sollte man wirklich nichts ändern und die Antwort des Wechselrichters 1:1 übernehmen, das Thema hatten wir ja schon. LG hat da so einige Buchstabendreher etc. drin... 0.0.4 läuft und Zeitstempel/ letzte Änderung entspricht jetzt meinem "Geschmack". Ich bin schon auf die nächste Version gespannt - kein Druck!
Dass der Lademodus umgestellt werden kann, ist echt der Knaller. Damit kann ich per script im Winter Schnellladen einstellen, da kommt sowieso kaum was vom Dach und das muss dann nicht noch z.T. ins Netz gespeist werden, nur dass ich es später wieder teuer kaufen darf, anstatt Kapazität in der Batterie zu haben. Das ist mir mit Wettervorhersage nämlich in den letzten Wochen passiert, so dass ich wieder auf Schnellladen umgestiegen bin. Wenn "Winter" dann vorbei ist, gehe ich wieder auf Schonladung bzw. Wettervorhersage, mal sehen, was am sinnvollsten ist. Bei Wettervorhersage hänge ich halt am Internet und kriege Firmware drauf, ohne dass ich es weiß oder bestätigen kann, vom fehlenden Changelog mal ganz abgesehen...
Ich bin am experimentieren mit den Lademodis. Ich habe eine reine Ostanlage und bei mir ist im Sommer der Akku bereits voll wenn die Lademodi greifen sollten. => Meine Idee ist wenn Solcast(API für PV Ertrag) einen hohen PV Ertrag Vorher sagt, den Akku morgens abzuschalten und eben dann später erst hinzu zu schalten, damit ich der 70% Regelung etwas entgehen kann. Ich glaube nicht mehr daran das LG funktionierende Lademodi hinbekommt.
Ach ja W ist auch bereits auf KW umgestellt. Musst nur die Datenpunkte nochmals löschen. Sobald diese neu angelegt werden sollten diese jetzt in KW sein. Das bestätigen der Kommandos sollte jetzt auch klappen.
Ich hatte den Adapter gelöscht, damit werden die Datenpunkte entfernt und komplett neu installiert. Ich habe jetzt einen Mix aus W und kW, z.B. sind die Stringleistungen in kW und Load Power in W:
Hat sich erledigt, habe nochmal komplett installiert - jetzt alles kW
Ich würde gerne die Lade- und Entladeleistung der Batterie begrenzen. Die Parameter gibt es nach meiner Interpretation für den Installateur in der Enervu-App zwar, sind aber nicht bedienbar. Die Frage ist, ob das durch die App verriegelt ist, wie beim Lademodus gegen den Betriebsmodus, oder in der Wechselrichter-Firmware aus Sicherheitsgründen. Lt. LG-Service ist die Entladeleistung nicht parametrierbar, ich würde sie gerne auf 3-4 kW beschränken. Bzgl. Installateur-Einstellungen: kriegst du die so raus, oder muss in der Adapterkonfiguration das Installateur-Passwort eingegeben werden? Noch was zum Betrieb der Anlage: Bei mir fängt die Batterie erst zu laden an, wenn ca. 250 Watt Überschuss vom Dach zur Verfügung steht. Drunter wird die (zugegeben kleine) Leistung ins Netz eingespeist. Ist das bei dir auch so? Dann beobachte ich zur Zeit, in der die Batterie eher leer als (teil-)geladen ist, dass sie immer wieder mal bei Ladestand 0% für 4 Minuten mit 4 kW aus dem Netz geladen wird. Kannst du das auch beobachten? Ich schreibe sämtliche Parameter aus home und common mit und wenn man sich die Charts anschaut, fällt das auf. Der Ausschnitt ist über 3 Tage:
Die Lade- bzw. Entlade Maximalleitung kann ich lesen, aber nicht schreiben. Für die Installateur Werte brauche ich das Installateur Passwort, wird wohl eine separate Optionale Eingabe im Admin geben. Das System speist bei mir auch erst ab einen gewissen Überschuss in den Akku, ich denke vorher ist es wegen den Umwandlungsverlusten nicht rentabel. Diese kurzen Ladungen aus dem Netz sind "Notfall Ladungen". Die kommen immer wenn der SOC zu weit abfällt.
The polling intervall for "common" and "home" can be set, but in the objects the categories are missing, i.e. you don't know which datapoints are updated in which interval: Maybe an additional layer "common", "home", "system" can be introduced with the names reflected in the "Adapterkonfiguration".
What I also figured out is that some datapoints are not being updated at all, e.g. battery - charging (4 lines at the bottom): or the entire network: