curl --header "User-Agent: FHEM" --header "Accept: application/xml" http://192.168.178.66:8080/goform/Deviceinfo.xml --output Deviceinfo.xml
Prompt wird eine 65kB große XML-Datei wie erwartet angelegt. Der entsprechende Aufruf aus 70_DENON_AVR.pm schlägt aber (aus zwei Gründen) fehl.sub DENON_AVR_RequestDeviceinfo {
my ($hash) = @_;
my $name = $hash->{NAME};
my $port = AttrVal($hash, 'deviceInfoPort', 80);
my $url = "http://$hash->{IP}:$port/goform/Deviceinfo.xml";
Log3 $name, 4, "DENON_AVR ($name) - requesting $url";
my $param = {
url => "$url",
timeout => 5,
hash => $hash,
method => "GET",
header => "User-Agent: FHEM\r\nAccept: application/xml",
callback => \&DENON_AVR_ParseDeviceinfoResponse
};
HttpUtils_NonblockingGet($param);
}
Zum einen findet FHEM das Attribut deviceInfoPort nicht, sondern nutzt den (falschen) default 80. Habe auch mal den Tip von shadow (weiter oben) und statt $hash den $name benutzt - ohne Erfolg. Vermutlich sind die Attribute während des Neustarts von FHEM (noch) nicht gesetzt, während das DENON_AVR device initialisiert wird. Ab wann sind die Attribute verfügbar?DENON_AVR (Denon) - Error while requesting http://192.168.178.66:8080/goform/Deviceinfo.xml - http://192.168.178.66:8080/goform/Deviceinfo.xml: empty answer received
Genau dasselbe Problem hatte wohl auch https://forum.fhem.de/index.php?topic=106457.0, aber ein Wechsel der httpversion => "1.1" in $param hat mir nicht geholfen. Am timeout von 5s sollte es nicht liegen, da curl innerhalb von Sekundenbruchteilen antwortet.DENON_AVR (Denon) - Error while requesting https://192.168.178.66/goform/Deviceinfo.xml - Error 403: ForbiddenOhne Port kann der Aufruf auch nicht funktionieren. Aber wieso kann der fehlen?!{ my ($hash) = $defs{"Denon"};; DENON_AVR_RequestDeviceinfo($hash)}Bei verbose=5 sehe ich dann sogar die XMl-Struktur im Logfile, aber die Zugriffe auf BrandCode oder ModelName schlagen fehl. Anscheinend macht die Funktion XMLin jetzt wohl irgendwas anders?!?!use XML::Simple;
$ref = XMLin('Deviceinfo.xml', KeyAttr => { }, ForceArray => [ ]);
print $ref->{BrandCode} . "\n";
print $ref->{ModelName} . "\n";
liefert das Erwartete ... aber eben NICHT im FHEM-Kontext.ZitatWie bekommt man denn die KI-Bewertung?Du öffnest die KI-Applikation deiner Wahl (ich verwende MS 'Copilot' im Smart-Mode) und fütterst die KI z.B. wie folgt am Prompt:
ZitatIch verwende das FHEM Modul SolarForecast (76_SolarForecast.pm) zur Prognose meines Hausverbrauchs. Mit dem aktuellen Training habe ich folgende Kennzahlen, Trainingslogs und visuelle Darstellung erreicht und möchte eine Bewertung meines Modells. Ich habe PV und eine/keine WP und ein/kein EV.
(Jetzt kopierst du hinein -> das komplette Trainingslog (mit Debug aiProcess), die Kennwerte aus "get ... valDecTree aiNeuralNetConState" und einen Screenshot des Balkendiagramms mit der Erläuterung welche Balkenfarbe Prognose und Realität ist.)
... und sendest die Anfrage ab.

Zitat von: pjakobs am 05 Januar 2026, 19:50:00moin @2space - als allererstes würde ich die Physik überprüfen: Kontakte, Lötstellen etc.
Wenn das alles funktioniert (Du kannst zum Test mal den Kontakt für Rot gegen Masse brücken, wenn das funktioniert, ist bis zu der Stelle alles richtig.
Die zweite Frage ist: ist die Pinbelegung korrekt eingestellt? Für Dich sollte das das mrpj Layout sein.
Du schreibst hier im Thread für die Version 5, ich vermute also mal, dass Du die nutzt - da kannst Du mal unter system settings / controller config / pin configuration nachsehen, sollte so aussehen wie im Anhang.
Zuallerletzt könnte es theoretisch auch ein MOSFET oder gar der ESP8266 sein, damit wärst Du aber in den ersten beiden Entwürfen der erste, halte ich für extrem unwahrscheinlich.
letztes KI-Training: 17.01.2026 20:17:52 / Laufzeit in Sekunden: 3218
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 109.36 ms
Verbrauchernummer Wärmepumpe: -
=== Modellparameter ===
Normierungsgrenzen: PV=11990 Wh, Hausverbrauch: Min=0 Wh / Max=6468 Wh
Trainingsdaten: 8299 Datensätze (Training=6639, Validierung=1660)
Architektur: Inputs=65, Hidden Layers=80-40-20, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.5, BitFail-Limit=-
Aktivierungen: Hidden=SIGMOID, Steilheit=0.9, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_common_active_pv
Zufallsgenerator: Mode=2, Periode=10
=== Trainingsmetriken ===
bestes Modell bei Epoche: 70 (von max. 15000)
Training MSE: 0.002557
Validation MSE: 0.001778
Validation MSE Average: 0.002537
Validation MSE Standard Deviation: 0.000114
Validation Bit_Fail: 1
Model Bias: 105 Wh
Model Slope: 0.9
Trainingsbewertung: ok
=== Fehlermaße der Prognosen ===
MAE: 159.45 Wh
MedAE: 82.92 Wh
RMSE: 213.90 Wh
RMSE relative: 51 %
RMSE Rating: acceptable
MAPE: 25.10 %
MdAPE: 18.69 %
R²: 0.86 <!-- Dimmer Licht Bad -->
<ftui-grid-tile row="3" col="10" height="2" width="4" shape="round">
<ftui-label size="3" height="0em">Licht Bad</ftui-label>
<!-- Flex-Container: Verhindert Überlappung -->
<div class="hbox items-center justify-space-around" style="height: 40%; width: 50%;">
<!-- Linke Spalte: Icon (ca. 30% Breite) -->
<div class="vbox width-30">
<ftui-button [(value)]="z2t_D601"
fill="none"
size="large"
class="cell">
<ftui-icon [name]="z2t_D601 | map('on: lightbulb-on, off: lightbulb')"
[color]="z2t_D601 | map('on: orange, off: white')"
size="5">
</ftui-icon>
</ftui-button>
</div>
<!-- Rechte Spalte: Slider (ca. 60% Breite) -->
<div class="vbox width-60">
<ftui-slider [value]="z2t_D601:Dimmer"
(value)="z2t_D601 Dimmer"
min="100"
max="1000"
step="10">
</ftui-slider>
</div>
</div>
</ftui-grid-tile>
Liegt vielleicht am Benutzer. Ziemlich sicher bin ich aber, dass was mit dem Löschen der Matchlist nicht stimmt:$io_dev->{MatchList} = []; # force rebuild
.clientArray löschen damit dieser neu berechnet wird oder tatsächlich eine neue MatchList schreiben, wobei ich nicht glaube dass FHEM das Package laden könnte, da es natürlich kein FHEM Modul ist. ...._resetClients die Matchlist wieder gesetzt wird, solange das IO noch nicht gepatcht wurde. Das Löschen findet ja unter anderen Bedingungen trotzdem statt.Internals:
._io_patched 1
BUF
Clients :MQTT2_Dispatcher:MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
ClientsKeepOrder 1
DEF mqtt:1883
DeviceName mqtt:1883
FD 4
FUUID 695e9c21-f33f-c986-e617-d7301881c4685bc6
NAME mqtt_broker
NR 49
PARTIAL
STATE opened
TYPE MQTT2_CLIENT
WBCallback
clientId mqtt_broker
eventCount 1
lastMsgTime 1768736553.88505
nextOpenDelay 10
nrConnects 1
MatchList:
READINGS:
2026-01-18 12:42:33 state opened
Attributes:
autocreate simple
verbose 5
setupEnvironment outsideTemp=MQTT2_ebusd_bai:1_Aussentemperatur_rounded
# ⭐ **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.