Leistungsprognose für Wechselrichter

[DS_Starter]

@all,

ich gehe davon dass ich die Sache mit der SolCast Call Anzeige im Header gefunden und beseitigt habe.
Liegt im contrib.
Es bietet sich an die Version heute nach Sonnenuntergang upzudaten damit das Device morgen mit einem "sauberen" Zähler
beginnen kann.

Sorry dass es momentan soviele Änderungen gibt.  Wir sind gerade auf der "Zielgeraden" und ich möchte viele Sachen noch umsetzen und geradeziehen bevor ich mich daran mache das Modul für den CheckIn vorzubereiten.
Danach etwas zu ändern ist natürlich auch kein Problem, aber für mich viel aufwändiger. 

Danke dass ihr das alles aushaltet und mich mit eurer Meinung und Testergebnissen unterstützt !!   

Heiko

[mcp]

Immer gerne doch. Das ist das Mindeste was man machen kann

Ich hab' eine Bitte:

Bisher meldet sich die Version in FHEM so:

FVERSION
76_SolarForecast.pm:v0.70.5-s21735/2020-04-20 TESTING

Kannst du evtl. das Datum auch immer mit aktualisieren, wenn du die Versionsnummer änderst?

Wegen meinem Bug vor paar Tagen hat's gedauert bis ich darauf gekommen bin, dass es an einem Update des Moduls lag - hatte aufs Datum geschaut und mir gedacht: ne, is nicht neu bzw. aktualisiert



Das wäre top. Danke dir.

[DS_Starter]

Na ich kann das Datum ganz entfernen. Das wird nämlich vom SVN selbst gesetzt wenn man das Modul offiziell eincheckt.
Das jetzige Datum stammt noch von einer älteren Vorlage.
Jedenfalls verwirrt das dann nicht mehr.

Habe es ins contrib geladen. Jetzt zeigt das Internal nur noch die aktuelle Version:

Code Auswählen Erweitern


FVERSION    0.70.6


Jetzt habe ich es auch mit Datum hinbekommen, muß nur dran denken es zu ändern:

Code Auswählen Erweitern


FVERSION  76_SolarForecast.pm:v0.70.6-s21735/2022-10-19 TESTING


[xerion]

@all,

ich gehe davon dass ich die Sache mit der SolCast Call Anzeige im Header gefunden und beseitigt habe.
Liegt im contrib.
Es bietet sich an die Version heute nach Sonnenuntergang upzudaten damit das Device morgen mit einem "sauberen" Zähler
beginnen kann.

Sorry dass es momentan soviele Änderungen gibt.  Wir sind gerade auf der "Zielgeraden" und ich möchte viele Sachen noch umsetzen und geradeziehen bevor ich mich daran mache das Modul für den CheckIn vorzubereiten.
Danach etwas zu ändern ist natürlich auch kein Problem, aber für mich viel aufwändiger. 

Danke dass ihr das alles aushaltet und mich mit eurer Meinung und Testergebnissen unterstützt !!   

Heiko

Moin Heiko,

bei mir sieht es jetzt besser aus:

[eldrik]

Moin, ich habe auch so eine ähnliche Anzeige und nutze auch zwei Account mit drei Strings:

EDIT:
Meinst du diese Readings:

Code Auswählen Erweitern

inverterStrings
OST,WEST_45,WEST_20

moduleDirection
OST=E WEST_45=W WEST_20=W

modulePeakString
OST=6.40 WEST_45=2.13 WEST_20=6.55

moduleRoofTops
OST=OST WEST_45=WEST_45 WEST_20=WEST_20



kurzes Feedback:

Ich habe gestern im Modul meine beiden Nordstrings zu einem großen einzelnen String zusammengefasst seitdem sehen die Werte weitaus besser aus und sind von prognostizierten Werten um die 30kwh auf 9 - 11kwh zurückgegangen, was tatsächlich sehr nah an den derzeitigen Erträgen liegt

Die jetzige Konfiguration werde ich noch etwas im Probebetrieb belassen und mich danach an die Verbraucher machen.

Tolles Modul!

Greetz
Eldrik

[xerion]

kurzes Feedback:

Ich habe gestern im Modul meine beiden Nordstrings zu einem großen einzelnen String zusammengefasst seitdem sehen die Werte weitaus besser aus und sind von prognostizierten Werten um die 30kwh auf 9 - 11kwh zurückgegangen, was tatsächlich sehr nah an den derzeitigen Erträgen liegt

Die jetzige Konfiguration werde ich noch etwas im Probebetrieb belassen und mich danach an die Verbraucher machen.

Tolles Modul!

Greetz
Eldrik

Ich kann leider nicht weiter zusammenfassen. Ich habe 2 Strings Ost und drei auf West und das auch noch mit unterschiedlichen Winkeln. Bei mir sieht es aber nicht so schlecht aus. Das Wetter ist nur aktuell zu schlecht um es richtig testen zu können.

[ambiman]

Hallo DS_Starter,

auch von meiner Seite ein herzliches Dankeschön für dieses Modul

Ich habe es seit nunmehr zwei Tagen in Betrieb genommen und möchte die Entwicklung gerne unterstützen.

Abseits etwaiger Bugs oder anderer Unzulänglichkeiten, würde ich gerne wissen welche Testdaten (Readings, verbose / debug Ausgaben o.ä.) ich liefern sollte damit das Modul weiter optimiert werden kann?

Viele Grüße und nochmals Danke,

ambiman

[DS_Starter]

Guten Morgen,

danke ambiman für dein Unterstützungsangebot. 

So pauschal lässt sich die Frage nicht beantworten. Hilfreich sind für mich Beobachtungen die aus Usersicht nicht schlüssig erscheinen, aus der Hilfe vllt. auch ungenügend ersichtlich sind.
Bei Define des Devices ist mir z.B. aufgefallen dass es an einer Stelle eine ungünstige Abfolge in der Guided Procedure gibt was ich leicht ändern kann.

Oder zuletzt dass die Anzeige der SolCast Requests in der Grafik bei manchen Usern eigenartig aussah. Solche Beobachtungen sind für mich hilfreich.

LG,
Heiko

[HoTi]

Hallo zusammen,

kann mir jemand helfen welche, der gefühlten 1000, readings ich von der Tesla Powerwall einsetzen muss.
Mir raucht der Kopf....

vg
Tim

[DS_Starter]

Hallo Tim,

ich selbst habe keine Powerwall und weiß auch nicht ob einer der SolarForecast Nutzer eine hat.
Spielt aber keine Rolle.
Du möchtest bestimmt den Setter "set ... currentBatteryDev" setzen, richtig ?

Du brauchst also aus deinem Powerwall Device die Readings, die folgende Werte liefern:

Code Auswählen Erweitern


pin         Reading welches die aktuelle Batterieladung liefert (also Ladung in die Batterie)
pout Reading welches die aktuelle Batterieentladung liefert
intotal Reading welches die totale Batterieladung liefert (fortlaufender Zähler)
outtotal Reading welches die totale Batterieentladung liefert (fortlaufender Zähler)
charge Reading welches den aktuellen Ladezustand (in Prozent) liefert


Aus der Hilfe zum Powerwall Device müsste das eigentlich hervorgehen.
Ansonsten poste mal ein List von deinem Powerwall Device, dann können wir es sicherlich herausbekommen.

[DS_Starter]

Moin,

im contrib liegt die neue V 0.70.7

* die SolCast Qualitätsanzeige wird später "grün" . Es müssen mehr Tage für einen Durchschnitt vorhanden sein.
* die Guided Procedure beim ersten Define ist verbessert
* die Prüfung der Anlage ist erweitert.
* kleinere Fixes

LG

[Skusi]

Hallo zusammen,
ich habe das Modul nun auch schon ein paar Wochen laufen und spiele mit den Möglichleiten die es bietet.
Ein riesen Danke erstmal an DS_Starter für die Entwicklung des Moduls. Erstklassige Arbeit !!!

Eine Frage konnte ich mir aber bisher nicht beantworten, deshalb stelle ich sie mal hier.

Ich habe nun mal 3 Consumer per Dummy angelegt und beobachte die Schaltungen bzw die Planungs Daten. Mir ist da nicht ganz klar welche Leistung für z.b. eine Waschmaschine oder Geschirrspüler ich da angeben soll. Meine Geschirrspüler läuft ca  2 Std und zieht am Anfang ca 15min viel Leistung zum aufheizen des Wassers, läuft dann sehr lange mit nur ca 250 W um dann am Ende nochmal aufzuheizen mit ca 2500 W.

Auf dem Typenschild ist ja nun die Max Leistung angegeben. Diese wird ja aber nur kurzzeitig abgerufen.
Bei der Waschmaschine verhält sich das ja ähnlich.

Welche Angabe der Leistung sollte ich nun unter Power bei den Consumern angeben damit das Modul richtig plant ?

[DS_Starter]

Ich habe nun mal 3 Consumer per Dummy angelegt und beobachte die Schaltungen bzw die Planungs Daten. Mir ist da nicht ganz klar welche Leistung für z.b. eine Waschmaschine oder Geschirrspüler ich da angeben soll. Meine Geschirrspüler läuft ca  2 Std und zieht am Anfang ca 15min viel Leistung zum aufheizen des Wassers, läuft dann sehr lange mit nur ca 250 W um dann am Ende nochmal aufzuheizen mit ca 2500 W.

Auf dem Typenschild ist ja nun die Max Leistung angegeben. Diese wird ja aber nur kurzzeitig abgerufen.
Bei der Waschmaschine verhält sich das ja ähnlich.

Welche Angabe der Leistung sollte ich nun unter Power bei den Consumern angeben damit das Modul richtig plant ?

Man gibt die nominale Leistung lt. Herstellerangabe an, also 2500W in deinem Fall.
Mir ist natürlich bewußt dass die Wama bzw. der Geschirrspüler dieses von dir beschriebene Verhalten zeigen.
Deswegen werden intern sogenannte Energy Pieces entsprechend des angegebenen Verbrauchertyps (Schlüssel "type") errechnet bzw. abgeleitet.

Ich habe noch vor diese Ableitung durch eine Consumer abhängige Messung zu optimieren. Das wird aber nur klappen wenn der Consumer die Energiedaten in seinen Readings liefert (Schlüssel "etotal"). Ist noch ein bisschen Zukunftsmusik.

[Dracolein]

Ich habe weiterhin massenhaft Logeinträge von FreezeMon betreffend SolarForecast. Da ich der einzige hier bin, gehe ich davon aus, dass es ein individuelles Problem sein muss.

Ausschnitt:

Code Auswählen Erweitern


2022.10.23 11:00:03 1: [Freezemon] FreezeMonitor: possible freeze starting at 11:00:00, delay is 3.103 possibly caused by: tmr-FHEM::SolarForecast::centralTask(PVVorschau) tmr-DOIF_TimerTrigger(Beschattungsautomatik) tmr-HttpUtils_TimeoutErr(N/A)
2022.10.23 11:05:53 1: [Freezemon] FreezeMonitor: possible freeze starting at 11:05:50, delay is 3.083 possibly caused by: tmr-FHEM::SolarForecast::centralTask(PVVorschau)
2022.10.23 11:07:03 1: [Freezemon] FreezeMonitor: possible freeze starting at 11:07:00, delay is 3.398 possibly caused by: tmr-FHEM::SolarForecast::centralTask(PVVorschau)
2022.10.23 11:08:13 1: [Freezemon] FreezeMonitor: possible freeze starting at 11:08:10, delay is 3.96 possibly caused by: tmr-FileLog_addLog(Log_GasTag) tmr-FHEM::SolarForecast::centralTask(PVVorschau)
2022.10.23 11:09:24 1: [Freezemon] FreezeMonitor: possible freeze starting at 11:09:20, delay is 4.995 possibly caused by: tmr-FHEM::SolarForecast::centralTask(PVVorschau)
2022.10.23 11:10:35 1: [Freezemon] FreezeMonitor: possible freeze starting at 11:10:30, delay is 5.077 possibly caused by: tmr-OctoPrint_GetStatus(AnyCubicI3MegaS) tmr-FHEM::SolarForecast::centralTask(PVVorschau)
2022.10.23 11:11:45 1: [Freezemon] FreezeMonitor: possible freeze starting at 11:11:40, delay is 5.638 possibly caused by: tmr-FHEM::SolarForecast::centralTask(PVVorschau)
2022.10.23 11:12:56 1: [Freezemon] FreezeMonitor: possible freeze starting at 11:12:50, delay is 6.712 possibly caused by: tmr-FHEM::SolarForecast::centralTask(PVVorschau)


Die Logeinträge gehen noch weiter, ein Muster was mir auffällt ist, dass die genannten Delays immer länger werden. Weiter unten im Log sind wir bei 15, 20, 25 Sekunden delay angekommen.
In der Folge erscheinen weitere FreezeMon Einträge von anderen Devices wie SSCam oder SMAInverter, also Modulen, die ebenfalls aus dem Netzwerk Daten abgreifen. Ich interpretiere dies als Folgesymptome.

Ich werde SolarForecast nun konsequent 2-3 Tage deaktivieren, um zu sehen, ob die Probleme damit verschwinden. Schlicht, da ich sonst keinerlei Idee zur Ursachenforschung habe
- Pi neugestartet
- FHEM ist aktuell
- SolareForecast ist aktuell
- alle Pakete sind aktuell
- eigentlich auch keine spürbaren Betriebsstörungen, bis auf zeitliche Phasen zwischen 10-40 Minuten, in denen unglaublich viele o.g. Logeinträge erfolgen.

Ob mein Pi 4 mit (glaube ich) 2 GB RAM leistungstechnisch am Limit ist, würde mich interessieren. Leider adhock keine Kenntnisse, wie ich das in Erfahrung bringe.

[DS_Starter]

Hallo Dracolein,

erste Maßnahme ... FreezeMon entfernen.
zweite Maßnahme ... dnsServer im global Device setzen.
dritte Maßnahme ... System neu starten

dann schauen wir in die Zeiten. Für SolarForecast stelle ich euch die Zeiten zur Verfügung mit "get .. valCurrent"
Meine Zeiten zum Vergleich:

Code Auswählen Erweitern


runTimeAPIResponseProc => 0.8527
runTimeCycleSummary => 0.6808


runTimeCycleSummary ist die Zeit des centralTask. Zeige dann mal wie es bei dir aussieht. Verzögerungen von 10 s und höher sind absolut indiskutabel und auch nicht normal.