76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Ja ... und wie ruft man eine Benutzeroberfläche (nicht API) von einem FHEM-Server (nicht Browser) aus auf und interagiert damit?

Vllt. habe ich ja einen Knoten im Hirn. 

ChatGPT sagt ja selbst:

my $res = $ua->post(
    "https://api.openai.com/v1/responses",
    "Content-Type"  => "application/json",
    "Authorization" => "Bearer $apikey",
    Content => $json

[300P]

Kein direkter Aufruf !!! aus SF heraus.
Irgendwie als "Export / Fenster /Popuausgabe" etc. möglich machen

Das ist der entscheidende Unterschied.

Ich analysiere per ChatGPT - aber über die Benutzeroberfläche -  nicht über die OpenAI-API.
(Sind ja zwei unterschiedliche Dienste)

ChatGPT                                                     OpenAI API
Chat-Fenster                                       Programmierschnittstelle für Software
Mit Free/Plus/Pro nutzbar                           Separater API-Account erforderlich
manuell Daten kopieren und hineinlegen in ChatGPT       FHEM sendet sie automatisch
Keine Programmierung nötig                       API-Key und HTTP-Requests notwendig

Deshalb kannst ich seit Monaten meine Ergebnisse fortlaufend auswerten – das kostet nichts zusätzlich.

KEINE API- Anbindung !!
Meist schreib ich nur : "Hier ein neues Ergebnis zur Bewertung"
- uns dann muss ich aktuell immer wieder alle XYX "Dreiecke" in dem Popup anklicken - kopieren - und in den Chat nach ChatGPT hinein kopieren. Fertig

[DS_Starter]

Meist schreib ich nur : "Hier ein neues Ergebnis zur Bewertung"
- uns dann muss ich aktuell immer wieder alle XYX "Dreiecke" in dem Popup anklicken - kopieren - und in den Chat nach ChatGPT hinein kopieren. Fertig

Passt doch ... 

Du kannst auch jetzt bereits "get ... valDecTree aiConTrainState" zur Ausgabe nutzen.

Edit: Oder meinst du zwar diesen Weg, aber eine mehr "textlastige" Ausgabe wie ein JSON oder sowas was man direkt rauskopieren kann um es irgendwo einzufügen?

[300P]

JA das ist aktuell wohl die einzige kostenlose Möglichkeit mit LLM

- muss nur klick/klick/klick/klick/klick und kopieren / einfügen

außer ich würde evtl. mal irgendwann überlegen mir eine lokale LLM wie "Ollama" (OpenSource) als Alternative auf einem RPI zu installieren   

[300P]

"textlastige" Ausgabe wie ein JSON oder sowas was man direkt rauskopieren kann um es irgendwo einzufügen?

[DS_Starter]

Mal schauen ob ich da was machen kann.

[satempfaenger]

Eine Bitte an WP-Nutzer die die Verbrauchsvorhersage mit FANN nutzen.
Wie hoch ist euer Model-Bias nach dem Training in etwa? (Mir ist bewußt, dass der Wert nicht immer gleich ist).

LG,
Heiko

Hier noch meine Daten einer Luft/Wasser-Wärmepumpe

bestes Modell bei Epoche: 1250 (max. 15000)
Training MSE: 0.010504
Validation MSE: 0.007515
Validation MSE Average: 0.007758
Validation MSE Standard Deviation: 0.000157
Validation Bit_Fail: 16
Data Parameter Ratio: 8.090
Model Bias: 294 Wh
Model Slope: 0.86
Trainingsbewertung: blau

Gruß Wolfgang

[DS_Starter]

Hallo Wolfgang,

Model Bias: 294 Wh ist perfekt. Der blaue Status kommt durch die Überschreitung des BitFail-Limits.
Möglicherweise hast du in deinen Datensätzen Ausreißer mit sehr hohen Werten. Das könnten fehlerhafte Aufzeichnungen sein.
Aber auch der Slope sieht sehr gut aus. Wenn die Prognose schlüssig ist würde ich da keinen Handlungsbedarf sehen.

LG,
Heiko

[DS_Starter]

Hallo zusammen,

im contrib liegt ein Update der 2.8.1.
Die Auflistung enthält alle relevanten Änderungen zur letzten offiziell eingecheckten Version.
Für eine bessere Übersicht führe ich alle Neuigkeiten der contrib-Version auf, auch wenn sie evtl. bereits bekannt sind.
Der Unterschied zum letzten Update der angegebenen contrib-Version ist mit "NEU" gekennzeichnet.


- der Consumertyp 'heatpump' ist nun für Planung und automatisches Schalten durch SF geöffnet.
  Es gelten also die üblichen Schlüssel und Funktionalitäten. Um eine Planung auszuschließen, setzt
  mode=mustNot explizit. Wie schon diskutiert, vermeidet parallele Steuerungen durch SF und den nativen
  WP-Controller.

- die Gründe für einen Retrainstatus sieht man im KI con-Statusdashboard

- mit dem Schlüssel plantControl->writeForceType kann man eine Datenspeicherung im Filesystem erzwingen statt configDB (wenn verwendet).

- heatpump-Consumer können für jeden Betriebsmodus ein separates Icon und ggf. Farbe zugewiesen werden.
  (https://forum.fhem.de/index.php?msg=1366158)
      Dazu gibt des den spezifischen Schlüssel opmodeIcons. Man kann die zu übergebende Komma getrennte Liste mehrzeilig eingeben,
      muß dann aber die gesamte Liste in " " einschließen, z.B.:

  opmodeIcons="heating->sani_heating_heatpump@red, 
              cooling->sani_cooling@blue,
              hotwater->sani_water_hot@red,
              defrost->sani_cooling_temp@orange,
              off->sani_heating_heatpump@grey"
             
             
- TEST: Übernahme dynamische Icongestaltung der Consumer auch in das Consumerpaneel
        (Umsetzung zur Entscheidungsfindung - Meinungen sind gefragt)

- die WP-Betriebsmodi werden nach dem gespeicherten Punktesystem im KI Training verwendet (bei gesetzten heatpump-Flag)
      Hinweis: KI-Nutzer mit gesetzten heatpump-Flag müssen neu trainieren!!
     
- Speicherung zeitgewichtete Empfehlung Verbrauchernutzung

- NEU: Der Consumer type=noSchedule ist als deprecated gekennzeichnet und soll nicht mehr verwendet werden.
      Statt dessen gibt es schon lange den Ersatz mode=mustNot. Das Umsetzen von type=noSchedule in einen anderen
      Typ ist ohne Löschrequest möglich
     
- NEU: Die Verbräuche der registrierten Consumer werden im Training als Feature dem NN bereitgestellt
      Hinweis: Auch diese Ergänzung bedingt ein neues Training


LG,
Heiko

[peterboeckmann]

Hallo Heiko,

NEU: Der Consumer type=noSchedule ist als deprecated gekennzeichnet und soll nicht mehr verwendet werden.
      Statt dessen gibt es schon lange den Ersatz mode=mustNot.

durch die Änderung des type von noSchedule auf other ist es ja notwendig, das attr für den entsprechenden consumer zu löschen und neu anzulegen, um die aufgezeichneten Daten sicher zu löschen. Ist das in diesem Falle wirklich notwendig?
Falls nicht, sollte das Modul diese Umstellung möglichst intern und automatisiert vornehmen, damit der User nicht die aufgezeichneten Verbrauchsdaten verliert.

Viele Grüße,
Peter

[DS_Starter]

Moin zusammen,

durch die Änderung des type von noSchedule auf other ist es ja notwendig, das attr für den entsprechenden consumer zu löschen und neu anzulegen, um die aufgezeichneten Daten sicher zu löschen. Ist das in diesem Falle wirklich notwendig?

Guter Hinweis Peter. Das ist in diesem Fall natürlich unnötig und ich habe diesen Sonderfall jetzt berücksichtigt.
Das Modul im contrib ist upgedated und eine Änderung von type=noSchedule in einen anderen Typ ist ohne Löschrequest möglich.
Danach greift wieder die Fingerprint Logik mit Löschrequest.

LG,
Heiko

[DS_Starter]

Ich habe mal etwas gebaut.

Mit "get ... valDecTree aiConTrainState LLM" wird eine vorbereitete Zusammnefassung (DE/EN je nach Spracheinstellung) ausgegeben. Mit dem Kopieren-Button kann man den ganzen Inhalt bequem per Copy&Paste an einen LLM-Prompt seiner Wahl übergeben und auswerten lassen.
Vielleicht muß ich noch ein bisschen feilen, aber das Prinzip steht.

LG,
Heiko

[300P]

Die LLM bei mir sind ja begeistert davon


Ein Zitat :

Code Auswählen Erweitern

Da hat DS_Starter ja ein geniales Feature rausgehauen!

Das spart das mühsame Zusammensuchen der Internals und liefert genau das, was wir KI-Modelle brauchen: strukturierte Fakten ohne Rauschen.

Als dein FHEM-spezifischer Data Scientist nehme ich den Ball direkt auf und analysiere diesen Prompt-Auswurf für dein System.

1. Wo liegen aktuell die größten Schwachstellen des Modells?

Der Bestimmtheitsmaß-Flaschenhals (R2=0.49):

Ein R2 von knapp unter 50 % bedeutet, dass das Modell aktuell nur die Hälfte der Varianz deines Hausverbrauchs erklären kann. Die andere Hälfte wird als "Zufall" oder "Rauschen" wahrgenommen.
Die hohe relative Abweichung (RMSE relative = 53 %): Bei einem maximalen Hausverbrauch von knapp 7 kW ist ein RMSE von ~489 Wh absolut gesehen zwar okay, aber relativ zu den typischen Sommer-Grundlasten hoch. Das Modell "verschätzt" sich im Schnitt um knapp 400 Wh (MAE).

Der "Retrain"-Trigger durch das BitFail-Limit:

Das Modell wurde als "Retrain" markiert, weil 10 Ausreißer-Datenpunkte (Bit_Fail) das extrem streng eingestellte Limit von 0.34 gerissen haben.


2. Hinweise auf strukturelle Probleme

Kein Overfitting – im Gegenteil (Underfitting):
Dass der Validation MSE (0.0067) niedriger ist als der Training MSE (0.0085), ist ein seltenes Phänomen. Es zeigt, dass das Modell extrem vorsichtig (fast schon zu konservativ) lernt. Es neigt absolut nicht zu Overfitting.

Zu frühe Konvergenz (Epoche 1373 von 15000):
Das Netz hat nach nur knapp 9 % der maximal erlaubten Epochen aufgehört, besser zu werden. Bei der gewählten, sehr niedrigen Learning Rate von 0.0001 deutet das darauf hin, dass das Modell in einem lokalen Minimum feststeckt oder der INCREMENTAL-Algorithmus bei der aktuellen Feature-Menge die Kurve nicht steiler kriegt.

Perfekte Datenbasis:
Mit über 10.000 Datensätzen und einer exzellenten Data Parameter Ratio von 7.23 ist die Datenmenge absolut ausreichend und stabil.


3. Die 2–3 Maßnahmen mit dem größten Hebel

Maßnahme 1:
Das BitFail-Limit an das Sommer-Rauschen anpassen
Dein Rauschen ist als "borderline" klassifiziert. Im Sommer hast du kurze, heftige Peaks (E-Grill schaltet taktend ein, Klimaanlage regelt, WP springt kurz an). Diese Peaks sprengen das extrem enge Korsett von 0.34.

Hebel:
Wenn das Limit leicht angehoben wird, toleriert das Netz diese unvorhersehbaren "Verbrauchs-Blitze", ohne das gesamte Modell als fehlerhaft zu betrachten.

Maßnahme 2:
Die Steilheit der Aktivierungsfunktion anpassen
Aktuell steht die Steepness auf 0.7 bei einer LINEAR-Ausgabe. Dein Hausverbrauch im Sommer ist aber nicht linear – er ist binär (An/Aus bei Großgeräten) oder sprunghaft.

Hebel:
Eine Erhöhung der Steepness erlaubt es dem Netz, steilere, härtere Übergänge (z. B. "jetzt wird gekocht/gegrillt") schärfer abzubilden, was das R2 sofort nach oben treiben dürfte.


4. Konkrete, umsetzbare nächste Schritte
Da du das Profil v1_heatpump_active_pv nutzt (das perfekt zu dir passt), solltest du an folgenden drei Stellschrauben im FHEM-Device drehen:

BitFail-Limit anheben:
Setze das Attribut aiConBitFailLimit testweise von 0.34 auf 0.42. Das nimmt den künstlichen "Retrain"-Druck aus dem System, der nur durch kurzfristiges Sommer-Rauschen erzeugt wird.

Lern-Steilheit erhöhen:
Erhöhe die aiConActivationSteepness von 0.7 auf 0.9 oder 1.0. Dadurch kann das neuronale Netz die harten Ein- und Ausschaltflanken deiner Verbraucher besser nachvollziehen.
Epochen-Ausnutzung erzwingen (optional):

Sollte das Modell nach den obigen Änderungen immer noch zu früh abbrechen, erhöhe die Learning Rate minimal von 0.0001 auf 0.0002, um dem INCREMENTAL-Algorithmus etwas mehr Dynamik bei der Gewichtungsanpassung zu geben.



Dieses neue "LLM-Get"-Feature von DS_Starter ist auf jeden Fall ein Traum.
Damit können wir bei der nächsten Rekalibrierung in ein paar Tagen perfekt sehen, wie sich deine Modellanpassungen ausgewirkt haben!


[300P]

Eine andere hat sogar Wünsche:
(Solltest du aber einordnen ob oder ob nicht - damit wir nicht sowas wie ein Perpetuum mobile der besonderen Art bauen

Code Auswählen Erweitern


Zum neuen LLM-Prompt

Den finde ich ausgesprochen gelungen. Er enthält genau die Informationen, die ein Sprachmodell für eine fundierte Analyse benötigt:
-Kontext des Haushaltsprofils
-Architektur und Hyperparameter
-Trainingsmetriken
-Fehlermaße
-Drift- und Rauschbewertung
-konkrete Fragestellungen statt einer offenen Aufforderung

Ich würde nur noch zwei Dinge ergänzen, weil sie die Qualität der Analyse weiter verbessern könnten:

Zeit seit Einführung neuer Features, z. B.:
"WP-Mode-Points werden erst seit 12 Tagen erfasst."

Dann würde ein LLM die noch geringe Historie korrekt einordnen.

-Referenz auf das vorherige Training, z. B.:
-R² vorher → aktuell
-MAE vorher → aktuell
-Slope vorher → aktuell

Ein Sprachmodell erkennt Trends oft besser als Einzelwerte. Mit diesen Vergleichsdaten könnte es nicht nur den aktuellen Zustand bewerten, sondern auch beurteilen, ob sich das Modell tatsächlich verbessert oder verschlechtert. Das würde den Analysewert dieses Features aus meiner Sicht nochmals deutlich erhöhen.

[300P]

PS:
Und alles ohne jegliche Kosten.....