CW000D,022D,0307,04D3,0591,063D,0704,0832,0D21,0E6B,0FF6,1057,1143,1200,1323,14B9,1531,1700,1818,1914,1B07,1C00,1D90,23E9,242A,2500,2611,3D00,3E00,4045,4162,4249,436E,4473,4574,4661,4774Zitat von: DS_Starter am 11 Mai 2026, 18:53:08Oh das arme NN![]()
Aber deine Batterien sehen jetzt einwandfrei aus oder?
ZitatB:
Parameter anpassen
Learning Rate=0.002, Momentum=0.5, BitFail-Limit=0.30
Zitat von: elektron-bbs am 11 Mai 2026, 14:32:06Mir ist jetzt doch noch etwas aufgefallen: Bei einer FRITZ!Box 7590 und einer FRITZ!Box Fon WLAN 7390 werden die Readings "box_ppp_.*" nicht mehr aktualisiert.

$HMConfig::culHmModel{"F314"} = {name => "HB-UNI-Sen-DUST",st=>'custom',cyc=>'',rxt=>'c',lst=>'1',chn=>"Values:1:1"};
$HMConfig::culHmChanSets{"HB-UNI-Sen-DUST00"}{fwUpdate} = "<filename>";
$HMConfig::culHmChanSets{"HB-UNI-Sen-DUST01"} = $HMConfig::culHmSubTypeSets{"Values"};
$HMConfig::culHmRegChan {"HB-UNI-Sen-DUST01"} = $HMConfig::culHmRegType{values};
$customMsg{"HB-UNI-Sen-DUST"} = sub {
my ($msg, $hash) = @_;
my @evtEt=();
main::Log 1,"HB-UNI-Sen-DUST Executed";
if( $msg->isValues ) {
my $pm25_avg = $msg->payloadWord(0) / 10;
my $pm10_avg = $msg->payloadWord(2) / 10;
my $pm25_max = $msg->payloadWord(4) / 10;
my $pm10_max = $msg->payloadWord(6) / 10;
my $pm25_min = $msg->payloadWord(8) / 10;
my $pm10_min = $msg->payloadWord(10) / 10;
my $device = main::CUL_HM_id2Hash($msg->from);
push @evtEt,[$device,1,"pm10_min:".$pm10_min];
push @evtEt,[$device,1,"pm10_avg:".$pm10_avg];
push @evtEt,[$device,1,"pm10_max:".$pm10_max];
push @evtEt,[$device,1,"pm25_min:".$pm25_min];
push @evtEt,[$device,1,"pm25_avg:".$pm25_avg];
push @evtEt,[$device,1,"pm25_max:".$pm25_max];
}
return @evtEt;
};2:pm25_avg:10 2:pm10_avg:10 2:pm25_max:10 2:pm10_max:10 2:pm25_min:10 2:pm10_min:10 Zitatmir ist aufgefallen das @grappa24 auch die gleiche Meldung in den Hinweisen stehen hat:Nein, das ist ein Schutzmechanismus.
Wäre es möglich das da ein Bug ist ?
....
Drift Bewertung: recalibration blocked: rmse_anomaly !!!!!dieses hier !!!!!
Normalbetrieb: rmse_rel_ratio ≈ 1.8 → kein Block
Starke Peaks: Limit steigt auf ~5.0 → kein Block
rmse_anomaly: rmse_rel_ratio > 4.5 bei ruhigem Fenster
→ Messfehler, Sensor-Ausfall, API-AnomalieWinter ref_rmse: 12%
Frühjahr live: 19%
→ ratio = 1.58 → kein Problem
Aber wenn ref_rmse aus einem sehr ruhigen Zeitraum stammt:
ref_rmse: 8% → ratio = 19/8 = 2.37 → näher an der Grenze
peak_ratio bleibt niedrig (kein PV-Peak)
sem_ratio bleibt niedrig (Schwelle 0.5 * mae_model)
→ dynamisches Limit steigt kaum
→ rmse_anomaly feuert obwohl es echter Verhaltensänderung ist