- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#91
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von 300P - 21 März 2026, 16:01:08Ja - so ist es jetzt wirklich eindeutig das alle Strings jeweils an alle WR zugeordnet werden
#92
Heizungssteuerung/Raumklima / Aw: Neues Modul: 58_DaikinClou...
Letzter Beitrag von FrankL - 21 März 2026, 15:51:39Hallo Wolfgang,
für eine Klimaanlage ist es wahrscheinlich das Beste, wenn sie durchläuft, auch wenn das Fenster mal 5 Minuten zum Lüften offen ist. Je weniger Takte, desto besser. Zumindest macht es in meinen Augen keinen Sinn, wenn deswegen der komplette Kältemittelkreislauf abgeschaltet wird, um ihn dann ggf. kurze Zeit später wieder aufzunehmen.
Wenn du da dennoch etwas automatisieren willst, würde ich dir empfehlen, die Klimaanlage nicht auszuschalten, sondern lediglich den "setpoint" (also die Zieltemperatur) zu reduzieren/zu verschieben, solange das Fenster offen ist. Also im Heizmodus setpoint um 3-5 Grad senken, im Kühlmodus natürlich um 3-5 Grad erhöhen, solange das jeweilige Fenster offen ist. Dafür eignet sich ein einfaches DOIF, welches auf den Zustand deines Fensters triggert. Das hätte auch den Charme, dass beim Schließen des Fensters nicht extra noch geprüft werden muss, ob die Klima vor dem Öffnen des Fensters überhaupt an war.
Denk aber bei der ganzen Automatisierung auch immer an das Request-Limit (siehe Reading "RateLimit-Remaining-day" im DAIKIN_MASTER). Wenn man in mehreren Räumen mit Klimaanlage öfters mal lüftet, kommen da schnell ein paar zusätzliche Requests zusammen.
MfG Frank
für eine Klimaanlage ist es wahrscheinlich das Beste, wenn sie durchläuft, auch wenn das Fenster mal 5 Minuten zum Lüften offen ist. Je weniger Takte, desto besser. Zumindest macht es in meinen Augen keinen Sinn, wenn deswegen der komplette Kältemittelkreislauf abgeschaltet wird, um ihn dann ggf. kurze Zeit später wieder aufzunehmen.
Wenn du da dennoch etwas automatisieren willst, würde ich dir empfehlen, die Klimaanlage nicht auszuschalten, sondern lediglich den "setpoint" (also die Zieltemperatur) zu reduzieren/zu verschieben, solange das Fenster offen ist. Also im Heizmodus setpoint um 3-5 Grad senken, im Kühlmodus natürlich um 3-5 Grad erhöhen, solange das jeweilige Fenster offen ist. Dafür eignet sich ein einfaches DOIF, welches auf den Zustand deines Fensters triggert. Das hätte auch den Charme, dass beim Schließen des Fensters nicht extra noch geprüft werden muss, ob die Klima vor dem Öffnen des Fensters überhaupt an war.
Denk aber bei der ganzen Automatisierung auch immer an das Request-Limit (siehe Reading "RateLimit-Remaining-day" im DAIKIN_MASTER). Wenn man in mehreren Räumen mit Klimaanlage öfters mal lüftet, kommen da schnell ein paar zusätzliche Requests zusammen.
MfG Frank
#93
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 21 März 2026, 15:45:26@300P,
goldener Hinweis ... aber anders als du vermutest
Der Strings-Eintrag ist falsch. Gesetzt ist:
Richtig wäre:
Dadurch ist Strings bei beiden Invertern nicht gesetzt und somit werden alle Strings bei beiden Invertern zugeordnet.
Das Ergebnis muß falsch werden.
-> strings= bei beiden Invertern korrigieren!
Edit: Und jetzt sieht man es auch im Screenshot von Dieter.
goldener Hinweis ... aber anders als du vermutest
Der Strings-Eintrag ist falsch. Gesetzt ist:
Code Auswählen
strings:Ostseite,Suedseite
Richtig wäre:
Code Auswählen
strings=Ostseite,Suedseite
Dadurch ist Strings bei beiden Invertern nicht gesetzt und somit werden alle Strings bei beiden Invertern zugeordnet.
Das Ergebnis muß falsch werden.
-> strings= bei beiden Invertern korrigieren!
Edit: Und jetzt sieht man es auch im Screenshot von Dieter.
#94
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von dieter114 - 21 März 2026, 15:44:51Zitat von: 300P am 21 März 2026, 15:22:27Zeig doch mal "get ....valInverter"Das ist so richtig. Zwei Inverter die beide aus dem Symogen24 ausgelesen werden.
Möglicherweise ist das auch der Grundfehler der Anlage.
Namen gleich und die Readings?
Es werden zwei Readings (hochlaufende Zähler) aus dem Fronius_Symo ausgelesen.
Die entsprechen je 2 bzw. sogar 3 Strings daran.
#95
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von 300P - 21 März 2026, 15:22:27Zitat von: dieter114 am 21 März 2026, 10:30:33attr Forecast setupInverterDev01 Fronius_Symo pvOut=PowerFlow_Site_P_PV:W etotal=User_Produced_FPV:kWh capacity=10000 strings:Ostseite,Suedseite
attr Forecast setupInverterDev02 Fronius_Symo pvOut=Meter_1_PowerReal_P_Sum:W etotal=Meter_1_EnergyReal_WAC_Sum_Produced:Wh capacity=4000 strings:Westseite,GH_Ost,GH_West
Das ist n.m.M. irgendwie nicht ganz richtig konfiguriert.....
2 verschiedene "etotal" an einem WR-Device-Namen
- Fronius_Symo pvOut=PowerFlow_Site_P_PV:W
- Fronius_Symo pvOut=Meter_1_PowerReal_P_Sum:W
oder
2 gleiche gleiche Device-Namen als WR-Device
- setupInverterDev01 Fronius_Symo
- setupInverterDev02 Fronius_Symo
->> soll / ist / kann das wirklich überhaupt so "real" sein ?
EDIT:
Zeig doch mal "get ....valInverter"
#96
Anfängerfragen / Aw: MATTER im FHEM? Schon was ...
Letzter Beitrag von stefanne - 21 März 2026, 15:18:33Hallo zusammen,
nach vielen Jahren mit FHEM stehe ich nun zum ersten Mal vor einer Herausforderung, für die ich (noch) keine direkte Lösung innerhalb meines Lieblingssystems gefunden habe.
Mit Blick auf die kommenden Entwicklungen – besonders im Bereich Energiemanagement und bei Hausgeräten – habe ich beschlossen, frühzeitig mit Matter zu starten. Um dies umzusetzen, habe ich mir parallel zu FHEM eine Home-Assistant-Instanz installiert. Über MQTT repliziere ich die Daten der neuen Geräte zurück in mein FHEM-System, was dank KI-Unterstützung glücklicherweise recht zügig machbar war.
Bisher habe ich meine Hardware immer strikt nach ihrer FHEM-Unterstützung ausgesucht. Angesichts der rasanten Entwicklung rund um Matter würde ich mich natürlich riesig freuen, perspektivisch eine native Integration oder ein Plugin in FHEM zu sehen. Die große Stärke von FHEM war für mich schon immer die enorme Vielfalt an Schnittstellen – seit ich damals meinen ersten Somfy-Rollladen eingebunden habe.
Meine Hausautomation ist mittlerweile zu einer stattlichen Landschaft angewachsen (EVCC, InfluxDB, SMA, Ellie, Max!, DuoFern etc.) und nun eben um Home Assistant und die erste Matter-Steckdose reicher. Es ist zu sehen, wie proprietäre Interfaces langsam verschwinden – mein alter FHEMduino liegt bereits als Andenken in der Bauteilkiste, und auch für 433MHz-Komponenten ist die Zeit bei mir abgelaufen.
Ich bin zwar selbst kein Entwickler – meine Stärke liegt eher im Konfigurieren und Systemdesign –, aber ich möchte an dieser Stelle einfach mal Danke sagen. Danke an diese großartige Gemeinschaft für eure unermüdliche Arbeit an FHEM, die mein Zuhause über Jahre so zuverlässig gesteuert hat.
Beste Grüße,
Stefan
nach vielen Jahren mit FHEM stehe ich nun zum ersten Mal vor einer Herausforderung, für die ich (noch) keine direkte Lösung innerhalb meines Lieblingssystems gefunden habe.
Mit Blick auf die kommenden Entwicklungen – besonders im Bereich Energiemanagement und bei Hausgeräten – habe ich beschlossen, frühzeitig mit Matter zu starten. Um dies umzusetzen, habe ich mir parallel zu FHEM eine Home-Assistant-Instanz installiert. Über MQTT repliziere ich die Daten der neuen Geräte zurück in mein FHEM-System, was dank KI-Unterstützung glücklicherweise recht zügig machbar war.
Bisher habe ich meine Hardware immer strikt nach ihrer FHEM-Unterstützung ausgesucht. Angesichts der rasanten Entwicklung rund um Matter würde ich mich natürlich riesig freuen, perspektivisch eine native Integration oder ein Plugin in FHEM zu sehen. Die große Stärke von FHEM war für mich schon immer die enorme Vielfalt an Schnittstellen – seit ich damals meinen ersten Somfy-Rollladen eingebunden habe.
Meine Hausautomation ist mittlerweile zu einer stattlichen Landschaft angewachsen (EVCC, InfluxDB, SMA, Ellie, Max!, DuoFern etc.) und nun eben um Home Assistant und die erste Matter-Steckdose reicher. Es ist zu sehen, wie proprietäre Interfaces langsam verschwinden – mein alter FHEMduino liegt bereits als Andenken in der Bauteilkiste, und auch für 433MHz-Komponenten ist die Zeit bei mir abgelaufen.
Ich bin zwar selbst kein Entwickler – meine Stärke liegt eher im Konfigurieren und Systemdesign –, aber ich möchte an dieser Stelle einfach mal Danke sagen. Danke an diese großartige Gemeinschaft für eure unermüdliche Arbeit an FHEM, die mein Zuhause über Jahre so zuverlässig gesteuert hat.
Beste Grüße,
Stefan
#97
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 21 März 2026, 15:05:16Ich habe mal die 12:00 Werte für den 22.03. genommen:
Dem gegenüber steht gemäß deinem Screeshot 12466 Wh für 22.03. 12:00.
Da gibt es also eine Differenz die nicht aus dem Korrekturfaktor 0.88 kommt. Der vermindert sogar die Prognose.
Die Prognose für morgen 12:00 sagt aber auch cloud=0, also wolkenloser Himmel! Nicht heute, aber morgen.
Rad1h - Globalstrahlung (googeln)
pv_estimate50 - siehe oben
GTIWh - Globalstrahlung auf die geneigte Fläche in Wh
Auf jeden Fall gibt es ein Gap, aber die API Werte sehen zunächst plausibel aus.
Der nächste Schritt ist
ctrlDebug=radiationProcess
einschalten, die Daten mit "get ... rooftopData" abrufen und die Logadaten komplett posten. Die sehen etwa so aus:
Das wird sehr umfangreich!
Code Auswählen
GH_Ost=
2026-03-22 12:00:00 => GTIWh: 588.4
pv_estimate50: 921.00
GH_West=
2026-03-22 12:00:00 => GTIWh: 597
pv_estimate50: 311.00
Ostseite=
2026-03-22 12:00:00 => GTIWh: 460.6
pv_estimate50: 1442.00
Suedseite=
2026-03-22 12:00:00 => GTIWh: 895
pv_estimate50: 6170.00
Westseite=
2026-03-22 12:00:00 => GTIWh: 378.7
pv_estimate50: 749.00
Summe= 9593
Dem gegenüber steht gemäß deinem Screeshot 12466 Wh für 22.03. 12:00.
Da gibt es also eine Differenz die nicht aus dem Korrekturfaktor 0.88 kommt. Der vermindert sogar die Prognose.
Die Prognose für morgen 12:00 sagt aber auch cloud=0, also wolkenloser Himmel! Nicht heute, aber morgen.
ZitatEstimate 50 bedeutet 50% der zu erwartenden Leistung?Nein, ist nur eine Bezeichnung und hier als durchschnittlich zu erwartendes Ergebnis.
Rad1h - Globalstrahlung (googeln)
pv_estimate50 - siehe oben
GTIWh - Globalstrahlung auf die geneigte Fläche in Wh
Auf jeden Fall gibt es ein Gap, aber die API Werte sehen zunächst plausibel aus.
Der nächste Schritt ist
ctrlDebug=radiationProcess
einschalten, die Daten mit "get ... rooftopData" abrufen und die Logadaten komplett posten. Die sehen etwa so aus:
Code Auswählen
2026.03.21 15:00:49.023 1: openMeteo DEBUG> PV API estimate for today Hour 16 string Schleppdach ->
Estimated PV generation (calc) => 314.9 Wh
Estimated PV generation (raw) => 409.00 Wh
Module Temp (calculated) => 15.25 C
PV correction factor => 0.77
PV correction quality => 0.13
String Peak => 2170 W
Win(+)/Loss(-) String Peak Power by Temp => 0.09 kWp
2026.03.21 15:00:49.023 1: openMeteo DEBUG> PV API estimate for today Hour 16 string Süddach ->
Estimated PV generation (calc) => 854.7 Wh
Estimated PV generation (raw) => 1110.00 Wh
Module Temp (calculated) => 15.25 C
PV correction factor => 0.77
PV correction quality => 0.13
String Peak => 5900 W
Win(+)/Loss(-) String Peak Power by Temp => 0.25 kWp
2026.03.21 15:00:49.024 1: openMeteo DEBUG> PV API estimate for today Hour 16 summary:
Cloudcover => 79
Forecasted temperature => 10.00 C
PV Correction mode => on_complex
PV generation forecast => 1170 Wh
Starttime => 2026-03-21 15:00:00
Total Rain last hour => 0.00 kg/m2
2026.03.21 15:00:49.024 1: openMeteo DEBUG> PV API estimate for today Hour 17 string Schleppdach ->
Estimated PV generation (calc) => 125.0 Wh
Estimated PV generation (raw) => 245.00 Wh
Module Temp (calculated) => 10.9 C
PV correction factor => 0.51
PV correction quality => 0.74
String Peak => 2210 W
Win(+)/Loss(-) String Peak Power by Temp => 0.13 kWp
2026.03.21 15:00:49.025 1: openMeteo DEBUG> PV API estimate for today Hour 17 string Süddach ->
Estimated PV generation (calc) => 328.4 Wh
Estimated PV generation (raw) => 644.00 Wh
Module Temp (calculated) => 10.9 C
PV correction factor => 0.51
PV correction quality => 0.74
String Peak => 6010 W
Win(+)/Loss(-) String Peak Power by Temp => 0.36 kWp
2026.03.21 15:00:49.025 1: openMeteo DEBUG> PV API estimate for today Hour 17 summary:
Cloudcover => 94
Forecasted temperature => 9.40 C
PV Correction mode => on_complex
PV generation forecast => 453 Wh
Starttime => 2026-03-21 16:00:00
Total Rain last hour => 0.00 kg/m2
...
Das wird sehr umfangreich!
#98
FRITZ!Box / Aw: 72_FRITZBOX.pm wird zu 72_...
Letzter Beitrag von elektron-bbs - 21 März 2026, 14:59:53Ach so, das hatte ich noch nicht entdeckt. Dann hat sich das schon erledigt.
#99
FRITZ!Box / Aw: 72_FRITZBOX.pm wird zu 72_...
Letzter Beitrag von JoWiemann - 21 März 2026, 14:54:30Hallo elektron-bbs,
das kannst Du doch mit dem Attribut retMsgbySet selber steuern.
Grüße Jörg
das kannst Du doch mit dem Attribut retMsgbySet selber steuern.
Grüße Jörg
#100
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von dieter114 - 21 März 2026, 14:43:40Also es würde sein:
2026-03-21 12:00:00 => GTIWh: 443.4
pv_estimate50: 3056.00
vom Südseitenfeld.
Estimate 50 bedeutet 50% der zu erwartenden Leistung?
Und wenn ja würde es bedeuten das dort über 6kW in 1h runterkommen.
Das ist die z.Z. maximal mögliche Leistung bei voller Sonne bezogen auf das Südfeld.
Hier ist es stark bewölkt und trübe, also höchstens 25% davon.
Mir fehlt einfach das Verständniss dazu. Was bedeuten all diese Werte
Rad1h, pv_estimate50 und GTIWh
LG WDS
2026-03-21 12:00:00 => GTIWh: 443.4
pv_estimate50: 3056.00
vom Südseitenfeld.
Estimate 50 bedeutet 50% der zu erwartenden Leistung?
Und wenn ja würde es bedeuten das dort über 6kW in 1h runterkommen.
Das ist die z.Z. maximal mögliche Leistung bei voller Sonne bezogen auf das Südfeld.
Hier ist es stark bewölkt und trübe, also höchstens 25% davon.
Mir fehlt einfach das Verständniss dazu. Was bedeuten all diese Werte
Rad1h, pv_estimate50 und GTIWh
LG WDS