@garfonso
Hab in den Haupteinstellungen den Wert für "Maximale abzurufende Verlaufsdatenpunkte" von 2000 auf 20000 erhöht.
Das hat mein Problem gelöst in sämtlichen History-Graph-Karten-Diagrammen.
Danke Garfonso für die schnelle Antwort und Lösung des Problems !

@hans_999 said in Test Adapter sun2000 v0.1.x - Huawei Wechselrichter:

Das kann ich nach kurzer Erfahrung mit diesem Speicher nur bestätigen.
Mir fiel nachts der hohe Eigenverbrauch (ca. 100W bis 400W in Peaks) auf. Prüfungen der üblichen Verdächtigen im Haus gaben keine Hinweise.
Dann habe ich bemerkt, dass dieser hohe Verbrauch gegen 0 geht, wenn der Speicher auf dem eingestellten Minimum (momentan 10%) ist und sich die Batterie abschaltet.
Bei momentan ca. 14 h ohne PV-Ertrag kommen da ca. 1,4kWh zusammen (bzw. gehen verloren).

Das ist schon ganz schön frustrierend.

So ist es mir auch ergangen. Am liebsten hätte ich die Anlage zurückgegeben / getauscht gegen einen anderen Hersteller, schließlich wurde geworben mit einem hocheffizienten WR. Ohne Batterie mag das stimmen, aber mit Batterie ist er nicht mehr so hocheffizient.
Und ich wollte eigentlich die maximal mögliche Autarkie erreichen und hatte gedacht, dass das System auch hocheffizient ist, wie beworben. Stellt man nun die Batterie auf min SOC 5 % wie von Huawei empfohlen, hat man dann statt den versprochenen 10 kWh nur 8 kWh Nettokapazität, wenn man eben den Eigenverbrauch beim Entladen dazurechnet. Man könnte es sicher auf einen Rechtsstreit anlegen, wenn man will.
Das Positive ist, dass man hier im Winter durch Steuerung über iobroker/sun2000-Adapter ein deutlich größeres Einsparpotential hat, als bei anderen Systemen, die vom Werk aus hocheffizient sind.

Insofern wäre eine dynamische Steuerung des min. SOC echt eine gute Idee.

Im ersten Schritt die einfachste Lösung. Leider ist der min SOC auf maximal 20% begrenzt. Im tiefen Winter, wenn Mal ein einziger Sonnentag ist (gemäß PV-Prognose), würde ich aber gerne das nächtliche Entladen komplett sperren und das Entladen erst ab einer gewissen Mindestlast am Tag zulassen (z.B. während WW-Bereitung mit Wärmepumpe, während den Heizzeiten mit der Wärmepumpe und abends wenn das Haus beleuchtet ist), so dass der Speicher die komplette Nacht im energiesparenden Ruhemodus ist.
Bei 150W Ausgangsleistung liegt der Umwandlungswirkungsgrad eines weniger effizienten System bei z.B. ca. 65% , bei 500 W schon bei ca. 87% und bei 800 W über 90%.

In nachfolgendem Bild 39 aus dem Speichertest 2024 der HTW Berlin sieht man, dass die Umwandlungsverluste bei System K1 den größten Anteil ausmachen. Aber auch die Bereitschaftsverluste kosten bei System K1 ca. 2,9% der Systemeffizienz. Wenn man jetzt also die Entladezeiten verkürzen würde, müssten m.E. auch die Bereitschaftsverluste reduziert werden. Man würde also mit den oben genannten Optimierungsmaßnahmen sowohl die Umwandlungsverluste, als auch die Bereitschaftsverluste reduzieren.
Im Sommer (und in großen Teilen der Übergangszeit bei mir) sind die PV-Erträge so groß, dass der Speicher die ganze Nacht ausreicht. Da kann man dann nichts optimieren, zumindest nicht, wenn man nicht die einzelnen Akkupacks (in meinem Fall 10kWh-Speicher Akkupack1 und Akkupack 2) separat steuern könnte, so dass nachts immer nur ein Akku entlädt. Damit könnte Huawei die Batterieeffizienz deutlich verbessern, aber dies liegt dann an Huawei, ein solches Firmware-Update zu entwickeln.

@bolliy
Ich muss kurz ausholen. Leider ist der Luna2000 sehr ineffizient
(sinkende-ertragswerte-bei-huawei-wr-nach-sonnenuntergang , evtl. entspricht das Huawei-System dem System K1 (zumindest die Lade-/Entladeleistung und Speicherkapazität stimmen überein) in der HTW-Stromspeicher-Inspektion-2024 .
Ich habe nachts bei geringem Hausverbrauch ca. 150 bis 250W ca. 110 bis 130 W Eigenverbrauch der 10kWh-Batterie (über den sinkenden Tages-PV-Ertrag berechnet).
Diese hohen Effizienzverluste sind gerade in den Wintermonaten prozentual sehr groß und hier geht es um einen zu großen, teuren Netzbezug (gegenüber zu geringerer Netzeinspeisung im Sommer).
Deswegen möchte ich sie durch eine bessere automatisierte Steuerung mit dem ioBroker/javascript/Adapter sun2000 optimieren. Dazu fallen mir theoretisch drei Möglichkeiten ein:

1. Steuerung des min SOC
   abends um ca. 22:00 Uhr den SOC z.B. auf 20% setzen, so dass bei geringem Hausverbrauch nicht mehr entladen wird und das System in den Ruhemodus geht.
   Morgens um ca. 06:30, wenn wir aufstehen, min SOC auf 5% runter, so dass die Batterie bei etwas höherem Hausverbrauch effizienter entlädt, als das nachts der Fall wäre.
2. Steuerung über Arbeitsmodus (Adresse 47086)
   Tagsüber: Max Eigenverbrauch (also Laden- und Entladen) bzw. zu Zeiten mit hohem Hausverbrauch Max. Eigenverbrauch und in den Abwesenheitszeiten (morgens), wo die Wärmepumpe aus ist, TOU-Modus (Zeitperioden Adresse 47083 ?) nur Laden
   Abends nach Sonnenuntergang und morgens beim Frühstück bis vor Sonnenaufgang: TOU-Modus Entladen
   Nachts: TOU-Modus ohne Zeitintervall (ich hoffe die Anlage geht dann auch in den Ruhemodus ?)
3. Steuerung über maximale Lade-/Entladeleistung
   Hat schon Mal jemand ausprobiert, ob der Wechselrichtung z.B. bei SOC 50 % und Entladeleistung = 0 nachts in den Ruhemodus geht ?

Es wäre also schön, wenn man neben dem min SOC auch noch den Arbeitsmodus (Adresse 47086) (max. Eigenverbrauch oder TOU) und für den Modus TOU die Zeitperioden mit Festlegung von Zeiten von-bis und Laden/Entladen (Adresse 47083 ?) lesen und schreiben könnte. Dann wäre man wirklich flexibel.

VG
Besimo

@bolliy
Ja, mit dem minSOC 20% kann man teilweise den Ruhemodus erzwingen bzw. dafür sorgen, dass er nach Sonnenuntergang etwas früher beginnt.
Mit Sonnenaufgang und dem Start des Inverters ist es aber vorbei mit dem Ruhemodus (im Test hatte ich die maximale Ladeleistung auf 0 begrenzt).
Und ich würde gerne etwas mehr Restkapazität im Winter im Akku haben, das ist besser für die Lebensdauer.

Die Ladezeit im tiefen Winter würde ich z.B. auf die Zeit von 9:00 bis 15:00 Uhr, also 6 Stunden begrenzen evtl. variabel je nach PV-Prognose). Entladen will ich, abhängig von der PV-Prognose und Speicherfüllstand nur bei großer Entladeleistung (z.B. Warmwasserbereitung Wärmepumpe oder große Heizlast Wärmepumpe), da die Grundlast der Luna2000 bei mir auch bei geringer Entladeleistung mehr als 100W/h beträgt. Die restlichen 14 bis 16 Stunden soll die Luna dann im Ruhezustand schlummern.

Ich bin mir jetzt nicht sicher, ob der Ruhemodus nur möglich ist, während der Inverter im Standby ist.

Jedenfalls wenn ich die maximale Ladeleistung auf null setze, wird der 10kWh-Speicher mit 200 W/h trotzdem weiter geladen (jeder Akku etwa mit 100W/h - in FS unter ESU erkennbar.

Hier Mal meine Ergebnisse der heutigen Experimente mit der max. Ladeleistung 0 W/h und mit TOU-Einstellungen (mittags habe ich die max. Ladeleistung auf mindestens 1000 W/h gesetzt, damit die AC-Leistung um die DC-Ladeleistung sinkt und somit die Grenze für PV-DC-Eingang von 11000 auf ca. 12000 angehoben wird und auch die Innentemperatur des Inverter geringer ist)

@bolliy
Ich habe gerade auf github ein Issue erstellt mit "Batterypack-Daten ergänzen". Da gibt es doch einige Adressen in den Modbus-Definitions. Damit könnte man die einzelnen Batteriepacks ganz gut überwachen (allerdings nicht die einzelnen Zellen). Ich habe so den Verdacht, dass bei mir einer der beiden Akkus nicht ok oder nicht richtig ausbalanciert ist.

Was den Ruhemodus angeht, habe ich diesen letzte Nacht Mal durch Entladen auf min SOC erzwungen.

Morgens um kurz nach 5, als der Inverter angesprungen ist, ist auch der Speicher aufgewacht, obwohl ich die maximale Ladeleistung auf 0 gesetzt hatte.

D.h. Ich kann durch Setzen der maximalen Ladeleistung auf 0 den Ruhemodus nicht über die Nacht hinaus verlängern (wäre interessant im Winter) und schon gar nicht erzwingen.
Hat jemand Erfahrung damit, wie man den energiesparenden Ruhemodus erzwingen kann - z.B. über TOU ?
Mein Plan ist, die Betriebszeit des Speichers im tiefen Winter auf ein Minimum zu reduzieren, um den hohen Eigenverbrauch des Luna zu reduzieren.

Und was das reduzieren der maximalen Ladeleistung auf 0 angeht, hat da jemand eine Erklärung, warum dennoch eine Ladeleistung angezeigt wird in FusionSolar bei den Akkus und warum der SOC hochgeht (wenn auch langsam) ?

@bolliy
Kurze Frage
Kann es sein, dass bereits bei Input Power die WR-Verluste enthalten sind ?

Wenn ich die Werte von String - PV1Current und PV2Current addiere komme ich auf größere Werte, als bei Input Power.
Die Differenz könnte den WR-Verlusten entsprechen, da die Differenz etwa gleich ist (hier im Beispiel 4,717-4,61 = 107Watt und 4,61-4,518=92Watt ?

(Meine Vermutung ist, dass die Differenz der Fusionsolar-Ertragswerte und dem Wert für InputPower der Eigenverbrauch der Luna2000-Batterie ist - Thema sinkender PV-Ertrag)

@hans_999 said in Test Adapter sun2000 v0.1.x - Huawei Wechselrichter:

Das kann ich nach kurzer Erfahrung mit diesem Speicher nur bestätigen.
Mir fiel nachts der hohe Eigenverbrauch (ca. 100W bis 400W in Peaks) auf. Prüfungen der üblichen Verdächtigen im Haus gaben keine Hinweise.
Dann habe ich bemerkt, dass dieser hohe Verbrauch gegen 0 geht, wenn der Speicher auf dem eingestellten Minimum (momentan 10%) ist und sich die Batterie abschaltet.
Bei momentan ca. 14 h ohne PV-Ertrag kommen da ca. 1,4kWh zusammen (bzw. gehen verloren).

Das ist schon ganz schön frustrierend.

So ist es mir auch ergangen. Am liebsten hätte ich die Anlage zurückgegeben / getauscht gegen einen anderen Hersteller, schließlich wurde geworben mit einem hocheffizienten WR. Ohne Batterie mag das stimmen, aber mit Batterie ist er nicht mehr so hocheffizient.
Und ich wollte eigentlich die maximal mögliche Autarkie erreichen und hatte gedacht, dass das System auch hocheffizient ist, wie beworben. Stellt man nun die Batterie auf min SOC 5 % wie von Huawei empfohlen, hat man dann statt den versprochenen 10 kWh nur 8 kWh Nettokapazität, wenn man eben den Eigenverbrauch beim Entladen dazurechnet. Man könnte es sicher auf einen Rechtsstreit anlegen, wenn man will.
Das Positive ist, dass man hier im Winter durch Steuerung über iobroker/sun2000-Adapter ein deutlich größeres Einsparpotential hat, als bei anderen Systemen, die vom Werk aus hocheffizient sind.

Insofern wäre eine dynamische Steuerung des min. SOC echt eine gute Idee.

Im ersten Schritt die einfachste Lösung. Leider ist der min SOC auf maximal 20% begrenzt. Im tiefen Winter, wenn Mal ein einziger Sonnentag ist (gemäß PV-Prognose), würde ich aber gerne das nächtliche Entladen komplett sperren und das Entladen erst ab einer gewissen Mindestlast am Tag zulassen (z.B. während WW-Bereitung mit Wärmepumpe, während den Heizzeiten mit der Wärmepumpe und abends wenn das Haus beleuchtet ist), so dass der Speicher die komplette Nacht im energiesparenden Ruhemodus ist.
Bei 150W Ausgangsleistung liegt der Umwandlungswirkungsgrad eines weniger effizienten System bei z.B. ca. 65% , bei 500 W schon bei ca. 87% und bei 800 W über 90%.

In nachfolgendem Bild 39 aus dem Speichertest 2024 der HTW Berlin sieht man, dass die Umwandlungsverluste bei System K1 den größten Anteil ausmachen. Aber auch die Bereitschaftsverluste kosten bei System K1 ca. 2,9% der Systemeffizienz. Wenn man jetzt also die Entladezeiten verkürzen würde, müssten m.E. auch die Bereitschaftsverluste reduziert werden. Man würde also mit den oben genannten Optimierungsmaßnahmen sowohl die Umwandlungsverluste, als auch die Bereitschaftsverluste reduzieren.
Im Sommer (und in großen Teilen der Übergangszeit bei mir) sind die PV-Erträge so groß, dass der Speicher die ganze Nacht ausreicht. Da kann man dann nichts optimieren, zumindest nicht, wenn man nicht die einzelnen Akkupacks (in meinem Fall 10kWh-Speicher Akkupack1 und Akkupack 2) separat steuern könnte, so dass nachts immer nur ein Akku entlädt. Damit könnte Huawei die Batterieeffizienz deutlich verbessern, aber dies liegt dann an Huawei, ein solches Firmware-Update zu entwickeln.

@bolliy
Ich muss kurz ausholen. Leider ist der Luna2000 sehr ineffizient
(sinkende-ertragswerte-bei-huawei-wr-nach-sonnenuntergang , evtl. entspricht das Huawei-System dem System K1 (zumindest die Lade-/Entladeleistung und Speicherkapazität stimmen überein) in der HTW-Stromspeicher-Inspektion-2024 .
Ich habe nachts bei geringem Hausverbrauch ca. 150 bis 250W ca. 110 bis 130 W Eigenverbrauch der 10kWh-Batterie (über den sinkenden Tages-PV-Ertrag berechnet).
Diese hohen Effizienzverluste sind gerade in den Wintermonaten prozentual sehr groß und hier geht es um einen zu großen, teuren Netzbezug (gegenüber zu geringerer Netzeinspeisung im Sommer).
Deswegen möchte ich sie durch eine bessere automatisierte Steuerung mit dem ioBroker/javascript/Adapter sun2000 optimieren. Dazu fallen mir theoretisch drei Möglichkeiten ein:

1. Steuerung des min SOC
   abends um ca. 22:00 Uhr den SOC z.B. auf 20% setzen, so dass bei geringem Hausverbrauch nicht mehr entladen wird und das System in den Ruhemodus geht.
   Morgens um ca. 06:30, wenn wir aufstehen, min SOC auf 5% runter, so dass die Batterie bei etwas höherem Hausverbrauch effizienter entlädt, als das nachts der Fall wäre.
2. Steuerung über Arbeitsmodus (Adresse 47086)
   Tagsüber: Max Eigenverbrauch (also Laden- und Entladen) bzw. zu Zeiten mit hohem Hausverbrauch Max. Eigenverbrauch und in den Abwesenheitszeiten (morgens), wo die Wärmepumpe aus ist, TOU-Modus (Zeitperioden Adresse 47083 ?) nur Laden
   Abends nach Sonnenuntergang und morgens beim Frühstück bis vor Sonnenaufgang: TOU-Modus Entladen
   Nachts: TOU-Modus ohne Zeitintervall (ich hoffe die Anlage geht dann auch in den Ruhemodus ?)
3. Steuerung über maximale Lade-/Entladeleistung
   Hat schon Mal jemand ausprobiert, ob der Wechselrichtung z.B. bei SOC 50 % und Entladeleistung = 0 nachts in den Ruhemodus geht ?

Es wäre also schön, wenn man neben dem min SOC auch noch den Arbeitsmodus (Adresse 47086) (max. Eigenverbrauch oder TOU) und für den Modus TOU die Zeitperioden mit Festlegung von Zeiten von-bis und Laden/Entladen (Adresse 47083 ?) lesen und schreiben könnte. Dann wäre man wirklich flexibel.

VG
Besimo

@xbit
nicht auszuschließen, dass ich mich vertippt habe, aber ich weiß es nicht.
Und bei mir stürzt die Instanz ja schon beim Start ab.

Ich glaube langsam wirklich, dass ich eine neue Lovelace-Instanz erstellen muss. Wenigstens hatte ich mir den Stand vor dem Update der node.js-Version gesichert. Jetzt muss ich halt hoffen, dass ich das neue Dashboard für die PV-Anlage, den Tuya-Adapter, den Shelly-Adapter und die Änderung auf Unteransichten wieder so hinbekomme, wie ich es hatte.

Ich wollte jetzt auch Mal testweise eine Lovelace.0-Instanz erstellen (0 war die alte, zwischenzeitlich gelöschte Instanz). Das hat leider nicht geklappt. Es ist nichts passiert

Gibt es eine Möglichkeit, per javascript die bisherigen Zuweisungen der Datenpunkte zur Lovelace.1-Instanz auf Lovelace.2 zu kopieren ?

@besimo

Fehler ist "instance system.adapter.lovelace.1 terminated with code 6 (UNCAUGHT_EXCEPTION)"

@xbit said in Test lovelace 4.x:

ich gebe dir völlig Recht, dass es vieles einfacher macht wenn man an die yaml Datei kommen würde ich glaube aber (da ich auch schon mal gefragt hatte) @Garfonso hat gesagt die Datei liegt nicht plain wie im HA vor. (oder so in der Art).

Danke für die Info.
Habe jetzt die Auto-Entities-Karte gelöscht. Leider geht die Instanz immer noch auf rot.
Eine Sicherung liegt lange zurück - Ganz schön viele Stunden Arbeit sind jetzt einfach weg

Zu dem Thema Instanz, wenn die .0 oder .1 (wie auch immer) nicht mehr geht und du hast ein Backup vom RAW Editor weiß ich nicht warum man alle Datenpunkte an eine neue Instanz (z.B. .2) binden sollte alte Instanz löschen neue hinzufügen, Code und Cards etc. rein fertig.

Danke auch für den Tipp. Ich werde jetzt noch eine Weile warten, bevor ich diese Instanz lösche und meine Arbeit der letzten vier Wochen endgültig weg ist.
Vielleicht gibt es ja doch noch einen Tipp, wie ich die Instanz zum starten bekommen kann ?

@pi-ter said in Test lovelace 4.x:

Vielleicht liege ich falsch und verstehe das Problem nicht. Aber:
Wieso sollte man etwas nachträglich sichern, wenn es durch Fehler zum Absturz kam?

z.B. wenn man den Fehler nicht findet, kann man die ganzen anderen Dashboards, an denen man nichts verändert hat, in einer neuen Lovelace-Instanz wieder verwenden. Außerdem hätte man die Chance, den Fehler zu suchen im Yaml-Code und wenn man Glück hat und den Fehler findet hat man so den geringsten Aufwand.

Ich kopiere mir vor jeder größeren Änderung an Lovelace über der Editor den yaml-code und sichere ihn.
Ausserdem in regelmäßigen Abständen auch bei kleineren, unkritischen Änderungen.

Da bin ich leider nicht so konsequent wie du. Bei meinem 1. Crash hatte ich eine Sicherung gemacht, jetzt eben gerade nicht, da das mitten in der Experimentierphase passiert ist und noch nichts abschliessend fertig war, wobei ich schon relativ viel neues gemacht hatte.

Wenn lovelace erst abgestürzt ist, weil es einen Fehler im Code gab, muss man m.E. nichts mehr sichern. Da wäre der Fehler ja im Code drin. Wozu den dann als BackUp nutzen?

Wenn der Adapter auf eine Textdatei zugreifen würde, könnte man diese in einem Texteditor öffnen, z.B. die zwei neuen Karten löschen und den Adapter erfolgreich neu starten. Das wäre jetzt der geringste Aufwand.

Also Vorbeugen ist aus meiner Sicht besser, als nach hinten fallen

Ja, ist aber jetzt zu spät und jeden Tag manuell sichern, da fehlt mir die Zeit.
Darf man denn nicht mehr aufstehen, wenn man Mal hingefallen ist ?
Ich bin nicht perfekt und werde es nie sein.

@xbit

Das löschen der auto-entities-card mag hier die Lösung sein.

Mich würde aber trotzdem interessieren, ob es nicht den anderen universellen Weg auch gibt über den yaml-code in der Datei, auf die der raw-editor zugreift. Das wäre dann ein universeller Weg, der immer gehen würde und man könnte nachträglich seine yaml-codes sichern.

Garfonso, der Entwickler des Lovelace-Adapters, weiß das bestimmt, wo diese Datei liegt und wie sie heisst.

Ich habe bereits meine 2te Lovelace-Instanz, weil mir schon Mal meine erste Lovelace-Instanz gecrashed ist. Da wusste ich nicht genau, wo der Fehler lag und da hätte ich nicht einfach eine Custom-Card löschen können.

Ich bin auch sehr verunsichert, weil das ja immer wieder passieren könnte, dass man in einer Karte eine Fehleingabe macht und dann die Lovelace-Instanz abstürzt. Wenn man dann keine Möglichkeit hat, den fehlerhaften yaml-Code zu korrigieren, dann müsste ich mir ernsthaft Gedanken machen, ob ich mein Smart-Home mit WP, PV-Anlage, Hausverbrauch und Gartenbewässerung mit einer einzigen Lovelace-Instanz mache.
Ich hatte beim ersten Crash schon einen riesigen Aufwand, eine neue Lovelace-Instanz zu erstellen und alles so wiederherzustellen, wie vorher, obwohl ich den Yaml-Code im Raw-Editor erst kurz vor dem Crash gesichert hatte und zu dem Zeitpunkt nur die WP eingebunden war, Ich musste bei sovielen Datenpunkten die neue Lovelace-Instanz zuweisen.

Also Frage an Garfonso (und an jeden, der die Antwort weiß) - Gibt es nach wiederholtem Absturz einer Lovelace-Instanz die Möglichkeit, den yaml-code aus dem Raw-Editor für die gesamte Lovelace-Instanz zu kopieren / sichern / editieren und falls ja, wie ?

VG
besimo