- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#31
FHEM Code changes / Revision 31545: controls_fhem....
Letzter Beitrag von System - 07 August 2026, 08:00:28Revision 31545: controls_fhem.txt: fhemupdate checkin
controls_fhem.txt: fhemupdate checkin
Source: Revision 31545: controls_fhem.txt: fhemupdate checkin
controls_fhem.txt: fhemupdate checkin
Source: Revision 31545: controls_fhem.txt: fhemupdate checkin
#32
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von TheTrumpeter - 07 August 2026, 08:00:06So, nach vielen Iterationsstufen, die teilweise auch in die Irre geführt haben (z.B. Durchprobieren der unterschiedlichen aiConActFunc wie von SF vorgeschlagen oder diverse andere HiddenLayer-Konfigurationen wie von Gemini vorgeschlagen) bin ich nun hier angelangt, siehe Screenshot.
Gemini bewertet das wie folgt:
### 📊 FANN-Analyse & Optimierungs-Bericht (Modul 76_SolarForecast.pm)
**Status des letzten Trainingslaufs (07.08.2026):** `Trainingsbewertung: Retrain`
* **Laufzeit:** 3.341 Sekunden (ca. 56 Min.) | **Algorithmus:** INCREMENTAL
* **Modell-Güte:** R² = 0.54 (Grundsubstanz für Wärmepumpen-Profil steht)
* **Kernproblem:** Die finale Modulfreigabe blockiert wegen `Data-Parameter-Ratio: CAUTION` und minimalem Overfitting.
---
#### 1. 🔍 Wo liegen aktuell die größten Schwachstellen?
* **Der ungelöste Parameterüberhang (`Ratio = 6.080 < 7`):**
Das Netz ist aufgrund der starren **123 Inputs** künstlich aufgebläht. Es besitzt zu viele synaptische Gewichte für die vorhandenen ~13.000 Datensätze. Das System lernt in den tiefen Epochen (Optimum bei Epoche 3.952) feines Datenrauschen statt allgemeingültiger Logik.
* **Minimales, blockierendes Overfitting (`MSE diff = 0.005892 > 0.005`):**
Der Validierungsfehler weicht um Haaresbreite zu stark vom Trainingsfehler ab. Es fehlen lediglich `0.000892` Punkte zur kritischen Freigabeschwelle des Moduls.
* **Gedeckelte Modell-Steigung (`ModelSlope = 0.54`):**
Die Steigung verfehlt das harte Wärmepumpen-Mindestlimit (`slope_min=0.60`). Dem FANN fehlt die mathematische Trennschärfe, um die Peak-Leistungen der Wärmepumpe sauber nachzubilden, weil diese im Wust der 123 Features schlicht untergehen.
---
#### 2. 🛠� Die wirksamsten Maßnahmen mit dem größten Hebel
* **Maßnahme 1: Radikale Feature-Reduktion (Inputs reduzieren) ⬇️**
* *Hebel:* Das ist die einzig verbleibende Stellschraube auf Datenebene. Jedes weggelassene, redundante Eingangsfeature streicht dutzende Gewichte aus dem Netz. Die Ratio springt über 7 und das Overfitting bricht zusammen.
* **Maßnahme 2: Proportionale Verkleinerung der Netzwerkbreite (Hidden Layers reduzieren) ⬇️**
* *Hebel:* Wechsel von 16-8 auf **12-6**. Ein schlankeres Netz erzwingt mathematisch eine stärkere Generalisierung und treibt die `ModelSlope` in Richtung 0.60.
---
#### 3. ⚠️ Hinweise auf strukturelle Probleme
* **Keine Algorithmus- oder Hyperparameter-Fehler (Gelöst):**
Die `Learning Rate` (0.0001) und der `INCREMENTAL`-Modus arbeiten perfekt. Das beweist die verschwindend geringe Standardabweichung der Validierung (`0.000004`).
* **Strukturelle Informations-Sättigung:**
Das FANN ist auf Hyperparameter-Ebene komplett ausoptimiert. Mehr Qualität lässt sich nicht mehr durch Drehen an den Rädchen erzwingen, sondern nur noch durch das Ausmisten irrelevanter Prädiktoren (Rauschfilterung).
---
#### 4. 🚀 Konkrete, umsetzbare nächste Schritte
Da das Modell mathematisch am Limit dessen läuft, was mit 123 Inputs möglich ist, muss jetzt die FHEM-Konfiguration der Datenquellen bereinigt werden:
1. **Historische Datenpunkte einschränken (Prio 1!):**
Prüfe die Attribute deines FHEM-Moduls. Falls Werte wie `aiConHistoryHours` auf 24 oder höher stehen, konsequent auf **6 oder 12 Stunden** reduzieren. Verbrauchswerte von vor über einem Tag enthalten für die Wärmepumpen-Logik fast nur noch Rauschen.
2. **Redundante Wetterprognose-Inputs abschalten:**
Überprüfe, ob mehrere Wetter- oder Strahlungsprognosen (DWD, Proplanta etc.) gleichzeitig aktiv in das Netz gespeist werden. Unnötige Kanäle deaktivieren. **Ziel: Die Anzeige `Inputs` muss beim nächsten Start zweistellig werden (unter 90).**
3. **Architektur verschmalern:**
Die Hidden Layers im gleichen Zuge von `16-8` auf **`12-6`** (oder alternativ auf eine einzelne Schicht mit **`14`** Neuronen) anpassen.
4. **Hyperparameter einfrieren & Retrain starten:**
`Learning Rate = 0.0001`, `Momentum = 0.5`, `BitFail-Limit = 0.34` und `INCREMENTAL` exakt so belassen. Nach der Feature-Ausdünnung das Training neu triggern.
Gemini schlägt immer wieder vor die "Inputs" zu reduzieren und irgendwelche etwaige Redundanzen bei der Datenerfassung zu entfernen. Diesbezüglich kann ich aber nix machen, bzw. wäre es auch nicht sinnvoll, oder???
Ich werde nun einen weiteren Versuch mit leicht reduzierten HiddenLayers starten, mal sehen was dann passiert. Schön langsam bin ich aber am Ende mit meinen Ideen (und auch die von Gemini haben bisher immer nur in die falsche Richtung gewirkt).
Gemini bewertet das wie folgt:
### 📊 FANN-Analyse & Optimierungs-Bericht (Modul 76_SolarForecast.pm)
**Status des letzten Trainingslaufs (07.08.2026):** `Trainingsbewertung: Retrain`
* **Laufzeit:** 3.341 Sekunden (ca. 56 Min.) | **Algorithmus:** INCREMENTAL
* **Modell-Güte:** R² = 0.54 (Grundsubstanz für Wärmepumpen-Profil steht)
* **Kernproblem:** Die finale Modulfreigabe blockiert wegen `Data-Parameter-Ratio: CAUTION` und minimalem Overfitting.
---
#### 1. 🔍 Wo liegen aktuell die größten Schwachstellen?
* **Der ungelöste Parameterüberhang (`Ratio = 6.080 < 7`):**
Das Netz ist aufgrund der starren **123 Inputs** künstlich aufgebläht. Es besitzt zu viele synaptische Gewichte für die vorhandenen ~13.000 Datensätze. Das System lernt in den tiefen Epochen (Optimum bei Epoche 3.952) feines Datenrauschen statt allgemeingültiger Logik.
* **Minimales, blockierendes Overfitting (`MSE diff = 0.005892 > 0.005`):**
Der Validierungsfehler weicht um Haaresbreite zu stark vom Trainingsfehler ab. Es fehlen lediglich `0.000892` Punkte zur kritischen Freigabeschwelle des Moduls.
* **Gedeckelte Modell-Steigung (`ModelSlope = 0.54`):**
Die Steigung verfehlt das harte Wärmepumpen-Mindestlimit (`slope_min=0.60`). Dem FANN fehlt die mathematische Trennschärfe, um die Peak-Leistungen der Wärmepumpe sauber nachzubilden, weil diese im Wust der 123 Features schlicht untergehen.
---
#### 2. 🛠� Die wirksamsten Maßnahmen mit dem größten Hebel
* **Maßnahme 1: Radikale Feature-Reduktion (Inputs reduzieren) ⬇️**
* *Hebel:* Das ist die einzig verbleibende Stellschraube auf Datenebene. Jedes weggelassene, redundante Eingangsfeature streicht dutzende Gewichte aus dem Netz. Die Ratio springt über 7 und das Overfitting bricht zusammen.
* **Maßnahme 2: Proportionale Verkleinerung der Netzwerkbreite (Hidden Layers reduzieren) ⬇️**
* *Hebel:* Wechsel von 16-8 auf **12-6**. Ein schlankeres Netz erzwingt mathematisch eine stärkere Generalisierung und treibt die `ModelSlope` in Richtung 0.60.
---
#### 3. ⚠️ Hinweise auf strukturelle Probleme
* **Keine Algorithmus- oder Hyperparameter-Fehler (Gelöst):**
Die `Learning Rate` (0.0001) und der `INCREMENTAL`-Modus arbeiten perfekt. Das beweist die verschwindend geringe Standardabweichung der Validierung (`0.000004`).
* **Strukturelle Informations-Sättigung:**
Das FANN ist auf Hyperparameter-Ebene komplett ausoptimiert. Mehr Qualität lässt sich nicht mehr durch Drehen an den Rädchen erzwingen, sondern nur noch durch das Ausmisten irrelevanter Prädiktoren (Rauschfilterung).
---
#### 4. 🚀 Konkrete, umsetzbare nächste Schritte
Da das Modell mathematisch am Limit dessen läuft, was mit 123 Inputs möglich ist, muss jetzt die FHEM-Konfiguration der Datenquellen bereinigt werden:
1. **Historische Datenpunkte einschränken (Prio 1!):**
Prüfe die Attribute deines FHEM-Moduls. Falls Werte wie `aiConHistoryHours` auf 24 oder höher stehen, konsequent auf **6 oder 12 Stunden** reduzieren. Verbrauchswerte von vor über einem Tag enthalten für die Wärmepumpen-Logik fast nur noch Rauschen.
2. **Redundante Wetterprognose-Inputs abschalten:**
Überprüfe, ob mehrere Wetter- oder Strahlungsprognosen (DWD, Proplanta etc.) gleichzeitig aktiv in das Netz gespeist werden. Unnötige Kanäle deaktivieren. **Ziel: Die Anzeige `Inputs` muss beim nächsten Start zweistellig werden (unter 90).**
3. **Architektur verschmalern:**
Die Hidden Layers im gleichen Zuge von `16-8` auf **`12-6`** (oder alternativ auf eine einzelne Schicht mit **`14`** Neuronen) anpassen.
4. **Hyperparameter einfrieren & Retrain starten:**
`Learning Rate = 0.0001`, `Momentum = 0.5`, `BitFail-Limit = 0.34` und `INCREMENTAL` exakt so belassen. Nach der Feature-Ausdünnung das Training neu triggern.
Gemini schlägt immer wieder vor die "Inputs" zu reduzieren und irgendwelche etwaige Redundanzen bei der Datenerfassung zu entfernen. Diesbezüglich kann ich aber nix machen, bzw. wäre es auch nicht sinnvoll, oder???
Ich werde nun einen weiteren Versuch mit leicht reduzierten HiddenLayers starten, mal sehen was dann passiert. Schön langsam bin ich aber am Ende mit meinen Ideen (und auch die von Gemini haben bisher immer nur in die falsche Richtung gewirkt).
#33
Automatisierung / Aw: Datenaustausch mit externe...
Letzter Beitrag von olwaldi - 07 August 2026, 07:21:17Naja, diese Alternativen kommen mir komplexer vor. Für weewx gibt es ansatzweise MQTT-Support, und in meinem fhem müßte ich MQTT erst aktivieren. Ähnlich bzgl. json, gibts nur ansatzweise.
Daher empfinde ich ja meine include-Lösung ja als wesentlich unter-komplexer. Auf weewx-Seite hingegen ist es sehr einfach, ein beliebiges Outputformat erzeugen zu lassen, könnte auch problemlos ein json sein. Aber das müßte man auf fhem-Seite wieder dekodieren. Und genau das spare ich mit dem include. Aber json gucke ich mir mal an, da mir json als Standard auch recht gut gefällt.
Nachtrg: Habe mir JsonMod kurz angeschaut - würde mein Problem lösen. Und ich habe auch meine Idee auf die Schnelle programmiert. Beides hat Vor- und Nachteile. Durch die Nutzung von include spare ich mir das zusätzliche json-Parsen und eine etwas aufwendigere Konfiguration in fhem. Andererseits muß ich den globalen verbose-Level VOR jedem include auf 0 setzen und hinterher wieder auf 3 (mein default). Das erledigt mein at automatisch, ist aber nicht wirklich elegant.
Letzendlich wollte ich ja nur wissen, ob man leicht Daten mit weewx austauschen kann, was ich klar bejahen kann. Aber aktuell habe ich keinen konkreten Bedarf.
Grüßle, Michael
Daher empfinde ich ja meine include-Lösung ja als wesentlich unter-komplexer. Auf weewx-Seite hingegen ist es sehr einfach, ein beliebiges Outputformat erzeugen zu lassen, könnte auch problemlos ein json sein. Aber das müßte man auf fhem-Seite wieder dekodieren. Und genau das spare ich mit dem include. Aber json gucke ich mir mal an, da mir json als Standard auch recht gut gefällt.
Nachtrg: Habe mir JsonMod kurz angeschaut - würde mein Problem lösen. Und ich habe auch meine Idee auf die Schnelle programmiert. Beides hat Vor- und Nachteile. Durch die Nutzung von include spare ich mir das zusätzliche json-Parsen und eine etwas aufwendigere Konfiguration in fhem. Andererseits muß ich den globalen verbose-Level VOR jedem include auf 0 setzen und hinterher wieder auf 3 (mein default). Das erledigt mein at automatisch, ist aber nicht wirklich elegant.
Letzendlich wollte ich ja nur wissen, ob man leicht Daten mit weewx austauschen kann, was ich klar bejahen kann. Aber aktuell habe ich keinen konkreten Bedarf.
Grüßle, Michael
#34
FHEM Code changes / Revision 31544: :test
Letzter Beitrag von System - 06 August 2026, 23:20:55 #35
FHEM Code changes / Revision 31543: :test
Letzter Beitrag von System - 06 August 2026, 23:20:55 #36
Homematic / Aw: RPC Server startet nicht m...
Letzter Beitrag von passibe - 06 August 2026, 22:10:41Alles klar, danke.
Was steht danach im Log? Ansonsten wie gesagt:
Was steht danach im Log? Ansonsten wie gesagt:
Zitat von: passibe am 31 Juli 2026, 15:01:12Kannst du mal auf verbose 5 stellen und das Log nach einem FHEM-Neustart posten?
#37
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von peterboeckmann - 06 August 2026, 21:30:42Hallo Heiko,
Zu deinen Bedenken bzgl. der NextHours-Prognose habe ich mal in meinen Erinnerungen gekramt. Ich denke, dass sich innerhalb des Ladevorgang der Modus nur äußerst selten ändert. Und wenn, dann ist ja gut erklärt, warum die Prognose nicht (mehr) passen kann.
Was sich ggf. tatsächlich mal ändern wird, ist die Ladestrom-Vorgabe. Diese wirkt aber natürlich nur im Modus "Manuell".
Außerdem ist mir noch eine Lücke aufgefallen, die ich möglicherweise anderen Steuerungen gegenüber habe: ich habe aktuell nicht die Möglichkeit zu steuern, ob einphasig oder dreiphasig geladen werden soll.
Das hätte aber natürlich großen Einfluss auf die CON-Prognose.
Vielleicht schaffe ich mir aber auch nochmal diese Möglichkeit. Zumindest träume ich davon...
Viele Grüße,
Peter
Zitat von: DS_Starter am 06 August 2026, 11:51:00Hallo Peter,
Grundsätzlich eine gute Idee – die Frage ist aber, wie ich das sauber ins bestehende Feature-Konzept einbauen könnte.
1. Analogie ist schon im Modul vorhanden
Das ist strukturell dasselbe Problem wie beim Wärmepumpen-Opmode-Tracking (Punkte-System mit gewichteter Sekundenakkumulation). Auch dort wird ein Betriebsmodus als Kategorie-Signal in eine Aggregation gegeben. Ich würde "Modus" der Wallbox genauso behandeln: nicht als rohen String, sondern als Punkte/Anteil pro Stunde (z.B. wie viele Sekunden der Stunde in Aus/Auto/Prio/Manuell verbracht wurden), analog zum HP-Muster. Das lässt sich vermutlich mit wenig Aufwand aus dem bestehenden Ansatz ableiten/kopieren.
2. Das eigentliche Problem: Training vs. Inferenz
Für die Trainingsdaten (Historie) ist das unproblematisch – dort hole ich den historischen Modus/Ladestrom-Wert zur jeweiligen Stunde.
Für die NextHours-Prognose ist das der Knackpunkt: Anders als PV- oder Wetterprognosen gibt es für "Modus in Stunde t+x" keine Vorhersagequelle – man kennt nur den aktuellen Live-Wert. Wenn ich den Wert einfach für alle Prognosestunden konstant fortschreibe, ist das für Nutzer, die selten manuell umschalten, eine brauchbare Näherung, für Nutzer mit häufigem Moduswechsel aber potenziell fehlerhaft – das NN lernt dann eine Abhängigkeit, die zur Prognosezeit oft nicht mehr stimmt.
Was natürlich dafür spricht - wenn der Modus auf Prio steht und sich damit eine Beziehung zum vergangenen/prognostizierten Überschuß ableiten lässt, wäre es ein echtes Signal für das NN.
Vllt. wird deutlich worauf ich hinaus will, der PV-Überschuß in Verknüpfung mit demm Modus "Prio" gibt ein echtes Feature, bei den anderen Status, z.B. "Manuell" -> "kann passieren oder auch nicht" gibt es keine solche Vorhersehbarkeit.
Aber danke für die Idee, ich lasse das bei mir nochmal sacken.
LG,
Heiko
Zu deinen Bedenken bzgl. der NextHours-Prognose habe ich mal in meinen Erinnerungen gekramt. Ich denke, dass sich innerhalb des Ladevorgang der Modus nur äußerst selten ändert. Und wenn, dann ist ja gut erklärt, warum die Prognose nicht (mehr) passen kann.
Was sich ggf. tatsächlich mal ändern wird, ist die Ladestrom-Vorgabe. Diese wirkt aber natürlich nur im Modus "Manuell".
Außerdem ist mir noch eine Lücke aufgefallen, die ich möglicherweise anderen Steuerungen gegenüber habe: ich habe aktuell nicht die Möglichkeit zu steuern, ob einphasig oder dreiphasig geladen werden soll.
Das hätte aber natürlich großen Einfluss auf die CON-Prognose.
Vielleicht schaffe ich mir aber auch nochmal diese Möglichkeit. Zumindest träume ich davon...
Viele Grüße,
Peter
#38
ESP Familie / Aw: BoseFix32 — lokaler SoundT...
Letzter Beitrag von betateilchen - 06 August 2026, 21:19:52Zitat von: tostmann am 06 August 2026, 17:37:59@betateilchen: Auto-Migrate at Boot bleibt wie gewünscht oben stehen. Das Zeitfenster, in dem man ihn ausschalten will, ist zu kurz, um vorher noch etwas aufklappen zu müssen.
Für den Wunschzettel, wenn mal alles andere erledigt ist:
Beim Aufruf von http://sixback.local/stop die Oberfläche direkt mit ausgeschalteter Migration erreichen...
#39
ESP Familie / Aw: BoseFix32 — lokaler SoundT...
Letzter Beitrag von fred_feuerstein - 06 August 2026, 20:47:49Das ist prima mit dem Verschieben der 4 Einträge in den System Tab.
Den Auto Migrate Eintrag oben, da habt ihr ja recht, den muss man auch mal schnell erreichen können.
Den Auto Migrate Eintrag oben, da habt ihr ja recht, den muss man auch mal schnell erreichen können.
#40