76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Und die V 1.51.2 ist auch eingecheckt und morgen früh im Update enthalten.

LG

[peterboeckmann]

Hallo Heiko,

Vielen Dank dafür:

Die Erweiterung von 'graphicSelect' betrifft die von peterboeckmann gwünschte Möglichkeit, Balken- und Fußgrafik in ihrer Reihenfolge vertauschen zu können.

Ich habe die V soeben gezogen, sieht auf den ersten Blick sehr gut aus.

Edit: Immer wieder toll zu sehen, wie Dein Modul wächst.

Viele Grüße,
Peter

[DS_Starter]

Danke Peter 
Stück für Stück ...

Lg,
Heiko

[grappa24]

Code Auswählen Erweitern

swap_noCons ist so ganz meins 

[DS_Starter]

Hallo zusammen,

in meinem contrib liegt die V 1.51.3.

Die Setter setupStringAzimuth und setupStringDeclination werden in die Attribute setupStringAzimuth bzw. setupStringDeclination umgesetzt. Die Setter sind danach nicht mehr vorhanden.
Der Vorgang erfolgt automatisch.

WICHTIG: Nach dem Download der Version direkt FHEM restarten. Nachdem FHEM wieder gestartet ist, die umgesetzte Struktur (Attribute) mit "save" speichern. Damit ist die Umsetzung abgeschlossen.

Weiterhin habe ich eine kleine Änderung im Balloon-Popup der Batterie in der Balkengrafik vorgenommen. Der Hinweis "keine Ladeempfehlung" ist ersetzt durch "laden wenn über Einspeiselimit". Dieser Hinweis trifft diesen Status deutlich besser, denn die Batterie kann/soll durchaus geladen werden, wenn eine Einspeisung über dem gesetzten Limit der Anlage (Attr plantControl->feedinPowerLimit) erfolgt. Genau dieser Mechanismus soll eine eventuelle Abregelung der Anlage verhindern.

LG,
Heiko 

[Shadow3561]

Moin,
seit heute wird bei mir die Verbrauchsgrafik nicht mehr richtig angezeigt.
Hat sich irgendwas verändert?

Code Auswählen Erweitern

graphicBeamHeightLevel3 hat leider keine Auswirkung.
V 1.51.2

Mit freundlichen Grüßen

[300P]

Bei mir sieht weiterhin alles gut aus:

Hab bis heute Mittag V1.51.2 genutzt - aktuell bin ich auf V1.51.3
Alle "graphicBeamHeightLevel1/2/3" stehen bei mir auf dem Wert "300"

Gruß
300P

[DS_Starter]

Setze doch graphicBeamHeightLevel3 auf einen deutlich höheren Wert, z.B. 1500.

Bei mir wird der Level dann deutlich übergewichtet.

[Shadow3561]

Done
Nach setzen des Attribut

Code Auswählen Erweitern

graphicShowNight 1habe ich den Fehler gefunden. Es war ein Aussreisser gestern Abend, sieh Bild.
Nach löschen mit

Code Auswählen Erweitern

set PV_forecast reset consumptionHistory 22 23ist alles wieder wie es sein soll.
Danke für den Hinweis, dass es wohl an meinem FHEM/Device liegen muss.
Mit freundlichen Grüßen

[DS_Starter]

Oh ja, das erklärt natürlich die Problematik.

[SparcWolf]

Hallo Heiko,

ich habe heute Morgen ein Update gemacht. Diese Meldungen sind mir im Log aufgefallen:

Code Auswählen Erweitern

2025.04.24 09:04:55 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14434.
2025.04.24 09:04:55 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14434.
2025.04.24 09:04:55 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14454.
2025.04.24 09:04:55 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14454.
VG und Danke für Deinen Einsatz hier,
  Guido.

[DS_Starter]

Morgen Guido,

da wird das SF Device vor dem FHEMWEB Device beim Start erzeugt. Das ist nicht weiter tragisch, aber vllt. bekomme ich die Warnung weg in solchen Fällen. Muß ich mal schauen.

LG,
Heiko

[TheTrumpeter]

Wurde in einem der letzten Releases eigentlich die Berechnung des "realen Verbrauchs" für die Balkengrafik angepasst?

Seit ein paar Releases ändert sich der angezeigte tatsächliche Verbrauch der laufenden Stunde sehr häufig, insbesondere wird der auch immer wieder weniger.

Früher war das meiner Meinung nach exakt die Summe aus "Bezug" plus "Erzeugung minus Einspeisung", nun habe ich das Gefühl, dass der Momentanverbrauch auch irgendwie mit berücksichtigt wird und daraus eine Hochrechnung versucht wird?

[DS_Starter]

Die Verbrauchsberechnung und deren Darstellung ist nicht geändert.
Allerdings ist die Ermittlung des realen Verbrauchs ein wenig komplexer als von dir geschrieben.
Dazu gibt es ein Kapitel im Wiki. 

LG,
Heiko

[TheTrumpeter]

Allerdings ist die Ermittlung des realen Verbrauchs ein wenig komplexer als von dir geschrieben.

Im Falle von Batterien oder sonstigen Erzeugern ja, in meinem einfachen Fall "PV-Anlage ohne Speicher" ist es exakt was ich geschrieben habe, nämlich die Summe aus "Bezug" plus "Erzeugung minus Einspeisung"

Zitat aus dem Wiki:

Verbrauch (Wh) = PV-Erzeugung + sonstige Erzeugung - Netzeinspeisung + Netzbezug - Batterieladung + Batterieentladung

Im Wiki steht auch, dass die Werte mit jedem Zyklus "Attribut plantControl->cycleInterval" gesammelt und der Verbrauch ermittelt wird. So wie ich das sehe, ändern sich die Werte aber bei jedem Event, das zu einer Neuberechnung in SolarForecast führt.
Werden dann auch alle für die Berechnung nötigen Werte "frisch abgeholt" oder ggf. teilweise Werte des letzten regulären Zyklusses verwendet?

Ich beobachte, dass der IST-Verbrauch in der Balkengrafik größere Sprünge macht, die mit den aktuellen Werten nicht erklärbar sind.
PV-Erzeugung hat eine Auflösung von 10 Wh, Netzbezug und -einspeisung haben eine Auflösung von 1 Wh, d.h. die Sprünge könnten höchstens durch diese unterschiedliche Auflösung in ebendiesem Bereich stattfinden.
Allerdings habe ich zusätzliche Event-Schwellen bei PV-Erzeugung in Höhe von 1 kWh bzw. bei den Smartmeter-Zählerständen in Höhe von 0.1 kWh gesetzt. Wenn also diese Schwellen verwendet werden und nicht die "Live-Werte", könnte es zu größeren Schwankungen kommen.