76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Das wäre doch schön - wenn ich den Alias im Device ändere schauts in der FHEM Übersicht wieder seltsam aus.

Nehme ich auf meine ToDo.

LG

[chrisx]

Hallo zusammen,

das Modul ist echt super!
Lese mit Begeisterung die ganze Entwicklung.

Wäre es möglich die Icons der Consumer[xx] in der Energieflußgrafik als Tabelle darzustellen? Bei 16 Geräten z.b. als 4x4, oder allgem. definierbar?

Viele Grüße
Christian

[DS_Starter]

Hallo Christian,

ich möchte nicht behaupten es würde nicht gehen. Da muß man Hirnschmalz und Zeit investieren.
Kannst du uns näher beschreiben (oder mit Screenshot) was der konkrete Grund deiner Anfrage ist?

LG,
Heiko

[chrisx]

Hallo Heiko,

versuche es kurz zu beschreiben...
Hab selbst ein Balkonkraftwerk mit Speicher.
Aktuell nutze ich das Modul zur Anzeige und Sammlung von Daten.
Somit habe ich auch Verbraucher in der Anzeige die nie aktiv geschalten werden. Deren aktuellen Verbrauch zu sehen - soweit vorhanden - finde ich durchaus interessant. Bei 16 Geräten in Reihe kann dies je nach Endgerät allgemein recht klein werden.

LG
Christian

[DS_Starter]

Bei 16 Geräten in Reihe kann dies je nach Endgerät allgemein recht klein werden.

Hast du mal mit den Einstellungen im Attr flowGraphicControl  -> size gespielt?
Es gibt noch weitere Schlüssel consumerdist, h2consumerdist die in dem Zusammenhang dienlich sein könnten.

[minierm]

hast du in deinem Batteriedevice den Schlüssel "cap" angegeben und hat der den korrekten Wert?
Lt. Codierung kann SoC > 100% nur auftreten wenn die erreichte Ladung der Batterie über dem Wert lt. Schlüssel 'cap' liegt.

Wert korrekt, aber falsche Einheit 11.5kWh statt 11500 Wh...

[minierm]

Im Attribut "setupBatteryDev1" wird unter "cap" der Wert "Nennkapazität"eingetragen, den der Hersteller für diese Batterie (=100%) angibt:

Code Auswählen Erweitern

cap    installierte Batteriekapazität. Option kann sein:
numerischer Wert - direkte Angabe der Batteriekapazität in Wh
<Readingname>:<Einheit> - Reading welches die Kapazität liefert und Einheit (Wh, kWh)

Im Lauf der Zeit steht dieser Wert aber dann nicht mehr voll zur Verfügung.
Er verringert sich leider immer mehr (damit meinte ich "Rest-Batteriekapazität" im Verhältnis zur Nennkapazität SoH).....

Im BWR kann man diesen (meist) als Readingwert % / Faktor etc. sehen.

Bei mir ist er bei einer Batterie bei 0.83 und bei einer bei 0.93.
Somit habe ich bei einer Nennkapazität von 9800 Watt bei der ersten Batterie nur noch (9800 * 0.83) 8134 Watt und bei der anderen (9800 * 0.93) 9114 Watt Restkapazität als Batteriespeicher zur Verfügung.

Und genau diese Rechnung könntest Du doch in einem Userreading ablegen und an SF übergeben?

[chrisx]

Bei 16 Geräten in Reihe kann dies je nach Endgerät allgemein recht klein werden.

Hast du mal mit den Einstellungen im Attr flowGraphicControl  -> size gespielt?
Es gibt noch weitere Schlüssel consumerdist, h2consumerdist die in dem Zusammenhang dienlich sein könnten.

Hilft leider nicht wirklich. Bestenfalls werden nur die Icons inkl. Schrift unleserlich, aber dafür nicht die anderen anderen grafischen Ebenen darüber.
Können vielleicht inaktive Verbraucher bei pcurr=xx:xx:"kleiner diesem Wert" ausgeblendet werden?

[DS_Starter]

Ich habe mal einen Test mit folgendem flowGraphicControl Attributinhalt erstellt:

Code Auswählen Erweitern

animate=1
consumerdist=90
h2consumerdist=50
shiftx=0
shifty=0
showconsumer=1
showconsumerdummy=1
showconsumerpower=1
showconsumerremaintime=0
size=600 strokewidth=12

Sieht dann aus wie im Anhang (16 Consumer).

[TheTrumpeter]

Bei mir ist er bei einer Batterie bei 0.83 und bei einer bei 0.93.
Somit habe ich bei einer Nennkapazität von 9800 Watt bei der ersten Batterie nur noch (9800 * 0.83) 8134 Watt und bei der anderen (9800 * 0.93) 9114 Watt Restkapazität als Batteriespeicher zur Verfügung.

Ist zwar OT, aber darf ich fragen wie alt die Batterien sind und um welche Zellchemie es sich jeweils dabei handelt?

[Parallix]

@minierm,

hast du in deinem Batteriedevice den Schlüssel "cap" angegeben und hat der den korrekten Wert?
Lt. Codierung kann SoC > 100% nur auftreten wenn die erreichte Ladung der Batterie über dem Wert lt. Schlüssel 'cap' liegt.

Es wird also die dem BAT-System zugeführte Energie ohne einen Abschlag (eigentlich erforderlich, da Wirkungsgrad immer kleiner 1.0) für den Forecast des SOC verwendet?

[300P]

Bei mir ist er bei einer Batterie bei 0.83 und bei einer bei 0.93.
Somit habe ich bei einer Nennkapazität von 9800 Watt bei der ersten Batterie nur noch (9800 * 0.83) 8134 Watt und bei der anderen (9800 * 0.93) 9114 Watt Restkapazität als Batteriespeicher zur Verfügung.

Ist zwar OT, aber darf ich fragen wie alt die Batterien sind und um welche Zellchemie es sich jeweils dabei handelt?

siehe Fusszeile - leider 2 x Hochvolt LGRESU10H ca. 6 bzw. 8 Jahre alt - Gott sei Dank ohne deren berüchtigten "Aufblähungen" (bislang)

[300P]

Im Attribut "setupBatteryDev1" wird unter "cap" der Wert "Nennkapazität"eingetragen, den der Hersteller für diese Batterie (=100%) angibt:

Code Auswählen Erweitern

cap    installierte Batteriekapazität. Option kann sein:
numerischer Wert - direkte Angabe der Batteriekapazität in Wh
<Readingname>:<Einheit> - Reading welches die Kapazität liefert und Einheit (Wh, kWh)

Im Lauf der Zeit steht dieser Wert aber dann nicht mehr voll zur Verfügung.
Er verringert sich leider immer mehr (damit meinte ich "Rest-Batteriekapazität" im Verhältnis zur Nennkapazität SoH).....

Im BWR kann man diesen (meist) als Readingwert % / Faktor etc. sehen.

Bei mir ist er bei einer Batterie bei 0.83 und bei einer bei 0.93.
Somit habe ich bei einer Nennkapazität von 9800 Watt bei der ersten Batterie nur noch (9800 * 0.83) 8134 Watt und bei der anderen (9800 * 0.93) 9114 Watt Restkapazität als Batteriespeicher zur Verfügung.

Und genau diese Rechnung könntest Du doch in einem Userreading ablegen und an SF übergeben?

Klar - da würde ich genauer als bisher  - aber.....
Hatte ich - mir reicht es aber wenn SF über den XY % Batterieladestatus weiss wie der Status der Batterie ist.

Hintergrund:
Ich hatte erst vor mit Tibber oder einem anderen dynamischen Stromtarif zu laden / entladen und den Strombezug / Einspeisung zu berücksichtigen. Da wäre es sicherlich angebracht gewesen.

Der dynamische Tarif ist aber (bei meinen Gegebenheiten) nach einer 12 monatigen Probephase bei mir negativ "aufgestoßen" und wäre in diesem Winter dann mit den hohen Preisen bei einem Kostenvergleich "noch mehr daneben" gewesen..

Deshalb hatte ich im abgeschnittenen Zitatausschnitt geschrieben:

Code Auswählen Erweitern

Der Wechselrichter berücksichtigt dies bei der Angabe bzw. Berechnung und anzeige des Ladestatus aber bereits.
Der Wert nützt mir deshalb auch nicht viel im SF.

Das ist ebenfalls ein reine Information wie "schlecht" meine Batterien im laufe der Betriebsjahre geworden sind.
Den Wert braucht man n.m.M. in SF auch nicht.

Gruß
300P

Gruß
300P

[DS_Starter]

Es wird also die dem BAT-System zugeführte Energie ohne einen Abschlag (eigentlich erforderlich, da Wirkungsgrad immer kleiner 1.0) für den Forecast des SOC verwendet?

Anderer Sachverhalt.
Durch das Batteriedevice wird der SoC in Prozent geliefert. Mit der Hochrechnung der wahrscheinlichen Ladungsmenge der nächsten Stunden kommt man auf den wahrscheinlichen Ziel-SoC. Da stecken etliche Wahrscheinlichkeiten drin, wie prognostizierte PV und prognostizierter Verbrauch. Mit der cap-Angabe im Attr erfolgt die Umrechnung in das Wh Äquivalent. Der Umwandlungsverlust der Ladung würde auch noch mit eingehen, hat allerdings im Verhältnis der beschriebenen Einflußfaktoren eine eher marginale Rolle.
Unabhängig davon wird max SoC in Wh begrenzt auf cap, d.h. cap kann nicht überschritten werden wenn richtig angegeben.

[Parallix]

Es wird also die dem BAT-System zugeführte Energie ohne einen Abschlag (eigentlich erforderlich, da Wirkungsgrad immer kleiner 1.0) für den Forecast des SOC verwendet?

Anderer Sachverhalt.
Durch das Batteriedevice wird der SoC in Prozent geliefert. Mit der Hochrechnung der wahrscheinlichen Ladungsmenge der nächsten Stunden kommt man auf den wahrscheinlichn Ziel-SoC. Da stecken etliche Wahrscheinlichkeiten drin, wie prognostizierte PV und prognostizierter Verbrauch. Mit der cap-Angabe im Attr erfolgt die Umrechnung in das Wh Äquivalent.

Leider gibt es in FHEM bis dato keine Auftrennung eines BAT-Devices in Low- und High-Level-Anteil. Dies macht es mir auch schwer, für den ansonsten guten Ansatz zu sein, dass alles, was primär eher BAT-bezogen ist, funktionstechnisch auch vom BAT-Device zu fordern. Spätestens dann, wenn hier in Deinem Modul von SOC auf Energie und umgekehrt abgebildet wird, ist das aber problematisch.

Für's erste schlage ich – analog zu den pv_correctionFactors – vor, auch bei der Berücksichtigung von Be- und Endladung der BATs in SF entsprechende Korrekturfaktoren einzubauen und in SF ermittelte und insb. angezeigte SOC-Werte oben (bei 100%) und unten (bei 0%) zu kappen.