76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Hallo zusammen,

in meinem contrib liegt die V 1.51.6.
Die verfügbaren Balkencontents bzgl. Batteriewerten sind etwas umgebaut (um die neuen Optionen zu ermöglichen) und erweitert.

- der bisherige Content batsocforecast_XX ist in batsocCombi_XX umbenannt
- neuer Content batsocForecast_XX
- neuer Content batsocReal_XX
- neuer Content batsocForecastSum   
- neuer Content batsocRealSum       

Nun können die Batteriewerte wie folgt in den Balken dargestellt werden:

batsocCombi_XX          der prognostizierte (ab kommender Stunde) und bis zur aktuellen Zeit real erreichte SOC (%) der Batterie XX
batsocForecast_XX      der prognostizierte SOC (%) der Batterie XX
batsocReal_XX              der real erreichte SOC (%) der Batterie XX
batsocForecastSum    der prognostizierte SOC (%) als Summe über alle Batterien
batsocRealSum        der real erreichte SOC (%) als Summe über alle Batterien


Die Umsetzung von batsocforecast_XX ist in batsocCombi_XX (falls gesetzt) erfolgt automatisch beim Restart. "Save" nicht vergessen.

@Gerd (Max__Meyer),
dein Request ist jetzt auch mit drin.

LG,
Heiko

[Max_Meyer]

Hallo zusammen,

in meinem contrib liegt die V 1.51.6.

@Gerd (Max__Meyer),
dein Request ist jetzt auch mit drin.

LG,
Heiko

Hallo Heiko,
Danke! - für mich ist das optimal- hab's gleich probiert und seh  jetzt 3x den Prognose-Ist-Vergleich
Gruß Gerd
PS: du musst aber auch mal Pause machen!

[tupol]

Hallo Heiko,

ich habe das in der Wiki erläuterte Diagram zur Darstellung der PV-Erzeugung umgesetzt und bin ganz begeistert, das Ganze jetzt auf diesem Wege verfolgen zu können. Allerdings finde ich persönlich die Darstellung besser mit "steps" anstatt "lines". (Siehe unterer Screenshot der deiner Umsetzung im Modul ähnelt.) Einziges Manko, es fehlt der AllPVforecastsToEvent-Eintrag=0 in der Stunde vor dem Sonnenaufgang. Dadurch fängt die Sonnenaufgangs-Stufe bereits beim Sonnenuntergang an. (siehe "initiale PV Vorhersage" im Bild.)
Meine Bitte: Könnt man zur vollen Stunden vor dem Sonnenaufgang noch ein AllPVforecastsToEvent=0 Eintrag setzen? (Oder eventuell für jede Stunde?)

Noch eine Frage zur AI beim DWD. Wie kommt es, dass nur die Sonnenhöhe und nicht auch die Sonnenrichtung Einfluss hat? Geometrisch gesehen ist z. B. bei mir die Verschattung und der Bestrahlungswinkel der Module von beiden abhängig? Die Uhrzeit ist da ja weniger relevant. Oder verstehe ich da etwas falsch?

Gruß
tupol

[DS_Starter]

Guten Morgen,

@tupol, ich schau mir das mal an. Bin mir aktuell unsicher, ob das relativ einfach zu realisieren ist. Kann ich noch nicht sagen.

Noch eine Frage zur AI beim DWD. Wie kommt es, dass nur die Sonnenhöhe und nicht auch die Sonnenrichtung Einfluss hat? Geometrisch gesehen ist z. B. bei mir die Verschattung und der Bestrahlungswinkel der Module von beiden abhängig? Die Uhrzeit ist da ja weniger relevant. Oder verstehe ich da etwas falsch?

Die Sonnenrichtung wird auch berücksichtigt. Die Uhrzeit ist im Prinzip ein Stellvertreterwert für die Sonnenrichtung. Tatsächlich wird die KI aber neben der Uhrzeit auch mit dem Sonnenazimuth (sunaz) gefüttert. Zu beachten ist, dass wir immer mit Stundenslots arbeiten, alles im Modul (außer aktuelle "Current" Werte) wird auf Stundenbasis gerechnet.
In den Entscheidungssätzen wird das Azimuth aber kaum aufgeführt. Warum das so ist, kann ich nicht beantworten, nur mutmaßen.

So könnte ich mir vorstellen, dass die Trefferanzahl bei Benutzung der Uhrzeit höher ist. Kleines Beispiel zur Erläuterung. Hier sind ein paar Datensätze gleicher Uhrzeit:

Code Auswählen Erweitern

2025033012 => hod: 12, nod: So, sunaz: 146, sunalt: 38, rad1h: -, wcc: 100, wid: 3, rr1c: 0.30, pvrl: 540, con: 584, temp: 7
2025033112 => hod: 12, nod: Mo, sunaz: 146, sunalt: 38, rad1h: -, wcc: 100, wid: 3, rr1c: 0.00, pvrl: 689, con: 574, temp: 7
2025040112 => hod: 12, nod: Di, sunaz: 146, sunalt: 38, rad1h: -, wcc: 64, wid: 2, rr1c: 0.00, pvrl: 4583, con: 1353, temp: 9
2025040212 => hod: 12, nod: Mi, sunaz: 145, sunalt: 39, rad1h: -, wcc: 20, wid: 1, rr1c: 0.00, pvrl: 4312, con: 982, temp: 11
2025040312 => hod: 12, nod: Do, sunaz: 145, sunalt: 39, rad1h: -, wcc: 0, wid: 0, rr1c: 0.00, pvrl: 5832, con: 1128, temp: 12
2025040412 => hod: 12, nod: Fr, sunaz: 145, sunalt: 40, rad1h: -, wcc: 0, wid: 0, rr1c: 0.00, pvrl: 5715, con: 918, temp: 16
2025040512 => hod: 12, nod: Sa, sunaz: 145, sunalt: 40, rad1h: -, wcc: 100, wid: 3, rr1c: 0.00, pvrl: 5015, con: 1123, temp: 11
2025040612 => hod: 12, nod: So, sunaz: 145, sunalt: 40, rad1h: -, wcc: 100, wid: 3, rr1c: 0.00, pvrl: 3007, con: 508, temp: 4
2025040712 => hod: 12, nod: Mo, sunaz: 145, sunalt: 41, rad1h: -, wcc: 56, wid: 2, rr1c: 0.00, pvrl: 4632, con: 641, temp: 9
2025040812 => hod: 12, nod: Di, sunaz: 145, sunalt: 41, rad1h: -, wcc: 27, wid: 1, rr1c: 0.00, pvrl: 3782, con: 417, temp: 11
2025040912 => hod: 12, nod: Mi, sunaz: 145, sunalt: 42, rad1h: -, wcc: 67, wid: 2, rr1c: 0.00, pvrl: 3729, con: 743, temp: 12
2025041012 => hod: 12, nod: Do, sunaz: 145, sunalt: 42, rad1h: -, wcc: 100, wid: 3, rr1c: 0.00, pvrl: 1449, con: 1198, temp: 9

Bei diesen 12 Datensätzen ist die Uhrzeit 12 mal gleich, das Azimuth aber nur 9 mal (145), die anderen Datensätze haben 1 Grad Änderung. Vermutlich hat das Auswirkung bei der Wichtung der Parameter, hod 12 wird vllt. als "höherwertiger" bei der Entscheidungsfindung als sunaz bei einem Grad Unterschied angesehen.

Wenn ich mal Zeit finde, will ich auch nochmal eine weitere KI, z.B. unter Verwendung von PDL::LinearAlgebra oder AI::NeuralNet::BackProp, implementieren und schauen wie sich die Ergebnisse damit gestalten.

LG,
Heiko

[DS_Starter]

@tupol, @all,

in meinem contrib liegt die V 1.51.7.
Die Events  'AllPVforecastsToEvent'-Events starten nun in täglich mit einem 0-Event um den definierten Aufsetzpunkt für die SVG-Plots zu haben.

Darüber hinaus gibt es mit plantControl->genPVforecastsToEvent die Möglichkeit die Events für den Plot-Type 'steps' zu optimieren. Die generelle Aktivierung von 0-Werten zu Beginn jeder Stunde würde zu einer unschönen Darstellung bei SVG 'lines' führen (siehe 3. Screenshot).

Code Auswählen Erweitern

genPVforecastsToEvent
Das Modul erzeugt täglich 'AllPVforecastsToEvent'-Events zur Visualisierung der PV Prognose.
Nähere Erläuterungen dazu sind im Wiki beschrieben
Die Eventerzeugung kann für bestimmte Nutzungen optimiert werden.
adapt4Steps - die Events werden für den SVG Plot-Type 'steps' optimiert

Die Auswirkung von genPVforecastsToEvent=adapt4Steps sieht man im 1. Screenshot.

LG,
Heiko

[Prof. Dr. Peter Henning]

Vergleichbar mit der Entwicklung vom Kleinkind über Schulkind zum Experten. 

Hm, ich hoffe mal, das meinst du als Witz. Menschen lernen durch Regelbildung - ein neuronales Netz bildet keine Regeln.

LG

pah

[DS_Starter]

Hallo pah,

damit wollte ich lediglich zum Ausdruck bringen, dass je mehr (Lern)datensätze der KI zur Vefügungung stehen die Anzahl der Knoten (und auch der Tiefe) steigt und damit eine granularere Ergebnisbildung ermöglicht wird.
Falls ich falsch liege oder es unrichtig ausgedrückt haben sollte ... bitte mich/uns gerne aufklären und es wissenschaftlich korrekt beschreiben. Ich lerne die Zusammenhänge um KI im Allgemeinen und deren Anwendung in unserem Kontext immer mehr und versuche weitere Verbesserungen zu erschließen.

LG,
Heiko

[Prof. Dr. Peter Henning]

Es geht ja hier nicht um Wissenschaft, insofern können wir den Ball flach halten.

Aber noch einmal: Die KI-Modelle, die Du verwendest, kennen keine Regeln. Sie haben nichts verstanden und werden auch nie etwas "verstehen". Sie können lediglich Muster erkennen. Und wenn sie kein Muster erkennen, erfinden sie komplett neue Realitäten.

Ein guter und einfach formulierter Artikel dazu ist hier zu finden: https://de.wikipedia.org/wiki/Halluzination_(K%C3%BCnstliche_Intelligenz)

Für Deine Vorhersage ist das weitgehend irrelevant - im Zweifelsfall ist einfach die Vorhersage falsch. Wenn man allerdings, und sei es nur in einer Rand-Diskussion, den Eindruck erweckt, solche Systeme könnten lernen und denken, entsteht die gewaltige Gefahr des Missbrauchs.

LG

pah

[DS_Starter]

Hallo Tobi,

ich habe nun ein wenig über deine Fragen in #2682 nachgedacht.

Kann man auch eine (stündliche) Prognose des Netzbezugs haben?
...
Gibt es (eventuell in einer fernen Zukunft) die Möglichkeit ein Verbrauchsvorhersage über die KI mit der Wettervorhersage in Verbindung zu bringen?

Beide Dinge sind m.M. nach eng miteinander verbunden.
Bereits längere Zeit habe ich vor die Verbrauchsvorhersage mit einem KI-Algo unterstützen zu lassen. Die Jahreszeiten bzw. Temperaturen und weitere Umwelteinflüsse können dabei der KI zur Verfügung gestellt werden.
Der erwartete Netzbezug ist unter anderem vom Ladezustand der Batterien (wenn vorhanden) und der Tageszeit (Lastgang) abhängig. Auch das kann eine KI m.M. nach gut verknüpfen.
In der V 1.51.7 habe ich KI-Rohdatensammlung erweitert.
Beide Fragen würde ich jetzt mal mit "Ja" beantworten und habe sie bei mir in die Planung aufgenommen.

LG,
Heiko 

[DS_Starter]

@all,

die V 1.51.7 ist eingecheckt.

LG

[300P]

Guten Tag Zusammen,

hier ein Tipp für die Nutzer der "ctrlSpecialReadings" bei den Consumern.

Mit FHEM bin ich die Tage vom RPI auf einen QNAP-Container umgezogen.
Parallel hab ich dabei 2 ConsumerXX (03/07) abgekoppelt und die zugehörigen attr gelöscht weil es sinnlos ist so geringe Verbraucher zu beobachten oder gar zu steuern.

Gestern bzw. heute habe ich dann zufällig dabei bemerkt das die "ctrlSpecialReadings" für die gesamten ConsumerXX nicht mehr bereitgestellt werden (einige Werte werden bei mir oben im Kopfbereich angezeigt),

Hier der Tipp :
Wer also einen ConsumerXX per attr "delete" entfernt muss darauf achten das er ihn auch bei den "ctrlSpecialReadings" nicht mehr angeklickt hat - falls er diese Werte als Reading vorher gesehen hat.
==>> Ansonsten werden alle ConsumerXX-Reading bei den "ctrlSpecialReadings" nicht mehr angezeigt.

Gruß
300P


##################

Hat sich mit V1.51.8 erledigt (s.u.) 


####################

[DS_Starter]

Problem erkannt und ist mit V 1.51.8 behoben.
Die V habe ich soeben in mein contrib geladen.

LG

[300P]

Hallo Heiko,

mein Consumer '_WP_Heizstab_WW' schaltet sich bei mir schön ein und aus:

Code Auswählen Erweitern

2025.05.02 18:00:02 2: Forecast - Consumer '_Brunnen' was external switched off
2025.05.02 18:00:32 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'on', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B on", cause: existing surplus
2025.05.02 18:00:33 2: Forecast - Consumer '_WP_Heizstab_WW' switched on (continued)
2025.05.02 18:20:23 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'off', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B off", cause: surplus shortage (Automatic = 1)
2025.05.02 18:20:23 2: Forecast - Consumer '_WP_Heizstab_WW' switched off (interrupted)
2025.05.02 18:20:53 2: Forecast - Consumer '_WP_Heizstab_WW' was external switched on
2025.05.02 18:20:53 2: Forecast - switching Consumer '_WP_Heizstab_WW' to 'on', command: "set FBDECT_fbahahttp_E8_DF_70_07_42_0B on", cause: existing surplus
2025.05.02 18:20:53 2: Forecast - Consumer '_WP_Heizstab_WW' switched on (continued)

Aber warum wird um 18:20:53 ein externes schalten dabei erkannt
- da wird eigentlich doch "nur" durch SF geschaltet
- irgendwie beachtet er auch nicht die 'locktime' von 300:300
(->>V1.51.8 )

EDIT : war auch schon vorher - hab mal im Log gesucht

Hier der Consumer '_WP_Heizstab_WW':

Code Auswählen Erweitern

FBDECT_fbahahttp_E8_DF_70_07_42_0B
type=heater
power=2170
mode=can
icon=sani_buffer_electric_heater_side@orange
mintime=SunPath
on=on
off=off
asynchron=0
notbefore=08:00
notafter=19:00
locktime=300:300
pcurr=power:W
etotal=energy:Wh
surpmeth=10
interruptable=1

[Dracolein]

Die Version V1.51.0 ist eingecheckt.
Es sind wie kommuniziert die Weiterentwicklungen V1.50.1 - 3 enthalten sowie:

- der Balkencontent batsocforecast_, energycosts, feedincome ist von der Wh -> kWh Konvertierung entkoppelt

- OpenMeteoDWDEnsemble: die Berechnung des Intervalls ist korrigiert

- ein neuer Setter cycleInterval zur dynamischen Anpassung der Datensammlung

- eine User spezifische Möglichkeit den Schwellenwert für die rot-Färbung der Haus->Consumer Linien festzulegen (flowGraphicControl->strokeCmrRedColLimit)


Die folgenden Attribute sind gelöscht (wenn obsolet) oder sind als Schlüssel in den Sammel-Attributen consumerControl bzw. plantControl aufgegangen:

- affectBatteryPreferredCharge, affectConsForecastInPlanning, ctrlShowLink, ctrlBackupFilesKeep
- affectConsForecastIdentWeekdays, affectConsForecastLastDays, ctrlInterval, ctrlGenPVdeviation
- affectSolCastPercentile, ctrlSolCastAPIoptimizeReq, consumerAdviceIcon, consumerLink, consumerLegend

Noch ein Wort zu den Attributen.
Ziel ist es, die Anzahl der Attribute im Zaum zu halten und wo es möglich und sinnvoll erscheint, thematisch in Sammelattributen zu clustern.
Es können später auch noch weitere Zusammenfassungen entstehen.

Solltet ihr jedoch aus irgendwelchen Gründen bestimmte Attribute weiterhin als separate Attribute benötigen, kann ich diese Attribute auch wieder aus den Sammelattributen herauslösen und als ctrl-Attr bereitstellen oder alternativ einen dynamischen Setter (wie cycleInterval) implementieren.
Solche Setter sind für dynamische Änderungen besser geeignet weil z.B. kein manueller "save" nötig ist.

Wie gesagt ist das Ziel so wenig Attribute wie möglich und soviel Attribute wie nötig im Modul zu haben.
Es soll aber keiner auf entsprechenden Komfort verzichten müssen.
Ich hoffe das klärt nochmal den Grund für diese Bemühungen.

PAH hatte seinerzeit ein schönes grafisches Interface auf JavaScript-Basis zur Einstellung aller Attribute angeregt. Das würde mir ebenfalls sehr gut gefallen. Allerdings sind meine JS-Fähigkeiten sehr beschränkt.
Wer diesbezüglich in der Lage ist und gern unterstützen möchte, ist herzlich willkommen.

LG,
Heiko

Hallo Heiko, ich habe heute nach (viel zu) langer Zeit ein Update laufen lassen und folgende Hinweise im Log gefunden, die ich in formativ teilen möchte:

Code Auswählen Erweitern

2025.05.02 19:07:54 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14712.
2025.05.02 19:07:54 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14712.
2025.05.02 19:07:54 1: PERL WARNING: Use of uninitialized value $FW_ME in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14732.
2025.05.02 19:07:54 1: PERL WARNING: Use of uninitialized value $FW_subdir in concatenation (.) or string at ./FHEM/76_SolarForecast.pm line 14732.

Desweiteren zeigt mir FHEM folgende Hinweise:

[300P]

Das mit den Perlwarnings ist bekannt und soweit okay

Schau mal hier im Beitrag #2605 und ..ff


Die Hinweise kommen weil evtl. Attribute inzwischen umbenannt worden sind.

Gruß
300P