Leistungsprognose für Wechselrichter

Begonnen von ch.eick, 18 Januar 2021, 08:35:46

Vorheriges Thema - Nächstes Thema

DS_Starter

Ich hatte schon eine Wiki-Seite begonnen:

https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung

Wenn du magst, hinterlege dort gerne dein Beispiel. Hier geht das Know How vielleicht schnell verloren.
Die Seite baue ich weiter aus wenn es regnet.  ;)

LG
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

der-Lolo

Hallo Heiko,
ich frage mich derzeit ob die Werte die ich beim einrichten zu berechnung genommen habe die richtigen sind -
Das Huawei System hat einen Hochvolt-Speicher, bei der darstellung mit den Balken funktioniert das meiner Meinung nach nicht richtig.
So entsteht ein ziemliches durcheinander bei den Beams ;)

Der Wechselrichter hat auch ein reading "WR_Eingangsleistung_Solar_W" vielleicht wäre es besser dieses zu benutzen.

Den Consumer Wärmepumpe habe ich auch immer noch nicht zufriedenstellend integriert. Ich würde eben auch gerne sehen wieviel Watt fürs heizen benutzt werden. Grundsätzlich würde ich das auch gerne bei Waschmaschine, Trockner und Spülmaschine machen.

Ich würde mich riesig über Beispiele freuen...

Gestern zeigte die Prognose für vorgestern eine Abweichung von -3% - fand ich klasse.

300P

Zitat von: DS_Starter am 11 April 2023, 16:02:28Ich hatte schon eine Wiki-Seite begonnen:

https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung

Wenn du magst, hinterlege dort gerne dein Beispiel. Hier geht das Know How vielleicht schnell verloren.
Die Seite baue ich weiter aus wenn es regnet.  ;)

LG


Ist erstmal jetzt erledigt  :)

Gruß
300P
Gruß
300P

FHEM 6.4|RPi|SMAEM|SMAInverter|SolarForecast|DbLog|DbRep|MariaDB|Buderus-MQTT_EMS|
Fritzbox|fhempy|JsonMod|HTTPMOD|Modbus ser+TCP|ESP32-Digitizer-AI_on_the_Edge|ESP32CAM usw.

DS_Starter

Guten Morgen,

Zitatich frage mich derzeit ob die Werte die ich beim einrichten zu berechnung genommen habe die richtigen sind -
Das Huawei System hat einen Hochvolt-Speicher, bei der darstellung mit den Balken funktioniert das meiner Meinung nach nicht richtig.
So entsteht ein ziemliches durcheinander bei den Beams

Die Frage lässt sich natürlich nicht so einfach beantworten. Dazu muss man sich deine Anlage genau anschauen und verstehen was wie zusammenspielt um diese Beziehungen in den Parametern/Schlüsseln des Moduls abzubilden.
Ich bemühe mich das Wiki zügig weiterzutreiben und mit Leben zu füllen. Hier das machen zu wollen würde den Rahmen sprengen. Konkrete Fragen kann man natürlich hier konkret beantworten.  ;)

ZitatDen Consumer Wärmepumpe habe ich auch immer noch nicht zufriedenstellend integriert. Ich würde eben auch gerne sehen wieviel Watt fürs heizen benutzt werden. Grundsätzlich würde ich das auch gerne bei Waschmaschine, Trockner und Spülmaschine machen.
Bei mir habe ich vor allen mich interessierenden Geräten Shellies installiert. Die lasse ich durch das Modul schalten wenn ich will oder registriere sie nur ohne Schaltfunktion um deren Energiewerte aufzunehmen und in die Verbrauchsgrafik zu integrieren.

LG
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

der-Lolo

#2359
Kannst Du mir mal eine Beispielkonfiguration eines Shellys zeigen? Sowohl im Device selbst als auch im ForeCast?
Ich habe eben einen Shelly an der Spülmaschine zwischengesteckt - die Spülmaschine zieht maax 2000W das geht sich also auf.

Bei den Waschmaschinen würde ich eher auf "alte" vorhandene Messteckdosen von HomeMatic setzen - die können bis 3,5kW
Falls jemand schon eine HM-ES-PMSw1-Pl im Einsatz mit dem Modul hat würde ich mich auch über eine Beispiel konfiguration freuen.

Welche Attribute werden gebraucht um die Meß-Steckdosen im Forcast zu integrieren? 

Bei den Beams bin ich mir noch nicht schlüssig wie ich die sinnvoll integriere - ich bin mit dem
currentInverterDev Sun2000 pv=WR_Eingangsleistung_Solar_W:W etotal=WR_Gesamtertrag_kWh:kWh capacity=8800
schon auf der Solaren-Eingangsleistung, wenn ich als Beam Content PVreal wähle - wird dann stündlich der Gesamtertrag genommen, oder die Eingangsleistung?

Ich hatte letzte Woche einen Tag an dem die Prognose für die angeschaute Stunde bei etwa 3000Wh lag, PVReal war dann bei 900Wh - es wurde aber der Überschuss komplett in die Batterie geladen. Das sah eigenartig in der Grafik aus. Problem ist auch das die Leistung wenn sie dann aus der Batterie kommt (Nachts) wieder über den Gesamtertrag des WR eingerechnet wird.

DS_Starter

#2360
ZitatKannst Du mir mal eine Beispielkonfiguration eines Shellys zeigen? Sowohl im Device selbst als auch im ForeCast?

Ich habe gleich im Wiki eine Beschreibung für einen Shelly erstellt:

https://wiki.fhem.de/wiki/SolarForecast_-_Solare_Prognose_(PV_Erzeugung)_und_Verbrauchersteuerung#Einbinden_/_Registrieren_von_Verbrauchern

Ein Beispiel für HM-ES-PMSw1-Pl ergänze ich noch.

ZitatBei den Beams bin ich mir noch nicht schlüssig wie ich die sinnvoll integriere - ich bin mit dem
currentInverterDev Sun2000 pv=WR_Eingangsleistung_Solar_W:W etotal=WR_Gesamtertrag_kWh:kWh capacity=8800
schon auf der Solaren-Eingangsleistung, wenn ich als Beam Content PVreal wähle - wird dann stündlich der Gesamtertrag genommen, oder die Eingangsleistung?
Aus dem Reading WR_Gesamtertrag_kWh (also etotal) wird der Ertrag auf Stundenbasis berechnet. Es ist nicht 100ig genau, da die Ermittlung bei jedem Zyklus (Attr ctrlInterval) efolgt und der nicht exakt immer zur vollen Stunde stattfindet.

Zitatch hatte letzte Woche einen Tag an dem die Prognose für die angeschaute Stunde bei etwa 3000Wh lag, PVReal war dann bei 900Wh - es wurde aber der Überschuss komplett in die Batterie geladen. Das sah eigenartig in der Grafik aus. Problem ist auch das die Leistung wenn sie dann aus der Batterie kommt (Nachts) wieder über den Gesamtertrag des WR eingerechnet wird.
Ich habe inzwischen auch eine Batterie angeschlossen und ich kann bislang keine eigenartigen Ergebnisse feststellen. (siehe Screenshot)
Prüfe bitte nochmal deine Angaben im Setup des Device.

ZitatProblem ist auch das die Leistung wenn sie dann aus der Batterie kommt (Nachts) wieder über den Gesamtertrag des WR eingerechnet wird.
Wo siehst du das ?

LG
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Eisix

Hallo,

habe seit 1 Monat das Modul laufen mit DWD und Autokorrektur an. Abweichung meist zwischen -25 und -45. Nach welcher Zeit sollten sich die Prognosen den einpendeln?

Gruß
Eisix

DS_Starter

Das kann man nicht an einem Termin festmachen. Es kommt darauf wie genau die DWD Vorhersagen sind in wie oft zu derselben Tageszeit (Stunde) die gleichen Bewölkungsbedingungen vorherrschen. Es gibt immerhin 100 unterschiedliche Bewökungsszenarien.
Die Qualitätsanzeige im Kopf gibt einen gewissen Hinweis darauf wie oft identische Bewökungsszenarien zur gleichen Stunde aufgezeichnet wurden die für eine Anpassung verwendet werden. Solange sie rot ist, sind nur wenige Vergleichswerte vorhanden.

Ich bevorzuge mittlerweile den SolCast Dienst. Aber das muß nicht immer die beste Wahl sein, vor allem weil neue Accounts nur 10 freie Calls pro Tag frei haben.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

der-Lolo

Danke Heiko, jetzt habe ich etwas zu lesen und ausprobieren.

Bei der konstellation eines Huawei Hybrid Wechselrichters wird Solarer Überschuss nicht vom WR in AC gewandelt, sondern direkt als DC in die Batterie geladen.
(Solange die Batterie nicht voll ist, oder die max. Ladeleistung (5kW) gerissen wird)
Erst wenn diese Energie wieder aus der Batterie abgerufen wird, fliest sie über den WR_Gesamtertrag_kWh in die Solarforecast Daten ein. Zumindest bin ich der meinung das genauso zu beobachten...

Deswegen glaube ich es wäre für die hier bei mir eingesetzte Hardware und die Treffgenauigkeit der Prognose besser wenn statt des WR_Gesamtertrag_kWh die WR_Eingangsleistung_Solar_W mit der Vorhersage vergleichen wird.

WR_Eingangsleistung_Solar_W - WR_Gesamtertrag_kWh - ESU1_Momentanleistung_W = von der Sonne erzeugte Leistung und zwar DC und AC. Wenn ESU1_Momentanleistung_W negativ ist, wird aus der Batterie entnommen und ans Haus geliefert, das wiederrum lässt WR_Gesamtertrag_kWh steigen.

Im Fall von Huawei WR und Batterie kann man die Batterie wie Solarpanelle ansehen die nach Bedarf liefern, oder speichern um den Hausverbrauch zu decken, oder Überschuss Einspeisung zu vermeiden.

Keine Ahnung wie andere Systeme arbeiten und Werte verrechnen.

Im Anhang noch ein Screenshot um den Nachtverbrauch / Batterieentnahme zu zeigen, ein weiterer Screenshot zeigt die Daten wie sie von Huawei dargestellt werden.
Grün ist was von der Sonne kommt, blau überdeckt grün bis die Batterie vollständig geladen ist - oder die 5kW max Ladeleistung überschritten wird.
Grün ist also die solare erzeugung, rot der Hausverbrauch, blau über rot die Energie die in die Batterie geladen wird - lila peaks nahe der Null-Linie sind Leistungen aus der Batterie um Netzbezug zu vermeiden.


Eine kleine optische anpassung würde ich gerne noch umsetzen.
Während der Einrichtung des Systems meine ich irgendwo gesehen zu haben bei welchen Ladeständen welche Batterie-Icon-farbe verwendet wird. Ich würde gerne unter 20% rot anzeigen, alles darüber grün. Wie kann ich das beeinflussen?


ch.eick

#2364
Moin
Zitat von: der-Lolo am 14 April 2023, 10:01:41Bei der konstellation eines Huawei Hybrid Wechselrichters wird Solarer Überschuss nicht vom WR in AC gewandelt, sondern direkt als DC in die Batterie geladen.
(Solange die Batterie nicht voll ist, oder die max. Ladeleistung (5kW) gerissen wird)
Erst wenn diese Energie wieder aus der Batterie abgerufen wird, fliest sie über den WR_Gesamtertrag_kWh in die Solarforecast Daten ein. Zumindest bin ich der meinung das genauso zu beobachten...

Im Fall von Huawei WR und Batterie kann man die Batterie wie Solarpanelle ansehen die nach Bedarf liefern, oder speichern um den Hausverbrauch zu decken, oder Überschuss Einspeisung zu vermeiden.

Keine Ahnung wie andere Systeme arbeiten und Werte verrechnen.
Das ist genau so wie Du es beobachtete hast. Aus diesem Grund korrigiere ich bei meinem Kostal Plenticore hybrid den Ertrag (Yield) um das was in oder aus dem Speicher geht. Da ich bei meiner Prognose jedoch die MySQL Datenbank verwende erfolgt das bei mir in einer MySQL SELECT Abfrage, bevor der korrigierte Ertrag in die KI Prognose geht.

ZitatDeswegen glaube ich es wäre für die hier bei mir eingesetzte Hardware und die Treffgenauigkeit der Prognose besser wenn statt des WR_Gesamtertrag_kWh die WR_Eingangsleistung_Solar_W mit der Vorhersage vergleichen wird.

WR_Eingangsleistung_Solar_W - WR_Gesamtertrag_kWh - ESU1_Momentanleistung_W = von der Sonne erzeugte Leistung und zwar DC und AC. Wenn ESU1_Momentanleistung_W negativ ist, wird aus der Batterie entnommen und ans Haus geliefert, das wiederrum lässt WR_Gesamtertrag_kWh steigen.
Das geht so einfach nicht, da Du so versuchst W mit Wh zu verechnen. Für die Prognose wird der Ertrag im kWh benötigt und das ganze Ergebnis müsste auch korrekter Weise als Stufendiagram dargestellt werden. Auch diesen Fehler habe ich bereits in meiner KI Prognose korrigiert, denn da hatte ich auch die momentan Leistung mit der Ertragsprognose in kWh gegenuber gestellt, was aber falsch war.
Bei der Korrektur um den Ertrag, der in den Speicher geht und später wieder heraus muss man auch beachten, dass es dort DC ist, wodurch man dann noch die DC/AC Verluste mit berücksichtigen sollte. Diese verluste habe ich fix auf 15 % gesetzt, was jedoch auch nur eine Näherung ist.

Macht man diese Korrektuern nicht, so erscheint der Ertrag z.B. am Morgen um einiges zu gering im Verhältnis zur Linie mit der momentan Leistung. In der Nacht wird dann verwirrender weise der durch den Speicher verzögert abgegebene Ertrag. Das bereinige ich, nidem ich die Prognose nur von 06:00 - 21:00 Uhr erstelle und vorwiegend im Winter die zu kleinen Werte unterdrücke.

Beim Kostal Plenticore gibt es diverse Batterie readings, von den man diese verwenden kann.
Battery_Total_DC_ChargeEnergy_DCsideToBattery
Battery_Total_DC_DischargeEnergy_DCsideFromBattery

Dann kommt noch eine Validierung der Berechnung
# Hier werden die DC Werte validiert und mit 0.85 DC/AC Wandlung berücksichtigt

      cast( -- validate yield
               if((Speicher.yield IS NULL),
                   WR.yield,
                   if((WR.yield IS NULL),Speicher.yield,WR.yield + Speicher.yield)
                 )
            AS DECIMAL(6)) AS yield                    if((DCfrom IS NULL),
                      DCto,
                      if((DCto IS NULL), DCfrom * -1, DCto - DCfrom)
          )*0.85 AS DECIMAL(6) ) AS yield


## Das Ergebnis des Speicher Yield kann +/- sein und muss nochmals mit dem WR yield validiert werden

      cast( -- validate yield
               if((Speicher.yield IS NULL),
                   WR.yield,
                   if((WR.yield IS NULL),Speicher.yield,WR.yield + Speicher.yield)
                 ) AS DECIMAL(6) ) AS yield

Für dieses Modul bedeutet das, dass Ihr dem Modul einen korrigierten Yield liefern müsst. Die Korrektur wäre dann über ein userReadings erforderlich, da hier ja im Modul ohne die DbLog (bei mir MySQL)gearbeitet wird. Der WR müsste eine Lade/Entladeleistung oder noch besser eine geladene/entladene Energie (kWh) liefern. Diese kWh wären dann aber DC, wie in meinem Beispiel beschrieben. Eine Berechnung über einen delta SOC des Speichers erachte ich als zu ungenau. Wenn der WR keinen eigenen Zähler für den Speicher liefert wäre der zuerst nachzubauen und auf einer Basis von 1h als Summe erforderlich.
Daraus wird dann ein korrigiertes userReadings für den gesamt Yield, was dann in diesem Modul angegeben werden müsste.

VG  Christian

Im Diagramm ist die blaue momentan Leistung nur zur Orientierung, Lila ist die Prognose aus der KI und hellblau der korrigierte Ertrag.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

der-Lolo

Ich verstehe die probleme die hierdurch entstehen - die folge ist leider das die Prognose nahezu unbrauchbar ist. Heiko hat hier sehr viel Arbeit und herzblut hineingesteckt - und auch Du hast ja dazu beigetragen das Solarforecast zu dem wird was es nun ist.

Für Hybrid Systeme sehe ich eigentlich nur die möglichkeit einen weiteren Beam einzuführen der die momentanleistung des Akkus wiederspiegelt. Egal ob Positiv oder negativ - es könnte z.b. Stündlich verrechnet werden um aus den erfassten W -> Wh zu machen.

Ich finde das Modul ist ein sehr guter Ansatz - optisch ein kleiner leckerbissen mit dem man auf den ersten Blick sieht was abgeht. Aber für Hybrid oder DC gekoppelte Systeme sehe ich die probleme... Es ist also leider nicht "universell"

Die Schaltung der Consumer ist so leider auch nicht ganz trivial - und auch der Consumer Forecast funktioniert nicht richtig.

 

DS_Starter

Hallo der-Lolo,

ZitatDeswegen glaube ich es wäre für die hier bei mir eingesetzte Hardware und die Treffgenauigkeit der Prognose besser wenn statt des WR_Gesamtertrag_kWh die WR_Eingangsleistung_Solar_W mit der Vorhersage vergleichen wird.

WR_Eingangsleistung_Solar_W - WR_Gesamtertrag_kWh - ESU1_Momentanleistung_W = von der Sonne erzeugte Leistung und zwar DC und AC. Wenn ESU1_Momentanleistung_W negativ ist, wird aus der Batterie entnommen und ans Haus geliefert, das wiederrum lässt WR_Gesamtertrag_kWh steigen.

Die Prognose selbst ist davon nicht betroffen, allerdings natürlich der Vergleich zwischen Prognose und realer Erzeugung die dann wieder eventuelle Korrekturfaktoren beeinflusst und falsch berechnet. Das ist wahrscheinlich was du damit meinst.

Wenn ich es richtig sehe, müssete es wohl heißen:

WR_Eingangsleistung_Solar_W - ESU1_Momentanleistung_W = erzeugte aktuelle Leistung

sonst passt es schon allein von den Einheiten her nicht (Mischung W und kWh).
Wenn dein System so arbeitet, dann könnest du dir einfach ein userReading errechnen lassen und dieses dann im Schlüssel "pv=" angeben. Für den Schlüssel etotal gilt Vergleichbares wenn eine vorherige Berechnung nötig sein sollte.

Demnächst stehe ich wohl vor einem ähnlichen "Problem". Ich habe neben dem PV-WR die letzten Wochen ein Batteriesystem mit Victron Energy und Pylontech installiert. Das habe ich schon erfolgreich im SolarForecast integriert. Nun will ich noch MPPT Regler einbauen die separate Strings bedienen und am PV-WR vorbei direkt in die Batterie einspeichern.
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

ch.eick

#2367
Zitat von: der-Lolo am 16 April 2023, 10:31:24Ich verstehe die probleme die hierdurch entstehen - die folge ist leider das die Prognose nahezu unbrauchbar ist. Heiko hat hier sehr viel Arbeit und herzblut hineingesteckt - und auch Du hast ja dazu beigetragen das Solarforecast zu dem wird was es nun ist.

Für Hybrid Systeme sehe ich eigentlich nur die möglichkeit einen weiteren Beam einzuführen der die momentanleistung des Akkus wiederspiegelt. Egal ob Positiv oder negativ - es könnte z.b. Stündlich verrechnet werden um aus den erfassten W -> Wh zu machen.

Ich finde das Modul ist ein sehr guter Ansatz - optisch ein kleiner leckerbissen mit dem man auf den ersten Blick sieht was abgeht. Aber für Hybrid oder DC gekoppelte Systeme sehe ich die probleme... Es ist also leider nicht "universell"

Die Schaltung der Consumer ist so leider auch nicht ganz trivial - und auch der Consumer Forecast funktioniert nicht richtig.
ZitatWenn dein System so arbeitet, dann könnest du dir einfach ein userReading errechnen lassen und dieses dann im Schlüssel "pv=" angeben. Für den Schlüssel etotal gilt Vergleichbares wenn eine vorherige Berechnung nötig sein sollte.
Siehe dazu meinen vorherigen Post, ich hatte gerade noch einen Update gemacht, der einen möglichen Ansatz zur Lösung beschreibt.
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

der-Lolo

#2368
Deine Formel schaut gut aus - zumal wenn die ESU Leistung ein negatives Vorzeichen bekommt, die aktuell erzeugte Leistung anwächst.
- und - gibt +
Ich versuchs mal mit einem userreading. Ich hatte schon überlegt die vorgänge in der Batterie so zu verarbeiten wie der user mit dem BHKW es macht, aber ich glaube Deine Variante ist zielführender...

Ich probiere es und Berichte.


Readings
ESS_Energie_Entladung_Tag_kWh
0
2023-04-16 00:00:11
ESS_Energie_Ladung_Tag_kWh
0.05
2023-04-16 10:28:55
ESS_Entladegrenze_Prozent
10
2023-04-13 22:24:13
ESS_Ladegrenze_Prozent
95
2023-04-13 22:24:12
ESS_SoC
10
2023-04-16 10:24:15
ESS_Status
running
2023-04-16 06:35:41
ESU1_Energie_Entladung_Tag_kWh
0
2023-04-16 00:00:10
ESU1_Energie_Ladung_Tag_kWh
0.05
2023-04-16 10:27:43
ESU1_Gesamtenergie_Entladung_kWh
189.12
2023-04-15 14:56:09
ESU1_Gesamtenergie_Ladung_kWh
189.44
2023-04-16 10:27:44
ESU1_Momentanleistung_W
42
2023-04-16 10:51:53
ESU1_SoC
10
2023-04-16 10:24:13
ESU1_Status
running
2023-04-16 06:35:48
ESU1_Temperatur
29.8
2023-04-16 10:51:54
PM_ActivePower_A
200
2023-04-16 10:51:55
PM_ActivePower_B
-759
2023-04-16 10:51:55
PM_ActivePower_C
125
2023-04-16 10:51:55
PM_Einspeisung_kWh
138.46
2023-04-15 10:32:45
PM_Meter_Status
0.01
2023-03-20 14:27:19
PM_Momentanleistung_W
-418
2023-04-16 10:51:55
PM_Netzbezug_kWh
317.98
2023-04-16 10:51:04
PV1_current
1.01
2023-04-16 10:51:52
PV1_voltage
846.1
2023-04-16 10:51:51
WR_Device_status
on_grid
2023-04-16 06:37:07
WR_Efficiency
100
2023-04-16 06:37:07
WR_Eingangsleistung_Solar_W
829
2023-04-16 10:51:42
WR_Energie_Tag_kWh
1.08
2023-04-16 10:51:53
WR_Gesamtertrag_kWh
643.9
2023-04-16 09:57:42
WR_Internal_temperature
32.7
2023-04-16 10:51:42
WR_Maximalleistung_Tag_kWp
0.833
2023-04-16 10:51:52
WR_Modus_Leistungsbegrenzung
unlimited
2023-03-20 14:27:21
WR_Momentanleistung_W
828
2023-04-16 10:51:52
WR_Shutdown_Time
1681586183
2023-04-15 19:16:33
WR_Startup_Time
1681627025
2023-04-16 06:37:08
state
CONNECTED
2023-04-14 22:37:54


DS_Starter

Was liefert der Huawei Hybrid Wechselrichter bzw. das Device dazu für Readings und deren Bedeutung ?
Ich denke schon dass wir dafür eine Lösung finden  werden. Wie gesagt habe ich wohl bald ein ähnliches Thema mit DC-Ladung.

Bezüglich Einfärbung der Batterie gibt es das Attr flowGraphicCss.
Du übernimmst den ganzen Default (ist in der Direkthilfe verfügbar) und änderst diese Werte wie gewünscht:

...
.flowg.bat25 { stroke: red; fill: red; }
.flowg.bat50 { stroke: darkorange; fill: darkorange; }
.flowg.bat75 { stroke: green; fill: green; }
...
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter