Hallo,
ausgehend von den Überlegungen in diesem Thema (https://forum.fhem.de/index.php?action=post;topic=144151.0) habe ich das Modul readingsProxy in Abstimmung mit justme1968 überarbeitet.
Der ursprüngliche Gedanke hinter dem Modul (https://forum.fhem.de/index.php?action=post;topic=144151.0) war es, aus einem Device ein Reading herauszulösen und damit ein neues steuerbares Gerät zu konstruieren. Mein Gedanke war es, Readings von mehreren Devices unter anderem Namen zusammenzufassen - Anwendungsfall hier, dass ich für meine PV-Anlage ein Mini-Dashboard wollte (ist gestern Nacht fertig geworden - Wiki-Artikel dazu erstelle ich noch), wofür ich aus 5 Devices Readings mit sehr langen Namen zusammenziehen und weitere userReadings zusammenbauen musste, was ohne saubere Benennung völlig undurchschaubar war.
Anbei das überarbeitete Modul: 33_readingsProxy.pm
Es sollte abwärtskompatibel sein. set und get gehen nur für den primären Proxy, also für das erste Reading eines anderen Devices, das man proxifiziert.
commandref ist aktualisiert. Wer das Modul bei sich einspielt, sollte dann noch contrib/commandref_join.pl laufen lassen.
Ich wäre für Tests der derzeitigen Anwender von readingsProxy dankbar, ob das überarbeitete Modul bei euch weiter funktioniert.
Viele Grüße
Boris
Ich habe mir schon öfters gewünscht das readingsProxy mehr als nur ein Reading aus einem Device verarbeiten kann. Schön das nun die Werte sogar auch aus mehr als nur einem Device kommen können !
Das wird bei mir vermutlich die eine oder andere simple readingsGroup ersetzen.
BTW: gibt es einen besonderen Grund dafür das du so viel mit main::Debug ins Log schreibst statt einfach via Log3 und einem höheren Level wie z.b. 4 / 5 ?
main::Debug muss noch raus. Das sind Reste aus der Entwicklung. Habe ich vergessen. Danke für den Hinweis. Das "echte" Logging habe ich ansonsten vom aktuellen Modulstand übernommen und nichts hinzugefügt oder weggenommen.
Ich möchte justme1968 nicht bitten, das Modul einzuchecken, bevor nicht ausreichend Feedback vorliegt, dass es abwärtskompatibel ist, vor allem in Bezug auf setFn, getFn und valueFn. Mit etwas mehr Elan könnte man diese Funktionen auch noch je Proxy und nicht nur für den primären Proxy einführen.
Ich hab nur ein readingsProxy Device. Das ist nicht gerade repräsentativ. Aber es funktioniert auch mit der neuen Version.
define proxySwitchMMWoZi readingsProxy enoSwitch02:channelA
attr proxySwitchMMWoZi userattr structexclude switch switch_map
attr proxySwitchMMWoZi room System->readingsProxy
attr proxySwitchMMWoZi switch structMultiMediaWz
attr proxySwitchMMWoZi valueFn {($VALUE eq "AI")?"on":"off"}
# DEF enoSwitch02:channelA
# FUUID 5c483e71-f33f-dc90-7389-3d0c8b63037ebb85
# FVERSION 33_readingsProxy.pm:0.162990/2018-03-01
# NAME proxySwitchMMWoZi
# NOTIFYDEV global,enoSwitch02
# NR 105
# NTFY_ORDER 50-proxySwitchMMWoZi
# STATE off
# TYPE readingsProxy
# eventCount 28
# primaryProxy enoSwitch02:channelA
# PROXIES:
# enoSwitch02:
# channelA enoSwitch02_channelA
# READINGS:
# 2026-03-31 17:24:59 enoSwitch02_channelA off
# 2018-03-13 16:04:28 lastCmd on
# 2026-03-31 17:24:59 state off
#
setstate proxySwitchMMWoZi off
setstate proxySwitchMMWoZi 2026-03-31 17:24:59 enoSwitch02_channelA off
setstate proxySwitchMMWoZi 2018-03-13 16:04:28 lastCmd on
setstate proxySwitchMMWoZi 2026-03-31 17:24:59 state off
Danke für die Rückmeldung. Nutzt das jetzt kaum jemand oder haben die Nutzer nur keine Lust aufs Testen? Frag ich am falschen Ort?
Zitat von: Dr. Boris Neubert am 10 April 2026, 21:13:54Danke für die Rückmeldung. Nutzt das jetzt kaum jemand oder haben die Nutzer nur keine Lust aufs Testen? Frag ich am falschen Ort?
Ort ist m.E. OK.
Testaufrufe sind nach meiner Erfahrung eher nur dann mit aktiver Beteiligung, wenn es akut Probleme zu lösen gibt, oder man gemeinsam Features entwickelt.
Hier stört mich persönlich, dass man es zum einen aus dem Forum holen muss (umständlicher als z.B. contrib) und das mit dem "debug"-Kommentar. Das logfile unnötig zu füllen, schreckt mich trotz (oder gerade wegen?) vieler sonstiger Umbauten eher ab ..
Erweiterte Version vom April 2026 liegt jetzt 33_readingsProxy.pm in contrib.
Version enthält keinen Debug-Code und ist bereit für produktiven Einsatz.
contrib/33_readingsProxy.pm nach FHEM/ kopieren und dort vorhandenes Modul damit überschreiben.
contrib/commandref_join.pl ausführen, um die Online-Hilfe zu aktualisieren.
Verfügbar in der lokalen Benutzerinstallation morgen früh nach 8 Uhr nach einem Update.
Danke, per
{ Svn_GetFile('contrib/33_readingsProxy.pm', 'FHEM/33_readingsProxy.pm') }läuft jetzt die Testversion (nach einem Neustart, reload gibt ein paar "uninitialized-"Warnings aus). "version" zeigt allerdings noch die alte Info an, ein Blick in "help readingsProxy" zeigt aber, dass die neue geladen sein muss.
Sonst zumindest auf die Schnelle unauffällig.
Die Doppelung beim "primary reading" ist ein kleiner Makel, aber verschmerzbar, ansonsten v.a.: Danke für's Kümmern und den m.E. gelungenen minimalinvasiven Eingriff!
Danke für das positive Feedback!
Zitat von: Beta-User am 12 April 2026, 09:07:23allerdings noch die alte Info an, ein Blick in "help readingsProxy" zeigt aber, dass die neue geladen sein muss.
Interessanterweise hat er beim Einchecken die $Id nicht aktualisiert ???
ZitatDie Doppelung beim "primary reading" ist ein kleiner Makel, aber verschmerzbar
Welche Doppelung beim primary reading meinst du?
ZitatInteressanterweise hat er beim Einchecken die $Id nicht aktualisiert ???
Vermutlich fehlt svn propset:
svn propset svn:keywords Id <file>
Vererbt sich nicht beim Kopieren! Gesetzt, committet, gelöst.
Zitat von: Dr. Boris Neubert am 12 April 2026, 15:29:49Welche Doppelung beim primary reading meinst du?
Habe einfach meine bisherige DEF beibehalten, und jetzt steht der vormals eine Wert eben doppelt da:
define Aussentemperatur_Nord readingsProxy Therme_Vi:heating.sensors.temperature.outside.value
attr Aussentemperatur_Nord group Wetter
attr Aussentemperatur_Nord icon temp_outside
attr Aussentemperatur_Nord room Startseite,Steuerung->Allgemein
attr Aussentemperatur_Nord setList state:colorpicker,BRI,0,1,100
attr Aussentemperatur_Nord stateFormat state °C
# DEF Therme_Vi:heating.sensors.temperature.outside.value
# FUUID 5c432276-f33f-d171-ab7f-17a1cd2474b5bbd5
# NAME Aussentemperatur_Nord
# NOTIFYDEV Therme_Vi,global
# NR 202
# NTFY_ORDER 50-Aussentemperatur_Nord
# STATE 10.8 °C
# TYPE readingsProxy
# eventCount 36
# primaryProxy Therme_Vi:heating.sensors.temperature.outside.value
# PROXIES:
# Therme_Vi:
# heating.sensors.temperature.outside.value Therme_Vi_heating.sensors.temperature.outside.value
# READINGS:
# 2026-04-13 17:19:36 Therme_Vi_heating.sensors.temperature.outside.value 10.8
# 2026-04-13 17:19:36 state 10.8
#
setstate Aussentemperatur_Nord 10.8 °C
setstate Aussentemperatur_Nord 2026-04-13 17:19:36 Therme_Vi_heating.sensors.temperature.outside.value 10.8
setstate Aussentemperatur_Nord 2026-04-13 17:19:36 state 10.8
Zitat von: Beta-User am 13 April 2026, 18:51:10setstate Aussentemperatur_Nord 10.8 °C
Die dritte Zeile ist das state-Reading, das aus dem primären Proxy kommt, und die erste Zeile wird vom stateFormat-Attribut produziert. Das habe ich auch so. Die dritte Zeile kommt vom legacy code in Zeile 154:
readingsProxy_readingsSingleUpdate($hash, "state", $value);Aus Gründen der Abwärtskompatibiltät nicht angepackt.
Von Beta-User und mir überarbeitete Version eingecheckt - ab morgen früh um 8 per Update verfügbar