Neueste Beiträge

#1

Heizungssteuerung/Raumklima / Aw: VALVES und die Fritz DECT ...

Letzter Beitrag von Beta-User - 26 Januar 2026, 07:14:42

Alternativ: die Readings mit dem Script (erst mal) an die Thermostate schreiben.

Falls Anpassungen an VALVES (contrib-Fassung) erforderlich wären bitte melden und ein "list" von einem der Thermostate einstellen.

#2

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

Letzter Beitrag von FlatTV - 26 Januar 2026, 07:10:00

Ich bin etwas verwirrt, worüber hier eigentlich geschrieben wird.

- Ist das nun ein Bug im Soundtouch-FHEM-Modul, oder bezieht sich das auf eines der Projekte
Bitte an die Ersteller der jeweiligen Posts: Klar schreiben, worauf sich das bezieht.

Guten morgen,
da hätte ich mich wohl klarer ausdrücken müssen. 
Es ist ein Bug im Modul 98_BOSEST.pm (Denke ich).
Wenn ich im FHEM Web-Frontend versuche die Source (AUX oder Bluetooth) umzustellen.

Jetzt muss ich doch mal einen Bug im Modul melden.
Wenn ich über das Webinterface die Source ändern möchte, wird statt der Source ,,AUX" der Wert 41 übergeben, das ist aber der Wert für Volume.
Im List des Device kann man das gut sehen.
Die Variable switchSource im helper hätte eigentlich auf ,,AUX" stehen müssen.

Code Auswählen Erweitern

...
     2026-01-25 21:55:23   source          STANDBY
     2026-01-25 21:55:23   state           online
     2026-01-25 21:55:22   stationName    
     2024-03-17 10:32:44   supportClockDisplay true
     2026-01-18 11:48:16   time           
     2026-01-18 10:34:43   timeTotal      
     2026-01-25 21:55:22   track          
     2026-01-25 21:26:10   volume          41
     2026-01-17 21:29:21   zoneMaster     
     2026-01-17 21:29:21   zoneMember_1   
     2026-01-17 21:28:45   zoneMember_2   
   helper:
     IP         192.168.178.30
     airplaySupport 1
     auxSupport 1
     bluetoothSupport 1
     bosewebsocket e9c1a814be06c06dd686aea2a587c63b
     dlnaServers NAS,pi4:_minidlna,FRITZ
     lastSpokenChannel
     mojoping   71de26af285a1452d8ebe6e6f1d46f17
     productHdmi1Support 0
     productTvSupport 0
     requestId  1
     sent_off   1
     sent_on    0
     supportedBassCmds
     supportedSourcesCmds aux,airplay,bluetooth,bt-discover
     switchSource 41
     wsconnected 1
     sources:
       HASH(0x55b2514e48)
       HASH(0x55bb1b1a98)
       HASH(0x55bb1b0ee0)
       HASH(0x55bb1be6f0)
       HASH(0x55bb1be240)
       HASH(0x55bb1baca0)
       HASH(0x55bb1a3158)
       HASH(0x55bb21cd00)
       HASH(0x55bb1b1948)
       HASH(0x55ba9c4760)
       HASH(0x55bb18f528)
       HASH(0x55bafa2428)
       HASH(0x55bb1b17b0)
       HASH(0x55bb1b18d0)
       HASH(0x55bb0f9520)
     stateCheck:...

Ich hatte mir mal testweise mit dem Dumper angeschaut, was die Funktion BOSEST_Set überhaupt im Array @params übergeben bekommt.

Code Auswählen Erweitern

2026.01.25 22:41:49 1: BOSEST: BOSEST_Set:
$VAR1 = [
          'source',
          '41'
        ];

#3

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von TheTrumpeter - 26 Januar 2026, 07:07:35

So, die KI hat wohl grad ein "bisschen" nach unten korrigiert.
So lange WP-Laufzeiten sind aber für das erwartete Wetter komplett übertrieben. Gestern war bei vergleichbaren Bedingungen um 15:00 "Schluss", heute erwarte ich es wie gesagt ähnlich.

#4

Sonstige Systeme / Aw: fhempy: tuya (lokal)

Letzter Beitrag von TheTrumpeter - 26 Januar 2026, 06:59:35

Und siehe da: Das automatisch erstellte Device kennt sage und schreibe 30 (!) neue Datenpunkte mit den ids 101 - 130, alle set-Befehle sind komplett vorhanden.

Das habe ich in der Vergangenheit für einfache Zwischensteckdern mit Verbrauchsmessung auch schon beobachtet...
Aus einer 4er-Packung mit scheinbar identischen Geräten wurden in FHEM mal "vollständige" und mal "Unvollständige" Geräte angelegt. Nach mehrmaligem Löschen und Neu-Hinzufügen wurden dann irgendwann doch vergleichbare Ergebnisse erzielt. Teilweise habe ich die Geräte sogar aus der Tuya-App gelöscht und neu angelernt.

Was genau zum Erfolg geführt hat, kann ich nun nicht mehr sagen. Das Löschen aus der App scheint wohl nicht nötig gewesen zu sein, weil Du das nicht gemacht hast.

#5

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von TheTrumpeter - 26 Januar 2026, 06:44:54

Seit dem letzten Update (das mit den fhemweb-Fehlermeldungen, bzw. die Korrektur danach) ist meine Verbrauchsprognose deutlich schlechter geworden.

Was mir aufgefallen ist: In der Nacht gibt es keine (langen) Lernzyklen mehr, es wird zwar was getan/gestartet, aber das ist umgehend wieder aus:

Code Auswählen Erweitern

2026.01.26 02:15:02 1: mySolarForecast DEBUG> AI Raw delete data equal or less than index >2021012700<
2026.01.26 02:15:02 1: mySolarForecast DEBUG> AI AddInstance & Training BlockingCall PID "5091" with Timeout 7200 s started
2026.01.26 02:15:04 1: mySolarForecast DEBUG> AI Instance add - Tree: 1 -> 6511 entities added for training (set verbose 4 for output more detail)
2026.01.26 02:15:04 1: mySolarForecast DEBUG> AI Instance add - Tree: 2 -> 6511 entities added for training (set verbose 4 for output more detail)
2026.01.26 02:15:05 1: mySolarForecast DEBUG> AI Instance add - Tree: 3 -> 6511 entities added for training (set verbose 4 for output more detail)
2026.01.26 02:15:09 1: mySolarForecast DEBUG> AI trained Tree: 1, number of entities: 6511
2026.01.26 02:15:09 1: mySolarForecast DEBUG> AI trained Tree: 3, number of entities: 6511
2026.01.26 02:15:09 1: mySolarForecast DEBUG> AI trained Tree: 2, number of entities: 6511
2026.01.26 02:15:09 1: mySolarForecast DEBUG> Training instances and their associated information where purged from the AI object
2026.01.26 02:15:09 1: mySolarForecast DEBUG> AI trained and saved data into file: ./FHEM/FhemUtils/AItra_SolarForecast_mySolarForecast
2026.01.26 02:15:09 1: mySolarForecast DEBUG> AI Training BlockingCall PID "5091" finished, state: ok
Für heute behauptet die KI steigenden Energieverbrauch gegen Abend, und zwar in Dimensionen, die 2x der Wärmepumpe entsprechen. Und das, obwohl die Außentemperaturen seit langem wieder leicht positiv sind:
Der Verbrauch bis 14:59 passt noch halbwegs, von 15:00 bis 15:59 ist es jedenfalls zu hoch. Falls noch WP-Lauf nötig ist, wären's ca. 2,5 kW, ansonsten 0,35 kW, was dann bis 21:59 fortgeschrieben werden sollte und sich bis 23:59 auf 0,2 kW reduzieren müsste.
WOHER die KI diese Verbrauchsannahme hat, ist mir völlig rätselhaft.

Hier noch die Trainingsdaten. Auch dort wird das letzte Training mit 23.01. 10:00 angegeben, was mein manuell gestartetes Training nach dem Update war:

Code Auswählen Erweitern

Informationen zum neuronalen Netz der Verbrauchsvorhersage

letztes KI-Training: 23.01.2026 10:02:36 / Laufzeit in Sekunden: 9852
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 88.41 ms
Verbrauchernummer Wärmepumpe:  03

=== Modellparameter ===

Normierungsgrenzen: PV=18612 Wh, Hausverbrauch: Min=0 Wh / Max=6400 Wh
Trainingsdaten: 8280 Datensätze (Training=6624, Validierung=1656)
Architektur: Inputs=98, Hidden Layers=80-40-20, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.4, BitFail-Limit=0.35
Aktivierungen: Hidden=SIGMOID, Steilheit=1.2, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_heatpump_active_pv
Zufallsgenerator: Mode=2, Periode=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 4299 (von max. 15000)
Training MSE: 0.000766
Validation MSE: 0.002285
Validation MSE Average: 0.002364
Validation MSE Standard Deviation: 0.000062
Validation Bit_Fail: 0
Model Bias: 19 Wh
Model Slope: 0.9
Trainingsbewertung: Retrain

=== Fehlermaße der Prognosen ===

MAE: 149.74 Wh
MedAE: 41.16 Wh
RMSE: 206.60 Wh
RMSE relative: 63 %
RMSE Rating: acceptable
MAPE: 16.47 %
MdAPE: 9.79 %
R²: 0.90

=== Rauschen ===

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

=== Drift-Kennzahlen ===

Drift Score: 2.00
Drift RMSE ratio: 2.07
Drift Slope: 0.168
Drift Bias: 0.66
Drift Bewertung: none

#6

Heizungssteuerung/Raumklima / Aw: VALVES und die Fritz DECT ...

Letzter Beitrag von JoWiemann - 26 Januar 2026, 06:34:41

Hallo Martin,

wenn Du Dein Script zur Verfügung stellst, dann kann ich das in das FritzBox Modul einbauen.

Grüße Jörg

#7

Sonstige Systeme / Aw: fhempy: tuya (lokal)

Letzter Beitrag von Prof. Dr. Peter Henning - 26 Januar 2026, 05:36:23

Ich bin gerade geplättet.

Nachdem ich gestern _einen_ der neuen Datenpunkte (mit der id 101) manuell hinzugefügt habe, ging erstmal gar nichts mehr. Also habe ich etwas gemacht, das eigentlich für mich ein No-Go ist: Das Device gelöscht, und erneut einen scan des fhempy durchführen lassen.

Und siehe da: Das automatisch erstellte Device kennt sage und schreibe 30 (!) neue Datenpunkte mit den ids 101 - 130, alle set-Befehle sind komplett vorhanden.

Entweder hat der Hersteller in den letzten 24 Stunden irgendetwas am Cloud-Zugang geändert - unwahrscheinlich.
Oder ich habe mit meinem "Aufmachen" des Datenpunktes 101 irgendetwas angetriggert, das fhempy dazu gebracht hat, diese Datenpunkte zu erkennen.

Ich muss heute erstmal testen, ob auch alles funktioniert.

LG

pah

#8

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

Letzter Beitrag von Prof. Dr. Peter Henning - 26 Januar 2026, 05:25:30

Ich bin etwas verwirrt, worüber hier eigentlich geschrieben wird.

- Ist das nun ein Bug im Soundtouch-FHEM-Modul, oder bezieht sich das auf eines der Projekte zum Ersatz der BOSE-Server?

- Welches Frontend ist gemeint, in dem eine Box "hinzugefügt" wurde, und warum soll es unfertig sein?

- Wieso sollte man überhaupt ein Frontend für den soundcork-Server etc. bauen, wenn man FHEM als Frontend nutzen kann?

Bitte an die Ersteller der jeweiligen Posts: Klar schreiben, worauf sich das bezieht.

LG

pah

[Revision 30783: 76_SolarForecast: Version 2.0.0 with AI::FANN integration]

#9

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

Letzter Beitrag von System - 26 Januar 2026, 00:40:48

Revision 30783: 76_SolarForecast: Version 2.0.0 with AI::FANN integration

76_SolarForecast: Version 2.0.0 with AI::FANN integration

Source: Revision 30783: 76_SolarForecast: Version 2.0.0 with AI::FANN integration

#10

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

Letzter Beitrag von FlatTV - 26 Januar 2026, 00:14:18

Jetzt muss ich doch mal einen Bug im Modul melden.
Wenn ich über das Webinterface die Source ändern möchte, wird statt der Source ,,AUX" der Wert 41 übergeben, das ist aber der Wert für Volume.
Im List des Device kann man das gut sehen.
Die Variable switchSource im helper hätte eigentlich auf ,,AUX" stehen müssen.

Code Auswählen Erweitern

...
     2026-01-25 21:55:23   source          STANDBY
     2026-01-25 21:55:23   state           online
     2026-01-25 21:55:22   stationName     
     2024-03-17 10:32:44   supportClockDisplay true
     2026-01-18 11:48:16   time           
     2026-01-18 10:34:43   timeTotal       
     2026-01-25 21:55:22   track           
     2026-01-25 21:26:10   volume          41
     2026-01-17 21:29:21   zoneMaster     
     2026-01-17 21:29:21   zoneMember_1   
     2026-01-17 21:28:45   zoneMember_2   
   helper:
     IP         192.168.178.30
     airplaySupport 1
     auxSupport 1
     bluetoothSupport 1
     bosewebsocket e9c1a814be06c06dd686aea2a587c63b
     dlnaServers NAS,pi4:_minidlna,FRITZ
     lastSpokenChannel
     mojoping   71de26af285a1452d8ebe6e6f1d46f17
     productHdmi1Support 0
     productTvSupport 0
     requestId  1
     sent_off   1
     sent_on    0
     supportedBassCmds
     supportedSourcesCmds aux,airplay,bluetooth,bt-discover
     switchSource 41
     wsconnected 1
     sources:
       HASH(0x55b2514e48)
       HASH(0x55bb1b1a98)
       HASH(0x55bb1b0ee0)
       HASH(0x55bb1be6f0)
       HASH(0x55bb1be240)
       HASH(0x55bb1baca0)
       HASH(0x55bb1a3158)
       HASH(0x55bb21cd00)
       HASH(0x55bb1b1948)
       HASH(0x55ba9c4760)
       HASH(0x55bb18f528)
       HASH(0x55bafa2428)
       HASH(0x55bb1b17b0)
       HASH(0x55bb1b18d0)
       HASH(0x55bb0f9520)
     stateCheck:...