Frage zum überarbeiteten Modul "readingsproxy"

Begonnen von piet_pit, 13 Mai 2026, 17:09:48

Vorheriges Thema - Nächstes Thema

piet_pit

Hallo Zusammen,
ich nutze ja "readingsproxy" für meinen Shelly ProDualCover PM, damit ich die beiden virtuellen Kanäle ansteuern und auch das Modul "AutoShuttersControl" nutzen kann und habe jetzt erst gelesen (wegen Urlaub), dass das Modul überarbeitet wurde.

Muss ich etwas tun, um das neue Modul zu testen oder wird das automatisch für meine bestehende Konfiguration eingesetzt?

Viele Grüße
Pit
FHEM Latest Revision: 29615
Raspberry Pi 3, Rasbian-Stretch
FRITZ!Box 7690
HM-Mod-RPI-PCB, JeeLink
CUNO 1.47

rabehd

Mein Verständnis und meine Erfahrung:
Was bisher ging, geht immer noch.
Es gibt eine erweiterte Funktionalität, die Du zukünftig nutzen kannst.
Schau Dir das mal an und überlege wo Du es bei bestehenden Device nutzen kannst.
Auch funktionierende Lösungen kann man hinterfragen.

Beta-User

Zitat von: piet_pit am 13 Mai 2026, 17:09:48Muss ich etwas tun, um das neue Modul zu testen oder wird das automatisch für meine bestehende Konfiguration eingesetzt?
Per regulärem update bekommst du die überarbeitete Fassung.

Die sollte 100% abwärtskompatibel sein. Bisher "konnte" readingsProxy genau ein Reading aus einem Device "importieren" (jedenfalls ohne zusätzliche Klimmzüge), die neue Fassung "viele Readings", und ist dabei nicht auf ein "Master"-Device beschränkt.

Was imo noch fehlt, ist eine vereinfachte Option, auch die (eventuell) zugehörigen set-Befehle ohne größeres "Drumrum" zur Verfügung zu stellen. Hier der Link zum Thread zu dem Shelly-2-Cover, dann ist das vielleicht für etwaige Mitleser etwas klarer. (OT: der ist geschlossen, was gerade für solche Querverweisungen nicht hilfreich ist... Bitte künftig Threads als "gelöst" markieren, aber nicht mehr schließen, siehe Forenhinweise im Anfängerbereich)

Um den set-Teil wollte ich mich bei Gelegenheit mal kümmern, Basis könnte Code aus einemm anderen, erweiterten Klon von readingsProxy sein, der das konnte; das kann man aber nicht einfach so übernehmen. Weiß noch nicht, wann ich dazu komme (und Lust habe), aber es würde mir schon mal helfen, wenn für "typische Szenarien" die Infos da wären, die es dazu braucht. Das wäre die Rückgabe von "getAllSets(<master-device>)"

Konkret also für diesen Shelly die Rückgabe aus der FHEM-Kommandozeile:
{getAllSets('DachgeschossRollo')} Immer unterstellt, es gibt dort kein eventMap oä!

Ob es für diesen Typ ohne weiteres klappt, wage ich übrigens zu bezweifeln, das war eher dafür gedacht, dass man z.B. "on" und "off" "eine Ebene höher" ziehen kann, also von
set master latch.A on
nach
set rP_latch_A on
Und wenn es denn Code gibt, wäre es natürlich schön, wenn das jemand testet... Dieser Teil ist nämlich sehr viel komplexer (und damit fehleranfällig) wie die jetzt per regulärem update verteilte Erweiterung  ;D .
Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors