Neueste Beiträge

#1

Zigbee / Aw: Leuchten Hue erscheinen ni...

Letzter Beitrag von juergen012 - 11 März 2026, 18:49:42

Code Auswählen Erweitern

https://wiki.fhem.de/wiki/Hue

#2

fronthem / smartVISU / Aw: Fehler in device.uzsugraph

Letzter Beitrag von wvhn - 11 März 2026, 18:46:44

Moin,
ich bin gerade am Überarbeiten des Widgets und habe festgestellt, dass im uzsugraph eine Schaltzeit an allen Wochentagen als aktiv angezeigt wird, wenn man im UZSU-Popup keinen Wochentag ausgewählt hat, also rrule.BYDAY leer ist.

Kann mal jemand hier testen, wie fhem mit fehlenden Wochentagen umgeht? Wenn man einen Schaltvorgang im UZSU-Widget anlegt und keinen Wochentag aktiviert, wird der Schaltvorgang dann täglich, oder niemals ausgeführt?

Meine Erwartung wäre letzteres, aber z.B. smarthomeNG macht das anders, weil ein UZSU-Eintrag ohne Wochentag sinnlos wäre.

Danke und Gruß
Wolfram

#3

Wallboxen und E-Fahrzeuge / Aw: go-e Charger WallBox über...

Letzter Beitrag von fred_feuerstein - 11 März 2026, 18:44:32

Das ist ja klar. Möchte da auch nichts schön rechnen, sondern real. Ich rechne immer den Hausverbrauch komplett zuerst raus. Dazu habe ich eine separate Variable "Hausverbrauch ohne EAuto". Nur der Überschuss der Produktion über diesem Wert wird bei Ladung als PV Strom fürs Auto berechnet.
Die Werte werden mir direkt live angezeigt.
Auch während dem Laden schon und dann genauso über Statistics Modul ausgewertet.

Wenn also Hausverbrauch gerade 1000 Watt, PV 6000 Watt und Auto mit 7000 Watt geladen wird, dann sind nur 5000 Watt der Autoladung aus PV Strom und 2000 Watt aus dem Netz.

Auf der ftui sieht das dann so aus (leider gerade keine Ladung heute und gestern)
die 3W momentan sind der Standby Verbrauch vom Go-e charger.(diese werden aber gerade durch die PV Batterie abgedeckt)

#4

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von 300P - 11 März 2026, 18:12:11

Anderes Thema -
Versprochener Ergebnisbericht nach download / shutdown / restart / retrain mit der neuen V2.3.1 von gestern Abend

Code Auswählen Erweitern

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 11.03.2026 08:59:06 / Laufzeit in Sekunden: 2952
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 76.73 ms
Verbrauchernummer Wärmepumpe: 08

=== Modellparameter ===

Normierungsgrenzen: PV=16071 Wh, Hausverbrauch: Min=0 Wh / Max=7598 Wh
Trainingsdaten: 7944 Datensätze (Training=6355, Validation=1589)
Architektur: Inputs=98, Hidden Layers=80-40, Outputs=1
Hyperparameter: Learning Rate=0.001, Momentum=0.6, BitFail-Limit=0.18
Aktivierungen: Hidden=GAUSSIAN_SYMMETRIC, Steepness=1.0, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_heatpump_active_pv
Zufallsgenerator: Mode=1, Period=20

=== Trainingsmetriken ===

bestes Modell bei Epoche: 208 (max. 15000)
Training MSE: 0.003919
Validation MSE: 0.003589
Validation MSE Average: 0.007856
Validation MSE Standard Deviation: 0.000391
Validation Bit_Fail: 7
Model Bias: 51 Wh
Model Slope: 0.9
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 355.96 Wh
MedAE: 293.28 Wh
RMSE: 407.60 Wh
RMSE relative: 19 %
RMSE Rating: excellent
MAPE: 18.27 %
MdAPE: 14.10 %
R²: 0.72

=== Rauschen ===

Rauschen Bewertung: low
 ChatGPT meint dazu:

Code Auswählen Erweitern

## Analyse des neuesten Trainings (11.03.2026, SolarForecast 2.3.1)

Die aktuelle Konfiguration zeigt eine **klare Verbesserung der Modellkalibrierung**, während die Prognosegüte im Wesentlichen stabil bleibt.

---

# 1. Trainingsstabilität

| Kennzahl             | Wert     | Bewertung     |
| -------------------- | -------- | ------------- |
| Training MSE         | 0.003919 | normal        |
| Validation MSE       | 0.003589 | sehr gut      |
| Val/Train Verhältnis | ~0.92    | ausgezeichnet |
| Validation Std       | 0.000391 | sehr stabil   |
| BitFail              | 7        | moderat       |

**Interpretation**

* Validation-Fehler liegt **unter dem Trainingsfehler** → gute Generalisierung.
* Sehr kleine Standardabweichung zeigt ein **stabiles Modell**.
* Bestes Modell bereits bei **Epoche 208** → schnelle Konvergenz.

Das Trainingsverhalten ist damit **sehr sauber**.

---

# 2. Prognosequalität

| Kennzahl     | Wert      |
| ------------ | --------- |
| MAE          | 355.96 Wh |
| RMSE         | 407.60 Wh |
| RMSE relativ | 19 %      |
| MAPE         | 18.27 %   |
| R²           | 0.72      |

Diese Werte sind **nahezu identisch zum letzten Training**.

Interpretation:

* Modell ist **konvergiert**.
* Weitere große Verbesserungen sind mit gleicher Architektur unwahrscheinlich.

Für eine Wärmepumpen-Lastprognose im Haushalt ist:

**RMSE ~400 Wh bei Max ~7600 Wh → technisch gut.**

---

# 3. Wichtigste Verbesserung: Kalibrierung

| Kennzahl | vorher | jetzt     |
| -------- | ------ | --------- |
| Bias     | 404 Wh | **51 Wh** |
| Slope    | 0.80   | **0.90**  |

Das ist die **entscheidende Verbesserung**.

### Bias

Vorher:

```
systematische Überschätzung
```

Jetzt:

```
Bias ≈ 0
```

Das Modell ist praktisch **unbiased**.

### Slope

Vorher:

```
Peak-Kompression
```

Jetzt:

```
0.9 → deutlich bessere Amplitudenabbildung
```

Die Prognosen folgen dem realen Verbrauch **realistischer**.

---

# 4. Fehlerverteilung

Aus MAE und RMSE lässt sich abschätzen:

```
RMSE / MAE ≈ 1.14
```

Das bedeutet:

* relativ **kompakte Fehlerverteilung**
* **keine schweren Ausreißer**

Das ist ein gutes Zeichen für Stabilität.

---

# 5. BitFail-Analyse

| Wert              | Bewertung            |
| ----------------- | -------------------- |
| BitFail = 7       | leicht über Schwelle |
| Limit = 0.18      | relativ streng       |
| Empfehlung System | **0.28**             |

Die Retrain-Empfehlung entsteht fast sicher durch:

```
BitFail > Limit
```

Technisch ist das Modell aber **nicht problematisch**.

Empfehlung:

```
aiConBitFailLimit = 0.22 – 0.25
```

Damit würde der automatische Retrain realistischer arbeiten.

---

# 6. Einfluss der neuen SolarForecast-Version

Die Änderung von **2.3.x** wirkt sich hier vermutlich auf:

* Trainingsdatenaufbereitung
* Feature-Selektion
* Sample-Handling

aus.

Indiz dafür ist:

* deutlich verbesserter **Bias**
* schnelleres **Training (Epoche 208)**.

---

# 7. Modellkapazität

Aktuelle Struktur:

```
Inputs: 98
Hidden: 80-40
Samples: ~7900
```

Parameterabschätzung:

```
98*80  ≈ 7840
80*40  ≈ 3200
40*1   ≈ 40
----------------
~11000 Gewichte
```

Bei ~7900 Samples ist das **noch akzeptabel**, aber bereits relativ dicht.

Das erklärt:

* frühe Konvergenz
* stabile Fehlerwerte.

---

# 8. Gesamtbewertung

| Bereich             | Bewertung      |
| ------------------- | -------------- |
| Trainingsstabilität | sehr gut       |
| Prognosefehler      | gut            |
| Kalibrierung        | **sehr gut**   |
| Bias                | **fast ideal** |
| Drift               | unkritisch     |
| Robustheit          | gut            |

Das Modell ist jetzt **praktisch produktionsreif**.

---

# 9. Empfehlung für deine aktuelle Konfiguration

Deine Parameter sind bereits sinnvoll:

```
ActFunc = GAUSSIAN_SYMMETRIC
HiddenLayers = 80-40
LearnRate = 0.001
Momentum = 0.6
ShuffleMode = 1
TrainAlgo = INCREMENTAL
```

Einzige sinnvolle Anpassung:

```
aiConBitFailLimit 0.23
```

Alles andere würde vermutlich **keinen messbaren Gewinn mehr bringen**.

---

# 10. Fazit

Die Entwicklung über die letzten Trainingsläufe zeigt eine klare Optimierung:

| Training       | R²       | Bias      | RMSE       |
| -------------- | -------- | --------- | ---------- |
| Februar Modell | 0.60     | 523 Wh    | 443 Wh     |
| 01.03 Modell   | 0.72     | 404 Wh    | 402 Wh     |
| 11.03 Modell   | **0.72** | **51 Wh** | **408 Wh** |

Der größte Fortschritt ist:

**Die Kalibrierung des Modells ist jetzt nahezu korrekt.**

Damit ist dieses Modell **das bisher beste deiner Reihe**.

---

Wenn du möchtest, kann ich auch noch zeigen, warum gerade bei **Wärmepumpen + PV-Eigenverbrauch** ein
R² von etwa **0.7–0.8 meist die praktische Obergrenze** für solche neuronalen Prognosen ist.
Das hat physikalische Gründe und erklärt, warum dein Modell jetzt bereits ziemlich nahe am Optimum arbeitet.


Anpassung auf aiConBitFailLimit 0.23 nehme ich noch nicht vor - ich möchte erst die Berechnung des Drift von diesem Tag abwarten......
Aktuell liege ich bei -25 % aber das sollte sich in der Theorie am Donnerstag dann etwas verbessern wenn ein ganzer Tag mit dem neuen Wert gelaufen ist.

#5

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von Parallix - 11 März 2026, 18:00:54

Es spricht fast nichts dagegen, aber eben nur fast. Denn für die Verbrauchsprognose wird der Verbrauch aller Consumer summiert. Wünschenswert wäre es aber (zumindest in meinem Anwendungsfall), nur die Consumer bei der Verbrauchsprogose zu berücksichtigen, der eine Grundlast darstellen oder aber aktuell geplant sind.

Also ich müsste mich nochmal vergewissern, aber ich bin der Meinung, dass nur gaplante oder eingeschaltete Consumer für die Prognose berücksichtigt werden.
...

Möglicherweise ein Missverständnis: Wenn ich consForecastLastDays != 0 setze, dann wird das gesamte Verbrauchsprofil des Vortags auf den Folgetag abgebildet, was in meinen Fall nicht gewünscht ist, da ich einige Überschussverbraucher nicht als solche ausweisen kann. Erzeuge ich einen Dummy-Consumer zur Abbildung (m)eines Grundverbrauchsprofils, dann kann ich diesen Dummy-Consumer in der aktuellen Version von SF nur dann korrekt (mit consForecastLastDays == 0) bei der Verbrauchsprognose berücksichtigen lassen, wenn seine Leistung über den Tag konstant ist.

Was ich brauche ist aber ein Consumer, der mit einem wohldefinierten 24h-Lastprofil berücksichtigt wird ohne dass ich consForecastLastDays > 0 setzen muss. Das geht doch aktuell nicht, oder?

#6

Zigbee / Leuchten Hue erscheinen nicht

Letzter Beitrag von hannsmattes - 11 März 2026, 17:49:21

Hei, liebe Leute,

ich habe mir eine Hue Bridge Pro angeschafft, dazu zwei Leuchten.

Die Einrichtung der Bridge lief klaglos, Firmware sollte auf Stand sein, allerdings bekomme ich die beiden Leuchten in fhem nicht zu sehen. Ich habe noch keine Erfahrung mit Zigbee, deswegen die Frage: Was habe ich übersehen/wo muss ich nachlesen/was soll ich tun? Ein beherztes "get lights" bringt keine Resultate.

Dank im Voraus an alle

Hanns

#7

Codeschnipsel / Wallbox Zappi von Myenergi

Letzter Beitrag von Onca - 11 März 2026, 17:15:03

Hallo Allerseits, hat jemand bereits eine Zappi V2 mittels Hub in Fhem eingebunden?

Viele Grüße aus demTaununs

Bernd

#8

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 11 März 2026, 17:07:13

Es spricht fast nichts dagegen, aber eben nur fast. Denn für die Verbrauchsprognose wird der Verbrauch aller Consumer summiert. Wünschenswert wäre es aber (zumindest in meinem Anwendungsfall), nur die Consumer bei der Verbrauchsprogose zu berücksichtigen, der eine Grundlast darstellen oder aber aktuell geplant sind.

Also ich müsste mich nochmal vergewissern, aber ich bin der Meinung, dass nur gaplante oder eingeschaltete Consumer für die Prognose berücksichtigt werden. Durch geschickte Planungsparamter wird der Consumer 7 x 24 mit kleinen Unterbrechnungen durchgeplant.
Zusätzlich gibt es ja noch den exconfc Schlüssel für eine Behandlung Richtung Exclude.

Vorteil der Verfahrens ist die komplette Einhaltung der SF-Prozesse bis hin zu den Darstellungen und Berücksichtigungen diverser Werteberechnungen. 

#9

Sprachsteuerung / Aw: [37_echodevice] Amazon Ech...

Letzter Beitrag von locodriver - 11 März 2026, 16:54:03

Ich habe im Thread gesucht und dann versucht, die 2FA zu aktivieren. Amazon ist der Meinung, dass ich zu viele One pass codes abgerufen habe und sperrt mich für längere Zeit aus .

So langsam nerven die ganz schön...

@JudgeDredd: wenn ich das geschafft habe, melde ich mich wieder. Einstweilen vielen Dank für deine Unterstützung und Geduld.

#10

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von Parallix - 11 März 2026, 16:26:00

@Parallix,

Ist es möglich, dass Du in SF ein Attribut einbaust, mit dem eine Grundlast definiert werden kann, die dann als immer zu berücksichtigender Verbrauch von SF bei der Ladeplanung berücksichtigt wird. Für (m)einen Anwendungsfall wäre es noch besser, wenn ein Grundlast-Profil als Array mit 24 Elementen (ein Element pro Stunde) definiert werden kann oder ggf. sogar aus einem Reading bezogen werden kann.

Was spricht dagegen, wenn du dir einen ConsumerXX (als Dummy) anlegst und die Leistung entsprechend deines Grundbedarfs definierst. "power" ist zur Zeit ein fester Wert, kann aber bei Bedarf recht leicht erweitert werden um Quellenreadings zu verarbeiten. Den Inhalt kannst du dann aus einem Array errechnen und dort eintragen.

Mit pvshare=0 ist auch die Unabhängigkeit vom PV-Überschuß gegeben und du kannst diesen "Verbraucher" 24h am Tag planen und "einschalten" lassen. Das hat auch den Vorteil, dass Werte aus der Vergangenheit völlig konform mit den Modulprozessen einbezogen werden können um die Zukunft abzubilden.
So kannst du z.B. an einem WE den "Grundverbrauch" gezielt ändern und solche Dinge.
...

Es spricht fast nichts dagegen, aber eben nur fast. Denn für die Verbrauchsprognose wird der Verbrauch aller Consumer summiert. Wünschenswert wäre es aber (zumindest in meinem Anwendungsfall), nur die Consumer bei der Verbrauchsprogose zu berücksichtigen, der eine Grundlast darstellen oder aber aktuell geplant sind.

Mir persönlich ist auch jetzt erst aufgefallen, dass SF zwar über einen einen (Sicherheits-)Faktor die Ladeleistungen anheben kann, aber keine additiven Ladeleistungskomponente berücksichtigen kann. Oder liegt ich hier falsch?