76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

300P · 21 Juni 2026, 11:10:02

Guten Morgen Heiko,

kleine Sicherheitsfrage zur neuen V2.7.0

Definierung meines Consumer08 (Heatpump)

SMA_Elgris_EM2 
type=heatpump
power=2500
icon=sani_heating_heatpump@orange 
pcurr=Bezug_Wirkleistung:W
etotal=Bezug_Wirkleistung_Zaehler:kWh
noshow=0
switchdev=MQTT_EMSwp
swstate=boiler_data_hpactivity:heating|cooling|hot.*|defrost:off
opmode=Forecast:user_wpmodus

Mit "swstate=xxxx" gebe/gab ich die direkten Readings aus der WP bislang mit.

Mit "opmode=XXXXX" gebe ich die Vorgabewerte des dazu angelegten userreading mit.

Unterschied ist:
in swstate steht dort ->>>>"hot water"
in opmode steht dort ->>>>"hotwater" (notwendiger Wert ohne "Leerzeichen")

Soll / muss ich eigentlich in swstate unbedingt auch diesen Wert "ohne Leerzeichen" nun angeben.
Dann wären m.M.n alle alten Werte in der AI:FANN irgendwie "weg".

EDIT:
Ich lösche ja den Consumer einmal dabei. dadurch wird da so oder so alles gelöscht

Oder liege ich falsch mit der Annahme ?

DS_Starter · 21 Juni 2026, 11:31:29

Moin 300P,

Im Schlüssel swstate gibst du <Reading>:<on-Regex>:<off-Regex> für den Schaltstatus des Kompressors an.
Für das Modul ist es dann WP an oder aus.

Deine Definition

swstate=boiler_data_hpactivity:heating|cooling|hot.*|defrost:off

erfüllt diese Vorgabe -> alles was "heating|cooling|hot.*|defrost" ist == on, off == off
Eventuell kannst du es dir an der Stelle zukünftig vereinfachen oder so lassen.

ZitatMit "opmode=XXXXX" gebe ich die Vorgabewerte des dazu angelegten userreading mit.

Unterschied ist:
in swstate steht dort ->>>>"hot water"
in opmode steht dort ->>>>"hotwater" (notwendiger Wert ohne "Leerzeichen")

Ja, genau. Die Schlüsselwerte in opmode "off heating defrost hotwater cooling pool poolheating" müssen dort exakt so erscheinen wegen dem internen Match auf Operation Mode.

ZitatSoll / muss ich eigentlich in swstate unbedingt auch diesen Wert "ohne Leerzeichen" nun angeben.
Dann wären m.M.n alle alten Werte in der AI:FANN irgendwie "weg".

Musst du nicht weil daraus intern ein boolischer Wert 0|1 für on/off erstellt wurde der ja weiterhin Gültigkeit hat. Kannst du aber schadlos machen. EIn Löschen des Consumers wird nur in bestimmten schädlichen Änderungsfällen gefordert.

ZitatIch lösche ja den Consumer einmal dabei. dadurch wird da so oder so alles gelöscht
Oder liege ich falsch mit der Annahme ?

Das Modul löscht nichts selbst, aber könnte in bestimmten Fällen eine Löschung requesten.
Falls das passiert ist beim Löschen natürlich alles weg inkl. der gesammelten Daten (dafür ist es ja gemacht) und der Consumer muß neu definiert werden (vorher die eingestellten Params mal rauskopieren).

Falls ein Löschen requestet wird, vorher sicherheitshalber nochmal nachfragen ... gerade in der Testphase.
Nicht gleich machen.

LG,
Heiko

Gisbert · 21 Juni 2026, 11:33:47

ZitatAber die KI kann immer noch nicht den Zeitpunkt vorhersagen, WANN der Verbraucher wahrscheinlich benutzt wird. Das ist das Hauptproblem ... auch bei BEV usw.

Hallo Heiko,

Es gibt ja eine Korrelation zwischen der Außentemperatur und dem Einsatz von Wärmepumpen und Klimaanlagen. Also die Wahrscheinlichkeit, dass die Wärmepumpe läuft, und die Energiemenge mit fallender Temperatur steigt, ist gegeben. Bei mir ist die zeitliche Verteilung dann häufig so, dass die Wärmepumpe zwischen 0:00 bis 9:00 läuft, und dann noch etwas tagsüber - bei sehr tiefen Temperaturen dann eher durchlaufend. Bei Klimaanlagen ist es genau umgekehrt.

Gibt es bei deiner KI eine Korrelation zwischen Wärmepumpen und Klimaanlagen und der Außentemperatur?

Dann gibt es noch den Sonderfall, dass man mit einer Klimaanlage heizt und kühlt, also bspw. kleiner 5°C Heizen und größer 25°C Kühlen.

Viele Grüße Gisbert

DS_Starter · 21 Juni 2026, 11:41:04

Moin Gisbert,

ZitatEs gibt ja eine Korrelation zwischen der Außentemperatur und dem Einsatz von Wärmepumpen und Klimaanlagen. Also die Wahrscheinlichkeit, dass die Wärmepumpe läuft, und die Energiemenge mit fallender Temperatur steigt, ist gegeben. Bei mir ist die zeitliche Verteilung dann häufig so, dass die Wärmepumpe zwischen 0:00 bis 9:00 läuft, und dann noch etwas tagsüber - bei sehr tiefen Temperaturen dann eher durchlaufend. Bei Klimaanlagen ist es genau umgekehrt.

Gibt es bei deiner KI eine Korrelation zwischen Wärmepumpen und Klimaanlagen und der Außentemperatur?

Ja, absolut. In setupEnvironment kann ein Außentemperaturmesser angegeben werden (Schlüssel outsideTemp).
Die Wohlfühltemperatur stellt man global mit plantControl->comforttemp ein.
Damit sind der KI die vorhanden Temp. Deltas für Heizen bzw. Kühlen bekannt.

Mit der aktuellen Contrib Version kannst du nun alle deine WP/Klimanlagen separat als Consumer definieren. Klimaanlage ist auch der type 'heatpump'. Natürlich müssen diese Daten wieder eine Zeit gesammelt werden bis ein Effekt im KI Training überhaupt möglich ist.

LG,
Heiko

Burny4600 · 21 Juni 2026, 11:44:21

fc_time wird zwar aktualisiert, aber der Inhalt nicht.

Code Auswählen

2026-06-21 08:00:00
Der Refresh ist zudem auf 1 definiert.

Code Auswählen

forecastRefresh=1

Code Auswählen

define DWD_KR DWD_OpenData
attr DWD_KR alertArea 809275141
attr DWD_KR alertExcludeEvents none
attr DWD_KR alertLanguage DE
attr DWD_KR alias Deutscher Wetter Dienst
attr DWD_KR comment Solarforecast verwendet DWD Wetterdevice:\
https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_S/all_stations/kml/\
https://www.dwd.de/DE/leistungen/met_verfahren_mosmix/met_verfahren_mosmix.html => MOSMIX Stationsparameterliste\
\
Neff,RR1c,SunUp,SunRise,SunSet,TTT,ww zusätzlich ist jedoch auch noch Rad1h notwendig, wenn dieses DWD-Device als Strahlungsdevice genutzt wird.\
\
https://mosmix.de/online.html\
\
get AB_WS_SS dwdCatalog lat=48.15\
get AB_WS_SS dwdCatalog lon=14.00\
\
https://dwd-geoportal.de/\
https://www.dwd.de/DE/leistungen/klimadatenweltweit/stationsverzeichnis.html?lsbId=374532\
https://opendata.dwd.de/climate_environment/CDC/help/stations_list_CLIMAT_data.txt\
\
https://messwerte.tawes.at/OOE/11012_Kremsmuenster/index.php\
\
WMO-Station ID      StationName     Latitude        Longitude       Height      Country\
                    Wels            48.15124159     14.00299087     318         Austria\
11012               KREMSMUENSTER   48.07           14.13           382         Austria\
11010               LINZ FL.        48.23           14.18           298         Austria\
11060               LINZ            48.30           14.28           262         Austria\
11008               ROHRBACH        48.57           14.00           602         Austria\
\
\
https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_S/all_stations/kml/\
https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_S/all_stations/kml/MOSMIX_S_LATEST_240.kmz\
https://opendata.dwd.de/weather/local_forecasts/mos/MOSMIX_L/single_stations/11012/kml/MOSMIX_L_LATEST_11012.kmz
attr DWD_KR devStateStyle style="text-align:right;;;;font-weight:bold;;;;"
attr DWD_KR disable 0
attr DWD_KR downloadTimeout 60
attr DWD_KR event-on-change-reading .*DD,.*FX1,.*FF,.*Neff,.*R101,.*R600,.*Rad1h,.*Rh00,.*RRhc,.*RR1c,.*SunD3,.*SunRise,.*SunSet,.*SunUp,.*Tg,.*Tn,.*Tx,.*TTT,.*ww,.*wwd
attr DWD_KR forecastDays 7
attr DWD_KR forecastProperties DD,FX1,FF,Neff,R101,R600,Rad1h,Rh00,RRhc,RR1c,SunD3,SunRise,SunSet,SunUp,Tg,Tn,Tx,TTT,ww,wwd
attr DWD_KR forecastPruning 1
attr DWD_KR forecastRefresh 1
attr DWD_KR forecastResolution 1
attr DWD_KR forecastStation 11012
attr DWD_KR forecastWW2Text 1
attr DWD_KR group Wetter Vorhersage
attr DWD_KR icon rc_WEB
attr DWD_KR room AB-Wetterstation
attr DWD_KR sortby 01.01
attr DWD_KR stateFormat Morgen den fc1_date in fc_description - Tmax fc1_Tx °C  -  ( state fc_time )
attr DWD_KR timezone CEST
attr DWD_KR verbose 2

Kann es sein, dass zwar die Daten lokal aktualisiert werden, aber die externen Daten aus der angeforderten Wetterstation nicht?
Dieses Thema gehört dann nicht in diesen Thread.

Die Fehler die ich im LOG gefunden habe, beziehen sich nicht auf das forcast Wettermodul.

Code Auswählen

2026.06.19 19:11:58 1: PERL WARNING: given is deprecated at ./FHEM/99_DWD_OpenData_Weblink.pm line 357.
2026.06.19 19:11:58 1: PERL WARNING: when is deprecated at ./FHEM/99_DWD_OpenData_Weblink.pm line 358.

2026.06.19 19:19:00.430 3: FHEMWEB WEB CSRF error: csrf_63522391202818 ne csrf_142552029777675 for client WEB_192.168.17.46_44171 / command get DWD_Weblink_Generator horizontalForecast. For details see the csrfToken FHEMWEB attribute.

DS_Starter · 21 Juni 2026, 11:53:01

ZitatKann es sein, dass zwar die Daten lokal aktualisiert werden, aber die externen Daten aus der angeforderten Wetterstation nicht?

Ja, das sieht danach aus was du beschreibst.

Zitat2026.06.19 19:11:58 1: PERL WARNING: given is deprecated at ./FHEM/99_DWD_OpenData_Weblink.pm line 357.
2026.06.19 19:11:58 1: PERL WARNING: when is deprecated at ./FHEM/99_DWD_OpenData_Weblink.pm line 358.

Die Warnung beziehen sich auf das Anzeigemodul 99_DWD_OpenData_Weblink.pm, nicht auf das Forecast Modul 55_DWD_OpenData.pm. Der Code in 99_DWD_OpenData_Weblink.pm müsste mal überarbeitet werden.

LG,
Heiko

300P · 21 Juni 2026, 12:16:46

Zitat von: DS_Starter am 21 Juni 2026, 11:31:29Musst du nicht weil daraus intern ein boolischer Wert 0|1 für on/off erstellt wurde der ja weiterhin Gültigkeit hat. Kannst du aber schadlos machen. EIn Löschen des Consumers wird nur in bestimmten schädlichen Änderungsfällen gefordert.

Dann lasse ich diesen Punkt erst einmal so

Zitat von: DS_Starter am 21 Juni 2026, 11:31:29Das Modul löscht nichts selbst, aber könnte in bestimmten Fällen eine Löschung requesten.
Falls das passiert ist beim Löschen natürlich alles weg inkl. der gesammelten Daten (dafür ist es ja gemacht) und der Consumer muß neu definiert werden (vorher die eingestellten Params mal rauskopieren).

Falls ein Löschen requestet wird, vorher sicherheitshalber nochmal nachfragen ... gerade in der Testphase.
Nicht gleich machen.

Ich war wohl wieder zu schnell beim umsetzen:
Hab auch die neuen Flags gesetzt und dann den Consumer mit dem opmode angepasst - da wollte er "..einmal löschen und neu anlegen..."
Zuerst dies - aiConProfile=active,pv,heatpump

Code Auswählen

aiConActFunc=SIGMOID_SYMMETRIC
aiConActivate=1
aiConAlpha=0.8
aiConBitFailLimit=0.22
aiConHiddenLayers=64-32-16
aiConLearnRate=0.0001
aiConMomentum=0.5
aiConProfile=active,pv,heatpump
aiConShufflePeriod=20
aiConSteepness=0.9
aiConTrainAlgo=INCREMENTAL
aiConTrainLimit=0
aiConTrainStart=70:9
aiStorageDuration=3600
aiTrainStart=3
aiTreesPV=30

Dann den Consumer08 aufgerufen und geändert
- Löschen wurde angefordert
- also Consumer08 Werte kopiert
- Consumer 08 gelöscht
- einmal save (cfg)
- dann den Consumer08 mit den kopierten Werten neu angelegt (Inhalt s.o.)

Retrain dann angeworfen - der erste Lauf schon sehr gut - aber neuer Retrain gemäß "Empfehlung" mit Bitfail = 0.22 doch noch erneut angeworfen:

Ergebnis:

Code Auswählen

letztes KI-Training: 21.06.2026 11:47:27 / Laufzeit in Sekunden: 1100
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 127.45 ms
Alpha: 0.8
Verbrauchernummer Wärmepumpe: 08

Bewertungsüberblick
Trainingsbewertung: ok (ok)
Lernverhalten: early früh konvergiert (9.6 % Epochenausnutzung)
Einstellhinweise:
Konvergenz erfolgt früh, Momentum/Lernrate sind bereits konservativ: um mehr nützliche Epochen vor dem Early-Stopping zu ermöglichen, aiConSteepness leicht reduzieren (z.B. um 0.1) für langsamere, feinere Konvergenz - bei zu niedrigen aiConSteepness-Wert kann das Netz komplett aufhören zu lernen (Slope≈0); alternativ Hidden-Layer-Größe/Tiefe (aiConHiddenLayers) leicht erhöhen für mehr Lernkapazität, was aber ggf. mehr Trainingsdaten erfordert
Architektur möglicherweise zu komplex für die Datenmenge: Verhältnis Trainingsdaten zu Netzparametern beträgt nur 0.9 (Zielwert: 8–20) - das Netz hat mehr Freiheitsgrade als die Daten zuverlässig füllen können; kleinere Architektur wie z.B. 14-8 versuchen (aiControl->aiConHiddenLayers)
Empfohlene Lernrate für die vorgeschlagene Architektur 14-8 mit 106 Inputs: 0.0050 (aiControl->aiConLearnRate)
Große Datenmenge (10361 Datensätze gesamt): falls saisonale Effekte die Prognosequalität beeinträchtigen, Training auf die neuesten Datensätze begrenzen (z.B. aiControl->aiConTrainLimit=5100) um das Modell auf aktuelle Verbrauchsmuster zu fokussieren. Der Hinweis ist für stochastische Haushalte weniger relevant als für strukturierte.

Rauschen Bewertung: Signal rauscharm, Messwerte zuverlässig (stable)
Drift Bewertung: -
Empfehlung für Retrain: keine

Modellparameter
Normierungsgrenzen: PV=9975 Wh, Hausverbrauch: Min=0 Wh / Max=6970 Wh
Trainingsdaten: 10361 Datensätze (Training=8288, Validation=2073)
Architektur: Inputs=106, Hidden Layers=64-32-16, Outputs=1
Hyperparameter: Learning Rate=0.0001, Momentum=0.5, BitFail-Limit=0.22
Aktivierungen: Hidden=SIGMOID_SYMMETRIC, Steepness=0.9, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Profile=v1_heatpump_active_pv
Zufallsgenerator: Mode=1, Period=20
Modellalter: - h

Trainingsmetriken
bestes Modell bei Epoche: 1438 (max. 15000)
Training MSE: 0.002316
Validation MSE: 0.001960
Validation MSE Average: 0.001977
Validation MSE Standard Deviation: 0.000034
Validation Bit_Fail: 3
Model Bias: 106 Wh
Model Slope: 0.91
Trainingsbewertung: ok

Fehlermaße der Prognosen
MAE: 226.29 Wh
MedAE: 166.05 Wh
RMSE: 259.66 Wh
RMSE relative: 25 %
RMSE Rating: good
MAPE: 22.82 %
MdAPE: 14.00 %
R²: 0.85

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

Drift-Kennzahlen (berechnet ab Modellalter > 6 h)
Analysefenster: - h
Drift RMSE Ratio: -
Semantic Ratio: -
Slope Reference: -
Slope Live: -
Slope Drift: -
Bias Reference: -
Bias Live: -
Bias Drift: -
Score: -
Index: -
Drift Bewertung: -
Empfehlung für Retrain: keine
letzte Rekalibrierung: -

Dieses 2.te Retrain-Ergebnis mit weitaus mehr Empfehlungen und sehr viel "früher" fertig als vorher......also wieder zurück auf Bitfail = 0.34 gegangen:

Code Auswählen

letztes KI-Training: 21.06.2026 12:13:29 / Laufzeit in Sekunden: 1414
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 115.24 ms
Alpha: 0.8
Verbrauchernummer Wärmepumpe: 08

Bewertungsüberblick
Trainingsbewertung: ok (ok)
Lernverhalten: ok gesundes Lernverhalten (13.2 % Epochenausnutzung)
Einstellhinweise:
Große Datenmenge (10361 Datensätze gesamt): falls saisonale Effekte die Prognosequalität beeinträchtigen, Training auf die neuesten Datensätze begrenzen (z.B. aiControl->aiConTrainLimit=5100) um das Modell auf aktuelle Verbrauchsmuster zu fokussieren. Der Hinweis ist für stochastische Haushalte weniger relevant als für strukturierte.

Rauschen Bewertung: Signal rauscharm, Messwerte zuverlässig (stable)
Drift Bewertung: -
Empfehlung für Retrain: keine

Modellparameter
Normierungsgrenzen: PV=9975 Wh, Hausverbrauch: Min=0 Wh / Max=6970 Wh
Trainingsdaten: 10361 Datensätze (Training=8288, Validation=2073)
Architektur: Inputs=106, Hidden Layers=64-32-16, Outputs=1
Hyperparameter: Learning Rate=0.0001, Momentum=0.5, BitFail-Limit=0.34
Aktivierungen: Hidden=SIGMOID_SYMMETRIC, Steepness=0.9, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Profile=v1_heatpump_active_pv
Zufallsgenerator: Mode=1, Period=20
Modellalter: - h

Trainingsmetriken
bestes Modell bei Epoche: 1981 (max. 15000)
Training MSE: 0.001982
Validation MSE: 0.001678
Validation MSE Average: 0.001716
Validation MSE Standard Deviation: 0.000034
Validation Bit_Fail: 0
Model Bias: 76 Wh
Model Slope: 0.90
Trainingsbewertung: ok

Fehlermaße der Prognosen
MAE: 207.13 Wh
MedAE: 148.62 Wh
RMSE: 240.55 Wh
RMSE relative: 23 %
RMSE Rating: good
MAPE: 20.34 %
MdAPE: 12.96 %
R²: 0.88

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

Drift-Kennzahlen (berechnet ab Modellalter > 6 h)
Analysefenster: - h
Drift RMSE Ratio: -
Semantic Ratio: -
Slope Reference: -
Slope Live: -
Slope Drift: -
Bias Reference: -
Bias Live: -
Bias Drift: -
Score: -
Index: -
Drift Bewertung: -
Empfehlung für Retrain: keine
letzte Rekalibrierung: -

So kann jetzt erst einmal wieder wochenlang laufen

Gisbert · 21 Juni 2026, 12:25:20

Zitat von: DS_Starter am 21 Juni 2026, 11:41:04Mit der aktuellen Contrib Version kannst du nun alle deine WP/Klimanlagen separat als Consumer definieren. Klimaanlage ist auch der type 'heatpump'. Natürlich müssen diese Daten wieder eine Zeit gesammelt werden bis ein Effekt im KI Training überhaupt möglich ist.

Hallo Heiko,

ich hab die Version 2.7.0, kann aber bei consumer03 und consumer04 keinen type=heatpump, das dieser type bei consumer01 eingestellt ist.

Bei aiControl habe ich folgende Definition, fehlt etwas?

Code Auswählen

aiConActivate=1
aiConProfile=v1_common_active
aiConHiddenLayers=64-32
aiConLearnRate=0.0001
aiConMomentum=0.5
aiConBitFailLimit=0.34
aiConShuffleMode=1
aiConShufflePeriod=15
aiConTrainLimit=4000
aiConSteepness=0.7

Viele Grüße Gisbert

peterboeckmann · 21 Juni 2026, 13:34:13

Hallo Heiko,

Zitat von: DS_Starter am 21 Juni 2026, 11:31:29Falls ein Löschen requestet wird, vorher sicherheitshalber nochmal nachfragen ... gerade in der Testphase.

dann frage ich malsicherheitshalber nach.

Ich will meinen

Code Auswählen

attr SolarForecast consumer09 MQTT2_KlimaODU type=other power=1500 pcurr=params_switch_0_apower:W:15 etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=frost auto=Automatik exconfc=1

ändern zu

Code Auswählen

attr SolarForecast consumer09 MQTT2_KlimaODU type=heatpump power=1500 pcurr=params_switch_0_apower:W:15 etotal=params_switch_0_aenergy_total:Wh on=on off=off icon=frost auto=Automatik exconfc=1 swstate=state:on:off opmode=MQTT2_KlimaODU:opmode

Nach Deiner Beschreibung sollte das hier richtig sein, oder?

Viele Grüße,
Peter

DS_Starter · 21 Juni 2026, 14:25:25

@Peter,

ja, bei einer Typänderung wird ein Löschrequest ausgelöst. Einfach die vorhandenen Params rauskopieren und nach dem Löschen des Consumers bei der Neuanlage mit den geänderten/ergänzten Parametern erstellen.

@Gisbert,

Zitatich hab die Version 2.7.0, kann aber bei consumer03 und consumer04 keinen type=heatpump, das dieser type bei consumer01 eingestellt ist.

Ich habe die V 2.7.0 nochmal im Contrib upgedated. Das funktioniert bei meinen Tests.
ABER ... aiControl ist der falsche Ort für die WP-Definition. Eine WP legst du als Consumer mit den Attributen consumerXX an.

@Peter, @Gisbert, bitte ladet euch die V 2.7.0 noch einmal neu aus dem contrib.

LG,
Heiko

Gisbert · 21 Juni 2026, 15:58:13

Zitat von: DS_Starter am 21 Juni 2026, 14:25:25@Peter, @Gisbert, bitte ladet euch die V 2.7.0 noch einmal neu aus dem contrib.

Hallo Heiko,

irgendetwas ist bei der neuen Version 2.7.0 von heute Nachmittag schiefgelaufen. Ich hab den Link im contrib kopiert, die Datei per sudo wget in den Ordner ./FHEM kopiert. Dann hab ich ein reload versucht, was nicht lief, schließlich einen Fhem-Neustart - jetzt ist das Device verschwunden.

Viele Grüße Gisbert

Burny4600 · 21 Juni 2026, 15:58:37

Zitat von: DS_Starter am 21 Juni 2026, 11:53:01Ja, das sieht danach aus was du beschreibst.

Die fc_time hinkt tatsächlich trotz stündlicher Aktualisierung um ca. 3 Stunden hinterher.
Das wird wirklich der Grund dafür sein.

peterboeckmann · 21 Juni 2026, 16:02:26

Hallo Gisbert, hallo Heiko,

Zitat von: Gisbert am 21 Juni 2026, 15:58:13
Zitat von: DS_Starter am 21 Juni 2026, 14:25:25@Peter, @Gisbert, bitte ladet euch die V 2.7.0 noch einmal neu aus dem contrib.

Hallo Heiko,

irgendetwas ist bei der neuen Version 2.7.0 von heute Nachmittag schiefgelaufen. Ich hab den Link im contrib kopiert, die Datei per sudo wget in den Ordner ./FHEM kopiert. Dann hab ich ein reload versucht, was nicht lief, schließlich einen Fhem-Neustart - jetzt ist das Device verschwunden.

Viele Grüße Gisbert

Bei mir hat das Update aus dem Contrib funktioniert. Ich habe allerdings sofort den Neustart gemacht, ohne reload davor.

Das Update mache ich immer über diesen befehl:

Code Auswählen

sudo wget -qO /opt/fhem/FHEM/76_SolarForecast.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/76_SolarForecast.pm

Viele Grüße,
Peter

DS_Starter · 21 Juni 2026, 16:26:01

@Gisbert,

Zitatirgendetwas ist bei der neuen Version 2.7.0 von heute Nachmittag schiefgelaufen. Ich hab den Link im contrib kopiert, die Datei per sudo wget in den Ordner ./FHEM kopiert. Dann hab ich ein reload versucht, was nicht lief, schließlich einen Fhem-Neustart - jetzt ist das Device verschwunden.

Wenn sowas passiert - ganz allgemein - keinesfalls "save config" drücken.
Das File aus dem contrib nochmal laden und restarten.

Wenn ich keinen Fehler gemacht habe (Syntaxfehler) ist danach alles ok.
reload kann manchmal problematisch sein, wenn interne Strukturen im Modul verändert wurden ... kann schief gehen, bei dem Release allerdings nicht der Fall.

Gisbert · 21 Juni 2026, 16:33:40

Hallo Heiko,

reload hat etwas kaputt gemacht.
Die Datei aus dem contrib runterladen und ein Fhem-Neustart hat alles wieder zum Vorschein gebracht.
Ein reload versuche ich mir in Zukunft zu verkneifen.

save config hatte ich nicht gemacht - aber aus Versehen dann ein update all - ist da ein save config vorgeschaltet? Und was macht ein save config in diesem Zusammenhang für Probleme?

Viele Grüße Gisbert