76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Nein, alles normal.

Bei Verbrauchprognose immer schauen wie plantControl->consForecastIdentWeekdays und consForecastLastDays gesetzt ist. Davon hängt ab aus welchem Datenspeicher (pvHistory oder pvCircular) die Prognose abgeleitet wird.

Aber der erste Anlaufpunkt für eine erste Analyse ist das Debugging über ctrlDebug->consumption bzw. consumption_long.
Meist sieht man da schon einen Hinweis auf die Ursache.

[Parallix]

Nein, alles normal.

Naja, normal ist dieser Verbrauch bei mir nicht

Bei Verbrauchprognose immer schauen wie plantControl->consForecastIdentWeekdays und consForecastLastDays gesetzt ist. Davon hängt ab aus welchem Datenspeicher (pvHistory oder pvCircular) die Prognose abgeleitet wird.

Bei mir wie folgt:

Code Auswählen Erweitern

consForecastIdentWeekdays=0 consForecastLastDays=1

Aber der erste Anlaufpunkt für eine erste Analyse ist das Debugging über ctrlDebug->consumption bzw. consumption_long.
Meist sieht man da schon einen Hinweis auf die Ursache.

Hier brauche ich etwas Hilfe, da mir das Format nicht ganz klar ist. Nehmen wir mal folgendes Beispiel soeben aus SF gezogener Debug-Daten:

Code Auswählen Erweitern

01 => pvapifc: 0, pvaifc: -, pvfc: 0, aihit: 0, pvrl: 0
      batin01: 0, batin02: 0, batin03: -
      batout01: 133, batout02: 135, batout03: -
      confc: 90, gcon: 0, gfeedin: 200, wcc: 49, rr1c: 0.00
      temp: 19.30, wid: 101, wtxt: -
      pprl01: -, pprl02: -, pprl03: -
      pvcorrf: -
      quality: -
      pvrlsum: -
      pvfcsum: -
      dnumsum: -
      con_all => Di  @ 119 92 68 105 85 95 87 77 1 83 100 87 49 87 65 30 68 97 68
                 Do  @ 67 85 64 88 102 107 96 3 80 12 50 83 44 60 17 17 6 97
                 Fr  @ 85 223 139 76 81 5 100 83 33 5 41 48 55 40 6 107
                 So  @ 87 93 88 15 89 135 95 2 69 57 65 120 51 11 107 90 21
                 Sa  @ 116 26 87 91 89 55 85 2 17 34 93 24 2 89 29 1 26 21 90
                 Mo  @ 144 47 113 2 62 68 100 1 103 92 22 83 6 25 92 124 123 9 11
                 Mi  @ 82 73 92 69 65 71 103 80 36 200 159 92 44 201 132 144 105 82 84198
      gcons_a => Sa  @ 0 0 0 0 0 0 0
                 Fr  @ 0 0 0 0 0 0
                 So  @ 0 0 0 0 0 0 0
                 Do  @ 0 0 0 0 0 0
                 Di  @ 0 0 0 0 0 0 0
                 Mi  @ 0 0 0 0 0 84100
                 Mo  @ 0 0 0 0 0 0 0

Hier fällt der große Wert 84198 bei con_all bzw. 84100 bei gcons_a am Mittwoch auf. Welche Energiemengen (Einheit?) sollen denn hier wann bezogen worden sein?

[DS_Starter]

Welche Energiemengen (Einheit?) sollen denn hier wann bezogen worden sein?

Das sind Wh (der abgefragten Stunde). Werde ich in der Online-Hilfe ergänzen.

Bei der Einstellung

consForecastIdentWeekdays=0 consForecastLastDays=1

wird der nur der gestrige Tag aus der pvHistory verwendet. Hole dir mal bitte die get ... pvHstory 16.

[bismosa]

Hallo!

Ich habe irgendwie Schwierigkeiten die Poolpumpensteuerung aus dem Wiki richtig zu verwenden.
Mein Ziel ist es, das die Poolpumpe mind. 3h am Tag läuft. Nach Möglichkeit schon vormittags. Sollte aber nicht genug Strom vorhanden sein, darf es bis 18Uhr das nachholen (zur Not halt auch aus dem Netz)

die 99_mySolarForecastUtils.pm ist angelegt und aus dem Beispiel 1:1 übernommen.
Im SF-Modul habe ich:

Code Auswählen Erweitern

attr SF ctrlUserExitFn {\
::pumpControl ($name, '02', 180);;\
}
und

Code Auswählen Erweitern

attr SF consumer02 Firmata_Aussensteckdose:Pool\
icon=sani_pump \
type=other \
power=500 \
mode=must \
mintime=480 \
notafter=10\
on=on off=off \
auto=automatic \
interruptable=Firmata_Aussensteckdose:SF_Int:1 \
swoffcond=Firmata_Aussensteckdose:SF_Abort:1

Die Pumpe schaltet meiner Meinung nach etwas willkürlich:

Code Auswählen Erweitern

2025-06-15_08:07:27 Firmata_Aussensteckdose automatic: 0
2025-06-15_08:07:33 Firmata_Aussensteckdose automatic: 1
2025-06-15_08:07:39 Firmata_Aussensteckdose automatic: 1
2025-06-15_08:24:29 Firmata_Aussensteckdose automatic: 0
2025-06-15_08:24:35 Firmata_Aussensteckdose automatic: 1
2025-06-15_10:00:04 Firmata_Aussensteckdose on
2025-06-15_10:00:46 Firmata_Aussensteckdose off
2025-06-15_15:01:46 Firmata_Aussensteckdose on
2025-06-15_16:00:07 Firmata_Aussensteckdose off
2025-06-15_16:03:37 Firmata_Aussensteckdose on
2025-06-15_17:06:37 Firmata_Aussensteckdose off
2025-06-15_17:08:57 Firmata_Aussensteckdose on
2025-06-15_17:21:47 Firmata_Aussensteckdose off
2025-06-15_17:35:47 Firmata_Aussensteckdose on
2025-06-15_17:59:07 Firmata_Aussensteckdose off
2025-06-15_18:00:05 Firmata_Aussensteckdose off
2025-06-16_09:46:27 Firmata_Aussensteckdose on
2025-06-16_09:47:37 Firmata_Aussensteckdose off
2025-06-16_14:48:37 Firmata_Aussensteckdose on
2025-06-16_17:47:07 Firmata_Aussensteckdose off

Ist das ein erklärbares verhalten? PV-Strom war gestern den ganzen Tag reichlich vorhanden.
Am Sonntag war das verhalten sehr ähnlich. Da war aber nicht immer genug Strom da. Vor allem stört mich z.B. die Einschaltzeit für weniger als eine Minute um 10Uhr. Das war Sonntag genau so.

Danke für das Modul!

Gruß
Bismosa

[Parallix]

Welche Energiemengen (Einheit?) sollen denn hier wann bezogen worden sein?

Das sind Wh (am gesamten Tag). Werde ich in der Online-Hilfe ergänzen.

Pro Zeile sind's ja mehrere Werte, deren Anzahl sich aber von Zeile zu Zeile unterscheidet. wie sieht's mit der zeitlichen Zuordnung aus?

Bei der Einstellung

consForecastIdentWeekdays=0 consForecastLastDays=1

wird der nur der gestrige Tag aus der pvHistory verwendet.

Hatte ich mir schon gedacht, obwohl eine Reduzierung der Ausgaben von get() auf Basis der Einstellungen das Debugging unterstützen würde.

Hole dir mal bitte die get ... pvHstory 16.

Gerne! Da der Outpunt länglich ist, wohl besser als Datei.

[DS_Starter]

Ich sehe zwei Ausreißerprognosen:

      08 => pvfc: 2708, pvrl: 2400, pvrlvd: 1, rad1h: 800
            etotali01: 28153200, etotali02: -, etotali03: -, etotali04: -
            pvrl01: 2400, pvrl02: -, pvrl03: -, pvrl04: -
            etotalp01: -, etotalp02: -, etotalp03: -
            pprl01: -, pprl02: -, pprl03: -
            confc: 83786, con: 129, gcons: 0, conprice: 0.40
            gfeedin: 2100, feedprice: 0.075
            DoN: 1, sunaz: 74, sunalt: 17
            batintotal01: 1123491, batintotal02: 1108899, batintotal03: -
            batouttotal01: 1020901, batouttotal02: 1013755, batouttotal03: -
            batprogsoc01: 3.0, batprogsoc02: 3.0, batprogsoc03: -, socprogwhsum: 306
            batsoc01: 42, batsoc02: 40.2, batsoc03: -, socwhsum: 4192
            lcintimebat01: 1, lcintimebat02: 1, lcintimebat03: -
            batin01: 91, batin02: 82, batin03: -
            batout01: 0, batout02: 0, batout03: -
            weatherid: 0, wcc: 0, rr1c: 0.00, pvcorrf: 0.82/0.79 temp: 14.60,
            minutescsm01: 0
            minutescsm02: 60

      23 => pvfc: 0, pvrl: 0, pvrlvd: 1, rad1h: 0
            etotali01: 28256800, etotali02: -, etotali03: -, etotali04: -
            pvrl01: 0, pvrl02: -, pvrl03: -, pvrl04: -
            etotalp01: -, etotalp02: -, etotalp03: -
            pprl01: -, pprl02: -, pprl03: -
            confc: 84113, con: 9, gcons: 0, conprice: 0.40
            gfeedin: 400, feedprice: 0.075
            DoN: 0, sunaz: 319, sunalt: -6
            batintotal01: 1124942, batintotal02: 1110288, batintotal03: -
            batouttotal01: 1020991, batouttotal02: 1013880, batouttotal03: -
            batprogsoc01: 3.0, batprogsoc02: 3.0, batprogsoc03: -, socprogwhsum: 306
            batsoc01: 80.7, batsoc02: 75.4, batsoc03: -, socwhsum: 7961
            lcintimebat01: 1, lcintimebat02: 1, lcintimebat03: -
            batin01: 0, batin02: 0, batin03: -
            batout01: 172, batout02: 182, batout03: -
            weatherid: 101, wcc: 20, rr1c: 0.00, pvcorrf: 1.00/- temp: 19.00,
            minutescsm01: 0
            minutescsm02: 60

Einen Grund dafür erkenne ich momentan noch nicht. Da müsste man sich noch die Logausgabe des Debug mit der Herleitung anschauen.

[DS_Starter]

@Bismosa,

Ist das ein erklärbares verhalten?

Es wird bei jedem Zyklus der Überschuß, also PV - Verbrauch, ermittelt und daraus die Schaltung (bei interruptable) abgeleitet.
Möglicherweise gab es zu diesen Zeiten keinen Überschuß weil ein anderes Gerät auch an war verbunden mit einer kurzfristigen Bewölkung z.B.

Du kannst solche kurzen Laufzeiten / Unterbrechnungen unterbinden, indem du den locktime Schlüssel verwendest. Das verhindert dass deine Pumpe über Gebühr schaltet.

Edit: Alternativ kannst du auch mit dem surpmeth Schlüssel die PV-Überschuß Bewertung glätten.

LG,
Heiko

[DS_Starter]

@Parallix,

ich habe deinen Wunsch bzgl. Zusatzreadings schonmal teilweise umgesetzt.
Im contrib befindet sich die V 1.52.13. ctrlSpecialReadings enthält jetzt die Option:

 remainingHrsWoChargeRcmdBat_XX    die verbleibende Anzahl Stunden ohne Ladeempfehlung für Batterie XX am aktuellen Tag


Ich musste den Key einkürzen. Das Reading einfach zu lang.

LG

 

[Parallix]

...
ich habe deinen Wunsch bzgl. Zusatzreadings schonmal teilweise umgesetzt.
Im contrib befindet sich die V 1.52.13. ctrlSpecialReadings enthält jetzt die Option:
remainingHrsWoChargeRcmdBat_XX     die verbleibende Anzahl Stunden ohne Ladeempfehlung für Batterie XX am aktuellen Tag

Super! Danke! Werde ich direkt am nächsten Feiertag bei mir einbauen!

Ich musste den Key einkürzen. Das Reading einfach zu lang.
...

Das ist nun wirklich kein Problem!

[Parallix]

Ich sehe zwei Ausreißerprognosen:
...
Einen Grund dafür erkenne ich momentan noch nicht. Da müsste man sich noch die Logausgabe des Debug mit der Herleitung anschauen.

Leider kommen solche Ausreißer - wahrscheinlich nicht nur bei mir - immer mal wieder vor. Vor diesem Hintergrund möchte ich anregen, dass SF seinen Input etwas mehr prüft. Da Energiezählern stets akkumulierend arbeiten, muss deren Werteverlauf monoton steigend sein  (Zählerwechsel einmal ausgeschlossen). Ausreißer nach unten sind also sofort identifizierbar und solche nach oben sollten auch einfach identifizierbar sein. Kommt es zu solchen Ausreißern, sollte SF diese proaktiv entfernen (und ggf. einem entsprechenden Log-Eintrag produzieren), da die Zuverlässigkeit der Software hierdurch enorm gesteigert werden kann. Das jedenfalls ist mein Vorschlag.

[DS_Starter]

Leider kommen solche Ausreißer - wahrscheinlich nicht nur bei mir - immer mal wieder vor. Vor diesem Hintergrund möchte ich anregen, dass SF seinen Input etwas mehr prüft. Da Energiezählern stets akkumulierend arbeiten, muss deren Werteverlauf monoton steigend sein  (Zählerwechsel einmal ausgeschlossen). Ausreißer nach unten sind also sofort identifizierbar und solche nach oben sollten auch einfach identifizierbar sein.

Die Verletzung der Monotonie nach unten kann ich abfangen wie ich es bei den Invertern auch schon eingebaut habe. Das baue ich ein.
Nach oben sehe ich keine Möglichkeit. Wenn jemand ein Elektroauto (mit Netzanteil) lädt oder eine Baumaßnahme durchführt, hat das einen außergewöhnlich hohen Energie-Ausschlag nach oben im Verhältnis zum sonstigen Durchschnitt zur Folge. Wo soll ich eine Grenze einziehen, die einen Fehler sicher erkennt. Mir fällt diesbezüglich nichts ein was sich in der Praxis bewähren könnte.

[Wzut]

Ich habe etwas weiter gespielt
Die Bat Icons measure_battery_X gibt es nur in fünf Stufen, bei Rollos und Licht hat FHEM Icons mit 11 Stufen. Daher habe ich mir mal 11 neue gemacht (0-100) Mit etwas css lässt sich der aktuelle SoC auf dem Bat Icon darstellen (Stichwort z-index). Dabei ist mir aufgefallen das $soc für alte und aktuelle Werte ein Integer Wert ist, bei der Prognose aber ein Float ( 100,0 war aber zu lang für die kleine Batterie , daher gewandelt )

[bismosa]

Es wird bei jedem Zyklus der Überschuß, also PV - Verbrauch, ermittelt und daraus die Schaltung (bei interruptable) abgeleitet.
Möglicherweise gab es zu diesen Zeiten keinen Überschuß weil ein anderes Gerät auch an war verbunden mit einer kurzfristigen Bewölkung z.B.

Du kannst solche kurzen Laufzeiten / Unterbrechnungen unterbinden, indem du den locktime Schlüssel verwendest. Das verhindert dass deine Pumpe über Gebühr schaltet.

LG,
Heiko

Hallo Heiko,

ich kann eigentlich ausschließen, das es zu diesen Zeiten keinen PV-Überschuss gab. Ich hatte immer mind. 1000-1500W eingespeist.
Wie es da bei der berechneten Prognose aussah weiß ich allerdings nicht.
Heute Morgen kann es tatsächlich sein, das es um 10Uhr noch nicht ausreichend war. Dennoch wurde die Pumpe wieder für ein paar Sekunden eingeschaltet.

Aktuell ist die Prognose bei 8000W und die tatsächliche Einspeisung noch etwas da drüber. Die Pumpe (mit 500W angegeben) läuft dennoch nicht.
Irgendwie verstehe ich hier wohl das Verhalten noch nicht.
locktime sollte hier doch dann nur die Laufzeit "verlängern" um ein zu kurzes Schalten zu unterbinden. Dann wäre die Pumpe heute Morgen etwas länger eingeschaltet geblieben.

Ich habe auch eine andere schaltbare Steckdose für eine Klimaanlage (derzeit aber ohne einen Verbraucher angeschlossen):

Code Auswählen Erweitern

attr SF consumer04 MQTT2_zigbee_plug_Klimaanlage type=heater power=1000 \
mode=can  \
notbefore=09:00 notafter=09:00\
interruptable=1\
locktime=180:180\
on=on off=off\
mintime=SunPath\
auto=automatic\
Diese lief von 9:02 bis 22:07 durchgehend. Die hätte abgeschaltet, wenn der Überschuss nicht ausreichend gewesen wäre. Da funktioniert das super.

Gruß
Bismosa

[DS_Starter]

@bismosa,

wenn die Analyseanforderung zu komplex wird, dann kommt man über eine Debugausgabe nicht herum.
Dazu setzt du dir:

 ctrlDebug->consumerSwitchingXX

XX = der Counsumer (deine Pumpe) deren Schaltverhalten du ergründen möchtest.

Wenn eine Schaltung passiert, die für dich nicht nachvollziehbar ist hole den entsprechenden Bereich aus dem Log und dann können wir gemeinsam versuchen die Ursache zu ergründen.

LG,
Heiko

[DS_Starter]

@Wzut,

Die Bat Icons measure_battery_X gibt es nur in fünf Stufen, bei Rollos und Licht hat FHEM Icons mit 11 Stufen. Daher habe ich mir mal 11 neue gemacht (0-100)

Lässt du deine neuen Icons einchecken? Wenn ja, könnte/würde ich deine Lösung in SF einbauen. Das sieht schön "flüssig" aus. Brauche dann nur noch die Info wie du die Werte direkt auf die Batterie bringst. Das würde ich evtl. konfigurierbar gestalten. PC-Nutzer bekommen die Info per Mouse-Over. Auf einem Tablet ist so ein Aufdruck sicherlich häufig gewünscht.