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 "asynchron" 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.

"asynchron" 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:

[dieter114]

Hallo Heiko,
bez. Marktanalyse kann ich ebenfalls nur gratulieren.
Die Erzeugungsprognose ist schon reichlich ausgeklügelt und verblüffend genau.
Ich verwende sie auch für EVCC und wenn ich dann nach deiner Marktprognose gehe,
müsste ich eigentlich das Optimum erreicht haben
An der Verbrauchsprognose muss wohl noch etwas gearbeitet werden, da bin ich aber guter Hoffnung 
Ich habe einfach einmal ein KI-Training angestossen.
Alle Achtung was danach "unter der Haube" so abgeht. Siehe Foto anlg.
Es ist ein PI5 mit fest montierter M.2 SSD - immerhin...
Weiter sind meine Problemchen wohl mehr der Tatsache geschuldet
das ich in den letzten 2 Tagen mein Auto mit Strom vom Netz geladen hatte.
Nach dem Training sind die CON Werte etwas besser aber immer noch viel zu hoch.
LG WDS

[Gisbert]

Moin Gisbert,

Wichtig sind zunächst die Infos und Einstellungen:

- AI Nutzung für Consumption Forecast Ja/ Nein
- Wenn nein -> Einstellungen der relevante Parameter in plantControl -> consForecastBase, consForecastIdentWeekdays, consForecastInPlanning, consForecastLastDays

- abhängig davon muß an sich die Speicher pvHistory und/oder pvCircular anschauen ob historische Daten enthalten sind die die Prognose nach oben ziehen

LG,
Heiko

Hallo Heiko,

nachdem ich mich mit deinem Modul und den Definitionen etwas näher beschäftigt habe, ist mir aufgefallen, dass ich etwas bei dem Attribut setupInverterDev01 pvIn und pvOut falsch verstanden hatte:

Code Auswählen Erweitern

attr mySolarForecast setupInverterDev01 Deye_Inverter pvIn=pv_total_power:W pvOut=inverter_power:W capacity=13200 etotal=total_pv_production:kWh strings=Sueddach1,Sueddach2
a
Hinweis für den DEYE-Hybrdidwechselrichter:
pv_total_power --> Summe aus Register 672 und folgende
inverter_power --> Register 636

Jedenfalls ist die AC-Menge um geschätzte 10 kWh kleiner als die PV-DC-Menge, was sich natürlich dann auch auf den Verbrauch auswirkt, d.h. um diesen Betrag erhöht. Wenn ich diesen Betrag berücksichtige, dann kommt die Verbrauchsprognose in die gewünschte Richtung; sie ist dann immer noch ca. 5 kWh zu groß. Ich habe das jetzt nach der obigen Definition angepasst und beobachte das jetzt weiter.

Ich habe die AI-Nutzung für die Verbraucher jetzt auch aktiviert:

Code Auswählen Erweitern

attr mySolarForecast aiControl aiConActivate=1\
aiConProfile=v1_heatpump_pv\
aiConTrainStart=1:5Dann habe ich ausgeführt:

Code Auswählen Erweitern

set mySolarForecast aiDecTree runConTrainWann kann ich mit einem brauchbarem ersten Ergebnis rechnen?

Viele Grüße Gisbert