76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Mikel2906]

Hallo Heiko,
ich habe im Log diese Fehlermeldung.

03:00:06 1: PERL WARNING: Use of uninitialized value $_ in pattern match (m//) at ./FHEM/76_SolarForecast.pm line 31005

my $persist_cnt = grep { /^(moderate|severe)$/ } @recent;

Welche Variable fehlt in meiner Config?

Gruß Michael

Version 2.9.1

[DS_Starter]

@300P,
dann werde ich den neuen opmode gleich mit ins Training integrieren, dann dürften auch die Warnungen weg sein.

@Michael,

Welche Variable fehlt in meiner Config?

Da fehlt nichts. Es ist vermutlich ein Gap innerhalb des Moduls bei der Prüfung.
Es sind weniger Stundensätze da als geprüft werden sollen. Schaue ich mir mir an.
 

[DS_Starter]

Ich habe die von euch gemeldeten Warnungen vermutlich beseitigt.
Update liegt im contrib.

[300P]

@300P,
dann werde ich den neuen opmode gleich mit ins Training integrieren, dann dürften auch die Warnungen weg sein.

Das wird ja so oder dauern ehe da was an Daten mit "eco" anfallen werden (jedenfalls bei mir).
Aber andere fahren ja vielleicht schon die Tage noch in Urlaub und schalten auf das "eco"....und sind danach auch wieder lange @home........


EDIT:
Neue Contrib-Version provier ich dann gleich.... Danke

[Flachzange]

Nabend zusammen,

nach dem Release ist vor dem Release ...

Wie von Chris in #6533 angeregt, kann man nun mit dem Schlüssel plantControl->writeForceType eine Datenspeicherung im Filesystem erzwingen. Diese Möglichkeit ist nur für configDB-User relevant.

writeForceType    
Legt den Persistenztyp für die Speicherung der Bewegungsdaten fest. (Manche Daten werden grundsätzlich im Filesystem persistiert)
   auto - Speicherung in Filesystem oder ConfigDB wenn vorhanden, file - Speicherung im Filesystem, default: auto

Die Version 2.8.1 liegt im contrib.

LG,
Heiko

Hallo Heiko,

danke, habe jetzt erst die Gelegenheit gehabt mir das mal anzuschauen und zu testen. Du scheinst das file-Attribut ausschließlich beim Speichern zu nutzen. Das muss ja analog bei allen Datei-Operationen gemacht werden, sonst wird beim Einlesen ein alter Stand aus configDB gezogen und nicht aus der Datei.

Der Einleseaufruf findet heute aber vor der Auswertung von plantControl->writeForceType statt und dadurch wird hier grundsätzlich erstmal immer auto herangezogen, was dann ebenfalls wieder zum alten Stand führt, selbst wenn es dort berücksichtigt würde.

Ich bin mir ehrlich gesagt nicht sicher, ob es das Attribut wirklich braucht. Es ist auch als configDB-Nutzer völlig OK, wenn Module derartige Laufzeitdaten immer im Dateisystem ablegen. Keep it simple hätte ich gesagt.

Gruß
Chris

[DS_Starter]

Hallo Chris,

danke für den Hinweis. Stimmt natürlich, dass es beim Lesen ebenfalls ziehen muß.
Schaue ich mir morgen an.
Ich habe einen Attr-Schlüssel gewählt damit configDB-User die Wahl haben.

LG,
Heiko

[Flachzange]

Hallo Chris,

danke für den Hinweis. Stimmt natürlich, dass es beim Lesen ebenfalls ziehen muß.
Schaue ich mir morgen an.
Ich habe einen Attr-Schlüssel gewählt damit configDB-User die Wahl haben.

LG,
Heiko

Danke, bitte dann nur bedenken, dass das Einlesen erst nach der Auswertung des Attr-Schlüssel erfolgen darf und bitte alle File-Operationen anpassen (siehe auch Anhang in https://forum.fhem.de/index.php?msg=1366008)

[300P]

Ich habe die von euch gemeldeten Warnungen vermutlich beseitigt.
Update liegt im contrib.

V2.9.2 ->> sehe nix mehr - Danke

[DS_Starter]

Danke, bitte dann nur bedenken, dass das Einlesen erst nach der Auswertung des Attr-Schlüssel erfolgen darf

Ja und das wird eine etwas größere Herausforderung.
Mal sehen ob das machbar ist, ansonsten werde ich tatsächlich Filesystem lesen/schreiben fixieren müssen.

[Bitschubser]

Hallo,

ich habe ein Problem mit den prognostizierten Verbrauchswerten. Die liegen teilweise viel zu hoch.
Ich vermute, dass der Verbrauch der Wallbox mit in die Prognose einbezogen wird, denn ein durchschnittlicher Verbrauch 10 bis 11 kW in einer Stunde ohne Wallbox ist schon schwer zu erreichen.
Meine Wallbox ist als consumer01 definiert:

Code Auswählen Erweitern

attr SolarForecast consumer01 CP_OpenWB type=noSchedule power=11000 icon=wallbox pcurr=chargepoint5_power:W etotal=chargepoint5_imported:Wh exconfc=1Das müsste doch passen, oder?
CP_OpenWB ist die Wallbox und chargepoint5_power ist das Reading mit der Ladeleistung in Watt
In der Grafik wird der verbrauch des Hauses und der Wallbox korrekt angezeigt.

Wie kann ich sehen wer oder was die Prognose so hochtreibt und das dann ggf. unterbinden?

[300P]

z.B. so:

(Alle Verbrauchswerte >= 5000 kWh / Stunde)

set Forecast reset aiData searchValue=con>=5000

2026.07.25 15:41:05 1: Forecast - AI Raw data found - idx: 2026043015 -> key=con, val=5208
2026.07.25 15:41:05 1: Forecast - AI Raw data found - idx: 2026050115 -> key=con, val=5552
2026.07.25 15:41:05 1: Forecast - AI Raw data found - idx: 2026051120 -> key=con, val=6638
2026.07.25 15:41:05 1: Forecast - AI Raw data found - idx: 2026051121 -> key=con, val=5984
2026.07.25 15:41:05 1: Forecast - AI Raw data found - idx: 2026051122 -> key=con, val=5079
2026.07.25 15:41:05 1: Forecast - AI Raw data found - idx: 2026062716 -> key=con, val=5009



Kommt aber auch auf andere Parameter noch an

[Prof. Dr. Peter Henning]

Ich möchte doch mal stark anregen, die Einheit kWh/Stunde durch kW zu ersetzen. Und wenn nötig, als Mittelwert zu kennzeichnen.

LG

pah

[DS_Starter]

Ich möchte doch mal stark anregen, die Einheit kWh/Stunde durch kW zu ersetzen.

Wo hast du eine solche Stelle gefunden? Suche im Code bringt keinen Fund.


Ach ... ist einfach zu warm 

LG,
Heiko

[Bitschubser]

Danke Peter für deinen Hinweis. Ich habe es selbstverständlich in meinem Post geändert.
Bringt mich aber nicht wirklich weiter.

[DS_Starter]

@Bitschubser,

was liefert dein Log mit ctrlDebug=consumption_long?

Verwendest du KI (Fann)? oder die Standard Legacy-Prognose?