76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Parallix]

...

Für mich sieht es so aus, als ob alle 5 consumer für sich betrachtet die Einschaltbedingung erfüllen und alle 5 eingeschaltet werden, anschließend erfolgt 2500W Netzbezug und es werden alle 5 wieder ausgeschaltet und so toggelt es dann.

Ja, das ist ein Problem was momentan auftreten kann und du hast es richtig erkannt.
...
Helfen würde in diesem Fall eine Cycle-Chain, d.h. wenn ein Consumer eingeschaltet wurde, darf im selben Zyklus kein weiterer Consumer eingeschaltet werden. Erst im nächsten Zyklus wäre dies möglich sofern die Netzverhältnisse es erlauben. Eine solche Logik muß ich aber erst implementieren.
...

Natürlich könnte man in einem solchen Fall die einzelnen Consumer mit einem Round-Robin-Scheduler ans Netz bringen. Sinnvoll könnte aber auch ein Scheduling nach Prioritäten sein. Meinerseits glaube ich mich zu erinnern, dass Heiko mal berichtet hat, dass Prioritäten durch die Reihenfolge der definierten Consumer (statisch) abgebildet sind.

Erinnern möchte ich an dieser Stelle auch an den hier beschriebenen Bug.

[DS_Starter]

Guten Morgen,

Meinerseits glaube ich mich zu erinnern, dass Heiko mal berichtet hat, dass Prioritäten durch die Reihenfolge der definierten Consumer (statisch) abgebildet sind.

Ja, so ist es. Die definierten Consumer werden in der Reihenfolge ihrer Nummern abgearbeitet. Im Falle einer Cycle-Chain würde zuerst 01 geprüft und eingeschaltet, in nächsten Interval 02, dann 03 usw. Im Fall von sehr vielen Verbrauchern und einem größeren Interval käme der letzte Verbraucher u.U. erst nach 20 Minuten an die Reihe. Deswegen ist auch ein solches Verfahren nicht unproblematisch.
Denkbar wäre auch eine Gewichtung, d.h. bei aktivierter Chain könnten z.B. soviele Verbraucher in einem Cycle geprüft und geschaltet werden deren nominaler pvshare zusammen nicht mehr als beispielsweise 75% des vorhandenen Überschussses ausmacht.
Eine solche Logik muß ich aber erstmal implementieren.

Erinnern möchte ich an dieser Stelle auch an den hier beschriebenen Bug.

Habe ich nicht vergessen.

[Parallix]

@Heiko und @all: Frohe Ostern!

...
Eine solche Logik muß ich aber erstmal implementieren.

Zuvor sollten wir hier aber möglichst alle praktisch relevanten Anwendungsfälle und für deren Behandlung geeignete Scheduling-Verfahren identifizieren.

[DS_Starter]

@Parallix,

Erinnern möchte ich an dieser Stelle auch an den hier beschriebenen Bug.

Ich bekomme diese Situation bei mir nicht nachgestellt.
Kannst du mir mehr Informationen zu deinem konkreten Setup geben und den entsprechenden Ergebnissen in Nexthours etc.? Damit kann ich dann versuchen ein ähnliches Verhalten zu simulieren.

[Parallix]

@Parallix,

Erinnern möchte ich an dieser Stelle auch an den hier beschriebenen Bug.

Ich bekomme diese Situation bei mir nicht nachgestellt.
Kannst du mir mehr Informationen zu deinem konkreten Setup geben und den entsprechenden Ergebnissen in Nexthours etc.? Damit kann ich dann versuchen ein ähnliches Verhalten zu simulieren.

Gerne. Habe das in die angehangene Datei gepackt. Einen zu den Werten passenden Eindruck liefert auch die angefügte Grafik. Sollte ich noch etwas vergessen haben, dann melde Dich bitte. Bin heute aber nur bis ca. 12:00 MESZ online.

PS: Etwas seltsam finde ich auch, dass der Verbraucher immer für 4h eingeplant wird, obgleich  mintime=180. Ich hätte erwartet, dass er ihn wenigstens für 3h einplant plus den Stunden, in denen genügend PV-Überschuss da ist. Am aktuellen Tag wären es dann 4h und am morgigen Tag 8h (vgl. PV-Forecast-Grafik).

[peterboeckmann]

Hallo Heiko,

Integriert ist nun der Consumertyp "bev".

*freu*

Ich habe die Version aus dem contrib gezogen und mein bev definiert:

Code Auswählen Erweitern

attr consumer15 WallboxLeistungssumme type=bev power=11040 pcurr=power:W:10 etotal=total:Wh on=on off=off icon=wallbox auto=Automatik exconfc=1
evid=evid:KiaNiro
batCap=64800
power=11040
currSoC=currSocKiaNiro
targetSoC=80
Dazu habe ich zwei Anmerkungen:
1) batCap wird benötigt, ist aber in der Hilfe mit einem kleinen c angegeben: batcap
2) Kannst Du bitte für den targetSoC auch ein Reading anbindbar machen? Dann kann ich den aus dem Auto übernehmen.

Vielen Dank und viele Grüße,
Peter

Frohe Ostern an alle!

[grappa24]

Auch von mir Frohe Ostern!

Mein erster Versuch mit bev.

Hab jetzt parallel einen normalen Consumer06 und einen bev-Consumer Consumer07 für meinen Cupra angelgt

Code Auswählen Erweitern

consumer06 MQTT2_evcc type=noSchedule power=0 pcurr=chargePower:W icon=car exconfc=1 aliasshort=Cupra

Code Auswählen Erweitern

consumer07 MQTT2_evcc type=bev power=3500 pcurr=chargePower:W etotal=etotal:kWh icon=wallbox evid=evid:CupraFormentor exconfc=1 batCap=10400 currSoC=currSoC targetSoC=80
Obwohl beide die pcurr aus dem selben reading beziehen (chargePower:W) wird sie bei dem alten Consumer unter dem Icon als Wert angezeigt, beim bev-Consumer wird "0" angezeigt.

[DS_Starter]

@Peter,

ich habe beide Anmerkungen umgesetzt. Liegt im contrib.

@grappa24,

Obwohl beide die pcurr aus dem selben reading beziehen (chargePower:W) wird sie bei dem alten Consumer unter dem Icon als Wert angezeigt, beim bev-Consumer wird "0" angezeigt.

So sollte es sein, sofern dein Consumer type=bev nicht aktiviert ist solange das EV nicht erkannt wurde via evid. Du siehst es auch am Reading z.B.:

consumer20  name='BEV 2' state='deactivated' mode='mustNot' planningstate='noSchedule'

Das ist genau das Architekturmerkmal. Erst wenn der EV via evid erkannt ist, wird der so definierte ConsumerXX aktiv und liefert die zugeordneten Daten.
Hat man mehr als einen EV im Haushalt, legt man mehr als einen bev-Consumer an und achtet darauf evid entsprechend unterschiedlich zu definieren.

Wünsche ebenfalls schöne Ostern und bemühe mich keine Eier ins SF Nest zu legen. 

[grappa24]

Das ist genau das Architekturmerkmal. Erst wenn der EV via evid erkannt ist, wird der so definierte ConsumerXX aktiv und liefert die zugeordneten Daten.
Hat man mehr als einen EV im Haushalt, legt man mehr als einen bev-Consumer an und achtet darauf evid entsprechend unterschiedlich zu definieren.

Damit steht nun auch mein bev-Consumer:

Code Auswählen Erweitern

MQTT2_evcc type=bev power=3500 pcurr=chargePower:W etotal=etotal:kWh icon=car evid=evid:Cupra exconfc=1 batCap=10400 currSoC=currSoC targetSoC=80und weil meine Fronius Wallbox absolut nix zur Identifikation des BEV via MQTT beiträgt und ich eh immer nur ein- und dasselbs BEV lade hab ich ein Reading evid in meinem Wallbox-Device fest mit dem Wert Cupra belegt - kann man mal machen 

[Parallix]

Nach einem Osterbesuch wieder zu Hause angekommen, liegt mir folgenden Log-Eintrag vor:

Code Auswählen Erweitern

...
2026.04.05 15:20:10 1: SF - Open-Meteo API server response:  SSL connect attempt failed error:0A000126:SSL routines::unexpected eof while reading
2026.04.05 15:28:59 1: reload: Error:Modul 99_mySolarForecastUtils deactivated:
2026.04.05 15:28:59 1: Including fhem.cfg
...
Da mein Watchdog-Prozess ausgelöst hat, frage ich mich, ob die Kontaktaufnahme zu o.g. Server möglicherweise blockierend ist. Wenn ja, so wäre das der Grund für das Ansprechen des Watchdog-Prozesses und den daraus resultierenden FHEM-Neustart.

[klaus.schauer]

So sollte es sein, sofern dein Consumer type=bev nicht aktiviert ist solange das EV nicht erkannt wurde via evid. Du siehst es auch am Reading z.B.:
consumer20  name='BEV 2' state='deactivated' mode='mustNot' planningstate='noSchedule'

Das ist genau das Architekturmerkmal. Erst wenn der EV via evid erkannt ist, wird der so definierte ConsumerXX aktiv und liefert die zugeordneten Daten.
Hat man mehr als einen EV im Haushalt, legt man mehr als einen bev-Consumer an und achtet darauf evid entsprechend unterschiedlich zu definieren.

Ersetzt der Consumer-Typ bev den Consumer-Typ charger oder sind bei Bedarf x Consumer von Typ charger und y Consumer vom Typ bev zu definieren?

[DS_Starter]

Da mein Watchdog-Prozess ausgelöst hat, frage ich mich, ob die Kontaktaufnahme zu o.g. Server möglicherweise blockierend ist.

Eher nicht. Bei der Meldung "SF - Open-Meteo API server response:..." hat HttpUtils bereits die Antwort zurück geliefert. Wenn etwas blockiert, müsste es in der Verarbeitung danach sein. Da sehe ich aber nichts was das sein könnte. Mal darüber schlafen.

Ersetzt der Consumer-Typ bev den Consumer-Typ charger oder sind bei Bedarf x Consumer von Typ charger und y Consumer vom Typ bev zu definieren?

Der Typ Charger gibt es weiterhin. Die Idee dahinter war aber simpler als es scheint. Gedacht ist dieser Typ zum Beispiel für einen Plug an dem ein Tablet oder Mobiltel zum Aufladen gehängt ist. Also einfache Ladegeräte.

Für EV gibt es nun diesen speziellen Consumer.

[DS_Starter]

@Parallix,
wahrscheinlich konnte ich den von dir festgestellten Bug beseitigen.
Im contrib liegt die V2.5.1 zum Test bereit.

PS: Etwas seltsam finde ich auch, dass der Verbraucher immer für 4h eingeplant wird, obgleich  mintime=180. Ich hätte erwartet, dass er ihn wenigstens für 3h einplant plus den Stunden, in denen genügend PV-Überschuss da ist. Am aktuellen Tag wären es dann 4h und am morgigen Tag 8h

In deinen bereitgestellten Daten ist aber erkennbar, dass der Consumer genau mit 3 Stunden (mintime=180) eingeplant wurde, also so wie du es vorgegeben hast:

Code Auswählen Erweitern

     2026-04-05 09:47:51   consumer03      name='Wallbox' state='off' mode='can' planningstate='planned'
     2026-04-05 09:47:51   consumer03_currentPower 0 W
     2026-04-05 09:47:51   consumer03_planned_start 05.04.2026 12:00:00
     2026-04-05 09:47:51   consumer03_planned_stop 05.04.2026 15:00:00

mintime heißt auch nicht "minimale Zeit", sondern "Einplanungszeit in Minuten". Das ist eine Vorgabe wenn man von dem Typ-default abweichen will.
Wenn du über den Tag PV-Überschüsse ausnutzen willst, lässt du mit "SunPath[:<Offset_Sunrise>:<Offset_Sunset>] " einplanen und setzt den Consumer interruptable.