Neueste Beiträge

#1

Multimedia / Aw: Modul für Denon (Marantz) ...

Letzter Beitrag von olwaldi - 18 Januar 2026, 14:09:35

Angeregt durch die letzten Beiträge hier habe ich nochmal genauer nach meinem (älteren) Problem mit der sub DENON_AVR_RequestDeviceinfo geguckt.

Zur Erinnerung: Mein Denon X6400H hat beim Aufruf dieser Funktion immer eine Fehlermeldung gebracht. Mittlerweile habe ich gelernt, mittels curl dieselbe URL wie in der sub aufzurufen durch

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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?

Zum anderen scheint FHEM den Output nicht zu bekommen, selbst wenn ich Port 8080 erzwinge:

Code Auswählen Erweitern

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.

Und noch mysteriöser: Obwohl $port bei der Zuweisung in $url definitiv gesetzt ist, fehlt dieser Stringanteil je nach Fehlermeldung:

Code Auswählen Erweitern

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?!

Angehängt habe ich "meine" Version von 70_DENON_AVR.pm - enthält meine Bugfixes on top der aktuell in SVN eingecheckten Version https://svn.fhem.de/fhem/trunk/fhem/70_DENON_AVR.pm


Bin gespannt auf eure Ideen, Michael
PS @vneise: toggle funktioniert bei mir problemlos.

Nachtrag: Ich kann sogar die sub explizit aufrufen durch

Code Auswählen Erweitern

{  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?!?!

Nachtrag2: Aber XMLin funktioniert "standalone" problemlos:

Code Auswählen Erweitern

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.

#2

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 18 Januar 2026, 14:02:20

Wie 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:

Ich 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.

Du bekommst dann eine textuelle Auswertung. Diese Bewertung schaust du dir an und prüfst auf Validität. Eine KI denkt sich auch gerne mal etwas aus und berichtet Unfug weil z.B. Seitenbedingungen nicht bekannt sind. Die stellst du richtig - z.B. die Normierung wird bereits 100%ig umgesetzt / meine PV arbeitet z.Zt. nicht weil von Schnee bedeckt - und verlangst eine neue Bewertung.
Üblicherweise kommen dann noch Empfehlungen heraus, die man natürlich auch mit einem natürlichen Verstand gegenchecken muß. 

#3

MQTT / Aw: GOVEE2MQTT - Client mit we...

Letzter Beitrag von Dracolein - 18 Januar 2026, 13:52:36

Hallo Dek, steuerst Du Dein Govee Device erfolgreich via Govee2MQTT auf einer HA-Instanz mittels MQTT FHEM<-> HA ?

Über Ratschläge und Infos wäre ich dankbar, ich bin selbst zu unfähig diese Lösung zu bauen, glaube ich.

#4

Homematic / HM-Taster löst nur bei mechani...

Letzter Beitrag von dadoc - 18 Januar 2026, 13:41:29

Hallo zusammen,
Ich habe in fhem einen Tradfri-Treiber (zigbee, über z2mqtt), den ich u.a. über einen mechanischen Taster schalte. Der Taster hängt an einem 12/7 I/O wired-HM-Modul und ist über hmccu in fhem verfügbar.
Beim manuellen Betätigen des Taster wird in fhem entsprechend ein Event ausgelöst, auf das ich triggern kann; im Log der ccu steht ,,S250 Tastendruck kurz".
Wenn ich den Taster aber in PocketHome integriere und dort betätige, steht zwar im ccu-Log dasselbe wie beim mechanischen Drücken; in fhem aber kommt nichts an.
Soll das so?
Danke & Grüße
Martin

;

#5

Bastelecke / Aw: ESP RGBWW Wifi Led Control...

Letzter Beitrag von 2space - 18 Januar 2026, 13:40:34

Hallo pjakobs,

moin @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.

ich hab den Thread zur neuen Firmware mal verlassen und bin vermutlich hier besser aufgehoben. Die Einstellungen sind identisch zu deinen Screenshots. Ich hab mir die Lötstellen auf dem Board angeschaut. Sieht soweit gut aus (Bilder sind angehängt). Verbinde ich das Kabel für die roten LEDs mit dem Port für grün oder blau, dann leuchten auch die roten LEDs des Stripes. Die Kanäle für G, B, WW, CW scheinen soweit in Ordnung. Irgendetwas auf dem Board scheint nicht mehr okay zu sein. Ich sollte ja testweise den MOSFET überbrücken. Das habe ich jetzt noch nicht versucht, da ich in diesem Bereich keine Erfahrung habe ich die beiden Stellen die ich überbrücken würde farblich markiert und würde auf eine Bestätigung durch euch warten.

Mfg 2space

#6

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von grappa24 - 18 Januar 2026, 13:21:53

Wie bekommt man denn die KI-Bewertung?

sieht jetzt ganz gut aus bei mir:

Code Auswählen Erweitern

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

#7

TabletUI / Aw: FTUI version 3

Letzter Beitrag von FischFuss - 18 Januar 2026, 13:14:03

Hallo Leute,
ich habe mir nun auch - mit Hilfe eines Chat-bots, da ich überhaupt keine Ahnung von Webdesign habe - zusammengebaut. Ich habe jetzt alles zusammengestell und es sieht super aus... bis auf dieses eine (2x4)Tile. Es soll einen Dimmer darstellen, auf der linken Seite ein Icon zum ein- und ausschalten und rechts daneben einen horizontalen slider.
Leider bekomme ich Icon und slider nicht nebeneinander, sondern nur übereinander. (siehe Bild)
Hier der ChatBot generierte Code;

Code Auswählen Erweitern

       <!-- 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>

Ich hoffe jemand von Euch kann den code so verändern, dass das Icon links ist und der Slider rechts daneben... ich raff das einfach nicht (Und ZWEI verschiedene Chatbots offensichtlich auch nicht).
Vielen Dank schonmal für Eure Hilfe!

#8

FHEM Development / Aw: code checkin unter fhem/li...

Letzter Beitrag von Sidey - 18 Januar 2026, 12:45:47

Hallo herrmannj,

Ich habe vor, das Package bei mir einzubinden.
Leider klappt es nicht Liegt vielleicht am Benutzer. Ziemlich sicher bin ich aber, dass was mit dem Löschen der Matchlist nicht stimmt:


In Zeile 103:

Code Auswählen Erweitern

$io_dev->{MatchList} = []; # force rebuild

Ich lasse MQTT2_Client patchen, aber das löschen der MatchList führt kein rebuild oder sowas aus.
Vermutlich wolltest Du den

Code Auswählen Erweitern

.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.
Da MatchList dazu da ist, noch nicht geladene FHEM Module zu laden, könnte die Zeile (103) vermutlich komplett entfernt werden. Vor allem, da in

Code Auswählen Erweitern

...._resetClients die Matchlist wieder gesetzt wird, solange das IO noch nicht gepatcht wurde. Das Löschen findet ja unter anderen Bedingungen trotzdem statt.

Nach dem Einbinden war jedenfalls meine Matchlist leer und damit würden MQTT2_DEVICE und MQTT_GENERIC_BRIDGE nie geladen werden.

Code Auswählen Erweitern

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


Grüße Sidey

[Revision 30751: 76_SolarForecast: contrib Version 2.0.0]

#9

FHEM Code changes / Revision 30751: 76_SolarForeca...

Letzter Beitrag von System - 18 Januar 2026, 12:40:57

Revision 30751: 76_SolarForecast: contrib Version 2.0.0

76_SolarForecast: contrib Version 2.0.0

Source: Revision 30751: 76_SolarForecast: contrib Version 2.0.0

#10

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.