76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[Mikel2906]

Ja die Tagesüberschüsse sind zu hoch. Ich habe ein paar Screenshots beigefügt. Hilft dir das weiter?

[DS_Starter]

Die Abweichungen der PV Erzeugung sind deutlich zu groß.

- Wie lange ist die Anlage in Betrieb?
- Sind Änderungen vorgenommen worden?
- Sind alle Angaben bzgl. Ausrichtung richtig.
- Wie sehen die Autokorrekturfaktoren aus? (Klick auf den Punkt neben Autokorrektur)

  Sie sollten ungefähr so aussehen wie im Screenshot.

[Mikel2906]

Die Anlage ist seit Juni 2023 in Betrieb. Ich habe im Frühjahr einen Schreib-Lese-Kopf am Zähler installiert, weil der Wechselrichter keine richtigen Werte zur Verfügung gestellt hatte (Einspeisung, Verbrauch usw.). Nach der Installation hatte ich immer nächtliche Ausreißer beim Verbrauch und der Einspeisung. Das funktioniert schon lange. Im Juni musste ich den Raspberry Pi wechseln, da er defekt war. Ich habe alle Daten per Backup wieder eingespielt, und seitdem habe ich das Problem.

Wie soll ich vorgehen? Einfach warten und noch weitere Daten sammeln, bis es funktioniert?

[DS_Starter]

Wenn du auf den Screenshot schaust, siehst du das Problem. Die Faktoren sind jenseits von gut und böse. Normal sind Faktoren 0.2 - 1.5, maximal 2. Wodurch auch immer das gekommen ist.
Die müssen alle weg und neu aufbauen lassen.

Dazu nutzt du den Befehl:

Code Auswählen Erweitern

set <name> reset pvCorrection cached
Danach sollten die Faktoren bei 1 liegen (im Popup prüfen) und dann lassen wir sie neu automatisch aufbauen.
Die Situation sollte sich jetzt aber deutlich verbessern, insbesondere die Prognosequalität.

[Mikel2906]

Alles klar habe ich gemacht. Vielen Dank Heiko und ein schönes Wochenende

[300P]

Hallo Zusammen an meinen ersten regnerischen Sonntag nach dem Urlaub !  ->>

Während des Urlaubes sind wir (Flussreise) bei gutem Wasserstand los und am Ende konnten wir nur noch an einer einzigen Stelle wieder ausschiffen. Fast wäre noch eine Busreise draus geworden.


Hab natürlich auf mein SF von unterwegs geschaut und Updates eingespielt....aber alle CON-Vorhersagewerte in den Wochen immer "totales Chaos".
Logisch - wir waren zwar nicht "present"-  aber das allein nutzt als INPUT augenscheinlich nicht viel wenn bei uns gar keiner keiner wäscht kocht - grillt - sauniert .... kein großer Verbrauch wenn überhaupt niemand langer da ist.

Da hatte ich bei der Rückfahrt eine Idee 

Die schwierigsten CON-Situationen waren fast immer

Urlaub / Abwesenheit
WP im Abwesendmodus
sehr stark geänderte Tagesstruktur
ungewöhnlich niedrige Grundlast
etc.

Genau diese Zustände könnten durch einen HouseMode explizit beschrieben, statt vom Netz bzw. Verbrauch irgendwie indirekt erraten werden zu müssen.
Dadurch gäbe es evtl. weniger Drift-Fehlalarme und die Slope Live wird auch in solchen Sonderphasen deutlich stabiler bleiben.

Falls Heiko, der ohnehin ständig freundlicherweise an neuen Features arbeite - optimiert und ergänzt, noch einen intessanten NN-INPUT einbringen "möchte" oder könnte.    

Trennung von Presence und zusätzlich eine Art "Betriebsmodus des Hauses".

Beispiel

Presence:
0 = niemand
1 = mindestens eine Person (das ist ja schon so vorhanden)

HouseMode:
normal        (alles wie "immer")
vacation      (Urlaub oder geplante längere Abwesenheit  da ist 100 % keiner da - sehr viel standy)
away          (da bleibt alles wegen kurzfristiger Abwesenheit  Stunden erst einmal auf normal)
sleep          (Nachtruhe)

Diese Informationen sind ja nicht identisch.
...und für die CON-Verbrauchsprognose sind diese vier z.B. sehr unterschiedliche Situationen.

- Du bist im Urlaub → presence = 0, HouseMode = vacation
- Alle arbeiten tagsüber → presence = 0, HouseMode = normal
- Nachts schlafen alle → presence = 1, HouseMode = sleep
- Homeoffice → presence = 1, HouseMode = normal

Mein angedachte HouseMode-Codierung wäre so

normal   -   Normalbetrieb
                Alltag, reguläre Nutzung, normale Heizung-, AC- und WP-Strategie.
vacation -   Geplante längere Abwesenheit
                Urlaub, WP / AC / Heizung auf Abwesend, Warmwasser dadurch reduziert, viele Systeme im Standby.
away     -   Kurzzeit-Abwesenheit
                Tagsüber niemand zu Hause, aber das Haus läuft im normalen Modus weiter.
sleep    -   Nachtruhe
                Bewohner anwesend, aber stark reduziertes Aktivitätsniveau.


Beispiele zwecks der Unterschiede zwischen den HouseModes

Merkmal                away                      vacation
-----------------------------------------------------------------------
Dauer                    Stunden                  Tage/Wochen
WP-Strategie         normal                    Abwesend
Warmwasser          normal                    reduziert
Kühlschrank etc.    gleich                     gleich
Grundlast               ähnlich                   oft deutlich niedriger
Nutzeraktionen      keine                       keine
(wie z.B. Sauna/Grill/Kochen)



Vielleicht ist es ja eine Überlegung Wert ? ? ?

[DS_Starter]

Hallo 300P,

willkommen zurück und ich hoffe der Urlaub war erholsam und voller Erlebnisse!

Da hatte ich bei der Rückfahrt eine Idee 

Ideen sind immer gut. 

Problem wird sein, dass speziell bei dir die Datensätze mit Presence=0 vermutlich sehr gering zur Gesamtzahl sind. Du kannst probieren beim Training mit aiControl->aiConAbsOversample die Einflußstärke der Abwesenheit zu steigern.

Ungeachtet dessen, lass uns mal den HouseMode etwas genauer anschauen denn es gibt bereits einige Dinge im System die das Konstrukt abbilden:

HouseMode:
normal        - dafür gibt es keine Zusatzinfo, ist auch nicht nötig
vacation      - (Urlaub oder geplante längere Abwesenheit  da ist 100 % keiner da - sehr viel standy)
                -> dafür gibt ist in SF bereits die zentrale FHEM holiday2we Funktionalität eingebaut
                -> d.h. wenn du deine Kalender pflegst und sie in FHEM verfügbar sind, bekommt SF automatisch
                  die Urlaubsinformationen
away          - dafür gibt es setupEnvironment->presence
sleep        - dafür werden die Stundenfeatures in SF genutzt


Übersetzt heißt das entsprechend deiner Zustandstabelle für das Training bzw. Inferenz in SF:

- Du bist im Urlaub → presence = 0, holiday2we = 1
- Alle arbeiten tagsüber → presence = 0, holiday2we = 0
- Nachts schlafen alle → presence = 1, SF Stundenfeatures (Auswertung CON-Verhalten für jede Stunde, holiday2we = 0)
- Homeoffice → presence = 1, holiday2we = 0


Das heißt, der KI liegen alle Informationen bereits vor, nur in diskreten oder anderen Aggregationen.
Man kann nun aus diesen Informationen durch Verknüpfungen einen Zustand Homemode=0 ... 1 ableiten.
Nur steckt darin kein zusätzlicher Informationsgehalt für die KI als er bereits vorhanden ist und hätte lediglich einen redundanten Charakter.

Grundsätzlich ist die Idee schon gut, nur bräuchte man Informationen, die die KI bisher noch nicht in irgendeiner Form erhält. Wenn du da noch Ideen hättest -> einfach raushauen. 

LG,
Heiko

[DS_Starter]

Hallo zusammen,

ich habe soben die V 2.9.1 eingecheckt.

Zusammenfassung der Version:

- ein Gap in den Profilen wurde entdeckt die heatpump beinhalten aber kein pv (v1_heatpump zum Beispiel).
  In diesen Fällen wurden nicht alle heatpump-Features einbezogen.

  Die betroffenen User trainieren bitte mit der V 2.9.1 neu.
 
- Es gibt nun den Befehl "set .. reset aiData setValue ...". Damit können aiRawdata-Werte gezielt korrigiert werden.

- das Gemini Model kann im Schlüssel aiControl->geminiAPIkey nach dem API-Key angegeben werden (default: gemini-2.5-flash)

- die Victron API ((Model VictronKiAPI) kann den neuen Token-Auth verwenden


LG,
Heiko

[300P]

vacation      - (Urlaub oder geplante längere Abwesenheit  da ist 100 % keiner da - sehr viel standy)
                -> dafür gibt ist in SF bereits die zentrale FHEM holiday2we Funktionalität eingebaut
                -> d.h. wenn du deine Kalender pflegst und sie in FHEM verfügbar sind, bekommt SF automatisch
                  die Urlaubsinformationen

Ja hatte ich  auch eingepflegt

Code Auswählen Erweitern

# $Id: nw.holiday 22661 2020-08-24 12:56:10Z betateilchen $
# Feiertage in Nordrhein-Westfalen
# Siehe auch
# http://de.wikipedia.org/wiki/Feiertage_in_Deutschland

# Format fuer einzelne Tage: 1 MM-DD <Text>
1 01-01 Neujahr
1 05-01 Tag der Arbeit
1 10-03 Tag der Deutschen Einheit
1 11-01 Allerheiligen
1 12-25 1. Weihnachtstag
1 12-26 2. Weihnachtstag

# Osterbezogene Feiertage
# Format: 2 <relative Tage von Ostern> <Text> 2 -2 Karfreitag
2 -2 Karfreitag
2  1 Ostermontag
2 39 Christi Himmelfahrt
2 50 Pfingstmontag
2 60 Fronleichnam


#
# Erweiterung
# Urlaub immer wieder manuell eintragen !!!
# Format: 4 MM-DD MM-DD <Text>
#

4 07-11 07-18 Flussreise xxxxxxxxxxxxxx
4 08-30 09-06 xxxxxxx Norderxxxxx

away          - dafür gibt es setupEnvironment->presence

auch das ist bei mir aktiv für mehrere Handy (Personen)
-> egal wer oder wieviele Personen von der Familie zuhause anwesend sind ->>ist dann ist es "1"    (ansonsten wenn gar keiner da ist "0")

sleep        - dafür werden die Stundenfeatures in SF genutzt

gibt es da irgendwo was zu lesen wie das wirkt ? ich hab's dann bislang wohl irgendwie übersehen /-lesen....


Das alles aber auch diesmal nix genutzt

PS:
Das mit dem AC-/ WP- "away"-Betrieb Betrieb könnte für AC/WP evtl. mittels eines weiteren "opmode" noch mitgeteilt werden.
Bei mir gibt es z.B. einen einfachesn "absent" Buttom in der App (aus der Ferne) oder an dem Touchscreen der IDU (Inneneinheit) der alles auf sehr sparsam, Frostschutz etc. stellt und dies mittels der Schnittstelle im Device als Reading (set/get) auch zur Verfügung stellt / übernimmt.
   

[DS_Starter]

gibt es da irgendwo was zu lesen wie das wirkt ? ich hab's dann bislang wohl irgendwie übersehen /-lesen....

Nein. Das sind Bestandteile der internen Features die an den Profilen hängen. Man kann sich das im Code indirekt ansehen bzw. einlesen.
In V 2.9.0 Zeilen 1936 - 1952 -> Zeitstruktur time-base. Dort sind die grundlegenden Zeitstrukturen verankert. time-base ist Mitglied der Basis-Features im _aiFannFeatureBuilder.  Wenn man _aiFannFeatureBuilder im Code sucht kommt man automatisch zu aiFannConDataLoad wo die ganzen Trainingsdaten aus aiRawData und anderen nötigen Quellen zusammengestellt und aufbereitet werden.

Die Tageszeit/Nachtzeit ist über hod bzw. Sonnenstandsparameter integraler Bestandteil jedes Datensatzes. Genauso die Jahreszeit über den Monat eingebaut im Index aus dem extrahiert wird:

Code Auswählen Erweitern

2026071918 => hod: 18, dayname: So, sunaz: 262.50, sunalt: 32.80, rad1h: -, wcc: 27, weatherid: 1, rr1c: 0.00, temp: 20.6, socwhsum: 31968
              windspeed: 4.65, windspeed_fast: 4.65, pvrl: 1591, pvrlvd: 1, comforttemp: 21, conaifc: 784, con: 610, gcons: 11, presence: 1, holiday: 0
              hpcsm: -, bevcsm: -
              rcmdcsm01: 0:100, rcmdcsm02: 1:100, rcmdcsm03: 0:100, rcmdcsm04: 0:100, rcmdcsm05: 0:100, rcmdcsm06: 1:0, rcmdcsm07: 0:100, rcmdcsm08: 1:0, rcmdcsm09: 0:100, rcmdcsm10: 1:0
              rcmdcsm11: 0:100, rcmdcsm12: 0:100, rcmdcsm13: 0:100, rcmdcsm14: 0:100
              exconfc01: 0, exconfc03: 0, exconfc04: 0, exconfc05: 0, exconfc06: 0, exconfc07: 0, exconfc08: 0, exconfc09: 0, exconfc11: 1, exconfc12: 1
              exconfc13: 0, exconfc14: 0
              csme01: 28, csme03: 0, csme04: 123, csme05: 0, csme06: 11, csme07: 0, csme08: 10, csme09: 28, csme11: 0, csme12: 0, csme13: 0, csme14: 0


Das mit dem AC-/ WP- "away"-Betrieb Betrieb könnte für AC/WP evtl. mittels eines weiteren "opmode" noch mitgeteilt werden.
Bei mir gibt es z.B. einen einfachesn "absent" Buttom in der App (aus der Ferne) oder an dem Touchscreen der IDU (Inneneinheit) der alles auf sehr sparsam, Frostschutz etc. stellt und dies mittels der Schnittstelle im Device als Reading (set/get) auch zur Verfügung stellt / übernimmt.

Den möglichen opmode in heatpump zu erweitern halte ich für eine sinnvolle Möglichkeit. Dann wäre z.B. möglich:

off heating defrost hotwater cooling pool poolheating economy

Der economy-Mode könnte algemein den Sparbetrieb der WP kennzeichnen der bei Abwesenheit, oder auch in anderen Fällen, eingeschaltet wird.

Ich kann auch nachvollziehen, dass Abwesenheit in der KI noch nicht zur Geltung kommt. So viele Datensätze mit Abwesenheit bei nicht berufstätigen Haushalten werden halt nicht gesammelt.
Bis das anschlägt ist es vllt. sinnvoll, in der Zeit der Abwesenheit die CON-Prognose durch Legacy vornehmen zu lassen. Das geht einfach und dynamisch mit aiControl->aiConAlpha=0, z.B.:

Code Auswählen Erweitern

set <name> attrKeyVal aiControl aiConAlpha=0

und danach wieder

set <name> attrKeyVal aiControl aiConAlpha=1


Das hat keinen Einfluß auf die Datensammlung und die darauf folgenden Trainings.

[300P]

Bis das anschlägt ist es vllt. sinnvoll, in der Zeit der Abwesenheit die CON-Prognose durch Legacy vornehmen zu lassen. Das geht einfach und dynamisch mit aiControl->aiConAlpha=0, z.B.:

👍
manchmal ist ja so einfach....und man selber sieht den Wald vor lauter Bäumen nicht 🤩


Ansonsten geb ich dir recht - es gibt im Ansatz ja nicht viele Stunden/Tage wo alle bei uns "abwesend" sind..


Aktuell sind es 670 Werte bei mir mit "presence: 0" - beginnend ab 20.Januar 2026.

Das wären bei mir (24 Stunden * 6 Monate * 30 Tage) dann so ca. 15 %  Abwesenheit.
Eigentlich doch schon was an Daten - aber sicherlich auch wenig Treffer bei hohen Temperaturen >= 25 °C ...


PS:
Der evtl. zukünftige zusätzliche "neue" opmode wird da aber auch sicherlich schon viel helfen.