Neueste Beiträge

#91

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.

#92

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

;

#93

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

#94

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

#95

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!

#96

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]

#97

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

#98

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.


#99

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

#100

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.