Leistungsprognose für Wechselrichter

[DS_Starter]

Habs übernommen, passt soweit ich das sehe 

Mache mich jetzt mal über die HashVal sub her ...

EDIT: kann ich die vielen auskommentierten Zeilen in deiner sub mal entfernen oder willst du die noch drin haben ?

[Wzut]

wenn es  Code Zeilen sind können die weg, i.d.R. hatte ich die oft für dich gelassen, nur ein paar einzelne waren Tests wie z.B zusätzliche Log3 usw. 

[DS_Starter]

@Wzut, es gibt jetzt eine Funktion HistoryVal, welches Werte des pvhistory Hashes liefert.
Die Verwendung habe ich im Funktionscode beschrieben, habe bereits im gesamten Modul außer in deiner sub HistoryVal eingesetzt.

In deiner sub habe ich dir in den Zeilen 2147-2149 die Verwendung beispielhaft eingetragen.

Liegt im contrib.

[DS_Starter]

Frage... in dem pvhistory Hash sind ja alle historischen Vorhersage und realen Werte vorhanden:

Code Auswählen Erweitern


22 => 01 => pvreal: 0, pvforecast: 0, gridcon: 751
      02 => pvreal: 0, pvforecast: 0, gridcon: 604
      03 => pvreal: 0, pvforecast: 0, gridcon: 428
      04 => pvreal: 0, pvforecast: 0, gridcon: 525
      05 => pvreal: 0, pvforecast: 0, gridcon: 432
      06 => pvreal: 0, pvforecast: 0, gridcon: 564
      07 => pvreal: 6, pvforecast: 78, gridcon: 831
      08 => pvreal: 135, pvforecast: 305, gridcon: 506
      09 => pvreal: 277, pvforecast: 633, gridcon: 685
      10 => pvreal: 598, pvforecast: 1420, gridcon: 126
      11 => pvreal: 2765, pvforecast: 1525, gridcon: 0
      12 => pvreal: 2184, pvforecast: 1667, gridcon: 0
      13 => pvreal: 2562, pvforecast: 1950, gridcon: 444
      14 => pvreal: 1692, pvforecast: 1893, gridcon: 10
      15 => pvreal: 1093, pvforecast: 1700, gridcon: 17
      16 => pvreal: 2678, pvforecast: 1406, gridcon: 0
      17 => pvreal: 1466, pvforecast: 1030, gridcon: 3
      18 => pvreal: 528, pvforecast: 376, gridcon: 282
      19 => pvreal: 33, pvforecast: 49, gridcon: 566
      20 => pvreal: 0, pvforecast: 0, gridcon: 705
      21 => pvreal: 0, pvforecast: 0, gridcon: 977
      22 => pvreal: 0, pvforecast: 0, gridcon: 507
      23 => pvreal: 0, pvforecast: 0, gridcon: 0
      99 => pvreal: 16017, pvforecast: 14032, gridcon: 8963


Dagegen befinden sich die Ringspeicherdaten pvforecast, pvreal, consumption in jeweils separaten Hashes.
Wäre es nicht einfacher auch ein zentrales Hash für diesen Ringspeicher zu erstellen und dort die Ringspeicherwerte zu sammeln ?
Ging mir gerade durch den Kopf.

[Wzut]

Zu HistoryVal , ich würde da noch ändern :

Code Auswählen Erweitern

3368c3368
<   my $def  = shift;
---
>   my $def  = shift // 0;
3373c3373
<   my ($d,$n,$default) = @_;
---
>   #my ($d,$n,$default) = @_;

a. kann man dann default beim Aufruf oft ganz weglassen und b. vermute ich noch einen copy & paste Rest aus ReadingsVal
Ich hatte gestern Abend noch etwas gespielt ohne wirklich erfolgreich zu sein. Mir schwebte vor so elegant wie Dumper vorzugehen und die komplette Kette zu analysieren, dann wäre zwar die Prüfung aufwendiger, der übergeben hash könnte dann aber universeller sein, bzw. die Sub könnte auch für andere hashes verwendet werden. Ich spiel mal weiter, hat ja keine Eile.

Wenn du den Ringpuffer zusammenführen willst , nur zu. Ich hätte ja auch die weather id noch bei pvhistory spendiert.
Und noch eine Anmerkung die dem User auch egal sein dürfte : Ich war am Anfang etwas verwirrt über die Key Namen :
Bsp dem User gezeigt in pvhisory -> pvreal,pvforcast & gridcon - keys aber  pvrl , pvfc & gcons 

Stichwort gridcon :
Beim zusammenklicken der ersten Grafik mit consumption habe ich mich über die Werte gewundert , und warum du als Namen da noch das grid zugefügt hast. Dann viel aber der Groschen, es ist ja der reine Netzbezug und nicht wie man denken könnte der tatsächliche Verbrauch.
Du merkst sicher schon wohin das führt ... man könnte aus de vorhanden Werten auch noch den tatsächlichen Verbrauch ableiten und als weiteren Wert intern halten und auswählen
 

[DS_Starter]

Moin,

Code Auswählen Erweitern


my $def  = shift // 0;

Ja, das übernehme ich.

Ich erstelle noch eine weitere Funktion für die zukünftigen Werte. Der Name ist noch nicht da. Die ist dann für den weiteren zentralen Hash wo alles rein geht was jetzt in den separaten Ringpuffern liegt.
Dann sieht man auch gleich am Funktionsnamen welchen Hash man im Programm abfragt.

Du merkst sicher schon wohin das führt ... man könnte aus de vorhanden Werten auch noch den tatsächlichen Verbrauch ableiten und als weiteren Wert intern halten und auswählen

Ja genau, das ist der Plan  Erinnerst du dich noch an IsConsumptionRecommended ? Das könnte auch wiederbelebt werden und zur Entscheidungsfindung beim User dienen.

[Wzut]

Erinnerst du dich noch an IsConsumptionRecommended ?

Ja sicher, hatte auch seine Fans. Aber da hast du mehr Ahnung von als ich und du must dann auch die Daten erstmal wieder irgendwie erfinden.
Das entfernen von ein paar Kommantare Zeichen und wiederbeleben der Icon Anzeige in der Grafik ist dann nur noch ein Klacks.

[DS_Starter]

Hab eine neue V hochgeladen.
Die einzelnen Ringpuffer sind in einem Puffer "circular" aufgegangen. Mit get <> pvCircular sieht man den Inhalt.
Es gibt dazu die Funktion CircularVal um die Werte abzufragen.
Ich habe übrigens das

Code Auswählen Erweitern


my $def  = shift // 0;


wieder entfernt. Du fragt in deiner sub auf "exists($hfcg->{$i}{weather})" ab. Wenn die Funktion dann immer einen default Wert zurück gibt, wirst du nicht glücklich denn {weather} bekommt man jetzt mit:

Code Auswählen Erweitern


$hfcg->{$i}{weather} = CircularVal ($hash, $hfcg->{$i}{time_str}, "weatherid", undef);


Ich habe jetzt im ganzen Modul schon auf CircularVal umgestellt.
Aufgefallen ist mir noch, dass dir für history_hour <0 die historischen WeatherIds fehlen. Dazu muß ich dir noch das History-Hash erweitern. Momentan passen die Wettericons in diesem Fall nicht.
Desweiteren baue ich noch eine Funktion zur Abfrage des NextHours-Hash, damit das dann auch sauber ist.

[Wzut]

sehr schön und ja hast recht mit undef ....
Ich halte mich jetzt mit der sub ein paar Tage zurück, da ich im Moment neue MAX! Nüsse zu knacken habe

[DS_Starter]

Die historischen WeatherIds werden jetzt auch befüllt und die  Funktion zur Abfrage des NextHours-Hash ist eingebaut.

@all, die letzte Zeit war es ein ziemlich einseitiger Dialog zwischen Wzut und mir ... wahrscheinlich hat sich keiner getraut upzudaten. 

Ich denke jetzt wäre wieder ein guter Zeitpunkt das Modul mal zu aktualisieren.

LG,
Heiko

[Wzut]

ziemlich einseitiger Dialog

schwarzer Schimmel ? einseitig = Mono
Neue Version  geladen und sofort ist für gestern Abend 23:00 Uhr das bisher fehlende Wetter Icon erschienen.

[DS_Starter]

schwarzer Schimmel ? einseitig = Mono

Hab auch erst ne Weile drüber nachgedacht. Aber weil wir beide uns ausgetauscht haben, hatte ich mich für Dialog entschieden, allerdings einseitig.    Nun ja ...

Frage ... für die Datenbankfreunde wären doch meiner Meinung nach zur Zeit die Werte für

PVforecast
PVreal

interessant denke ich. Jeweils mit dem relevanten Timestamp. PVreal bekommt man theoretisch auch von seinem WR geliefert, aber ich denke da so an Konstrukte mit Dummy etc. wo es sich sicherlich besser macht diese hier aus dem Modul zu loggen.
Gibt es Meinungen/Ergänzungen dazu ?

[EinEinfach]

Gibt es Meinungen/Ergänzungen dazu ?

Für die Leute, die eine Visualisierung z.B. über Grafana umsetzen wäre ein Forecast-Reading mit unterschiedlichen Timestamps und natürlich unterschiedlichen Werten zu dem jeweiligen Timestamp interessant. Wie man mit den Werten umgeht, wenn Forecast sich ändern, überschreiben, alte behalten, weiß ich auch nicht. Ich brauche die alten Werte nicht.

[DS_Starter]

Ich habe das Eventmanagement geprüft/korrigiert. Es gibt keine NextHour-Readings mehr. Diese Daten findet man mit get <> nextHours wenn es interessiert. Sonst werden die nur intern für die Steuerung verwendet. Das spart Readings + Events.

Ansonsten gibt es jetzt zusätzliche Events für das Logging für PVforecast, PVreal mit jeweils für den Wert zutreffenden Timestamp:

Code Auswählen Erweitern


2021-03-24 01:00:00.000 SolarForecast SolCast5 PVreal: 0
2021-03-24 02:00:00.000 SolarForecast SolCast5 PVreal: 0
2021-03-24 03:00:00.000 SolarForecast SolCast5 PVreal: 0
2021-03-24 04:00:00.000 SolarForecast SolCast5 PVreal: 0
2021-03-24 05:00:00.000 SolarForecast SolCast5 PVreal: 0
2021-03-24 06:00:00.000 SolarForecast SolCast5 PVreal: 0
2021-03-24 07:00:00.000 SolarForecast SolCast5 PVreal: 35
2021-03-24 08:00:00.000 SolarForecast SolCast5 PVforecast: 103
2021-03-24 08:00:00.000 SolarForecast SolCast5 PVreal: 347
2021-03-24 09:00:00.000 SolarForecast SolCast5 PVforecast: 409
2021-03-24 09:00:00.000 SolarForecast SolCast5 PVreal: 738
2021-03-24 10:00:00.000 SolarForecast SolCast5 PVforecast: 863
2021-03-24 10:00:00.000 SolarForecast SolCast5 PVreal: 2930
2021-03-24 11:00:00.000 SolarForecast SolCast5 PVforecast: 1347
2021-03-24 11:00:00.000 SolarForecast SolCast5 PVreal: 665
2021-03-24 12:00:00.000 SolarForecast SolCast5 PVforecast: 1746
2021-03-24 13:00:00.000 SolarForecast SolCast5 PVforecast: 2183
2021-03-24 14:00:00.000 SolarForecast SolCast5 PVforecast: 2328
2021-03-24 15:00:00.000 SolarForecast SolCast5 PVforecast: 2334
2021-03-24 16:00:00.000 SolarForecast SolCast5 PVforecast: 2081
2021-03-24 17:00:00.000 SolarForecast SolCast5 PVforecast: 1593
2021-03-24 18:00:00.000 SolarForecast SolCast5 PVforecast: 1150
2021-03-24 19:00:00.000 SolarForecast SolCast5 PVforecast: 427
2021-03-24 20:00:00.000 SolarForecast SolCast5 PVforecast: 59


Das global Attr mseclog wird berücksichtigt. Die zusätzlichen Events kann man nicht mit event-on-.* abstellen momentan.

Liegt wieder im contrib wer mag.

[DS_Starter]

Ich habe die Eventgenerierung nochmal angepasst. Gridconsumption ist nun auch mit dabei.
Außerdem wird immer nur die letzte abgeschlossene Stunde generiert, z.B. aktuell:

Code Auswählen Erweitern


2021-03-24 16:00:00.000 SolarForecast SolCast PVforecast: 2501
2021-03-24 16:00:00.000 SolarForecast SolCast PVreal: 2721
2021-03-24 16:00:00.000 SolarForecast SolCast Gridconsumption: 0


Das hat zwei Vorteile:
1. weniger Events
2. es wird immer nur ein abgeschlossener Zeitraum gemeldet. Die Werte ändern sich nicht mehr und in der Datenbank gibt es demzufolge nur einen einzigen Datensatz. Außerdem ist das wichtig falls man mit einem primary key in der DB arbeitet.