76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Parallix]

Dass offensichtlich fehlerbehaftete Daten aber einfach weiter prozessiert werden, halte ich für sehr problematisch.

Ja ist es. Nur kann das Modul nicht immer als regulierende Instanz aufteten und alle Input-Fehler ausbügeln. Das sehe ich nicht als dessen Aufgabe.
Allerdings werden fehlerhafte Input-Daten nicht für die weiteren Prognoseberechnungen gespeichert. Sichtbar als "aktuelle Daten" sind sie schon.

Wenn die Daten nicht im Rahmen der weiteren Prozesssierung herangezogen werden, bin ich schon sehr beruhigt. Hatte das Gegenteil angenommen, da die Verbrauchsprognose immer sehr seltsame Werte liefert. Aktuell sehe ich für morgen eine Verbrauchsschätzung von 0,2kWh, was ja prima wäre, aber natürlich absolut utopisch ist.

In deinem speziellen Fall sollte man sich das mal anschauen um zu erkennen woher das Problem kommt denn Vermutungen helfen nicht wirklich. Vllt. hat ein Datenlieferant (Device) ein Problem welches dort gerichtet werden muß.
Wahrscheinlich hilft hier ein "set ... ctrDebug collectData". Das können wir uns mal anschauen.
Ist halt etwas aufwändig wenn es nur sporadisch auftritt, Debug schreibt jede Menge Daten.

Meinerseits gehe ich davon aus, dass die Ursache für das o.g. Verhalten darin zu suchen ist, dass die Daten via Modbus UDP geholt werden und gelegentlich nicht Readings mit gleichem Zeitstempel aktualisiert vorliegen. Werde aber mal versuchen, das genauer herauszufinden. Ist - wie Du bereits geschrieben hast - aufgrund des sporadischen Auftretens halt nur recht aufwändig.

[DS_Starter]

Hatte das Gegenteil angenommen, da die Verbrauchsprognose immer sehr seltsame Werte liefert. Aktuell sehe ich für morgen eine Verbrauchsschätzung von 0,2kWh, was ja prima wäre, aber natürlich absolut utopisch ist.

Das kann man sich mal anschauen über ein "get ... pvHistory", dort ist für jede Stunde der Key 'con' relevant.
Vllt. gibt es einen regelmäßigen "Ausreißer". Ich will ja nicht generell ausschließen dass das Modul gegensteuern kann, aber ich muß genau wissen was warum woher kommt bevor ich korrigierende Maßnahmen ergreife sonst gibt es heilloses Chaos.

Meinerseits gehe ich davon aus, dass die Ursache für das o.g. Verhalten darin zu suchen ist, dass die Daten via Modbus UDP geholt werden und gelegentlich nicht Readings mit gleichem Zeitstempel aktualisiert vorliegen.

Der Zeitstempel ist für das SF egal, es nimmt nur den Wert aus dem Reading.
Es gibt Module die arbeiten mit einem "updateReadingIfchanged", d.h. wenn sich der Wert des Readings nicht ändert, erfolgt keine Update, auch des Zeitstempels nicht (was ich persönlich für unschön/irreführend halte und deswegen auf diese Funktion generell verzichte). Trotzdem hat das Reading aber einen gelieferten Wert und ist nur nicht aktualisiert.
Das ist auch ein Grund herauszubekommen woher dieses Problem ursächlich kommt.

[DS_Starter]

@Parallix,
möglicherweise ist ein ctrlDebug=consumption,collectData wirkungsvoller.

Es gibt nämlich bei einem negativen Hausverbrauch die Meldung:

 "... The calculated Energy consumption of the house is negative. This appears to be an error. Check Readings ..."

[Parallix]

Hatte das Gegenteil angenommen, da die Verbrauchsprognose immer sehr seltsame Werte liefert. Aktuell sehe ich für morgen eine Verbrauchsschätzung von 0,2kWh, was ja prima wäre, aber natürlich absolut utopisch ist.

Das kann man sich mal anschauen über ein "get ... pvHistory", dort ist für jede Stunde der Key 'con' relevant.
Vllt. gibt es einen regelmäßigen "Ausreißer". Ich will ja nicht generell ausschließen dass das Modul gegensteuern kann, aber ich muß genau wissen was warum woher kommt bevor ich korrigierende Maßnahmen ergreife sonst gibt es heilloses Chaos.

Hier die pvHistory-Daten:

[Parallix]

Der Zeitstempel ist für das SF egal, es nimmt nur den Wert aus dem Reading.

Wenn SF den Hausverbrauch aus einer Differenzbildung von nicht synchron gewonnenen Daten (unterschiedlicher Zeitstempel) bestimmt, dann kann das doch zu o.g. Problem führen, oder?

[DS_Starter]

Wenn SF den Hausverbrauch aus einer Differenzbildung von nicht synchron gewonnenen Daten (unterschiedlicher Zeitstempel) bestimmt, dann kann das doch zu o.g. Problem führen, oder?

Im Prinzip ja wenn Datenaktualität zuweit auseinanderliegt, allerdings fängt SF intern schon eine ganze Reihe von Situationen ab die zu Problemen führen können. Wie schon geschrieben ist der Zeitstempel kein verlässlicher Indikator für die Aktualität falls die Module ein updateReadingIfChanged verwenden.
Die Datenlieferanten in FHEM, also die Devices, werden niemals synchrone Zeitstempel der gelieferten Readings haben. Sie liefern auch nicht wirklich die Zustände in Echtzeit ab.
Zum Beispiel aktualisiert SMAEM (Energiemesser) typerischerweise alle 60 Sekunden den Stand. Welche Leistung 15 Sekunden vor dem Update bezogen wurde ist unbekannt.

Es wird also immer einen Gap zur absoluten Realität geben. Der ist aber i.A. hinreichend klein dass er keine Probleme macht. Aber als User kann man durchaus Maßnahmen ergreifen dass die Datenlieferanten relativ synchrone Daten liefern.

Man nimmt ein führendes Device, z.B. das SMAEM und triggert über ein Notify alle anderen Devices (z.B. SMAInverter) an die Daten abzurufen sobald die Readings in SMAEM aktualisiert wurden. Das geht mit anderen Devices sicherlich ähnlich. Die meisten Devices haben sicherlich einen Modus um per Anforderung Daten zu holen, zumindest wenn sie aktiv Daten abrufen können.
 

[Parallix]

Zum Beispiel aktualisiert SMAEM (Energiemesser) typerischerweise alle 60 Sekunden den Stand. Welche Leistung 15 Sekunden vor dem Update bezogen wurde ist unbekannt.

Das ist auch nicht ganz so tragisch, denn eine Energiemessung - auf Basis bereits vorliegender integraler Werte - ist wesentlich robuster als eine instantane Leistungsmessung. Daher verstehe ich auch nicht, warum WR-Leistungsdaten häufig in Modulen integriert werden, statt direkt die WR-Energiedaten zu prozessieren. In SF werden - wahrscheinlich abgesehen von den Zahlen im Flow - ja glücklicherweise Enegiedaten prozessiert, richtig?

[DS_Starter]

@Parallix auf den ersten Blick ...

Es gibt heute Bereiche die ganz ok. aussehen:

Code Auswählen Erweitern

834033    787610    742938    705725    100    100    0    0    0    -59
834033    787610    742938    705725    200    100    0    100    100    60
834033    787610    742938    705725    -18    0    100    300    300    278
834154    787709    742938    705725    699    0    599    2100    2100    682
834564    788144    742938    705725    557    0    301    2800    2800    1350
835543    789047    742938    705725    74880    80500    2300    0    0    1377
837091    790850    742938    705725    307    0    2500    3100    3100    1303


Die Hohe Entladeleistung der Bat kommt wahrscheinlich von der Ladung eines E-Autos?

Dann gibt es an vorherigen Tagen die Bereiche:

Code Auswählen Erweitern

0    -    0    -    -200    0    200    0    0    -250
0    -    0    -    -400    0    400    0    0    -200
0    -    0    -    -199    0    199    0    0    -91
0    -    0    -    -1000    0    1000    0    0    -103
-    -    -    -    8901    700    13899    22200    22200    5002
0    -    0    -    -700    0    700    0    0    -60
0    -    0    -    -200    0    200    0    0    -74
0    -    0    -    -200    0    300    0    0    -30
0    -    0    -    -100    0    100    0    0    -57
0    -    0    -    -300    0    300    0    0    -20
0    -    0    -    -300    0    300    0    0    -40
0    -    0    -    -200    0    200    0    0    -13
0    -    0    -    -300    0    300    0    0    -26
0    -    0    -    -100    0    300    200    200    76
0    -    0    -    300    0    300    600    600    278
0    -    0    -    -200    0    2200    2000    2000    692

Hier fehlt die Batterie(n).
Ich nehme an du hattest die Batterien bereits im Hausnetz, aber noch nicht in SF integriert.
Der Lade/Entlade-Anteil an fehlt dann in der Summenbildung.
Die History geht normalerweise bis 31 Tage zurück. Du kannst für die Verbrauchsprognose vorerst mit dem Attr affectConsForecastLastDays = 1 oder 2 setzen um nur die letzten 1 bzw. 2 Tage für den Forecast heranzuziehen.
Beachte auch Attr affectConsForecastIdentWeekdays dazu.

In SF werden - wahrscheinlich abgesehen von den Zahlen im Flow - ja glücklicherweise Enegiedaten prozessiert, richtig?

Ja, dafür brauche/verwende ich die entsprechenden Schlüssel in den setup-Attributen. Es werden dann entsprechende Differenzen erstellt. Daher kommt auch allgemeine Forderung nach stetig steigenden Zählern wo es wichtig ist.

[Parallix]

@Parallix auf den ersten Blick ...

Es gibt heute Bereiche die ganz ok. aussehen:

Code Auswählen Erweitern

834033    787610    742938    705725    100    100    0    0    0    -59
834033    787610    742938    705725    200    100    0    100    100    60
834033    787610    742938    705725    -18    0    100    300    300    278
834154    787709    742938    705725    699    0    599    2100    2100    682
834564    788144    742938    705725    557    0    301    2800    2800    1350
835543    789047    742938    705725    74880    80500    2300    0    0    1377
837091    790850    742938    705725    307    0    2500    3100    3100    1303


Die Hohe Entladeleistung der Bat kommt wahrscheinlich von der Ladung eines E-Autos?

Nein, ich habe (noch) kein Elekro-Auto.

Wahrscheinlich sind die hohen Werte auf Datenmüll zurückzuführen. Möglicher Grund: Im FHEM BYD-Modul bekomme ich immer mal wieder

Code Auswählen Erweitern

Error: Can't connect to 192.168.2.16:8080  bzw. Error: Can't connect to 192.168.2.17:8080 (habe ja zwei BAT-Systeme). Leider bekomme ich WR-seitig derzeit noch nicht alle Daten vom zweiten Akku, da mir hierzu schlicht einige Modbus-Register für BAT2 fehlen.

[Parallix]

...
Dann gibt es an vorherigen Tagen die Bereiche:

Code Auswählen Erweitern

0    -    0    -    -200    0    200    0    0    -250
0    -    0    -    -400    0    400    0    0    -200
0    -    0    -    -199    0    199    0    0    -91
0    -    0    -    -1000    0    1000    0    0    -103
-    -    -    -    8901    700    13899    22200    22200    5002
0    -    0    -    -700    0    700    0    0    -60
0    -    0    -    -200    0    200    0    0    -74
0    -    0    -    -200    0    300    0    0    -30
0    -    0    -    -100    0    100    0    0    -57
0    -    0    -    -300    0    300    0    0    -20
0    -    0    -    -300    0    300    0    0    -40
0    -    0    -    -200    0    200    0    0    -13
0    -    0    -    -300    0    300    0    0    -26
0    -    0    -    -100    0    300    200    200    76
0    -    0    -    300    0    300    600    600    278
0    -    0    -    -200    0    2200    2000    2000    692

Hier fehlt die Batterie(n).
Ich nehme an du hattest die Batterien bereits im Hausnetz, aber noch nicht in SF integriert.
Der Lade/Entlade-Anteil an fehlt dann in der Summenbildung.
...

Bis zur Einführung der Multi BAT System"-Features in SF hatte ich für SF beide BATs für extern zusammengefasst (lief viele Monate). Die Lücke könnte während der Umstellung "Single BAT System" -> "Multi BAT System" entstanden sein.

[DS_Starter]

Ok. Die weiter oben genannten Attr werden dir sehr wahrscheinlich helfen.
Die pvHistory speichert max. 31 Tage, d.h. die Problemdaten werden nach ihrer Haltezeit sukszessive automatisch bereinigt. Dann kann man die Attr auch wieder hochsetzen bzw. löschen.

Es gibt auch die Methode die pvHistory selektiv oder ganz zu löschen, siehe "set ... reset pvHistory".

[Parallix]

Ok. Die weiter oben genannten Attr werden dir sehr wahrscheinlich helfen.
Die pvHistory speichert max. 31 Tage, d.h. die Problemdaten werden nach ihrer Haltezeit sukszessive automatisch bereinigt. Dann kann man die Attr auch wieder hochsetzen bzw. löschen.

Es gibt auch die Methode die pvHistory selektiv oder ganz zu löschen, siehe "set ... reset pvHistory".

Habe jetzt affectConsForecastLastDays=1 und affectConsForecastIdentWeekdays=1 gesetzt und bin gespannt, ob die nächsten Tage alles (noch) besser wird.

Bei Sichtung der Modul-Doku ist mir aufgefallen, dass die Beschreibung von affectConsForecastLastDays möglicherweise missverständlich ist, da von vorangegangenen Tagen die Rede ist. Im Zusammenspiel mit affectConsForecastIdentWeekdays sind bei affectConsForecastLastDays aber wahrscheinlich nicht die vorangegangenen Tage, sonder die vorangegangenen Wochentage gemeint. Wenn ja, so könnte man das vielleicht auch so schreiben.

[DS_Starter]

@all,

ich habe ein wenig aufgeräumt:

- das Attr graphicBeam1MaxVal ist obsolet, es ist durch die Weiterentwicklungen bereits länger wirkungslos
- das (experimentelle) Attr ctrlAreaFactorUsage ist obsolet -> die SF Devices Model DWD nutzen jetzt
  per Standard die Routine von PAH ergänzt um die Flexanpassung abhängig von der Bewölkung (ursprünglich trackFlex)
- die ComRef ist editiert, @Parallix deinen Hinweis habe ich mit eingearbeitet

Die Anpassungen werden automatisch durchgeführt, ihr braucht nicht aktiv werden außer ggf. "save config" drücken. 

LG,
Heiko

[DS_Starter]

In der nächsten Version (morgen früh) ist folgendes eingebaut:

- im Header gibgt es ein weiters Icon zum direkten und einfachen Absprung zum SolarForecast Wiki
- die Berechnung der Verbrauchsprognose ist von einer Durchschnittsermittlung auf die Verwendung des Median
  umgestellt. Ich verspreche mir davon eine noch bessere Ausfilterung von Ausreißern zur Unter- oder Oberseite.

Die V liegt auch schon in meinem contrib.

LG

[Parallix]

Irgendwo weiter oben hatten ich schon einmal geschrieben. dass (bei Vorliegen mehreren BAT-Devices) ein zusammengeführter SOC nur dann einigermaßen sinnvoll erscheint, wenn er aus den gewichteten Mittelwerten (Wichtung mit der jeweiligen BAT-Kapazität) der einzelnen BAT-SOCs gewonnen wird. Anhand der Modulinfo hat man derzeit noch das Gefühl, dass die o.g Wichtung noch nicht erfolgt, wenn z.B. folgendes betrachtet wird:

batteryTrigger ...
...
Der verwendete SoC wird als Durchschnitt des SoC aller definierten Batterie Geräte gebildet.
...

Ist dem wirklich so?