- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#1
Automatisierung / LightScene: Tooltip statt [ARR...
Letzter Beitrag von Icinger - 07 Dezember 2025, 08:22:09Hallo,
Wenn man mit lightSceneParamstoSave nutzt, erscheint in der HTML-Übersicht immer ein "[ARRAY........]" statt dem auszuführenden Befehl.
Dieser Diff ersetzt dieses [ARRAY...] durch ein "[..]" und zusätzlich einem Tooltip mit den gespeicherten Parameteren dazu.
lg, Stefan
Wenn man mit lightSceneParamstoSave nutzt, erscheint in der HTML-Übersicht immer ein "[ARRAY........]" statt dem auszuführenden Befehl.
Dieser Diff ersetzt dieses [ARRAY...] durch ein "[..]" und zusätzlich einem Tooltip mit den gespeicherten Parameteren dazu.
Code Auswählen
164a165,170
> if(ref($state) eq 'ARRAY') {
> my $dumper = Data::Dumper->new([]);
> $dumper->Terse(1);
> $dumper->Values([$state]);
> $state= $dumper->Dump;
> }
178c184
< $ret .= "<td><div>". $state ."</div></td>";
---
> $ret .= "<td><div title=\"".$state."\">". "[..]" ."</div></td>";lg, Stefan
#2
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von klaus.schauer - 07 Dezember 2025, 08:05:36Zitat von: DS_Starter am 05 Dezember 2025, 21:03:59Hallo klaus.schauer,Ich verwende die gleiche Quelle, gebe aber noch den Zeitraum mit: https://api.energy-charts.info/price?country=DE-LU&start=<todayDate>&end=<tomorrowDate>. Beide Varianten liefern wohl die gleichen Ergebnisse.ZitatDie EPEX Spot Day-Ahead Preise werden täglich abgerufen und für den aktuellen Tag und den Folgetag in Internals gespeichert, um diese in Prognoseverfahren ggf. zu berücksichtigen.Die Abrufroutinen kannst du gern mitteilen. Den Börsenpreis hatte ich vor über https://api.energy-charts.info/price?bzn=DE-LU zu implementieren. Die Alternativen würde ich vergleichen.ZitatAugenblickich hole ich mir die Prognosen zur Windgeschwindigkeit über das Modul DWD_OpenData. Könnte man die stündlichen Prognosen zur Windgeschwindigkeit (FF-Werte) auch intern in inSolarForecast (valCurrent, nextHours) zusätzlich zur Temperatur ablegen?Wenn diese Werte hilfreich sind, nehme ich sie mit auf. Das ist kein Problem.
Falls Du die Windgeschwindigkeit (FF-Werte) mit einbauen würdest, würde ich meine Routinen entsprechend anpassen und dann hier als kompletten Satz zur Verfügung stellen. Ist ja nicht so eilig.
#3
FHEM Code changes / Revision 30592: controls_fhem....
Letzter Beitrag von System - 07 Dezember 2025, 07:51:07Revision 30592: controls_fhem.txt: fhemupdate checkin
controls_fhem.txt: fhemupdate checkin
Source: Revision 30592: controls_fhem.txt: fhemupdate checkin
controls_fhem.txt: fhemupdate checkin
Source: Revision 30592: controls_fhem.txt: fhemupdate checkin
#4
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von klaus.schauer - 07 Dezember 2025, 07:46:35Zitat von: DS_Starter am 06 Dezember 2025, 22:45:59ein wichtiger Schritt in Richtung eines funktionierenden neuronalen Netz für die Verbrauchsvorhersage ist getan.Dies gilt sicherlich auch für die Prognosen bei Raumheizungen. Neben dem deterministisch berechneten Energiebedarf / h und dem tatsächlichen Wert wären wahrscheinlich auch die Eingangsgrößen der Berechnung und ggf. auch die Sonneneinstrahlung hilfreich. Um dies zu beurteilen, fehlt mir allerdings die Kenntnis.
Mit AI::FANN habe ich ein solches Netz implementiert.
Edit: Während der Beschätigung mit dem NN ist mir klar geworden, dass man für ein gutes Training (z.B. die Prognose wann ein EV geladen werden könnte) der KI Features bereitstellen muß/sollte, die einen Bezug zu diesem Event herstellen. Ein bestimmter Tag oder ähnliche Zeitindikatoren sind zu schwach und haben keinen wirklichen Bezug. Ein starker Indikator könnte der Ladezustand der EV-Batterie sein.
#5
Sonstiges / Aw: Ecowitt API - diverse Wett...
Letzter Beitrag von Dr. Boris Neubert - 06 Dezember 2025, 23:39:54So, das Ding läuft im IoT-Netzwerk mit dem Modul GW1000_TCP. 
MQTT ist aktiviert, verbindet sich auch alle 8 Sekunden mit FHEM, schickt aber keine Sensor-Daten (MQTT over TCP ist eingestellt). Geprüft mit verbose 5 am MQTT2_SERVER in FHEM und MQTT Explorer. @Beta-User: wie hast Du es hinbekommen, dass dein Gateway Sensor-Daten per MQTT sendet?
GW1000_TCP zeigt nicht alle Sensor-Daten an, die der Wittboy über das GW2000X in Live Data anzeigt. Es fehlen:
Wie muss ich das Modul anpassen, um diese Werte als Readings zu sehen?
Es gibt ein Reading namens Light. Ich vermute, dass das die Solar Irradiance ist, nur in anderen Einheiten. Tabelle (Arbeitszimmerlampe bei Nacht / bessere Werte ein anderes Mal bei Tag und draußen):
Light | Solar Irradiance / W/m^2 | Umrechnungsfaktor
1100.0 | 0.87 | 0.00079091
500.0 | 0.39 | 0.00078
400.0 | 0.32 | 0.0008
300.0 | 0.24 | 0.0008
Außerdem wird regelmäßig das Reading Unknown_SensorID aktualisiert. Was bedeutet das?
Das Attribut updateInterval sollte nur ein l (ell) am Ende haben.
Modul sollte einfach Ecowitt heißen. Ich würde mich freuen, wenn Du es offiziell eincheckst!
Herzlichen Dank für Deine Arbeit.
Viele Grüße
Boris
MQTT ist aktiviert, verbindet sich auch alle 8 Sekunden mit FHEM, schickt aber keine Sensor-Daten (MQTT over TCP ist eingestellt). Geprüft mit verbose 5 am MQTT2_SERVER in FHEM und MQTT Explorer. @Beta-User: wie hast Du es hinbekommen, dass dein Gateway Sensor-Daten per MQTT sendet?
GW1000_TCP zeigt nicht alle Sensor-Daten an, die der Wittboy über das GW2000X in Live Data anzeigt. Es fehlen:
- Feels like (gefühlte Temperatur), in °C
- VPD (Vapor Pressure Deficit = Dampfdruckdefizit) in kPa (im Internet nachlesen)
- Dew point (Taupunkt), in °C
- Rain 24Hours (Niederschlag in den letzten 24 Stunden), in mm (nicht zu verwechseln mit Rain Day)
- Solar Irradiance (Sonneneinstrahlung), in W/m^2
- 10Min.Avg Wind Direction (durchschnittliche Windrichtung in den letzten 10 Minuten), in °
Wie muss ich das Modul anpassen, um diese Werte als Readings zu sehen?
Es gibt ein Reading namens Light. Ich vermute, dass das die Solar Irradiance ist, nur in anderen Einheiten. Tabelle (Arbeitszimmerlampe bei Nacht / bessere Werte ein anderes Mal bei Tag und draußen):
Light | Solar Irradiance / W/m^2 | Umrechnungsfaktor
1100.0 | 0.87 | 0.00079091
500.0 | 0.39 | 0.00078
400.0 | 0.32 | 0.0008
300.0 | 0.24 | 0.0008
Außerdem wird regelmäßig das Reading Unknown_SensorID aktualisiert. Was bedeutet das?
Das Attribut updateInterval sollte nur ein l (ell) am Ende haben.
Modul sollte einfach Ecowitt heißen. Ich würde mich freuen, wenn Du es offiziell eincheckst!
Herzlichen Dank für Deine Arbeit.
Viele Grüße
Boris
#6
FHEM Code changes / Revision 30591: 76_SolarForeca...
Letzter Beitrag von System - 06 Dezember 2025, 22:50:53Revision 30591: 76_SolarForecast: contrib Version 2.0.0
76_SolarForecast: contrib Version 2.0.0
Source: Revision 30591: 76_SolarForecast: contrib Version 2.0.0
76_SolarForecast: contrib Version 2.0.0
Source: Revision 30591: 76_SolarForecast: contrib Version 2.0.0
#7
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 06 Dezember 2025, 22:45:59Hallo zusammen,
ein wichtiger Schritt in Richtung eines funktionierenden neuronalen Netz für die Verbrauchsvorhersage ist getan.
Mit AI::FANN habe ich ein solches Netz implementiert.
Die Version 2.0.0 befindet sich für interessierte User im contrib. Die Version kann produktiv eingesetzt werden. Das neuronale Netz hat noch keine Auswirkung auf verwendete Verbrauchsprognosen und kann autark getestet werden.
Zur Vorbereitung muß man die FANN (Fast Artificial Neural Network) Library auf dem FHEM Server installieren. Das geht in Linux einfach mit:
Für Windows gibt es auch Verfahren. Dazu im Netz einfach mal suchen falls es relevant ist.
Danach muß man noch das Perl Modul AI::FANN installieren. Das geht in FHEM direkt mit dem FHEM Installer Modul bzw. einem solchen Device, oder mit:
Um zu testen, trainiert man sein Model zunächst manuell mit:
Damit man im Log das Training verfolgen kann, setzt man ctrlDebug=aiProcess. Im Log gibt es dann Ausschriften wie diese:
Ein erfogreiches Training wird auch in der Grafik signalisiert. Die Qualität des trainierten Netzes und weitere Informationen darüber kann man aufrufen mit:
Man erhält dann eine Übersicht wie nachfolgend die neben den Netz KPI's auch Erläuterungen zu den Kennzahlen liefert und wie diese zu bewerten sind.
Man kann diese Kennzahlen auch sehr gut einer KI seiner Wahl (z.B. MS Copilot) übergeben und sie bewerten lassen.
Wichtiger ist natürlich das reale Ergebnis der Prognose.
Um Prognosewerte zu sehen, schaltet man ctrlDebug=aiData oder ctrlDebug=aiData,aiProcess ein und sieht dann im Log:
Der Wert "consumption forecast" ist die Prognose der KI, Der Wert "legacy value" ist die Prognose von meiner herkömmliche Routine zum Vergleich. Wie gesagt, die Ergebnisse der Verbrauchs-KI werden nur in das Log geschrieben und haben sonst keine Verknüpfung im Modul.
Es gibt eine ganze Reihe von Einstellmöglichkeiten für das Setup des neuronalen Netzes. Ich habe zunächst ein funktionierendes Setup implementiert. Der User kann die Laufparameter aktuell nicht modifizieren. Aber das werde ich bereitstellen in einer der nächsten Schritte.
Wer im Code agieren will, findet die Parameter ab Zeile 21330 bis 21341.
Meine bisherigen Erkenntnisse / Erfahrungen mit AI::FANN sind sehr positiv. Wahrscheinlich werde ich später auch die PV-Prognose darauf umstellen und so AI:DecisionTree mit einer "echten" KI ablösen.
Wer mag, kann nun mit Tests und Ideen mitwirken. Sollte es sich als günstig erweisen, mache ich einen separaten Thread nur für diese NN-Entwicklungsthema auf.
@Wolle02 ... das Thema mit der Circular Bereinigung schaue ich mit die kommenden Tage an.
Edit: Während der Beschätigung mit dem NN ist mir klar geworden, dass man für ein gutes Training (z.B. die Prognose wann ein EV geladen werden könnte) der KI Features bereitstellen muß/sollte, die einen Bezug zu diesem Event herstellen. Ein bestimmter Tag oder ähnliche Zeitindikatoren sind zu schwach und haben keinen wirklichen Bezug. Ein starker Indikator könnte der Ladezustand der EV-Batterie sein. Dazu müsste ich einen solchen Schlüssel für die Definition einen Consumers vom Typ BEV bereitstellen. Vielleicht fallen euch noch weitere Indikatoren ein, die einen Bezug zum Ladeverhalten eines BEV haben und die vom Modul konsumiert werden können.
LG,
Heiko
ein wichtiger Schritt in Richtung eines funktionierenden neuronalen Netz für die Verbrauchsvorhersage ist getan.
Mit AI::FANN habe ich ein solches Netz implementiert.
Die Version 2.0.0 befindet sich für interessierte User im contrib. Die Version kann produktiv eingesetzt werden. Das neuronale Netz hat noch keine Auswirkung auf verwendete Verbrauchsprognosen und kann autark getestet werden.
Zur Vorbereitung muß man die FANN (Fast Artificial Neural Network) Library auf dem FHEM Server installieren. Das geht in Linux einfach mit:
Code Auswählen
suso apt-get update
sudo apt-get install gcc
sudo apt-get install libfann-dev
Für Windows gibt es auch Verfahren. Dazu im Netz einfach mal suchen falls es relevant ist.
Danach muß man noch das Perl Modul AI::FANN installieren. Das geht in FHEM direkt mit dem FHEM Installer Modul bzw. einem solchen Device, oder mit:
Code Auswählen
sudo cpanm AI::FANN (wenn cpanm installiert)
oder:
sudo cpan install AI::FANN
Um zu testen, trainiert man sein Model zunächst manuell mit:
Code Auswählen
set ... aiNeuralNet runConTrain
Damit man im Log das Training verfolgen kann, setzt man ctrlDebug=aiProcess. Im Log gibt es dann Ausschriften wie diese:
Code Auswählen
2025.12.06 21:17:06.591 1: SolCast DEBUG> Neural Netwwork Training for Consumption Forecast BlockingCall PID "326440" with Timeout 86400 s started
2025.12.06 21:17:07.178 1: SolCast DEBUG> Neural Network Training started with Params:
training datasets=6708, hidden Neurons=50,25, Epoches=15000, mse_error=0.001, learning rate=0.01000, learning momentum=0.9, Data sharing=chronological split (Train=5366, Test=1341)
2025.12.06 21:17:07.508 1: SolCast DEBUG> Snapshot saved at epoch 7: Train MSE=0.031000, Val MSE=0.004811, Val Bit_Fail=2
2025.12.06 21:17:07.798 1: SolCast DEBUG> Snapshot saved at epoch 14: Train MSE=0.006000, Val MSE=0.004705, Val Bit_Fail=2
2025.12.06 21:17:07.945 1: SolCast DEBUG> Snapshot saved at epoch 17: Train MSE=0.004000, Val MSE=0.004355, Val Bit_Fail=1
2025.12.06 21:17:08.212 1: SolCast DEBUG> Snapshot saved at epoch 23: Train MSE=0.003000, Val MSE=0.003766, Val Bit_Fail=1
2025.12.06 21:17:08.263 1: SolCast DEBUG> Snapshot saved at epoch 24: Train MSE=0.003000, Val MSE=0.003205, Val Bit_Fail=1
2025.12.06 21:17:08.313 1: SolCast DEBUG> Snapshot saved at epoch 25: Train MSE=0.002000, Val MSE=0.003014, Val Bit_Fail=1
2025.12.06 21:17:08.357 1: SolCast DEBUG> Snapshot saved at epoch 26: Train MSE=0.002000, Val MSE=0.002796, Val Bit_Fail=1
2025.12.06 21:17:08.405 1: SolCast DEBUG> Snapshot saved at epoch 27: Train MSE=0.002000, Val MSE=0.002067, Val Bit_Fail=1
2025.12.06 21:17:09.468 1: SolCast DEBUG> Snapshot saved at epoch 52: Train MSE=0.002000, Val MSE=0.002060, Val Bit_Fail=1
2025.12.06 21:17:09.579 1: SolCast DEBUG> Snapshot saved at epoch 54: Train MSE=0.002000, Val MSE=0.002014, Val Bit_Fail=1
2025.12.06 21:17:09.664 1: SolCast DEBUG> Snapshot saved at epoch 56: Train MSE=0.002000, Val MSE=0.001963, Val Bit_Fail=1
2025.12.06 21:17:09.749 1: SolCast DEBUG> Snapshot saved at epoch 58: Train MSE=0.002000, Val MSE=0.001941, Val Bit_Fail=1
2025.12.06 21:17:09.794 1: SolCast DEBUG> Snapshot saved at epoch 59: Train MSE=0.002000, Val MSE=0.001928, Val Bit_Fail=1
2025.12.06 21:17:09.839 1: SolCast DEBUG> Snapshot saved at epoch 60: Train MSE=0.002000, Val MSE=0.001913, Val Bit_Fail=1
2025.12.06 21:17:09.883 1: SolCast DEBUG> Snapshot saved at epoch 61: Train MSE=0.002000, Val MSE=0.001894, Val Bit_Fail=1
2025.12.06 21:17:09.927 1: SolCast DEBUG> Snapshot saved at epoch 62: Train MSE=0.002000, Val MSE=0.001874, Val Bit_Fail=1
2025.12.06 21:17:09.971 1: SolCast DEBUG> Snapshot saved at epoch 63: Train MSE=0.002000, Val MSE=0.001851, Val Bit_Fail=1
2025.12.06 21:17:10.016 1: SolCast DEBUG> Snapshot saved at epoch 64: Train MSE=0.002000, Val MSE=0.001833, Val Bit_Fail=1
2025.12.06 21:17:10.060 1: SolCast DEBUG> Snapshot saved at epoch 65: Train MSE=0.002000, Val MSE=0.001797, Val Bit_Fail=1
2025.12.06 21:17:10.208 1: SolCast DEBUG> Snapshot saved at epoch 68: Train MSE=0.002000, Val MSE=0.001779, Val Bit_Fail=1
2025.12.06 21:17:10.257 1: SolCast DEBUG> Snapshot saved at epoch 69: Train MSE=0.002000, Val MSE=0.001775, Val Bit_Fail=1
2025.12.06 21:17:10.755 1: SolCast DEBUG> Snapshot saved at epoch 80: Train MSE=0.002000, Val MSE=0.001773, Val Bit_Fail=1
2025.12.06 21:17:10.806 1: SolCast DEBUG> Snapshot saved at epoch 81: Train MSE=0.002000, Val MSE=0.001770, Val Bit_Fail=1
2025.12.06 21:17:10.850 1: SolCast DEBUG> Snapshot saved at epoch 82: Train MSE=0.002000, Val MSE=0.001763, Val Bit_Fail=1
2025.12.06 21:17:10.932 1: SolCast DEBUG> Snapshot saved at epoch 84: Train MSE=0.002000, Val MSE=0.001761, Val Bit_Fail=1
2025.12.06 21:17:10.988 1: SolCast DEBUG> Snapshot saved at epoch 85: Train MSE=0.002000, Val MSE=0.001743, Val Bit_Fail=1
2025.12.06 21:17:11.048 1: SolCast DEBUG> Snapshot saved at epoch 86: Train MSE=0.002000, Val MSE=0.001733, Val Bit_Fail=1
2025.12.06 21:17:11.114 1: SolCast DEBUG> Snapshot saved at epoch 87: Train MSE=0.002000, Val MSE=0.001724, Val Bit_Fail=1
2025.12.06 21:17:11.177 1: SolCast DEBUG> Snapshot saved at epoch 88: Train MSE=0.002000, Val MSE=0.001721, Val Bit_Fail=1
2025.12.06 21:17:11.823 1: SolCast DEBUG> Epoche 100: Train MSE=0.002181, Val MSE=0.001893 .... Bit_Fail=5
2025.12.06 21:17:12.637 1: SolCast DEBUG> Snapshot saved at epoch 118: Train MSE=0.002000, Val MSE=0.001715, Val Bit_Fail=1
2025.12.06 21:17:12.735 1: SolCast DEBUG> Snapshot saved at epoch 120: Train MSE=0.001000, Val MSE=0.001700, Val Bit_Fail=1
2025.12.06 21:17:13.883 1: SolCast DEBUG> Snapshot saved at epoch 141: Train MSE=0.001000, Val MSE=0.001688, Val Bit_Fail=1
2025.12.06 21:17:16.929 1: SolCast DEBUG> Epoche 200: Train MSE=0.001378, Val MSE=0.001940 .... Bit_Fail=5
2025.12.06 21:17:18.804 1: SolCast DEBUG> Snapshot saved at epoch 245: Train MSE=0.001000, Val MSE=0.001684, Val Bit_Fail=1
2025.12.06 21:17:18.861 1: SolCast DEBUG> Snapshot saved at epoch 246: Train MSE=0.001000, Val MSE=0.001665, Val Bit_Fail=1
2025.12.06 21:17:21.091 1: SolCast DEBUG> Epoche 300: Train MSE=0.002070, Val MSE=0.002599 .... Bit_Fail=6
2025.12.06 21:17:25.428 1: SolCast DEBUG> Epoche 400: Train MSE=0.001600, Val MSE=0.001980 .... Bit_Fail=5
2025.12.06 21:17:29.813 1: SolCast DEBUG> Epoche 500: Train MSE=0.035005, Val MSE=0.002786 .... Bit_Fail=8
2025.12.06 21:17:34.323 1: SolCast DEBUG> Epoche 600: Train MSE=0.002071, Val MSE=0.004351 .... Bit_Fail=7
2025.12.06 21:17:38.761 1: SolCast DEBUG> Epoche 700: Train MSE=0.007921, Val MSE=0.032519 .... Bit_Fail=27
2025.12.06 21:17:43.032 1: SolCast DEBUG> Epoche 800: Train MSE=0.002365, Val MSE=0.002768 .... Bit_Fail=9
2025.12.06 21:17:47.946 1: SolCast DEBUG> Epoche 900: Train MSE=0.002002, Val MSE=0.002659 .... Bit_Fail=6
2025.12.06 21:17:52.370 1: SolCast DEBUG> Epoche 1000: Train MSE=8.918653, Val MSE=0.005512 .... Bit_Fail=53
2025.12.06 21:17:57.315 1: SolCast DEBUG> Epoche 1100: Train MSE=0.004355, Val MSE=430.838212 .... Bit_Fail=18
2025.12.06 21:18:01.664 1: SolCast DEBUG> Epoche 1200: Train MSE=0.018462, Val MSE=140.060431 .... Bit_Fail=14
2025.12.06 21:18:06.528 1: SolCast DEBUG> Epoche 1300: Train MSE=0.221598, Val MSE=249.383456 .... Bit_Fail=22
2025.12.06 21:18:11.177 1: SolCast DEBUG> Epoche 1400: Train MSE=0.041970, Val MSE=594.477068 .... Bit_Fail=30
2025.12.06 21:18:15.624 1: SolCast DEBUG> Epoche 1500: Train MSE=0.058910, Val MSE=617.049691 .... Bit_Fail=27
2025.12.06 21:18:20.262 1: SolCast DEBUG> Epoche 1600: Train MSE=0.008360, Val MSE=885.589472 .... Bit_Fail=31
2025.12.06 21:18:25.160 1: SolCast DEBUG> Epoche 1700: Train MSE=0.006807, Val MSE=885.227558 .... Bit_Fail=29
2025.12.06 21:18:29.893 1: SolCast DEBUG> Epoche 1800: Train MSE=2.663923, Val MSE=915.590333 .... Bit_Fail=27
2025.12.06 21:18:34.462 1: SolCast DEBUG> Epoche 1900: Train MSE=0.212181, Val MSE=856.785082 .... Bit_Fail=22
2025.12.06 21:18:39.078 1: SolCast DEBUG> Epoche 2000: Train MSE=0.583634, Val MSE=442.416236 .... Bit_Fail=15
2025.12.06 21:18:43.662 1: SolCast DEBUG> Epoche 2100: Train MSE=0.032788, Val MSE=316.984446 .... Bit_Fail=16
2025.12.06 21:18:48.307 1: SolCast DEBUG> Epoche 2200: Train MSE=0.041520, Val MSE=295.451476 .... Bit_Fail=16
2025.12.06 21:18:52.693 1: SolCast DEBUG> Epoche 2300: Train MSE=0.016586, Val MSE=295.108131 .... Bit_Fail=16
2025.12.06 21:18:57.509 1: SolCast DEBUG> Epoche 2400: Train MSE=0.021561, Val MSE=294.800016 .... Bit_Fail=17
2025.12.06 21:19:01.984 1: SolCast DEBUG> Epoche 2500: Train MSE=0.006636, Val MSE=294.777228 .... Bit_Fail=16
2025.12.06 21:19:06.662 1: SolCast DEBUG> Epoche 2600: Train MSE=0.005158, Val MSE=294.522419 .... Bit_Fail=15
2025.12.06 21:19:11.179 1: SolCast DEBUG> Epoche 2700: Train MSE=0.020796, Val MSE=0.025932 .... Bit_Fail=28
2025.12.06 21:19:16.013 1: SolCast DEBUG> Epoche 2800: Train MSE=0.049026, Val MSE=440.109527 .... Bit_Fail=40
2025.12.06 21:19:20.479 1: SolCast DEBUG> Epoche 2900: Train MSE=0.018596, Val MSE=13.773080 .... Bit_Fail=33
2025.12.06 21:19:24.982 1: SolCast DEBUG> Epoche 3000: Train MSE=47.658855, Val MSE=87.796865 .... Bit_Fail=611
2025.12.06 21:19:29.964 1: SolCast DEBUG> Epoche 3100: Train MSE=18.301807, Val MSE=15.492119 .... Bit_Fail=184
2025.12.06 21:19:35.284 1: SolCast DEBUG> Epoche 3200: Train MSE=11.717161, Val MSE=1.571558 .... Bit_Fail=140
2025.12.06 21:19:37.457 1: SolCast DEBUG> Early stopping bei Epoche 3246: Validation MSE=18.081247 (no improvement since 3000 epochs)
2025.12.06 21:19:37.460 1: SolCast DEBUG> Best Forecast Model reloaded with Train MSE=0.001000
2025.12.06 21:19:37.462 1: SolCast DEBUG> Run Validation Test with 20% of Input data ...
2025.12.06 21:19:37.476 1: SolCast DEBUG> Validation finished - Best Training MSE=0.001000, Validation MSE=0.002000, Validation Bit_Fail=1
2025.12.06 21:19:37.480 1: SolCast DEBUG> Neural Netwwork training data successfuly written to file: ./FHEM/FhemUtils/NeuralNet_SolarForecast_SolCast
2025.12.06 21:19:37.653 1: SolCast DEBUG> Neural Netwwork Training BlockingCall PID '326440' finished, state: ok
Ein erfogreiches Training wird auch in der Grafik signalisiert. Die Qualität des trainierten Netzes und weitere Informationen darüber kann man aufrufen mit:
Code Auswählen
get ... valDecTree aiNeuralNetConState
Man erhält dann eine Übersicht wie nachfolgend die neben den Netz KPI's auch Erläuterungen zu den Kennzahlen liefert und wie diese zu bewerten sind.
Code Auswählen
Informationen zum neuronalen Netz der Verbrauchsvorhersage
letztes KI-Training: 06.12.2025 21:36:40 / Laufzeit in Sekunden: 88.63
letzte KI-Ergebnis Generierungsdauer: 0.02 ms
=== Modellparameter ===
Trainingsdaten: 7344 (Training=5875, Validierung=1469)
Architektur: Inputs=16, Hidden Layers=50-25, Outputs=1
Hyperparameter: LR=0.010, Momentum=0.9, BitFail-Limit=0.35
Aktivierungen: Hidden=Sigmoid, Output=Linear
=== Trainingsmetriken ===
bestes Modell bei Epoche: 61 (von max. 15000)
Training MSE: 0.001
Validation MSE: 0.002
Validation Bit_Fail: 3
=== Fehlermaße der Prognosen ===
MAE: 219.36 Wh
MedAE: 120.61 Wh
RMSE: 0.042
MAPE: 26.838 %
MdAPE: 19.028 %
R²: 0.157
Erläuterung der Kennzahlen
Train MSE / Validation MSE → wie gut das Netz trainiert und generalisiert. Daumenregel:
MSE < 0.01 → sehr gut
MSE 0.01–0.05 → brauchbar
MSE > 0.1 → schwach
Interpretation Verhältnis Train MSE zu Validation MSE:
Validation ≈ Train → gute Generalisierung
Validation deutlich größer → Überfitting
Validation kleiner → Validierungsdaten sind einfacher oder Split begünstigt
Validation Bit_Fail → Anzahl der Ausreißer
MAE (Mean Absolute Error) → mittlere absolute Abweichung in Wh. Richtwerte bei typischem Verbrauch 500–1500 Wh:
< 100 Wh → sehr gut
100–300 Wh → brauchbar
> 300 Wh → schwach
MedAE (Median Absolute Error) → Median der absoluten Fehler in Wh (toleriert einzelne Ausreißer besser)
< 100 Wh → sehr gut
100–200 Wh → gut
200–300 Wh → mittelmäßig
> 300 Wh → schwach
RMSE (Root Mean Squared Error) → mittlere quadratische Abweichung in Wh
Interpretation: wie groß Fehler im Mittel sind, mit Betonung auf Ausreißer
Richtwerte:
< 0.01 → sehr gut
0.01–0.03 → gut
0.03–0.05 → mittelmäßig / akzeptabel
> 0.05 → schwach
MAPE (Mean Absolute Percentage Error) → relative Abweichung in %
Richtwerte:
< 10 % → sehr gut - Modell liegt fast immer sehr nah an den echten Werten
10–20 % → gut - Prognosen sind solide, kleine Abweichungen sind normal
20–30 % → mittelmäßig / akzeptabel - Modell ist brauchbar, aber nicht präzise – für grobe Trends ok
> 30 % → schwach - Modell verfehlt die Werte deutlich, oft durch Ausreißer oder fehlende Features
⚠️ Vorsicht: bei kleinen Werten (<200 Wh) kann MAPE stark verzerren → MdAPE heranziehen
MdAPE (Median Absolute Percentage Error) → Median der prozentualen Fehler in % (robuster gegenüber kleinen Werten)
Richtwerte:
< 10 % → sehr gut
10–20 % → gut
20–30 % → mittelmäßig
> 30 % → schwach
R² (Bestimmtheitsmaß) → Maß für die Erklärungskraft des Modells. Je näher R² an 1 liegt, desto besser.
R² = 1.0 → perfekte Vorhersage, alle Punkte liegen exakt auf der Regressionslinie
R² > 0.8 → sehr gut - Modell erfasst den Großteil der Streuung → sehr zuverlässige Prognosen
R² = 0.6 – 0.8 → brauchbar - Modell erklärt einen soliden Teil der Varianz → brauchbar für viele Anwendungen
R² = 0.5–0.6 → mäßig / grenzwertig - Modell liegt knapp über ,,zufällig" → Muster erkannt, Prognosen nur eingeschränkt nützlich
R² < 0.5 → schwach - Modell erklärt weniger als die Hälfte der Varianz → deutlicher Verbesserungsbedarf
R² = 0.0 → Modell erklärt gar nichts, es ist nicht besser als der Mittelwert der Daten
R² < 0.0 → Modell ist schlechter als einfach immer den Mittelwert vorherzusagen
⚠️ R² ist sehr empfindlich gegenüber Ausreißern und Varianz in den Daten.
Man kann diese Kennzahlen auch sehr gut einer KI seiner Wahl (z.B. MS Copilot) übergeben und sie bewerten lassen.
Wichtiger ist natürlich das reale Ergebnis der Prognose.
Um Prognosewerte zu sehen, schaltet man ctrlDebug=aiData oder ctrlDebug=aiData,aiProcess ein und sieht dann im Log:
Code Auswählen
2025.12.06 22:32:58.313 1: SolCast DEBUG> Neural Network - hod: 23 -> consumption forecast: 702 Wh, legacy value: 652
2025.12.06 22:32:58.313 1: SolCast DEBUG> Neural Network - hod: 24 -> consumption forecast: 684 Wh, legacy value: 614
2025.12.06 22:32:58.313 1: SolCast DEBUG> Neural Network - hod: 1 -> consumption forecast: 562 Wh, legacy value: 556
2025.12.06 22:32:58.314 1: SolCast DEBUG> Neural Network - hod: 2 -> consumption forecast: 564 Wh, legacy value: 493
2025.12.06 22:32:58.314 1: SolCast DEBUG> Neural Network - hod: 3 -> consumption forecast: 547 Wh, legacy value: 470
2025.12.06 22:32:58.314 1: SolCast DEBUG> Neural Network - hod: 4 -> consumption forecast: 539 Wh, legacy value: 469
2025.12.06 22:32:58.315 1: SolCast DEBUG> Neural Network - hod: 5 -> consumption forecast: 595 Wh, legacy value: 480
2025.12.06 22:32:58.315 1: SolCast DEBUG> Neural Network - hod: 6 -> consumption forecast: 643 Wh, legacy value: 512
2025.12.06 22:32:58.316 1: SolCast DEBUG> Neural Network - hod: 7 -> consumption forecast: 699 Wh, legacy value: 528
2025.12.06 22:32:58.316 1: SolCast DEBUG> Neural Network - hod: 8 -> consumption forecast: 760 Wh, legacy value: 884
2025.12.06 22:32:58.316 1: SolCast DEBUG> Neural Network - hod: 9 -> consumption forecast: 830 Wh, legacy value: 730
2025.12.06 22:32:58.317 1: SolCast DEBUG> Neural Network - hod: 10 -> consumption forecast: 800 Wh, legacy value: 861
2025.12.06 22:32:58.317 1: SolCast DEBUG> Neural Network - hod: 11 -> consumption forecast: 984 Wh, legacy value: 1112
2025.12.06 22:32:58.317 1: SolCast DEBUG> Neural Network - hod: 12 -> consumption forecast: 1099 Wh, legacy value: 818
2025.12.06 22:32:58.318 1: SolCast DEBUG> Neural Network - hod: 13 -> consumption forecast: 1042 Wh, legacy value: 840
2025.12.06 22:32:58.318 1: SolCast DEBUG> Neural Network - hod: 14 -> consumption forecast: 913 Wh, legacy value: 812
2025.12.06 22:32:58.318 1: SolCast DEBUG> Neural Network - hod: 15 -> consumption forecast: 849 Wh, legacy value: 623
2025.12.06 22:32:58.319 1: SolCast DEBUG> Neural Network - hod: 16 -> consumption forecast: 801 Wh, legacy value: 834
2025.12.06 22:32:58.319 1: SolCast DEBUG> Neural Network - hod: 17 -> consumption forecast: 758 Wh, legacy value: 590
2025.12.06 22:32:58.319 1: SolCast DEBUG> Neural Network - hod: 18 -> consumption forecast: 881 Wh, legacy value: 699
2025.12.06 22:32:58.320 1: SolCast DEBUG> Neural Network - hod: 19 -> consumption forecast: 839 Wh, legacy value: 622
2025.12.06 22:32:58.320 1: SolCast DEBUG> Neural Network - hod: 20 -> consumption forecast: 796 Wh, legacy value: 653
2025.12.06 22:32:58.320 1: SolCast DEBUG> Neural Network - hod: 21 -> consumption forecast: 759 Wh, legacy value: 688
2025.12.06 22:32:58.321 1: SolCast DEBUG> Neural Network - hod: 22 -> consumption forecast: 729 Wh, legacy value: 666
2025.12.06 22:32:58.321 1: SolCast DEBUG> Neural Network - hod: 23 -> consumption forecast: 705 Wh, legacy value: 652
2025.12.06 22:32:58.321 1: SolCast DEBUG> Neural Network - hod: 24 -> consumption forecast: 689 Wh, legacy value: 614
2025.12.06 22:32:58.322 1: SolCast DEBUG> Neural Network - hod: 1 -> consumption forecast: 583 Wh, legacy value: 556
2025.12.06 22:32:58.322 1: SolCast DEBUG> Neural Network - hod: 2 -> consumption forecast: 574 Wh, legacy value: 493
2025.12.06 22:32:58.323 1: SolCast DEBUG> Neural Network - hod: 3 -> consumption forecast: 574 Wh, legacy value: 470
2025.12.06 22:32:58.323 1: SolCast DEBUG> Neural Network - hod: 4 -> consumption forecast: 585 Wh, legacy value: 469
2025.12.06 22:32:58.323 1: SolCast DEBUG> Neural Network - hod: 5 -> consumption forecast: 610 Wh, legacy value: 480
2025.12.06 22:32:58.324 1: SolCast DEBUG> Neural Network - hod: 6 -> consumption forecast: 648 Wh, legacy value: 512
2025.12.06 22:32:58.324 1: SolCast DEBUG> Neural Network - hod: 7 -> consumption forecast: 699 Wh, legacy value: 528
2025.12.06 22:32:58.324 1: SolCast DEBUG> Neural Network - hod: 8 -> consumption forecast: 757 Wh, legacy value: 884
2025.12.06 22:32:58.325 1: SolCast DEBUG> Neural Network - hod: 9 -> consumption forecast: 829 Wh, legacy value: 730
2025.12.06 22:32:58.325 1: SolCast DEBUG> Neural Network - hod: 10 -> consumption forecast: 796 Wh, legacy value: 861
2025.12.06 22:32:58.325 1: SolCast DEBUG> Neural Network - hod: 11 -> consumption forecast: 991 Wh, legacy value: 1112
2025.12.06 22:32:58.326 1: SolCast DEBUG> Neural Network - hod: 12 -> consumption forecast: 1095 Wh, legacy value: 818
2025.12.06 22:32:58.326 1: SolCast DEBUG> Neural Network - hod: 13 -> consumption forecast: 1041 Wh, legacy value: 840
2025.12.06 22:32:58.326 1: SolCast DEBUG> Neural Network - hod: 14 -> consumption forecast: 880 Wh, legacy value: 812
2025.12.06 22:32:58.327 1: SolCast DEBUG> Neural Network - hod: 15 -> consumption forecast: 844 Wh, legacy value: 623
2025.12.06 22:32:58.327 1: SolCast DEBUG> Neural Network - hod: 16 -> consumption forecast: 796 Wh, legacy value: 834
2025.12.06 22:32:58.328 1: SolCast DEBUG> Neural Network - hod: 17 -> consumption forecast: 756 Wh, legacy value: 590
2025.12.06 22:32:58.328 1: SolCast DEBUG> Neural Network - hod: 18 -> consumption forecast: 879 Wh, legacy value: 699
2025.12.06 22:32:58.328 1: SolCast DEBUG> Neural Network - hod: 19 -> consumption forecast: 836 Wh, legacy value: 622
2025.12.06 22:32:58.329 1: SolCast DEBUG> Neural Network - hod: 20 -> consumption forecast: 795 Wh, legacy value: 653
2025.12.06 22:32:58.329 1: SolCast DEBUG> Neural Network - hod: 21 -> consumption forecast: 757 Wh, legacy value: 688
2025.12.06 22:32:58.329 1: SolCast DEBUG> Neural Network - hod: 22 -> consumption forecast: 728 Wh, legacy value: 666
2025.12.06 22:32:58.330 1: SolCast DEBUG> Neural Network - hod: 23 -> consumption forecast: 705 Wh, legacy value: 652
2025.12.06 22:32:58.330 1: SolCast DEBUG> Neural Network - hod: 24 -> consumption forecast: 681 Wh, legacy value: 614
Der Wert "consumption forecast" ist die Prognose der KI, Der Wert "legacy value" ist die Prognose von meiner herkömmliche Routine zum Vergleich. Wie gesagt, die Ergebnisse der Verbrauchs-KI werden nur in das Log geschrieben und haben sonst keine Verknüpfung im Modul.
Es gibt eine ganze Reihe von Einstellmöglichkeiten für das Setup des neuronalen Netzes. Ich habe zunächst ein funktionierendes Setup implementiert. Der User kann die Laufparameter aktuell nicht modifizieren. Aber das werde ich bereitstellen in einer der nächsten Schritte.
Wer im Code agieren will, findet die Parameter ab Zeile 21330 bis 21341.
Meine bisherigen Erkenntnisse / Erfahrungen mit AI::FANN sind sehr positiv. Wahrscheinlich werde ich später auch die PV-Prognose darauf umstellen und so AI:DecisionTree mit einer "echten" KI ablösen.
Wer mag, kann nun mit Tests und Ideen mitwirken. Sollte es sich als günstig erweisen, mache ich einen separaten Thread nur für diese NN-Entwicklungsthema auf.
@Wolle02 ... das Thema mit der Circular Bereinigung schaue ich mit die kommenden Tage an.
Edit: Während der Beschätigung mit dem NN ist mir klar geworden, dass man für ein gutes Training (z.B. die Prognose wann ein EV geladen werden könnte) der KI Features bereitstellen muß/sollte, die einen Bezug zu diesem Event herstellen. Ein bestimmter Tag oder ähnliche Zeitindikatoren sind zu schwach und haben keinen wirklichen Bezug. Ein starker Indikator könnte der Ladezustand der EV-Batterie sein. Dazu müsste ich einen solchen Schlüssel für die Definition einen Consumers vom Typ BEV bereitstellen. Vielleicht fallen euch noch weitere Indikatoren ein, die einen Bezug zum Ladeverhalten eines BEV haben und die vom Modul konsumiert werden können.
LG,
Heiko
#8
ESP Familie / Aw: Mittelwertbildung im Tasmo...
Letzter Beitrag von Gisbert - 06 Dezember 2025, 21:19:25Zitat von: Gisbert am 12 Oktober 2025, 00:33:22Hallo Dieter,
ChatGPT war nicht sonderlich hilfreich, teilweise richtig falsch - bis auf eine Kleinigkeit, die besser gelöst wurde. Wenn man den publish-Befehl so schreibt:Code Auswählen=>Publish tele/%topic%/curr_w_avg %mpow%dann wird der gemittelte Wert direkt in das Reading geschrieben.
Mein Script sieht insgesamt so aus, wobei die Teleperiod auch auf 300 gesetzt wurde:Code Auswählen>DIch hoffe, dass ich damit der Datenflut Herr werde, ohne dass die Qualität darunter leidet. Ich werde berichten, wenn ich was nennenswertes rausgefunden habe.
pow=0
; moving average
M:mpow=0
>B
=>sensor53 r
>T
; get sensor values
pow=sml[1]
>S
; average sensor values every second
mpow=pow
; write average to sensor log every 5 minutes
if upsecs%300==0
then
; send MQTT
=>Publish tele/%topic%/curr_w_avg %mpow%
endif
>M 1
+1,3,s,0,9600,PICUS
1,77070100100700ff@1,Consumption (current),W,curr_w,0
1,77070100010800ff@1000,Consumption (total),Kwh,total_kwh,4
1,77070100020800ff@1000,Feed (total),Kwh,total_kwh_out,4
#
Viele Grüße Gisbert
Ich hatte ganz vergessen, dass ich ein Versprechen abgegeben hatte. Zeit es einzulösen.
Ich bin mit obigen Lösung zufrieden und nutze sie seitdem.
Viele Grüße Gisbert
#9
Server - Linux / Aw: Proxmox Backup Server - wi...
Letzter Beitrag von betateilchen - 06 Dezember 2025, 20:08:01Danke für den Schubs. Das Standardbackup hatte ich einfach gar nicht mehr auf dem Schirm.
#10
FHEMWEB / Aw: Trotz Reverse Proxy: Conne...
Letzter Beitrag von Otto123 - 06 Dezember 2025, 19:17:50Hallo Heiko,
da ich dein exaktes Setup nur ahnen kann:
mit global bindet FHEM die 8083 an alle Netzwerkschnittstellen: 0.0.0.0:8083 beantwortet aber eigentlich nur Anfragen aus privaten Netzwerken (siehe help FHEMWEB - allowfrom Attribute, dein Log zeigt: es hat genauso gewirkt
)
ohne global bindet FHEM die 8083 an 127.0.0.1:8083
Die Portbindungen kannst Du Dir z.B. mit ss -lntu anschauen.
Insofern sollten jetzt die Logeinträge in FHEM vom 1.12. Geschichte sein.
Dein Proxy wirkt als Sicherheitsschleuse natürlich nicht für "alles" was an die öffentliche IP gebunden ist. Du solltest also darauf achten, dass nur Port 80 und 443 von deinem Proxy an die öffentliche IP gebunden sind. Alles andere sollte nur intern lauschen, ansonsten sind alle Prozesse die öffentlich lauschen potentiell angreifbar.
Gruß Otto
da ich dein exaktes Setup nur ahnen kann:
mit global bindet FHEM die 8083 an alle Netzwerkschnittstellen: 0.0.0.0:8083 beantwortet aber eigentlich nur Anfragen aus privaten Netzwerken (siehe help FHEMWEB - allowfrom Attribute, dein Log zeigt: es hat genauso gewirkt
)ohne global bindet FHEM die 8083 an 127.0.0.1:8083
Die Portbindungen kannst Du Dir z.B. mit ss -lntu anschauen.
Insofern sollten jetzt die Logeinträge in FHEM vom 1.12. Geschichte sein.
Dein Proxy wirkt als Sicherheitsschleuse natürlich nicht für "alles" was an die öffentliche IP gebunden ist. Du solltest also darauf achten, dass nur Port 80 und 443 von deinem Proxy an die öffentliche IP gebunden sind. Alles andere sollte nur intern lauschen, ansonsten sind alle Prozesse die öffentlich lauschen potentiell angreifbar.
Gruß Otto