Leistungsprognose für Wechselrichter

[Wzut]

Danke, werde ich mir anschauen - ja ich habe bei mir die Typen pcvo und diff laufen, allerdings noch mit Fehler.
Die Rechnerei mit den Stunden kostet Nerven, ich habe ein neues Attribut hour_offset drin ( -12 bis 0 ) Stunden um die X-Achse in die Vergangenheit zu verschieben. Mal schauen ob das mit deiner neuen Version dann einfacher wird und ich auch gleich die Fehler los bin.
Achso hatte ich bis jetzt vergessen : Bitte diese neuen hashes nicht intern löschen, lass sie einfach als Ringpuffer immer durchlaufen,
ich brech dann die pvreal Ausgabe ab sobald die aktuelle Stunde auf der X Achse erreicht ist.   

[DS_Starter]

Achso hatte ich bis jetzt vergessen : Bitte diese neuen hashes nicht intern löschen, lass sie einfach als Ringpuffer immer durchlaufen,
ich brech dann die pvreal Ausgabe ab sobald die aktuelle Stunde auf der X Achse erreicht ist.   

So ist es implementiert. Nach Neustart ist die Hashes aber erstmal leer und füllt sich mit den Datenabrufen.
pvreal füllt sich nach und nach bzw. Stunde um Stunde.
Aber das siehst du ja ...

[DS_Starter]

Nach längerer Testzeit habe ich die weiter vorn erwähnte neue SMAInverter-Version eingecheckt, ist morgen früh im Update enthalten (https://forum.fhem.de/index.php/topic,56080.msg1134664.html#msg1134664).

Grüße

[dk3572]

Hallo Heiko,

ich habe das Update gemacht und das currentInverterDev wieder in SMA_Wechselrichter pv=total_pac:kW etoday=etoday:kWh geändert.
Jetzt steht leider in pvreal wieder 0.
Mit dem userReading etoday_fc funktioniert es.

Wenn ich dich richtig verstanden habe, sollte das doch nicht mehr nötig sein.

VG Dieter

Edit:
Es steht auch fast jeden Tag um 01 folgendes in der History (mal mehr, mal weniger):

Code Auswählen Erweitern

01 => pvreal: 20055, pvforecast: 0

[DS_Starter]

Nabend Dieter,

klappt bei mir tadellos mit der SMAInverter Version

FVERSION 76_SMAInverter.pm:v2.14.1-s23909/2021-03-07

und ohne dem Workaround mit dem userreading. Ich benutze jetzt wieder

currentInverterDev MySTP_5000 pv=total_pac:kW etoday=etoday:kWh

Das sind Beispiel History-Werte von gestern und heute:

Code Auswählen Erweitern


09 => 00 => pvreal: 0, pvforecast: 0
      01 => pvreal: 0, pvforecast: 0
      02 => pvreal: 0, pvforecast: 0
      03 => pvreal: 0, pvforecast: 0
      04 => pvreal: 0, pvforecast: 0
      05 => pvreal: 0, pvforecast: 0
      06 => pvreal: 2, pvforecast: 0
      07 => pvreal: 304, pvforecast: 23
      08 => pvreal: 1541, pvforecast: 351
      09 => pvreal: 1941, pvforecast: 635
      10 => pvreal: 3142, pvforecast: 703
      11 => pvreal: 3871, pvforecast: 1484
      12 => pvreal: 4519, pvforecast: 1769
      13 => pvreal: 4140, pvforecast: 1365
      14 => pvreal: 1773, pvforecast: 1374
      15 => pvreal: 922, pvforecast: 1232
      16 => pvreal: 531, pvforecast: 892
      17 => pvreal: 131, pvforecast: 203
      18 => pvreal: 1, pvforecast: 86
      19 => pvreal: 0, pvforecast: 0
      20 => pvreal: 0, pvforecast: 0
      21 => pvreal: 0, pvforecast: 0
      22 => pvreal: 0, pvforecast: 0
      23 => pvreal: 0, pvforecast: 0
08 => 00 => pvreal: 0, pvforecast: 0
      01 => pvreal: 0, pvforecast: 0
      02 => pvreal: 0, pvforecast: 0
      03 => pvreal: 0, pvforecast: 0
      04 => pvreal: 0, pvforecast: 0
      05 => pvreal: 0, pvforecast: 0
      06 => pvreal: 0, pvforecast: 0
      07 => pvreal: 21, pvforecast: 0
      08 => pvreal: 637, pvforecast: 240
      09 => pvreal: 777, pvforecast: 563
      10 => pvreal: 796, pvforecast: 869
      11 => pvreal: 3034, pvforecast: 1607
      12 => pvreal: 4314, pvforecast: 2313
      13 => pvreal: 3566, pvforecast: 2952
      14 => pvreal: 3091, pvforecast: 2167
      15 => pvreal: 3122, pvforecast: 1600
      16 => pvreal: 1606, pvforecast: 693
      17 => pvreal: 284, pvforecast: 432
      18 => pvreal: 0, pvforecast: 143
      19 => pvreal: 0, pvforecast: 0
      20 => pvreal: 0, pvforecast: 0
      21 => pvreal: 0, pvforecast: 0
      22 => pvreal: 0, pvforecast: 0
      23 => pvreal: 0, pvforecast: 0


Komisch ... wenn es bei dir nicht klappt kannst du das userreading weiterhin verwenden. Verstehe es allerdings nicht wenn es doch bei mir funktioniert.

Grüße,
Heiko

[ioT4db]

Hallo Heiko,

ich kann das von Dieter bestätigen.

Es ist bei mir exakt das gleiche Verhalten, wenn keine Userreadings verwendet werden.

Versionen:

Code Auswählen Erweitern

76_SMAInverter.pm:v2.14.1-s23909/2021-03-07

Code Auswählen Erweitern

76_SolarForecast.pm:v0.8.0-s21735/2020-04-20 TESTING
currentInverterDev SMAtripower8 pv=total_pac:kW etoday=etoday:kWh

...
Edit:
Es steht auch fast jeden Tag um 01 folgendes in der History (mal mehr, mal weniger):

Code Auswählen Erweitern

01 => pvreal: 20055, pvforecast: 0

@Dieter
bei mir ist das immer exakt der reale Ertrag vom Vortag. Ich glaube weiter vorn wurde schonmal erklärt, warum das so ist...

[DS_Starter]

Moin,

ja dann benutzt weiter das userreading.
Es gibt WR Typen, da muss das SMAInverter Modul den etoday intern berechnen weil der WR es nicht liefert. Meiner liefert den Wert. Damit erkläre ich mir jetzt mal das unterschiedliche Verhalten bei mir und bei euch. 
Aber mit dem userreading kommt man ja auch klar denke ich.

LG,
Heiko

[thobo]

Moin zusammen,

also ich hab bis gerade noch mit der Vorab-Version von SmaInverter gearbeitet, da war noch alles ok. Hab aber gerade das Update gezogen. Mal schauen, wie es morgen aussieht, ich werde berichten!
Allerdings habe ich hier das Phänomen, dass meine Vorhersage immer genau eine Stunde später anfängt, als mein Inverter schon Strom produziert. Gleiches nur umgekehrt habe ich am Abend. Während SolarForecast noch Erträge voraussagt, ist im realen Leben die Sonne schon lange untergegangen.
Ursache müssen die Daten vom Deutschen Wetter Dienst sein, da dort entsprechende Vorhersagen stehen. Also hab ich ein wenig gegraben und etwas von UTC und ggf. nötige Anpassungen gelesen. In der Ref zu dem DWD Modul steht auch was dazu. Habt ihr das auch gemacht / muss ich das tatsächlich durchführen oder geht das mittlerweile automatisch oder über ein attr?? (Alles was ich gefunden hab, ist schon relativ alt)

Eine weitere Frage zum DWD, auch wenn sie vielleicht nicht direkt hier hin gehört. (Falls die Antwort dazu zu lange dauern würde, bitte einfach abblocken, dann schaue ich wo ich die Frage besser stellen kann)
In Meiner nähe gibt es mehrere Stationen, die angeblich auch die hier benötigten Daten liefern. Allerdings kann ich sie nicht nehmen, da die Stations-ID beim Wetterdienst nicht abrufbar ist (404) und das obwohl ich sehen kann dass in der Stationsübersicht täglich ein neues Datum für neue Daten eingetragen werden. Weiß jmd. wieso das so ist??

Viele Grüße und DANKE
Thomas

[Wzut]

@Heiko, das mit den beiden neuen hashes unter $data ist super, die elende Rechnerei hat sich stark vereinfacht. Mein einer Fehler an dem ich so festhing hat sich damit auch erschlagen. Und du kennst ja den Spruch mit dem kleinen Finger und der ganzen Hand :
Bitte noch zwei hashes in dieser Art :
Nr 1 müsste die Wetterdaten aufnehmen, denn z.Z. kann ich für Vergangenheit kein Icon anzeigen da ich keine Wetter History habe.
Nr. 2 den tatsächlichen Verbrauch
Dann noch eine Frage dazu : der(die) neue hash ist ja ein 24 Stunden Ringpuffer, wie schaut das aus mit den Werten der aktuellen Stunde,
wird dieser Wert immer aktuell frisch gehalten oder ist er der alte Wert von gestern und wird erst mit Ablauf der aktuellen Stunde überschrieben ? 

Z.Z habe ich die beiden Typen pvco und diff in der Art missbraucht das sie nun Forcast und Real als Werte benutzen.
D.h. wenn später mal wieder eine Verbrauchsprognose dazukommen sollte müssten wir die jetzigen vier Varianten eigentlich verdoppeln.
Bzw. mit den vier Grundwerten : Forcast, Erzeugung, Verbrauch und geschätzer Verbrauch komme auf vier Basis Typen mit jeweils nur einem Wert plus 4x4x2 = 32 erweiterte Typen mit jeweils zwei Werten (Darstellung Schema pvco & diff )
von der HTML Erzeugung ist das kein Problem und bedarf auch keiner Änderung, da nur am Anfang festgelegt wird wer Wert1 ist und wer Wert2
und das an zwei Stellen : einmal bei der Startstunde $pv{0} & $co{0} und dann weiter unten nochmal bei $pv{$i} & $co{$i}
Um das Thema Header und Footer habe ich mich bis jetzt gar nicht gekümmert, vllt. sollten wir da auch mal überlegen was man da sinnvoll anzeigt in Abhängigkeit des gewählten Darstellungstyps ? 
     
   
@thobo , verrate doch mal Station IDs die nicht so wollen, dann kann man das mal bei sich prüfen

[thobo]

Da hätte ich drauf kommen können, das ich ein paar Daten liefern muss!

Also aktuell nutzte ich die Stations-ID H203.
Besser wäre aber die H301, da sie wesentlich näher ist.
H304 oder H401 wären auch ok, aber bei diesen drei (H301, H304 und H401) bekomme ich keine Daten / den 404'er (hab auch schon die URL selber eingegeben: die entsprechenden Unterordner fehlen da einfach).

Viele Grüße
Thomas

[Wzut]

OK, die gehen bei mir auch nicht. Leider finde ich den super Link zu der Karte nicht mehr wo man so schön zoomen konnte.
Je näher man seinem Wohnort kommt umso mehr Stationen erscheinen da, dann gilt es testen welche die Rad1h Werte liefern.
Vllt. liest ja der User noch mit der es damals gepostet hatte.

[ioT4db]

meintest Du vlt die? https://wettwarn.de/mosmix/mosmix.html

und hier noch die Liste der Stationen, die Rad1h liefern - sind halt leider nicht so viele
https://opendata.dwd.de/climate_environment/CDC/observations_germany/climate/hourly/solar/ST_Stundenwerte_Beschreibung_Stationen.txt entfernt, da schlecht/unvollständig

[ch.eick]

OK, die gehen bei mir auch nicht. Leider finde ich den super Link zu der Karte nicht mehr wo man so schön zoomen konnte.
Je näher man seinem Wohnort kommt umso mehr Stationen erscheinen da, dann gilt es testen welche die Rad1h Werte liefern.
Vllt. liest ja der User noch mit der es damals gepostet hatte.

Meinst Du den hier ... mist, zu spät
DWD Mosmix Stationen

VG Christian

[Wzut]

Ihr seid ja so gut ... genau die
Tipp : erst scrollen und zoomen, dann die Stationen einschalten sonst wird man erschlagen.

[ioT4db]

hab meinen Beitrag https://forum.fhem.de/index.php/topic,117864.msg1138615.html#msg1138615
noch um die Stationen ergänzt, die rad1h liefern...