76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[TheTrumpeter]

Ich ahne was das Problem ist. Die hohen Excludes (E-Auto?) wobei es keine Einplanungen für die nächsten Stunden gibt wo ein entspechender Aufschlag stattfinden würde.

Ich habe nur einen Verbraucher mit "exclude", nämlich die WW-Bereitung über die Wärmepumpe. Die "zieht" aber nicht mehr als 2-2,5 kW.

Kann es sein, dass es (seit dem Update) Probleme gibt, wenn Verbraucher dem gleichen FHEM-Gerät zugewiesen sind?
Die Wärmepumpe ist ein einziges Gerät, je nach Betriebsart wird der Verbrauch dann der Heizung, Kühlung oder WW zugewiesen. Es kann aber natürlich immer nur ein Betrieb auf einmal laufen, sodass pro Stunde in Summe nicht mehr als die oben genannten 2-2,5 kW zusammenkommen können.

[TheTrumpeter]

Nachtrag: Die WW-Bereitung ist 2 Verbrauchern zugewiesen, 1x mit "must" und 1x mit "can" mit unterschiedlichen Startbedingungen. Kann es sein, dass der Verbrauch dadurch irgendwie "doppelt" registriert wird?

[DS_Starter]

Die Verbraucher werden anhand ihrer Nummer, hier "4" was ich gesehen habe, verwaltet. Wenn es einen weiteren Consumer, z.B. "2" gibt, der im Prinzip das gleiche Device abbildet, wird SF diese beiden Consumer wie separate Consumer betrachten. SF "sieht" keinen Zusammenhang zwischen beiden.

Folgendes habe ich am Beispiel Hour 17 erkannt:

Code Auswählen Erweitern

2025.02.19 12:51:46 1: mySolarForecast DEBUG> excl. hist 4000 Wh for Hour 17, Considered value numbers: 1
2025.02.19 12:51:46 1: mySolarForecast DEBUG> estimated cons of Hour 17: -3562 Wh, Considered value numbers: 13

Historisch wurde ein aufgezeichneter Wert von 4000Wh für die Stunde 17 exkludiert und da es keine Einplanung für eben diese Stunde gibt der als Aufschlag in die Prognose eingehen würde geht der Zielwert in das Negative.
Entweder müsste man das exclude verhindern mit exconfc=0 oder aber eine Planung (aber keine Schaltung) ausführen lassen.

Mit "get ... valConsumerMaster 4" sieht man die geplanten Stundenleistungsbestandteile, als Beispiel:

Code Auswählen Erweitern

ehodpieces => 11=10.00 12=10.00 13=10.00 14=10.00 15=10.00 ....
die als Aufschlag in den Stundenzielwert eingehen würden, aber nur sofern eine Einplanung des Consumers stattfindet. Diese "Dummyplanung" kann man durch eine geschickte consumer-Konfiguration erreichen.
An sich ist die WW-Integration oder ein E-Auto genau das Szenario welches ich mit einer KI abarbeiten möchte.

Edit: Aber ich werde im Code noch etwas anpassen um dieses Problem zu entschärfen.

[DS_Starter]

Ich glaube ich habe einen Ansatz zur Verbesserung. Zeig mir mal bitte die Ausgabe von

 "get ... valConsumerMaster 4"

[Dirk070]

Ich hatte Deinen Hinweis "Interessant ist hier initdaygcon." so interpretiert, dass dieser Wert zum Tagesstart Null sein kann oder eben ein ständig wachsender Zähler ist.
Bei mir wurde erst gegen 00:05 der Zähler resettet (auf Null). Ich habe es nun realisieren können, dass der Zähler um 00:00 auf Null gesetzt wird.
Daher mein Screenshot. Meintest Du andere/weitere Werte?

Bis 6:00 Uhr gab es demnach keinen Verbrauch und auch die Werte um 7 oder 8 sind deutlich zu gering.

Nicht Verbrauch, es geht um den Netzbezug, oder?

Kann es sein, dass die Einheit der Readings

contotal=Grid_Today_EnergyOut:kWh bzw feedtotal=Grid_Today_EnergyIn:kWh

nicht kWh sondern Wh sein müsste?

Ansonsten führe bitte ein "get ... pvCircular 99" aus und poste die Ausgabe.
Sie sieht etwa so aus:

Code Auswählen Erweitern

99 => tdayDvtn: -, ydayDvtn: 26.22
      todayConsumption: 7962, feedintotal: 2639818.8, initdayfeedin: 2639800.2
      gridcontotal: 925395.7, initdaygcon: 925108.4
      initdaybatintot01: 4205688.9725021, initdaybatintot02: -, initdaybatintot03: -

Interessant ist hier initdaygcon.

Irgenwie sprechen wir scheinbar nicht von dem gleichem......? ?

So müsste es eigentlich aussehen bei einem aktuellen Tagesverbrauch von 5047 Wh und 17.1 Wh Einspeisung bei Stunde 99

Code Auswählen Erweitern

99 => tdayDvtn: 4.35, ydayDvtn: -104.16
      todayConsumption: 5047, feedintotal: 2978953.8, initdayfeedin: 2978936.9
      gridcontotal: 780894.4, initdaygcon: 780869.5
      initdaybatintot01: 9578888, initdaybatintot02: 6686075, initdaybatintot03: -
      initdaybatouttot01: 6868960, initdaybatouttot02: 4713902, initdaybatouttot03: -
      batintot01: 9579845, batintot02: 6686580, batintot03: -
      batouttot01: 6870720, batouttot02: 4718635, batouttot03: -
      lastTsMaxSocRchd01: 1739903302, lastTsMaxSocRchd02: 1739895601, lastTsMaxSocRchd03: -
      nextTsMaxSocChge01: 1741631302, nextTsMaxSocChge02: 1741623601, nextTsMaxSocChge03: -
      days2care01: 19, days2care02: 19, days2care03: -
      runTimeTrainAI: 0.9987, aitrainLastFinishTs: 1739927704, aiRulesNumber: 3426
      attrInvChangedTs: 1736179151


[DS_Starter]

@TheTrumpeter, ich habe dir die Testversion im contrib upgedatet. Bitte teste das Ergebnis in deinem Umfeld.

LG

[fume]

Hallo, habe mal eine Frage, gibt es in consumer-mintime eine möglichkeit den Wert eines Readings zu übernehmen.
Habe es mit device:reading und {ReadingsVal("device","reading",0)} versucht aber scheinbar wird der Wert nicht übernommen.
Fehler: The key "mintime" must be an integer or a string starting with "SunPath."

Ich würde gerne eine Flexible mintime die in einen externen doif errechnet wird angeben.

[DS_Starter]

Hallo, habe mal eine Frage, gibt es in consumer-mintime eine möglichkeit den Wert eines Readings zu übernehmen.
Habe es mit device:reading und {ReadingsVal("device","reading",0)} versucht aber scheinbar wird der Wert nicht übernommen.
Fehler: The key "mintime" must be an integer or a string starting with "SunPath."

Ich würde gerne eine Flexible mintime die in einen externen doif errechnet wird angeben.

Momentan nicht, kann ich aber einbauen.

[fume]

Momentan nicht, kann ich aber einbauen.

Danke, währe eine super Sache um zb. die Laufzeit einer Poolumpe nach Wassertemperatur flexibel einzuschalten.

[TheTrumpeter]

Ich glaube ich habe einen Ansatz zur Verbesserung. Zeig mir mal bitte die Ausgabe von

 "get ... valConsumerMaster 4"

Sorry, war gestern dann nicht mehr hier...

Code Auswählen Erweitern

04 => alias => Warmwasser optional
      asynchron => 1
      auto => 0
      autoreading => solarforecast_dhw_auto
      avgenergy => 2867.89
      currpowerpercent => 76.1
      cycleDayNum => 0
      cycleStarttime => 1739956686
      cycleTime => 35.7666666666667
      dspignorecond =>
      dswitch => Mythz
      dswoffcond =>
      dswoncond => Mythz
      ehodpieces => 10=3000.00
      energythreshold =>
      epiecAVG => 1=0.00
      epiecAVG_hours => 1
      epiecHist => 9
      epiecHist_1 => 1=0.00
      epiecHist_10 => 1=0.00
      epiecHist_10_hours => 0
      epiecHist_1_hours => 0
      epiecHist_2 => 1=0.00 2=0.00
      epiecHist_2_hours => 1
      epiecHist_3 => 1=0.00
      epiecHist_3_hours => 0
      epiecHist_4 => 1=0.00
      epiecHist_4_hours => 0
      epiecHist_5 => 1=0.00 2=0.00
      epiecHist_5_hours => 1
      epiecHist_6 => 1=0.00
      epiecHist_6_hours => 0
      epiecHist_7 => 1=0.00
      epiecHist_7_hours => 0
      epiecHist_8 => 1=0.00 2=0.00
      epiecHist_8_hours => 1
      epiecHist_9 => 1=0.00 2=0.00
      epiecHist_9_hours => 1
      epiecHour => -1
      epiecStartEtotal => 5020000
      epiecStartTime => 1739954050
      epieces => 1=3000.00
      exconfc => 1
      hysteresis => 0
      icon => sani_water_hot
      interruptable => 0
      isConsumptionRecommended => 1
      isIntimeframe => 1
      lastAutoOnTs => 1739953992
      lastMinutesOn => 15.6166666666667
      lastOnTime => 1739958838
      locktime => 0:0
      logoffon => off
      mintime => 60
      minutesOn => 0
      mode => can
      name => Mythz
      noshow => 0
      notafter => {main::min('17:00', sprintf('%02d:%02d', (split ':', main::sunset_abs('HORIZON=0',-120*60))[0], (split ':', main::sunset_abs('HORIZON=0',-120*60))[1]))}
      notbefore => {main::max('08:05', sprintf('%02d:%02d', (split ':', main::sunrise_abs('HORIZON=0',120*60))[0], (split ':', main::sunrise_abs('HORIZON=0',120*60))[1]))}
      offcom =>
      offreg => 0
      oncom => pOpMode manual
      onoff => off
      onreg => 1
      physoffon => off
      planSupplement =>
      plandelete => regular
      planstate => replanned: 2025-02-20 09:45:09 - 2025-02-20 10:45:09
      planswitchoff => 1740044709
      planswitchon => 1740041109
      power => 3000
      powerthreshold => 1
      remainTime => 0
      retotal => sElectrDHWTotal
      rigncond =>
      rpcurr => cur_power_dhw
      rswoffcond =>
      rswoncond => dhw_temp
      rswstate => HeatingDHW
      runtimeAvgDay => 47.27
      spignorecondregex =>
      startTime => 1739956686
      state => off
      surpmeth => SmartMeterRestAPI:pvoffset_mean_5min
      swoffcondregex =>
      swoncondregex => 4[0-3][.]*\d*|[0-3]\d[.]*\d*
      type => heater
      uetotal => kWh
      upcurr => kW

@TheTrumpeter, ich habe dir die Testversion im contrib upgedatet. Bitte teste das Ergebnis in deinem Umfeld.

Kann ich erst morgen Vormittag einspielen, werd's dann aber gleich rückmelden.

[TheTrumpeter]

Hallo, habe mal eine Frage, gibt es in consumer-mintime eine möglichkeit den Wert eines Readings zu übernehmen.
Habe es mit device:reading und {ReadingsVal("device","reading",0)} versucht aber scheinbar wird der Wert nicht übernommen.
Fehler: The key "mintime" must be an integer or a string starting with "SunPath."

Ich würde gerne eine Flexible mintime die in einen externen doif errechnet wird angeben.

Momentan nicht, kann ich aber einbauen.

Wär's nicht generell einfacher die komplexe Consumer-Konfiguration in mehrere Attribute auszulagern wie es z.B. beim ModbusTCP-Modul üblich ist? Da werden die Eigenschaften für einen Wert über mehrere Attribute mit gleichem Prefix konfiguriert.
Hier wäre es sinngemäss "Consumer[xx]alias", "Consumer[xx]mintime", "Consumer[xx]bla". Manche Dinge sind mandatory, andere optional. So könnte man sehr einfach bedarfsgerechte Änderungen von Außen vornehmen.
Im konkreten Fall könnte der User das mittels "attr SolarForecast Consumer[xx]mintime 90" machen, ohne das gesamte komplexe "Consumer[xx]"-Attribut verändern zu müssen. Dann müsstest Du auch nicht für solche und ähnliche Wünsche das Modul immer wieder ändern und flexibler/komplexer machen.

[DS_Starter]

Wär's nicht generell einfacher die komplexe Consumer-Konfiguration in mehrere Attribute auszulagern wie es z.B. beim ModbusTCP-Modul üblich ist? Da werden die Eigenschaften für einen Wert über mehrere Attribute mit gleichem Prefix konfiguriert.

Nein. Wir können aktuell 16 Consumer mit jeweils 24 Schlüsseln einbinden. Das wären 384 Attribute.
Wir hatte früher eine Unmenge Attribute und ich habe deswegen diese Aggregationen vorgenommen und versuche Schritt für Schritt die Anzahl der Attr weiter zu senken wo es sinnvoll ist.
Das ist also kein Weg und es besteht dazu auch keine Notwendigkeit.

Hier wäre es sinngemäss "Consumer[xx]alias", "Consumer[xx]mintime", "Consumer[xx]bla". Manche Dinge sind mandatory, andere optional. So könnte man sehr einfach bedarfsgerechte Änderungen von Außen vornehmen.
Im konkreten Fall könnte der User das mittels "attr SolarForecast Consumer[xx]mintime 90" machen, ohne das gesamte komplexe "Consumer[xx]"-Attribut verändern zu müssen. Dann müsstest Du auch nicht für solche und ähnliche Wünsche das Modul immer wieder ändern und flexibler/komplexer machen.

Was die Attribute können, muß auch im Code verarbeitet werden. Eine Anpassung ist für mich auf jeden Fall nötig. Es lässt sich mit der aktuellen Architektur sehr gut (auch für mich) lösen.

Für den Nutzer ist es auch sehr einfach ein Attribut zu ändern. In der Struktur kann man die Schlüssel auch jeweils in eine separate Zeile oder, in thematische Blöcke zusammengefasst, in mehrere Zeilen schrieben und hat so einen schnellen Überblick. Also z.B. so:

Code Auswählen Erweitern

deCONZ_HUEDevice1:Tablet+Flur icon=tablet type=charger
power=0 pcurr=power:W etotal=consumption:Wh
auto=automatic
on=on off=off
mintime=1430
interruptable=samsunggalaxy.fully:batterylevel:[4-9][0-9]|[0-9]{3}:50

Es ist ein Handgriff für den User hier etwas zu ändern. Dem Modul ist es egal, dass es ein paar Werte mehr prüfen und verarbeiten muß beim speichern. 

[DS_Starter]

@TheTrumpeter, wie sieht denn heute deine Verbrauchsvorhersage aus falls du das heutige Update schon gemacht hast?

[TheTrumpeter]

@TheTrumpeter, wie sieht denn heute deine Verbrauchsvorhersage aus falls du das heutige Update schon gemacht hast?

Hab's jetzt gemacht.
(Vom Conrib kann ich unterwegs nix einspielen, aber ein normales Update geht grundsätzlich. Tu's nur nicht gerne, weil wenn's zu Problemen kommt ist es von daheim aus grundsätzlich einfacher zu lösen.)

Prognose schaut gut aus, keine "0"en und die Vorhersage ist grundsätzlich plausibel. Vor dem Update waren einzelne Stunden auf 0, der Rest auch plausibel.

[Hardy62]

Hallo guten Tag,
ich habe eine Frage: seit einem FHEM-Update am 18.02.25 wird der Ladezustand meiner Batterie im Solarforecast-Modul (Graphik -"Spinne") nicht mehr angezeigt - nur noch "0".
Im Reading "Current_BatCharge_01" steht aktuell der richtige SOC-Wert drin.
Hat sich etwas grundlegend geändert ? Wo könnte der Fehler stecken?
VLG Hardy