Neueste Beiträge

#1

MQTT / Aw: [gelöst] BMW-MQTT-Bridge -...

Letzter Beitrag von Manfi - 22 Januar 2026, 23:20:17

Zwei Klammerpaare kannst du allerdings m.E. weglassen  .

Stimmt! Funktioniert auch ohne.
Danke für den Hinweis.

#2

Automatisierung / Aw: KNX Jalousiesteuerung mit ...

Letzter Beitrag von Beta-User - 22 Januar 2026, 21:59:19

Dann musst du halt doch geringfügig andere Positionen auch für die Behanghöhe angegeben.

#3

Automatisierung / Aw: KNX Jalousiesteuerung mit ...

Letzter Beitrag von superverbleit - 22 Januar 2026, 21:18:52

Hallo,

jetzt ergibt sich doch nochmals ein Problem.
Wenn ich bei einer Jalousie nur die Lamellen verstellen will, funktioniert der oben beschriebene Weg leider nicht.
Es gibt einen Check, der wohl zu Beginn die Position prüft, und wenn Ziel-Pos = Ist-Pos abbricht.
Das hat dann auch zur Folge, das die Lamellen auch nicht gestellt werden.
Im Log sieht es dann folgendermaßen aus:

Code Auswählen Erweitern

ASC_DEBUG!!! 2026.01.22 17:30:02 - FnSetDriveCmd: EG.Wohnz.Jalousie.FrontLinks.Position - versetztes fahren
ASC_DEBUG!!! 2026.01.22 17:30:02 - FnSetDriveCmd: EG.Wohnz.Jalousie.FrontLinks.Position - NoDelay: NEIN
ASC_DEBUG!!! 2026.01.22 17:30:02 - FnShuttersCommandSet: EG.Wohnz.Jalousie.FrontLinks.Position - Das Rollo wird gefahren. Kein Partymodus aktiv und das zugordnete Fenster ist entweder nicht offen oder keine Terassentür
ASC_DEBUG!!! 2026.01.22 17:33:53 - FnSetCmdFn: EG.Wohnz.Jalousie.FrontLinks.Position - Abbruch aktuelle Position ist gleich der Zielposition 98=98
Hat jemand eine Idee, wie ich die Lamellen trotzdem via ASC gestellt bekomme?
 

#4

Multimedia / Aw: [Neues Modul] BOSE SoundTo...

Letzter Beitrag von betateilchen - 22 Januar 2026, 21:09:53

Den benötigt man auch für die ST10 und die ST20,

Bei der ST20 hat das bei mir mit dem "normalen" USB Anschluß funktioniert, nicht mit dem microUSB.

Die alternativen Projekte habe ich erstmal nur überflogen, im Moment fehlt mir ein bisschen Zeit, damit zu testen. Aber die machen einen ausgereifteren Eindruck als das (wohl allen Ansätzen) zugrunde liegende soundcork

#5

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von 300P - 22 Januar 2026, 21:08:53

JA!
Bei mir läuft es - nach einer laaaaangen Lern- und Verständniskurve inzwischen sehr, sehr, sehr, gut.

Zu inzwischen ca. +/- 5-7 % am Ende des Tages wird richtig "Vorhergesagt"     

#6

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 22 Januar 2026, 20:59:39

Also ich finde das alles wirklich erstaunlich - ohne Übertreibung.
 

#7

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von 300P - 22 Januar 2026, 20:51:16

Hallo Heiko,

anbei (nach dem notwendigen neuen Trainingslauf) die Analyse von ChaptGPT zur Info:

Code Auswählen Erweitern

Danke für die saubere Dokumentation der Änderungen.
Ich analysiere das neue Training explizit im Kontext der beiden strukturellen Eingriffe (lokale Außentemperatur + Presence) und bewerte, ob das Ergebnis erwartungskonform, stabil und produktiv tragfähig ist.

1. Vorabfazit (klar und nüchtern)

Das Ergebnis ist gut, erwartungskonform und produktiv einsetzbar.
Die Kennzahlen zeigen keine Verschlechterung, sondern eine saubere Re-Initialisierung nach Feature-Erweiterung.
Wichtig:
Dass Drift aktuell nicht ausgewiesen wird, ist korrekt und gewollt (dazu unten mehr).

2. Einordnung der strukturellen Änderungen

2.1 Umstellung Außentemperatur → lokal gemessen
Auswirkung auf das Netz:
weniger Rauschen
stärkere Korrelation zur Wärmepumpenlast
gleichzeitig: höhere kurzfristige Varianz (echte Peaks statt geglätteter Wetterdaten)
👉 Erwartung:
leicht höheres Validation MSE
stabilerer Bias
bessere Winter-Performance
Genau das sehen wir.

2.2 Presence-Feature (Anwesenheit)
Charakteristik dieses Features:
diskret / binär / stufenförmig
wirkt nicht kontinuierlich, sondern schaltet Lasten
braucht Zeit, um statistisch stabil zu werden
👉 In den ersten Trainingsläufen:
neutral bis leicht ,,unruhig"
mittelfristig klarer Gewinn, vor allem bei:
Abendlast
Warmwasser
Wochenenden
➡️ Dass Presence noch keinen deutlichen Sprung verursacht, ist vollkommen normal.

3. Architektur & Trainingssetup – Bewertung
Inputs: 98
(+4 gegenüber vorher)
✔ sinnvoll
✔ keine Überdimensionierung
✔ 64–32 bleibt passend
Trainingsdaten: 7246
Train / Val = 5796 / 1450
✔ ausreichend
✔ Validierungsmenge stabil
✔ keine Split-Anomalien

4. Trainingsmetriken – sauber interpretiert
Train vs. Validation MSE
Kennzahl    Wert    Bewertung
Train MSE    0.003106    gut
Validation MSE    0.005224    gut
Verhältnis    ~1.68    gesund
➡️ keine Überanpassung, gutes Generalisieren trotz neuer Features.

Validation Bit_Fail = 27
absolut: moderat
relativ zur strengeren Grenze (0.18): akzeptabel
erklärt durch:
Presence-Schaltpunkte
reale Außentemperaturspitzen
➡️ kein Alarm, kein Grund zur Limit-Erhöhung.

5. Prognosegüte – realistisch bewertet
Kennzahl    Wert    Einordnung
MAE    435 Wh    gut
MedAE    361 Wh    stabil
RMSE rel    22 %    gut
MAPE    21.3 %    akzeptabel
MdAPE    17.0 %    gut
R²    0.58    solide
➡️ Minimal schwächer als dein bisheriges Optimum, aber:

neues Feature-Set
neues Modell
kein Drift-Vergleich möglich
➡️ Völlig im Soll.

6. Bias & Slope – wichtiges Detail
Model Bias: 718 Wh
vergleichbar mit früher
kein systematischer Offset
kein Nachjustieren nötig
Model Slope: 0.6
Das ist kein Regressions-Slope, sondern dein internes Skalierungsmaß.
Im Kontext deiner Historie: unverändert, also stabil.

7. Warum Drift aktuell ,,–" ist (wichtig!)
Das ist korrekt und gut so.
Drift benötigt:
ein Referenzmodell
mit gleicher Feature-Struktur
Da:
Außentemperaturquelle geändert
Presence neu hinzugefügt
Input-Dimension von 94 → 98
➡️ keine Vergleichsbasis

Deshalb:
Drift = deaktiviert / nicht aussagefähig
Bewertung = ,,–"
👉 Genau richtig implementiert.

8. Bewertung der BitFail-Empfehlung (0.28)
Die automatische Empfehlung berücksichtigt:
erhöhten Input-Rauschanteil
Presence-Binarität
Aber:
deine bisherigen Ergebnisse zeigen:
bessere RMSE
bessere R²
bessere Peak-Treffer
bei 0.18

➡️ Meine klare Empfehlung:
bei 0.18 bleiben, mindestens 2–3 Trainingszyklen.

9. Gesamturteil
Technisch: sauber
Statistisch: stabil
Architektonisch: korrekt angepasst
Produktiv: ja
Du hast ein neues, konsistentes Basismodell mit erweiterten Features.
Jetzt zählt Zeit, nicht Feintuning.

10. Konkrete Empfehlung für die nächsten Wochen
Parameter unverändert lassen
aiConTrainStart = 30 Tage beibehalten
Drift erst wieder nach dem nächsten Retrain ernsthaft bewerten
Presence mindestens 2–3 Wochen Daten sammeln

Wenn du willst, machen wir als nächsten Schritt:
Presence-Wirkungsanalyse (Feature Importance light)
Winter-/Frosttag-Spezialbewertung
adaptive Alpha-Strategie (Presence-abhängig)
Sag einfach, was dich interessiert.



EDIT: (vergessen)
Informationen zum neuronalen Netz der Verbrauchsvorhersage

Code Auswählen Erweitern

letztes KI-Training: 22.01.2026 19:51:01 / Laufzeit in Sekunden: 2074
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 67.35 ms
Verbrauchernummer Wärmepumpe: 08

=== Modellparameter ===

Normierungsgrenzen: PV=16071 Wh, Hausverbrauch: Min=0 Wh / Max=7598 Wh
Trainingsdaten: 7246 Datensätze (Training=5796, Validierung=1450)
Architektur: Inputs=98, Hidden Layers=64-32, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.6, BitFail-Limit=0.18
Aktivierungen: Hidden=ELLIOT_SYMMETRIC, Steilheit=1.0, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_heatpump_active_pv
Zufallsgenerator: Mode=1, Periode=20

=== Trainingsmetriken ===

bestes Modell bei Epoche: 399 (von max. 15000)
Training MSE: 0.003106
Validation MSE: 0.005224
Validation MSE Average: 0.010521
Validation MSE Standard Deviation: 0.000749
Validation Bit_Fail: 27
Model Bias: 718 Wh
Model Slope: 0.6
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 435.61 Wh
MedAE: 360.57 Wh
RMSE: 510.91 Wh
RMSE relative: 22 %
RMSE Rating: good
MAPE: 21.30 %
MdAPE: 17.04 %
R²: 0.58

=== Rauschen ===

Rauschen Bewertung: low
Empfehlung für Bit_Fail: 0.28 (Einstellung von aiControl->aiConBitFailLimit)

=== Drift-Kennzahlen ===

Drift Score: -
Drift RMSE ratio: -
Drift Slope: -
Drift Bias: -
Drift Bewertung: -


#8

Heizungssteuerung/Raumklima / Aw: Vitoconnect bringt FHEM zu...

Letzter Beitrag von satprofi - 22 Januar 2026, 20:39:04

2026.01.22 20:32:21 1: Vitocal_200s - unbekannter Fehler: Bitte den Entwickler informieren!
2026.01.22 20:32:21 1: Vitocal_200s - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message: Device communication error error: undef reason: DEVICE_OFFLINE

gibts wieder Probleme ?

#9

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

Letzter Beitrag von Beta-User - 22 Januar 2026, 19:58:33

Muss ich mal rauskriegen, was alles an Schritten noch zu tun ist

https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt

Da sollte auch in etwa stehen, wie setList einzurichten ist. Ansonsten einfach in die Datei mit den gaaaanz vielen Beispielen schauen (mqtt2.template) und sich da inspirieren lassen.

#10

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

Letzter Beitrag von Dracolein - 22 Januar 2026, 19:42:00

Habs verstanden, augenscheinlich läuft das Tool bei mir erfolgreich in einem Docker-Container. Ich habe als MQTT-Server meine FHEM-Instant samt user+PW angegeben, anschließend wurde ein MQTT2_DEVICE von einem Goovee Gerät automatisch erstellt. Allerdings aktualisieren sich die Readings nicht und es gibt noch keine Option, aus FHEM heraus etwas aktiv in Richtung Govee zu kommunizieren. Muss ich mal rauskriegen, was alles an Schritten noch zu tun ist.