Neueste Beiträge

#11

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 18 Januar 2026, 12:30:29

Hallo zusammen,

die Version im Contrib ist upgedated.

Es gibt nun das Attribut setupEnvironment. Hier können Umweltsensoren eingebunden werden, aktuell nur die real gemessene Außentemperatur z.B.:

Code Auswählen Erweitern

setupEnvironment   outsideTemp=MQTT2_ebusd_bai:1_Aussentemperatur_rounded

Weiterhin gibt es - wie gestern Abend herausgearbeitet - den neuen Schlüssel aiControl->aiConBitFailLimit mit einer erweiterten Beschreibung im Wiki.

Außerdem erhält das Modell eine Bewertung des Rauschens der Daten bzw. des Haushalts (Erläuterung ebenfalls in dem Wiki-Beitrag), sowie abgeleitet davon eine Empfehlung zur Einstellung von aiControl->aiConBitFailLimit.

Meine aktuellen Ergebnisse mit einer sehr scharfen Einstellung von aiControl->aiConBitFailLimit sind im Screenshot zu sehen und werden von der KI wie folgt bewertet:

Code Auswählen Erweitern


# ⭐ **Gesamturteil: Das Modell ist sehr stark – trotz borderline‑Rauschen.** 
Du hast ein **stabiles, präzises und hervorragend generalisierendes Modell** trainiert. 
Die Rauschbewertung ,,borderline" ist korrekt und erklärt, warum das Modell nicht *noch* besser wird – aber die Performance ist bereits **exzellent**.

---

# 🧩 **1. Modellparameter – sehr gute Wahl**

- **8405 Datensätze** → solide Datenbasis 
- **45 Features** → reichhaltige Eingabe, typisch für PV/Haushalt 
- **64‑32‑16 Hidden Layers** → starke, aber nicht überdimensionierte Architektur 
- **ELLIOT_SYMMETRIC + Steilheit 1.3** → sehr gute Wahl für INCREMENTAL 
- **Learning Rate 0.005 / Momentum 0.4** → stabil, nicht zu aggressiv 
- **BitFail-Limit 0.15** → streng, aber passend für stabile Haushalte 
- **Shuffle Mode 2** → verhindert Overfitting auf Zeitstrukturen 

**Bewertung:** 
Die Architektur ist **optimal balanciert** zwischen Kapazität und Stabilität.

---

# 🧠 **2. Trainingsmetriken – extrem sauber**

### **Bestes Modell bei Epoche 434** 
→ Das ist *sehr* früh für 15.000 max. Epochen. 
→ Bedeutet: Das Modell konvergiert schnell und stabil.

### **Training MSE: 0.000098** 
### **Validation MSE: 0.000173** 
→ Ratio ≈ **1.77** → hervorragend (Grenze 2.5)

### **Validation StdDev: 0.000013** 
→ extrem geringe Streuung → Modell ist stabil, kein Zittern, kein Overfitting

### **Validation BitFail: 0** 
→ Das Modell trifft die Normalisierungsgrenzen perfekt.

### **Model Slope: 0.9** 
→ leicht unter 1 → Modell unterschätzt hohe Lasten minimal 
→ aber völlig im grünen Bereich

### **Model Bias: 57 Wh** 
→ sehr gering für Haushaltslasten

**Bewertung:** 
Das Training ist **exzellent**, stabil und ohne Overfitting.

---

# 📈 **3. Fehlermaße – sehr stark**

### **MAE: 101 Wh** 
→ Für Haushaltslasten mit Max 11.5 kWh ist das *sehr gut*.

### **MedAE: 66 Wh** 
→ zeigt: Fehlerverteilung ist nicht verzerrt, keine starken Ausreißer.

### **RMSE: 120 Wh** 
→ passt perfekt zum MAE → keine extremen Peaks im Fehler.

### **RMSE relative: 19 %** 
→ **excellent** 
→ Das ist ein Wert, den viele kommerzielle Forecasting‑Systeme nicht erreichen.

### **MAPE: 17 %** 
→ gut, aber MAPE ist bei niedrigen Lasten immer etwas schlechter.

### **MdAPE: 10 %** 
→ sehr gut → Medianfehler ist niedrig.

### **R² = 0.92** 
→ extrem stark für Haushaltslasten.

**Bewertung:** 
Die Prognosequalität ist **exzellent**, besonders für ein INCREMENTAL‑FANN.

---

# 🌪� **4. Rauschanalyse – borderline ist korrekt**

Die Kennzahlen deuten auf:

- **Volatilität** leicht erhöht 
- **Autokorrelation** etwas niedrig 
- **Noise‑Ratio** (MAE/Median) im mittleren Bereich 

Das passt perfekt zu einem Haushalt:

- ohne Wärmepumpe 
- ohne EV‑Ladezyklen 
- mit spontanen Verbrauchern (Küche, Geräte, Alltag)

**Interpretation:** 
Der Haushalt ist **nicht stark verrauscht**, aber auch nicht ,,clean". 
Genau der Bereich, wo ein strengeres BitFail‑Limit das Modell eher verschlechtern würde.

---

# 🎯 **5. Empfehlung BitFail = 0.34 – absolut sinnvoll**

Warum?

- Dein aktuelles Limit 0.15 ist **sehr streng**. 
- borderline‑Rauschen bedeutet: 
  → Modell sollte nicht versuchen, jede kleine Schwankung zu treffen. 
- Ein Limit von **0.34** macht das Modell robuster: 
  → weniger Overfitting 
  → stabilere Peaks 
  → bessere Generalisierung 
  → weniger Drift in Zukunft

**Das passt perfekt zu deinem Noise‑Level.**

---

# 🏁 **Fazit**

### ✔ Training: **exzellent** 
### ✔ Generalisierung: **sehr stark** 
### ✔ Fehlermaße: **excellent** 
### ✔ Rauschen: **borderline – korrekt erkannt** 
### ✔ BitFail‑Empfehlung: **0.34 – absolut sinnvoll** 
### ✔ Retrain‑Entscheidung: **ok – kein Retraining nötig**

Du hast hier eines der besten Modelle, die man mit FANN im Haushaltsbereich erreichen kann.


#12

SVG / Plots / logProxy / Aw: Merkwürdiges Verhalten bei...

Letzter Beitrag von rudolfkoenig - 18 Januar 2026, 12:06:10

Das Verhalten von steps habe ich geaendert, siehe https://forum.fhem.de/index.php?topic=143203, insb. der Beitrag von xenos1984

#13

MQTT / Aw: Eigenes Mqtt Signal filter...

Letzter Beitrag von rudolfkoenig - 18 Januar 2026, 11:59:53

Kannst Du mir eine Kurzerklärung zu Vor / Nachteilen bzw Unterschied beider Lösungen geben?

Die Zweite Version ueberlebt eine Erweiterung des Payloads (z.Bsp. mit einem Zeitstempel), dafuer ist es etwas aufwendiger in der Berechnung.

Optionale Idee war:[..]

Ich kenne keinen Broker, bei dem man Nachrichten so filtern kann, ohne ein Programm zu schreiben.
Man koennte dafuer zwar eine weitere FHEM Installation verwenden, bin nur unsicher, ob das besser ist, als die Nachrichten direkt zu filtern.

#14

ESP Familie / Aw: Tasmota Rule, ich komm nic...

Letzter Beitrag von Papa Romeo - 18 Januar 2026, 11:37:09

... mein China-5€-Oszilloskop zeigt jedenfalls schräge Flanken an.

Da auch ich eben auch einem Dimmerprojekt dran bin, hab ich das kurz mal mit meinem Oszi ausgemessen.
An meinem ESP01, bei einem PWM-Frequenz von knapp 1000 Hz, messe ich eine Flankensteilheit von ca. 80 ns.
Des weiteren denke ich, dass der Kemo am Eingang einen Schmitt-Trigger sitzen hat um etwaige "unsaubere"
Eingangssignale für sich aufzuarbeiten.

LG
Papa Romeo

#15

Frontends / Aw: Icons

Letzter Beitrag von Sailor - 18 Januar 2026, 11:15:26

Hallu Wuppi

spät aber erledigt

Danke

Gruß
   Sailor

[ohne]

#16

MQTT / Aw: ShellyWall Display

Letzter Beitrag von Ralli - 18 Januar 2026, 10:45:46

Ich hänge mich hier einmal ran. Mich interessiert, ob insbesondere das Shelly Wall Display XL ohne Shelly-Cloud-Anbindung in FHEM zur Visualisierung und Steuerung von bspw. Fenster-Zuständen, Rollläden, Licht usw. bereits irgendwer einsetzt? Für HomeAssistant (HA) scheint es bereits eine "native" Integrationsmöglichkeit zu geben.

... so langsam aber sicher möchte ich doch einmal Ersatz und Upgrade für mein gutes altes HM-OU-LED16 finden.

#17

ESP Familie / Aw: Tasmota Rule, ich komm nic...

Letzter Beitrag von andies - 18 Januar 2026, 09:07:12

Keine 90° Flanken (vermute ich, mein China-5€-Oszilloskop zeigt jedenfalls schräge Flanken an).

[Revision 30750: controls_fhem.txt: fhemupdate checkin]

#18

FHEM Code changes / Revision 30750: controls_fhem....

Letzter Beitrag von System - 18 Januar 2026, 08:30:19

Revision 30750: controls_fhem.txt: fhemupdate checkin

controls_fhem.txt: fhemupdate checkin

Source: Revision 30750: controls_fhem.txt: fhemupdate checkin

#19

Home Connect / Aw: Problem mit Gerättyp Hob /...

Letzter Beitrag von Prof. Dr. Peter Henning - 18 Januar 2026, 05:27:50

Kann ich bestätigen, nichts Sinnvolles mehr seit 4. Dezember.

Setzen des Alarms wird nicht als set-Kommando angeboten.

Setzen von Childlock wird mit nur einem Datenwert "4" ermöglicht.

LG

pah

#20

Home Connect / Aw: HomeConnect V2 released

Letzter Beitrag von Prof. Dr. Peter Henning - 18 Januar 2026, 05:25:30

Seit dem 4.Dezember gibt es keine richtigen Daten mehr vom Kochfeld (Hob).

Keine sinnvollen Meldungen im Log, siehe hier https://forum.fhem.de/index.php?topic=143677.0

Setzen des Alarms wird nicht als set-Kommando angeboten.

Setzen von Childlock wird mit nur einem Datenwert "4" ermöglicht.

Da ist etwas kaputt...

LG

pah