76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[All-Ex]

Mir ist aufgefallen, dass bei apptime das SolarForecast Modul sehr viele counts hat, also sehr häufig aufgerufen wurde. In einer Minute waren es bei mir 1.699 Aufrufe. Ist das so gewollt, da jeder Aufruf einige CPU-Zyklen verbraucht?

Code Auswählen Erweitern

name                      function                max    count      total  average   maxDly   avgDly TS Max call     param Max call
sol.forecast.G_ai         CODE(0x55b87ac302d0)    349     1699     507.64     0.30     0.00     0.00 09.05. 08:51:13 HASH(sol.forecast.G_ai)

[peterboeckmann]

Hallo Heiko,

die Arbeit ist nicht umsonst. Manchmal brauchst es mehrere Anläufe um ein Problem zu lösen.

schön, dass Du das so siehst.
Ich bin jetzt erstmal auf v2.6.5 zurück und verzichte vorerst auf den Batteriewechselrichter in der FLussgrafik.

Viele Grüße,
Peter

[300P]

Mir ist aufgefallen, dass bei apptime das SolarForecast Modul sehr viele counts hat, also sehr häufig aufgerufen wurde. In einer Minute waren es bei mir 1.699 Aufrufe. Ist das so gewollt, da jeder Aufruf einige CPU-Zyklen verbraucht?

Das kommt u.U. auf deine jeweilige Konfiguration an.

Wer einen kurzen SF-Intervall eingestellt hat und/oder dann noch sehr stark alle externen Readingveränderungen (mit vielen Devices) auf das Modul durch seine Konfiguration in Richtung "Echtzeitvisualisierung bzw.-system" einwirken läßt, der kann bzw. wird das System ganz schön streßen....

Wie gesagt - SF-Konfiguration ->> IMHO -> ist alles.

[DS_Starter]

Hallo Peter,

zwei Dinge ...

Weiter vorn hatte ich geschrieben:

Wenn ich richtig kombiniere brauchst du ein userReading, welches die Summe aus packInputPower + outputHomePower bildet wenn es diese Summierung in ha_tjsLMch1
noch nicht geben sollte.

Das solltest du tun und dieses Reading angeben in

Code Auswählen Erweitern

attr SolarForecast setupBatteryDev02 ha_tjsLMch1\
  ...
  pout=packInputPower:W\
  ...

Allerdings ist es jetzt nicht das Problem. Du hast deinen Solarlader entfernt und dafür jetzt zwei statt einen Stringinverter. Aber du hast deinen Batterieinverter gelöscht, der die Verbindung des Knotens zur Batterie hergestellt hatte.

Für diesen Fall hatte ich wohl noch ein Problem im Vektor.
Zieh nochmal die V aus dem contrib, ändere aber zunächst nichts an deiner Konfig bzgl. userReading. Eins nach dem anderen.

LG,
Heiko

[DS_Starter]

Mir ist aufgefallen, dass bei apptime das SolarForecast Modul sehr viele counts hat, also sehr häufig aufgerufen wurde. In einer Minute waren es bei mir 1.699 Aufrufe. Ist das so gewollt, da jeder Aufruf einige CPU-Zyklen verbraucht?

Wie 300P schon schrieb, kommt es auf die Konfiguration an.
Wichtig hierbei ist auch der Schlüssel "asnychron" in den Setups die es anbieten. In diesem Fall wird ein neuer SF-Zyklus gestartet wenn ein entsprechender Event empfangen wird! Das kann zu sehr häufigen Auslösungen führen wenn dieser Parameter häufig eingesetzt wird bzw. die Events in Quellendevices nicht eingeschränkt sind/werden.

"asnychron" sollte nur dort verwendet werden wo es sinnvoll und ausdrücklich gewünscht ist (z.B. asynchron arbeitende Consumer -> Tuya).

[DS_Starter]

Ich habe eine Marktanyalyse für SF anfertigen lassen um einen Überblick über Stärken und Schwächen gegenüber der Peergroup zu erhalten. Auch um zu sehen wo es strategischen Verbesserungsbedarf gibt (sofern durch mich lösbar).
Wen es interessiert im Anhang.

[peterboeckmann]

Hallo Heiko,

Zieh nochmal die V aus dem contrib, ändere aber zunächst nichts an deiner Konfig bzgl. userReading. Eins nach dem anderen.

Ich hab die neue Version 2.6.7 gezogen und fhem neu gestartet.
Aktuell sind alle Speicher voll geladen, sogar das Auto.
Die Fälle mit Ladung und Entladung des Speicher schaue ich mir heute Abend bzw. Morgen früh an.

Der Rest passt offenbar, siehe Screenshot anbei.

Vielen Dank und viele Grüße,
Peter

[peterboeckmann]

Hallo Heiko,

Ich habe eine Marktanyalyse für SF anfertigen lassen um einen Überblick über Stärken und Schwächen gegenüber der Peergroup zu erhalten. Auch um zu sehen wo es strategischen Verbesserungsbedarf gibt (sofern durch mich lösbar).
Wen es interessiert im Anhang.

Zu der Marktanalyse kann man nur gratulieren.
Einen Punkt sehe ich aber anders:

Gegenüber kommerziellen HEMS-Produkten [...] besteht ein Rückstand bei [...] herstellerseitigem Support.

Deinen Support erreicht kaum ein kommerzieller Hersteller.

Vielen vielen Dank!

Viele Grüße,
Peter

[DS_Starter]

  ... danke!

Bei der Behauptung "beliebig viele Verbraucher einbindbar" irrt die Analyse auch. Das sind aber Details. Mir ging es um einen Gesamtblick auch hinsichtlich strategische Entwicklungsbedarfe.

Parallix hatte weiter vorn schon einige Gesichtspunkte bzgl. Verbraucher/Batteriesteuerung aufgeführt. Die Stellen hier wieder zu finden ist eine Herausforderung    obwohl ich mir viel notiere.

[DS_Starter]

@300P, kannst du bitte die V 2.6.7 aus dem Contrib mit deinen 2 Batteriesetups mal testen?
Wäre prima. 

[300P]

Mache ich😉

[300P]

Paar Minuten nach dem Start: