Leistungsprognose für Wechselrichter

[Dracolein]

Guten Morgen 

FVERSION 76_SolarForecast.pm:v0.70.9-s21735/2022-10-23 TESTING
currentRadiationDev: SolCast-API

Code Auswählen Erweitern


runTimeAPIResponseProc => 3.6709
runTimeCentralTask => 0.4768

Die API Response Time dürfte vermutlich bei mir länger sein, weil ich insg. 2 SolCast Accounts mit je 2 rooftop-IDs (=insg. 4 Strings) verwende, könnte das sein?

[DS_Starter]

Guten Morgen,

Die API Response Time dürfte vermutlich bei mir länger sein, weil ich insg. 2 SolCast Accounts mit je 2 rooftop-IDs (=insg. 4 Strings) verwende, könnte das sein?

Ja genau, allerdings sind das größtenteils Zeitanteile wo die Anfrage "unterwegs" ist.
Konsequenterweise müßte ich noch eine weitere Zeit erfassen die ausschließlich die Verarbeitungszeit in FHEM darstellt.
Mache ich vllt. noch.

Wie sieht es denn jetzt bei dir aus ?

[Dracolein]

Wie sieht es denn jetzt bei dir aus ?

Ich warte, dass der Kaffee seine Wirkung entfaltet 

Aktuell läuft alles. FreezeMon ist disabled=1.

Nochmaliger Werteabruf soeben:

Code Auswählen Erweitern


runTimeAPIResponseProc => 6.3708
runTimeCentralTask => 0.6701


[mcp]

Guten Morgen.

bei mir:

Code Auswählen Erweitern


runTimeAPIResponseProc => 1.4524
runTimeCentralTask => 2.2746


Raspberry Pi 4 Model B Rev 1.2, 4 GB RAM, 32 GB SD, Raspbian Bullseye, global DNS gesetzt, Load Average ~ 1

[DS_Starter]

@Dracolein, verschwende deine Credits nicht so 

Moin mcp,
runTimeCentralTask ist bei dir recht hoch.
Ich gehe mal diesen Weg noch ein Stück weiter und versuche die Zeit zu drücken.

[vuffiraa]

Guten Morgen,

dann werfe ich meine Zahlen hier auch noch mal in die Runde:

Code Auswählen Erweitern

runTimeAPIResponseProc => 3.2011
runTimeCycleSummary => 0.9193

Freezemon ist abgeschaltet und DNS ist eingetragen.

Soweit ich das im Code gesehen habe, wird die Zeit für runTimeAPIResponseProc ziemlich gleichverteilt in den beiden While-Schleifen der Subroutine __solCast_ApiResponse verbraucht.
Mein erster Kandidat wäre dabei die Subroutine ___convPendToPstart und dann convertTimeZone, bin mir aber nicht sicher.

Ansonsten läuft bei mir ein Perl 5.22.1, vielleicht gab es hier auch Optimierungen in neueren Versionen.

VG

[SparcWolf]

Moin,

bei mir folgende Werte:
  runTimeAPIResponseProc => 3.146
  runTimeCentralTask => 0.7285

RPi 3 Model B, Perl v5.24.1, global:DNS eingetragen, aktuell keine Verbraucher definiert.

VG.

[DS_Starter]

Eine weitere optimierte V ist ins contrib geladen.
Die Zeiten sehen nun bei mir wie folgt aus:

Code Auswählen Erweitern


runTimeCentralTask => 0.5417
runTimeLastAPIAnswer => 0.9654
runTimeLastAPIProc => 0.2506


Der Kennwert runTimeLastAPIAnswer ist unkritisch und zeigt die Info wie lange die letzte Anfrage "unterwegs" war.
FHEM arbeitet in der Zeit weiter.
runTimeCentralTask ist wie gehabt die Laufzeit vom CentralTask wo alles eingeht incl. der Verbrauchersteuerung die u.U. kritisch sein kann wenn die Verbrauchermodule blockieren sollten.

Für uns noch wichtig ist runTimeLastAPIProc. Es ist die Zeit die für die interne Verarbeitung einer (der letzten) API-Antwort
verwendet wird.
Dort ist auch die Zeit für ___convPendToPstart / convertTimeZone (@vuffiraa) enthalten.
Damit können wir das Laufzeitverhalten noch besser einschätzen.

In der Abrufverarbeitung und dem Centraltask werden nun nicht mehr alle SolCast Percentile "auf Vorrat" berechnet, sondern nur die welche die Autokorrektur verlangt.

@Dracolein, wie läuft dein "Problemsystem" ?

[Dracolein]

FVERSION: 76_SolarForecast.pm:v0.70.9-s21735/2022-10-24 TESTING

Code Auswählen Erweitern


runTimeCentralTask => 1.1946
runTimeLastAPIAnswer => 0.9322
runTimeLastAPIProc => 1.5192


Visuell keine Probleme, keine Logeinträge o.ä. derzeit.

[SparcWolf]

Hier bei mir:

Code Auswählen Erweitern

runTimeCentralTask => 0.9764
runTimeLastAPIAnswer => 1.1213
runTimeLastAPIProc => 1.5852

Autokorrektur ist noch nicht aktiv.
Keine Auffälligkeiten.

VG.

[mcp]

Moin Heiko,

Eine weitere optimierte V ist ins contrib geladen.
Die Zeiten sehen nun bei mir wie folgt aus:

Code Auswählen Erweitern


runTimeCentralTask => 0.5417
runTimeLastAPIAnswer => 0.9654
runTimeLastAPIProc => 0.2506


Hast du in deinem Modul irgendwo eine Art Event Interceptor oder so drin?

Ich hab' mir ein DOIF gebaut welches ein paar solCastData und valCurrent Werte als Readings ins SolarForecast Device pinselt, das klappt auch wunderbar - nur mit DOIF auf diese geänderten Readings reagieren klappt warum auch immer nicht.

Wollte den Kram bei Änderung loggen lassen so dass man über den Tag verteilt diese Werte sieht.

Wenn ich die Werte in ein anderes Device schreiben lasse oder ins DOIF selbst klappt das.

[DS_Starter]

Nein die Readings / Eventgenerierung ist FHEM Standard.
Ich weiß nicht wie genau du die Readings erzeugst, aber ich glaube es ist eine Eigenheit von setreading (https://fhem.de/commandref_DE.html#setreading), speziell dieser Hinweis:

...
Achtung: setreading generiert kein Event für ein Gerät X, falls es aus einem notify für Gerät X aufgerufen wurde. In so einem Fall könnte man auf "sleep 0.1; setreading X Y Z" ausweichen.
...

[mcp]

Nein die Readings / Eventgenerierung ist FHEM Standard.
Ich weiß nicht wie genau du die Readings erzeugst, aber ich glaube es ist eine Eigenheit von setreading (https://fhem.de/commandref_DE.html#setreading), speziell dieser Hinweis:

...
Achtung: setreading generiert kein Event für ein Gerät X, falls es aus einem notify für Gerät X aufgerufen wurde. In so einem Fall könnte man auf "sleep 0.1; setreading X Y Z" ausweichen.
...

ne, ich mach das schon fortgeschritten

Code Auswählen Erweitern


readingsBeginUpdate($hash);
readingsBulkUpdate($hash, "bla", "blub", 1);
...
readingsEndUpdate($hash, 1);


laut GUI werden bei Änderung auch Events generiert, nur reagiert kein DOIF/notify darauf.

Nur wenn ich die o.g. Readings in ein anderes Device pinseln lasse, reagiert DOIF oder notify darauf und kann dann entsprechend auch anhand von Änderung loggen.

Ich mein', ist nun kein Beinbruch, dann geht's halt in ein anderes Device, ich wollte es aber eigentlich an einer Stelle haben und am besten natürlich dort wo es passiert

[DS_Starter]

 

Siehst du die Events im Eventmonitor ?
Wenn ja, wie sehen sie dort aus ?

[mcp]

ja, sehe ich.

Code Auswählen Erweitern


2022-10-24 13:06:35 DOIF DOIF_SolarForecast_data_to_readings get_valCurrent
2022-10-24 13:06:35 SolarForecast SolarForecast valCurrent_runTimeCentralTask: 2.4661
2022-10-24 13:07:45 DOIF DOIF_SolarForecast_data_to_readings get_valCurrent
2022-10-24 13:07:45 SolarForecast SolarForecast valCurrent_runTimeCentralTask: 2.4045
2022-10-24 13:08:55 DOIF DOIF_SolarForecast_data_to_readings get_valCurrent
2022-10-24 13:08:55 SolarForecast SolarForecast valCurrent_runTimeCentralTask: 2.3967
2022-10-24 13:10:05 DOIF DOIF_SolarForecast_data_to_readings get_valCurrent
2022-10-24 13:10:05 SolarForecast SolarForecast valCurrent_runTimeCentralTask: 2.4223


aber egal, wenn Du sagst Event Interceptor gibt's nicht, dann ist das Problem evtl. woanders zu suchen.
Dann pinsel ich das woanders hin und bekomme dann ja auch die Log-Einträge bei geänderten Werten.

Dann hat man mal einen Überblick wie die Zeiten über den Tag verteilt variieren.