Hallo,
für ein Dashboard zu einer PV-Anlage möchte ich originale und berechnete Werte aus mindestens vier Geräten an einem neuen Gerät mit sprechenden Namen sammeln. Die berechneten Werte sind Summen und Differenzen von Werten von teils demselben, teil verschiedenen Geräten.
Das möchte ich tun, um die mindestens acht berechneten Werte nicht über die vier Geräte verstreut zu haben, wo die Readings auch noch zum Teil nicht selbsterklärende Namen haben. Auf die Readings möchte ich dann 1:1 aus RSS zugreifen können.
dummy mit userReadings scheidet aus, weil userReadings nur aktualisiert werden, wenn Readings am Gerät aktualisiert werden, was bei Dummys nicht der Fall ist.
readingsGroup dient nur der Darstellung, hat selber keine Readings.
readingsProxy kann nur ein Reading proxifizieren.
dummy mit notify befüllen macht es nur noch komplexer, als es eh schon ist.
Welchen Tipp könnt ihr mir geben?
Ansonsten scheint es mir so, dass readingsProxy schon gedanklich darauf vorbereitet sei, auch mehrere Readings zu proxifizieren. Man müsste das Modul "nur" aufbohren.
Ich nehme in solchen Fällen immer ein leeres DOIF (Def nur ##) und event_readings.
Patrick
Zitat von: Dr. Boris Neubert am 14 März 2026, 21:35:11Ansonsten scheint es mir so, dass readingsProxy schon gedanklich darauf vorbereitet sei, auch mehrere Readings zu proxifizieren. Man müsste das Modul "nur" aufbohren.
Vielleicht ein erster Ansatz in diese Richtung: https://forum.fhem.de/index.php?msg=1342809
Nachteil: Das ist weiter darauf ausgelegt, genau ein Master-Device zu "proxifizieren" (nettes Wort). Würgaround mit userReadings würde vermutlich funktionieren, allerdings muss man da wieder aufpassen, dass man keine veralteten Werte zieht...
Du darfst auch gerne den oben verlinkten Modulansatz ggf. weiter aufbohren!
Zitat von: PatrickR am 14 März 2026, 22:15:02Ich nehme in solchen Fällen immer ein leeres DOIF (Def nur ##) und event_readings.
Patrick
Damit kann man nicht nur eigene Readings mit Berechnung definieren, sondern auch Aggregationsfunktionen nutzen, die z. B. andere Readings aufsummieren oder sonstige Berechnungen anstellen. Diese kann man auch im gleichen Device visualisieren oder in anderen Devices nutzen.
Zitat von: Damian am 15 März 2026, 13:05:50Zitat von: PatrickR am 14 März 2026, 22:15:02Ich nehme in solchen Fällen immer ein leeres DOIF (Def nur ##) und event_readings.
Patrick
Damit kann man nicht nur eigene Readings mit Berechnung definieren, sondern auch Aggregationsfunktionen nutzen, die z. B. andere Readings aufsummieren oder sonstige Berechnungen anstellen. Diese kann man auch im gleichen Device visualisieren oder in anderen Devices nutzen.
Da es so schön zu Boris' Anwendungsfall passt hier mal mein "Photovoltaik"-Device:
defmod D_R_Photovoltaik DOIF ##
attr D_R_Photovoltaik DbLogInclude totalpvpower,totalacenergy,totaldcenergy,totalpvenergy,totalbatenergy,availablepower,surpluspower,multiplusmaxpower
attr D_R_Photovoltaik alias Photovoltaik
attr D_R_Photovoltaik event-on-change-reading totalpvenergy:0.25,.*
attr D_R_Photovoltaik event_Readings totalpvpower:(([XX.XX.Cerbo:system_dcpvpower]>=0 ? [XX.XX.Cerbo:system_dcpvpower] : 0)+[XX.XX.FroniusModbus:acpower]),\
totaldcenergy:([XX.XX.MPPT1:energy_system]+[XX.XX.MPPT2:energy_system]+[XX.XX.MPPTRS:energy_system]),\
totalacenergy:([XX.XX.FroniusModbus:energytotal]/1000),\
totalpvenergy:([$SELF:totaldcenergy]+[$SELF:totalacenergy:d1]),\
totalbatenergy:([XX.XX.Multiplus:energy_invertertoacin1_fhem:d1]+[XX.XX.Multiplus:energy_invertertoacout_fhem:d1]),\
gridpower:[UG.KE.Energiezaehler:power_consumption_total:d0]+[AU.GR.Energiezaehler:power_consumption_total:d0]-[AU.GR.Energiezaehler:power_production_total:d0],\
multiplusmaxpower:(\
[AU.GR.Temperatursensoren:temp_garage:d] >= 40 ? 3000 :\
[AU.GR.Temperatursensoren:temp_garage:d] >= 25 ? 3700 :\
4000\
),\
surpluspower:(\
[XX.XX.Cerbo:ess_state] == 10\
? ::minNum(\
[$SELF:availablepower],\
([XX.XX.Pylontech:power:d0] - ([$SELF:gridpower:d0]-[XX.XX.Cerbo:ess_gridsetpoint])\
))\
: 0\
),\
availablepower:(\
[XX.XX.Cerbo:ess_state] == 10\
? ([$SELF:multiplusmaxpower]+[XX.XX.Multiplus:activein_power:d0]) - ([$SELF:gridpower:d0]-[XX.XX.Cerbo:ess_gridsetpoint])\
: 0\
),\
radtoday:(\
(\
[DWD_PV:fc0_0_Rad1h]+[DWD_PV:fc0_0_Rad1h]+[DWD_PV:fc0_2_Rad1h]+[DWD_PV:fc0_3_Rad1h]+[DWD_PV:fc0_4_Rad1h]+\
[DWD_PV:fc0_5_Rad1h]+[DWD_PV:fc0_6_Rad1h]+[DWD_PV:fc0_7_Rad1h]+[DWD_PV:fc0_8_Rad1h]+[DWD_PV:fc0_9_Rad1h]+\
[DWD_PV:fc0_10_Rad1h]+[DWD_PV:fc0_11_Rad1h]+[DWD_PV:fc0_12_Rad1h]+[DWD_PV:fc0_13_Rad1h]+[DWD_PV:fc0_14_Rad1h]+\
[DWD_PV:fc0_15_Rad1h]+[DWD_PV:fc0_16_Rad1h]+[DWD_PV:fc0_17_Rad1h]+[DWD_PV:fc0_18_Rad1h]+[DWD_PV:fc0_19_Rad1h]+\
[DWD_PV:fc0_20_Rad1h]+[DWD_PV:fc0_21_Rad1h]+[DWD_PV:fc0_22_Rad1h]+[DWD_PV:fc0_23_Rad1h]\
)/1000\
),\
radtomorrow:(\
(\
[DWD_PV:fc1_0_Rad1h]+[DWD_PV:fc1_0_Rad1h]+[DWD_PV:fc1_2_Rad1h]+[DWD_PV:fc1_3_Rad1h]+[DWD_PV:fc1_4_Rad1h]+\
[DWD_PV:fc1_5_Rad1h]+[DWD_PV:fc1_6_Rad1h]+[DWD_PV:fc1_7_Rad1h]+[DWD_PV:fc1_8_Rad1h]+[DWD_PV:fc1_9_Rad1h]+\
[DWD_PV:fc1_10_Rad1h]+[DWD_PV:fc1_11_Rad1h]+[DWD_PV:fc1_12_Rad1h]+[DWD_PV:fc1_13_Rad1h]+[DWD_PV:fc1_14_Rad1h]+\
[DWD_PV:fc1_15_Rad1h]+[DWD_PV:fc1_16_Rad1h]+[DWD_PV:fc1_17_Rad1h]+[DWD_PV:fc1_18_Rad1h]+[DWD_PV:fc1_19_Rad1h]+\
[DWD_PV:fc1_20_Rad1h]+[DWD_PV:fc1_21_Rad1h]+[DWD_PV:fc1_22_Rad1h]+[DWD_PV:fc1_23_Rad1h]\
)/1000\
),\
forecasttoday:(sprintf('%.1f', [$SELF:radtoday]*2.9)),\
forecasttomorrow:(sprintf('%.1f', [$SELF:radtomorrow]*2.9)),\
forecasttodaymin:(sprintf('%.1f', [$SELF:radtoday]*1.3)),\
forecasttomorrowmin:(sprintf('%.1f', [$SELF:radtomorrow]*1.3)),\
forecasttodaymax:(sprintf('%.1f', [$SELF:radtoday]*4.2)),\
forecasttomorrowmax:(sprintf('%.1f', [$SELF:radtomorrow]*4.2))\
attr D_R_Photovoltaik group Verbrauch
attr D_R_Photovoltaik icon measure_photovoltaic_inst
attr D_R_Photovoltaik room Energiemanagement,Start
attr D_R_Photovoltaik sortby 10
attr D_R_Photovoltaik stateFormat {sprintf(\
'Gesamtleistung: %.0fW, Verfügbare Leistung: %.0fW, Überschussleistung: %.0fW, Gesamtenergie: %.0fkWh (AC: %.0fkWh, DC: %.0fkWh), Prognose heute/morgen: %.0f kWh/%.0f kWh',\
ReadingsVal($name, 'totalpvpower', ''),\
ReadingsVal($name, 'availablepower', ''),\
ReadingsVal($name, 'surpluspower', ''),\
ReadingsVal($name, 'totalpvenergy', ''),\
ReadingsVal($name, 'totalacenergy', ''),\
ReadingsVal($name, 'totaldcenergy', ''),\
ReadingsVal($name, 'forecasttoday', ''),\
ReadingsVal($name, 'forecasttomorrow', '')\
\
)}
Das dient nicht nur der Anzeige aller relevanten Daten an einer Stelle sondern aggregiert sie auch stufenweise, um z. B. die Prognose zu berechnen. Diese und auch die Berechnung des aktuellen Überschusses benutze ich dann in anderen Devices, um z. B. die Wallboxeinspeisung zu steuern.
Danke für Eure Rückmeldungen, Ideen und Vorschläge. Ich habe mich entschieden, readingsProxy zu überarbeiten. Bitte findet das Ergebnis in diesem Thema:
readingsProxy: überarbeitete Version zum Test (https://forum.fhem.de/index.php?topic=144287.new#new)
Hallo Boris,
Zitat von: Dr. Boris Neubert am 27 März 2026, 09:31:54Danke für Eure Rückmeldungen, Ideen und Vorschläge. Ich habe mich entschieden, readingsProxy zu überarbeiten. Bitte findet das Ergebnis in diesem Thema:
readingsProxy: überarbeitete Version zum Test (https://forum.fhem.de/index.php?topic=144287.new#new)
rein interessehalber. Warum hast Du Dich gegen die DOIF-Lösung entschieden?
Zur Einordnung: Ich nutze DOIF sehr intensiv, weil es eben so mächtig ist, verstehe aber jeden, der einen weiten Bogen um das Modul macht. Denn objektive Gründe dafür gibt es genügend, allen voran, dass FHEM mit seinen Helfer-Modulen ursprünglich die Unix-Philosophie verfolgt hat, DOIF aber eher der systemd ist.
Patrick
Hallo Patrick,
ich wusste, dass diese Frage kommt :-)
Das ist tatsächlich eine persönliche Präferenz. Hat auch mit Occams Rasiermesser zu tun oder meiner Liebe zur Unix-Philosophie, dass ein Tool genau eine Sache machen sollte und diese richtig gut. Beinahe hätte ich deine Lösung auch tatsächlich zum Vorbild genommen.
Ich verschmähe DOIF übrigens nicht. Ich nutze die darin enthaltenen Widgets in RSS, um damit Mini-Dashboards auf einem GIFTV mit 240x240 Pixeln zu realisieren. Dazu schreibe ich noch einen Wiki-Artikel.
Meine Readings am Proxy haben ähnliche Komplexität wie deine. Den Proxy brauche ich als Zwischenschicht, weil ich sonst nicht mehr durchgeblickt hätte.
Teaser
Habe mal einen Wiki-Artikel erstellt: Mini-Dashboard für PV-Anlage (https://wiki.fhem.de/wiki/Mini-Dashboard_f%C3%BCr_PV-Anlage)