76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Braucht es die hochfrequenten Log-Einträge (seit dem Update gefühlt viel häufiger)?
Eigentlich habe ich die Abfrage auf 900 Sekunden gestellt, warum kommen dann Log-Einträge alle paar Sekunden?

Brauchen nicht. Nur ist ein Aufruf intern mehrere Requests.
Im Normalfall merkt man davon nichts, jetzt im Fehlerfall schon.
Ich werde eine Zeitsperre für die Meldungen einbauen, dass sie nur alle X Minuten kommen falls die Situation auftritt.

[DS_Starter]

Irritiert bin ich aber immer noch, da z.B. mintime=180 zu einer Einplanung für 240 Minuten führt, wenn hierfür die Bedingungen zutreffen.

Zeig mal das entsprechend Consumer Reading, z.B.

Code Auswählen Erweitern

    2026-04-07 10:13:56   consumer02      name='Ladestation Bad' state='off' mode='must' planningstate='planned'
     2026-04-07 10:13:56   consumer02_planned_start 07.04.2026 11:00:00
     2026-04-07 10:13:56   consumer02_planned_stop 07.04.2026 16:00:00


[Parallix]

Irritiert bin ich aber immer noch, da z.B. mintime=180 zu einer Einplanung für 240 Minuten führt, wenn hierfür die Bedingungen zutreffen.

Zeig mal das entsprechend Consumer Reading, z.B.

Code Auswählen Erweitern

    2026-04-07 10:13:56   consumer02      name='Ladestation Bad' state='off' mode='must' planningstate='planned'
     2026-04-07 10:13:56   consumer02_planned_start 07.04.2026 11:00:00
     2026-04-07 10:13:56   consumer02_planned_stop 07.04.2026 16:00:00


Nun sehe ich selber schon das Problem in folgender Ausgabe:

Code Auswählen Erweitern

2026-04-07 10:22:43   consumer03      name='Wallbox' state='off' mode='can' planningstate='planned'
2026-04-07 10:22:43   consumer03_currentPower 0 W
2026-04-07 10:22:43   consumer03_planned_start 07.04.2026 10:15:30
2026-04-07 10:22:43   consumer03_planned_stop 07.04.2026 13:15:30
Die Einplanung beginnt nicht mit zu vollen Stunde, wenngleich für jeden Stunden-Bin die Entnahme der gleichen Energiemenge prognostiziert wird. In o.g. Fall also für 10, 11, 12, und 13 Uhr.

[DS_Starter]

Ich werde eine Zeitsperre für die Meldungen einbauen, dass sie nur alle X Minuten kommen falls die Situation auftritt.

Habe ich gemacht und als V2.5.2 ins contrib geladen wenn die aktuelle OpenMeteo Situation nerven sollte. Alternativ das SF auf verbose 0 temporär stellen.

[grappa24]

Code Auswählen Erweitern

consumer07  name='Formentor' state='on' mode='mustNot' planningstate='noSchedule' info='von extern umgeschaltet'
consumer07_currentPower   3477.49 WInteressante info zum BEV consumer

[Wolle02]

Es ist schon wieder eine ganze Menge geworden und es sind auch recht bedeutende Dinge dabei. Ich halte es für sinnvoll die Version einzuchecken, sie enthält:

- neuer Schlüssel plantControl->consForecastBase
- Einbindung des String Inverter Mapping check in den Konfigurationscheck
- Konfigurationscheck prüft con in aiRawData
- veränderte Berechnung und Darstellung von weiteren KI Drift Parametern
- comforttemp wird automatisch in plantControl verschoben
- BugFix in reductionState  -> Forum https://forum.fhem.de/index.php?msg=1360810
- neuer Schlüssel aiControl->aiConAbsOversample
- Einbindung von BEV-Consumern (aktuell NUR Datensammlung und Speicherung)
- Härtung der Anzeigefunktion von pvHistory
- Speicherung neuer BEV-Werte in pvHistory & aiRawData
- Bugfix in Legacy Vorhersage für den kommenden Tag -> Forum: https://forum.fhem.de/index.php?msg=1361272
- Bearbeitung der CommandReferenz
- kleine Änderungen im Grafikheader (Benennung CON und Verwendung von aktuellen Umgebungswerten statt gegättete Werte) 

Moin Heiko,

danke für das neue Release. Bislang hatte ich meine Wallbox als Consumer eingebunden; ich würde diesen Consumer nun einfach durch den neuen BEV-Consumer ersetzen. Eine Frage zur Hilfe. Hier steht:

evid   Der Schlüsselwert identifiziert ein angeschlossenes Elektrofahrzeug eindeutig.
<Reading>:<Regex> - Der angegebene reguläre Ausdruck wird auf den Readingswert angewendet. Passt der Ausdruck, wird der
  Consumer in SolarForecast aktiviert.
batCap   Gibt die nominale Batteriekapazität an. Die Angabe kann erfolgen durch:
Ganzzahl: 0..X - die Batteriekapaziät in Wh ohne Angabe der Einheit
<Reading>:<Einheit> - Reading welches die Kapazität liefert und die Einheit der Wertes (Wh, kWh)
etotal   Der Schlüssel ist eine Pflichtangabe mit der oben angegebenen Syntax. Der Wert ist die gesamte verbrauchte Ladeenergie.
pcurr   Der Schlüssel ist eine Pflichtangabe mit der oben angegebenen Syntax. Der Wert ist die aktuelle Ladeleistung.
power   Maximale Ladeleistung des Fahrzeugs bzw. der Wallbox mit der oben definierten Syntax.
currSoC   <Reading> - Reading des Devices welches den aktuellen Batterie-SoC des Fahrzeugs in % liefert.
   Das Reading muß einen Wert im Bereich 0 < X <= 100 liefern.
targetSoC   Optionale Angabe des Ziel-SoC für die Ladesession. Die Angabe kann alternativ festgelegt werden durch:
Ganzzahl: 0..100 - der Ziel-SoC in % als feste Einstellung (default: 80)
<Reading> - Reading welches den Ziel-SoC in (0..100 %) liefert.

Hier ist immer von der Syntax <Reading>:<Regex> oder <Reading>:<Einheit> die Rede. Müssen hier die Readings tatsächlich im SF-Device vorhanden sein oder wäre hier eher <Device>:<Reading>:<Regex> usw. richtig?

[DS_Starter]

Hallo Wolle02,

Hier ist immer von der Syntax <Reading>:<Regex> oder <Reading>:<Einheit> die Rede. Müssen hier die Readings tatsächlich im SF-Device vorhanden sein oder wäre hier eher <Device>:<Reading>:<Regex> usw. richtig?

Nein, nicht im SF-Device. Es wird davon ausgegangen, dass diese Readings im Consumer-Device, also typischerweise der Wallbox vorhanden sind. Das sollte ich wahrscheinlich in der Hilfe notieren.
Sollten andere Devices notwendig werden, müsste ich diese Möglichkeit erst noch vorsehen.