76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[kask]

Weil es mal ging heißt es ja nicht das es gut war

Code Auswählen Erweitern

SMATripower6 pv=PV_Gesamterzeugung:W etotal=PV_Gesamtertrag:Wh capacity=12260

In deiner definition steht aber bei PV_Gesamtertrag, was im currentInverterDev aber als totaler Gesamtzähler einzugegeben ist, der totale Tageszähler drin.

Code Auswählen Erweitern

PV_Gesamtertrag {ReadingsVal("SMATripower6","SPOT_ETODAY",0) + ReadingsVal("SMATripower5","SPOT_ETODAY",0)},

Sicher das es nicht so sein sollte?.

Code Auswählen Erweitern

SMATripower6 pv=PV_Gesamterzeugung:W etotal=PV_SPOT_ETOTAL_Gesamt:Wh capacity=12260

Habe selber kein SMA. Habe ein bischen hier im Forum gestöbert und würde sagen das es mir richtiger erscheint.

[300P]

würde ich auch so sehen....

[Dracolein]

ihr habt recht.... 

Wobei laut Doku:

currentInverterDev <Inverter Device Name> pv=<Readingname>:<Einheit> etotal=<Readingname>:<Einheit> [capacity=<max. WR-Leistung>]

Legt ein beliebiges Device und dessen Readings zur Lieferung der aktuellen PV Erzeugungswerte fest. Es kann auch ein Dummy Device mit entsprechenden Readings sein. Die Werte mehrerer Inverterdevices führt man z.B. in einem Dummy Device zusammen und gibt dieses Device mit den entsprechenden Readings an.
Die Angabe von capacity ist optional, wird aber zur Optimierung der Vorhersagegenauigkeit dringend empfohlen.

pv    Reading welches die aktuelle PV-Erzeugung liefert
etotal    Reading welches die gesamte erzeugte PV-Energie liefert (ein stetig aufsteigender Zähler)
Einheit    die jeweilige Einheit (W,kW,Wh,kWh)
capacity    Bemessungsleistung des Wechselrichters gemäß Datenblatt, d.h. max. möglicher Output in Watt
(Die Angabe ist optional, wird aber dringend empfohlen zu setzen)

Beispiel:
set <name> currentInverterDev STP5000 pv=total_pac:kW etotal=etotal:kWh capacity=5000

# Device STP5000 liefert PV-Werte. Die aktuell erzeugte Leistung im Reading "total_pac" (kW) und die tägliche Erzeugung im Reading "etotal" (kWh). Die max. Leistung des Wechselrichters beträgt 5000 Watt.

da wäre der totale Tageszähler anzugeben und nicht der totale Zähler über die gesamte Laufzeit...
...Kopfkratz...
... komisch, dass dies über die letzten fast 2 Jahre gar nicht aufgefallen war bei mir

edit:
wurde hier auch schon diskutiert. Habe es mal wie von Euch vorgeschlagen geändert & werde beobachten.

https://forum.fhem.de/index.php?topic=137058.msg1311220#msg1311220

[gent]

Hi,
ich habe eine Frage zum Wiki. Dort steht zum Schlüssel "auto" im "Beispiel Registrierung eines Shelly Devices":

Ist das angegebene Reading (im Beispiel "automatic") im Shelly.shellyplug3 nicht vorhanden, wird es vom Modul automatisch mit dem Wert "1" angelegt.

Das passiert bei meiner Consumer Definition des Consumers aber ncht:

Code Auswählen Erweitern

attr Forecast consumer01 SP.LaderHolger type=charger power=200 icon=electric_car_charger mintime=SunPath on=on off=off etotal=energy:Wh pcurr=power:W mode=can auto=automatic

Im Shelly Device SP.LaderHolger habe ich kein Reading "automatic".

Ist das Wiki da nicht mehr aktuell oder habe ich da etwas falsch verstanden?

Liebe Grüße
Holger

[kask]

Selbst keine Ahnung.
Aber hast du mal das Reading von Hand angelegt und geguckt ob das dann funktioniert?

[kask]

Ich hab ein Problem.
Ich bin momentan mein System am optimieren. Dazu versuche ich unteranderem die events zu reduzieren.
Jetzt habe ich folgende event-on-change regel angelegt bei meinen SolarForecast modulen.

Code Auswählen Erweitern

attr Forecast.* event-on-change-reading Today_MaxPVforecastTime,Today_PVdeviation:0.3,RestOfDay.*:50,T.*_PVforecast:50,Today_.*PV.*:50,Next.*cast:75,.*Tomorrow.*:50,statistic_.*Till.*:50

ich habe 7 Module laufen mit verschiedenen API's.

Code Auswählen Erweitern

Forecast
ForecastDWD
ForecastOpenMeteo
ForecastOpenMeteoEnsemble
ForecastOpenMeteoWorld
ForecastSolarAPI
VictronVRM

Und mit der event-on-change regel oben bekomme ich massiven CPU Load.
Der Trend im Bild zeigt das ich am ende wieder ein "event-on-change-reading .*" gesetzt habe und damit geht der load wieder runter.

Und jetzt die entscheidende Frage: Warum?
Kann mir das einer erklären?

Zudem würde ich gerne wissen ob man das geschwätzige Modul etwas ruhiger stimmen kann und wenn wie.

[300P]

Bei mir sind es sicherlich mehr als 400 definierte "Device" in der fhem.cfg und das FHEM läuft auf einem RPI4 (wird gebootet auf einer SSD).
Die zugehörige MARIA Datenbank ist extern auf auf einer QNAP.

=>> da wird man dann schon sensibel für den Datenwust und die anfallenden zugehörigen Events.



Hier mein Vorschlag:
Das wäre meiner Ansicht nach deine Freund zum reduzieren bei den Events. (also nur bei Datenänderung)
attr ForecastXYXYXYXYXYX event-on-change-reading .*

und dann noch dazu nehmen (wegen Logdatenmengen)....
attr ForecastXYXYXYXYXYX DbLogExclude .*
danach aber auch bitte danach nur die, die du auch "wirklich und lebenswichtig" immer wieder benötigst, mit "DbLogInclude" wieder reinnehmen.
(Bei mir sind das z.B. "0" geloggte Datensätze - und seit mehr als 2 Jahren für SF im DBLog)

Gruß
300P

[kask]

hmm, ich bin mir nicht sicher ob du das gelesen hast was ich geschrieben hatte.
Ich hatte bereits den regex .*, nun wollte ich weiter reduzieren bzw. besser filtern um die Datenmenge zu reduzieren.
Das Resultat ist das es weniger events werden aber die CPU load jetzt massiv ansteigt dadurch.

Ich loge auch garnichts von den Modulen selbst mit.

Ich habe auch einen Raspberry Pi mit knappen 600 Devices. Und so langsam komme ich an Grenzen.
Deshalb die geplannte optimierung.

[kask]

Vergesst was ich geschrieben hatte. Ich habe hier andere Probleme.
Der regex funktioniert jetzt ohne andere Änderungen.
Ich hatte vor kurzem das problem das wenn ich meine 99_myutis.pm geändert hatte das dann mein RAM kontinuierlich anstieg.
Ziemlich schnell sogar. Das hatte erste einmal gedauert bis ich das herausgefunden hatte.
Im Zuge dessen habe ich dann mein Datenaufkommen reduziert weil der load sehr, sehr oft über 1 lag (wir reden hier vom 1/4h load). So das das RAM-Leak Problem nicht mehr auftratt.
Den Grund kenne ich bis heute nicht.
Jetzt hatte ich weiter optimiert und als ich bei den weniger gesprächigen  Modulen ankam. Hatte ich das oben genannte Problem.
Änderung rückgängiggemacht und der Load sank wieder. Aktiviert und er stieg. Fhem neu gestartet das gleiche verhalten.
Dann hier im Thread gefragt.
Dann weiter probiert, aber der Load ging nie soweit runter wie ich Ihn vor der Event optimierung des Moduls hatte.

Jetzt habe ich letzendlich einen Reboot des ganzen Systems gemacht und der Load ist da wo er zuvor war und scheinbar stabil.

Mit ctrlInterval kann man den Interval der aktualisierung einstellen und damit auch das event aufkommen. Das hatte ich früher mal ziemlich tief gesetzt damit der flowchart öfter aktualisiert wurde. Jetzt sind aber in der Zwischenzeit weieter API's dazugekommen und ich habe diese immer mit RAW definition erstellt und somit auch immer den "schnellen" Interval mit geschlört. So das alle Module schön im 15sec Takt Daten aufbearbeitet hatten.

Also weiter suchen wo es be mir klemmt. Das Modul ist es jedenfalls nicht. Sehr dubios alles hier.

[kask]

Ich habe zwei Vorschläge für das Modul.
1.
Ich habe mehrere Module  aktiv. Könnte man nicht wenn ctrlInterval aktiv ist den ersten interval randomized in die zeit zwischen modul start und ctrlInterval value legen? Die Module laufen bei gleichem ctrlInterval bei mir ziemlich konstant gleich. Ich habe das behoben in dem ich allen unterscheidliche werte gegeben habe. Zum start sind sie syncron dann laufen die auseinander und dann nähern diese sich wieder. istnicht schick. schöner wäre es randomized zu machen dann hatte man immer mehr zeit zwischen den einzelnen modulen. Oder eventuell eine delay zeit vorgeben zu können wäre auch ok eventuell sogar besser. Das der erste Aufruf nach zeit x erst passiert. Somit könnte man das dann noch gesteuert timen.

2.
Könnte man in das Balkendiagramm nicht auch die Forcastconsumption einfliessen lassen. Jetzige Balken nur halb so breit und der consumption Forecast mit rein. Ist vieleicht etwas tricky mit den Zahlenwerten (eventuell vertikal anordnen dann?) . Fände ich schick den vermutliche Verbrauch auch zu sehen.

[300P]

Wie wäre es so:

Die SF die dir am "Herzen" liegt und treffsicher für dich ist mit einem Interval einer niedrigen Primzahl versehen.
(Primzahlen bis 100 lauten: 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97.)

Die anderen dann mit weit höheren Primzahlen im Hunderterbereich 

Damit sollte es grundsätzlich weniger gleichzeitig startende Läufe der diversen SF geben.

Gruß
300P

[kask]

Die Primzahl Theorie ist ja ganz schick..aber 3,5,7,11 x prim ist nun mal nix mehr prim.
Da kann ich auch 80,81,87 nehmen. Die Zahlen werden immer zusammen laufen und wieder auseinander gehen. Mit Primzahlen halt etwas gestreckt.
Aber nicht annähernd nie wie es ein Offset machen würde.
Das wird sich nie ändern. Mit einem Offset würden diese das auch machen. Aber nach einer größeren Zeit weil die Aufrufe Differenzen haben werden. Auch wenn es nur ms sind. Das mit unterschiedlichen Intervalen ist immer Käse (sofern nicht + Zufallszahl im jeden Call, und das will der eine vieleicht nicht damit würde die Glechmässigkeit fehlen).
Mit festen Werten ist immer eine Kontinuität im Spiel. Alles nur ein Frage der Zeit bis sich wieder welche treffen. Und bei dreien werden sich 2 immer schneller treffen bei angenommen werten von 71, 73, 79. 5183 (1,43h), 5609(1,55h), 5767 (1,6h)
Spätestens nach der multiplization aller Intervalle Treffen diese sich wieder (409457 (4,73d). Die natürliche Aufruf Differenz mal ausseracht gelassen).
Ich weiß sind 4,73 Tage. Aber wenn richtig, dann auch wirklich richtig durchdacht und mit Verstand.
Und zwischen drinne werden sich so mehrere treffen (hier im Beipsiel max 2).
Wenn ich kleine Intervalle haben möchte, was ich eigentlich anstrebe, dann geht das ganze halt nur noch schneller. Primzahl hin oder her.

Vieleicht bau ich mir ein notify was mir eine Zufallszahl in den ctrlInterval auf meinen Intervall schreibt.
Oder ein do_if/notify was beim ersten call das Modul disabled und wieder enabled nach meinem Offset. Weiß nicht was die timer dann da machen. Ich hoffe reseten
Das ist aber auch wieder Overhead. Wollte ich eigentlich loswerden.

Ich bin für einen Offset;) Ich brauch einen Offset für den ersten intervall call

[Christian83]

Hallo kask,

mal abgesehen davon, dass deine SF Devices immer von den dahinter liegenden Werten abhängig sind. Was genau ist der Sinn von mehreren zeitlich versetzten SF Devices?

[kask]

Mein Hauptanliegen liegt bei dem Consumptionwerten hierbei.
Nicht die PV Forecast Werte.
Da ist eine schnelle Abfrage nicht nötig.
Dafür sind mehrere Devices nicht wirklich nötig. So wie bisher festgestellt.
Ich bilde mir aus (fast) allen SF's z.B. auch Werte. Und der Durschnitt aller Devices liegt meist am nächsten zum wirklichen Ertrag.
Klar kann es passieren das einzelne SF's genauer sind.
Aber gerade bei unbeständigem Wetter ist es so immer genauer und bei gutem Wetter ist die Abweichung vernachlässigbar zu dem besseren SF's.
Für mich und meine Anlage ist der Durchschnittswert mein Favorit.
Deshalb habe ich nicht "die" API die am besten ist. Klar habe ich darunter Favoriten. Aber selbst die sind meist nicht genauer wie der Durschnitt aller.

Und bei mehreren Devices macht es halt auch Sinn diese Zeitversetzt durch zu takern. Sind ja nicht gerade die Resourcen schonensten Module mitunter.

Ich muss mal gucken wie ich das Umsetzte was ich mir da denke.
Vieleicht lass ich ein Modul öfter takern was die beste Aufrufverarbeitungszeit im Durchschnitt hat. VictronVRM vermutlich.

Code Auswählen Erweitern

ForecastDWD                              CODE(0x559d502140)                     364  6877772  561425.86     0.08     0.00     0.00 02.05. 00:28:23 HASH(ForecastDWD)
 ForecastSolarAPI                         CODE(0x559d502140)                     334  6877772  492662.48     0.07     0.00     0.00 02.05. 00:11:33 HASH(ForecastSolarAPI)
 Forecast                                 CODE(0x559d502140)                     330  6877772  542474.85     0.08     0.00     0.00 02.05. 00:00:05 HASH(Forecast)
 ForecastOpenMeteoEnsemble                CODE(0x559d502140)                     326  6877772 1075603.99     0.16     0.00     0.00 02.05. 00:00:04 HASH(ForecastOpenMeteoEnsemble)
 ForecastOpenMeteoWorld                   CODE(0x559d502140)                     313  6877772  530529.66     0.08     0.00     0.00 02.05. 00:00:04 HASH(ForecastOpenMeteoWorld)
 ForecastOpenMeteo                        CODE(0x559d502140)                     309  6877772  511606.73     0.07     0.00     0.00 02.05. 00:00:05 HASH(ForecastOpenMeteo)
 ForecastVictronVRM                       CODE(0x559d502140)                     290  6877772  499226.55     0.07     0.00     0.00 02.05. 00:00:05 HASH(ForecastVictronVRM)                   


Und die anderen tacker ich in einem sehr großem Interval durch. Ich muss mal gucken.

[TheTrumpeter]

Ich bin für einen Offset;) Ich brauch einen Offset für den ersten intervall call

Oder sowas wie "alignTime". Damit könnte der Start versetzt stattfinden.