Aw: readingsProxy: überarbeitete Version zum Test

[Beta-User]

Aus Gründen der Abwärtskompatibiltät nicht angepackt.

Hmmm, einerseits verständlich, andererseits stören mich die doppelten Events doch irgendwie.

Hier ein Vorschlag, wie man einerseits rückwärtskompatibel bleibt und andererseits künftig auch das "primaryReading" mappen kann. Zumindest der erste Aspekt scheint zu funktionieren.

Modernisiert ist da auch die commandref (auf "id"-Fassung).

[Beta-User]

...und hier noch eine (wegen der Klarheit des diff nicht besonders schön formatierte) Fassung, die für bulk-Updates auch "nur" bulk-updates am readingsProxy erzeugen sollte. Ist nur grob angetestet, scheint aber zu laufen.

Was mir nicht so ganz gefallen mag: Die "Pseudo-Events" beim FHEM-Start. Das sind keine neuen Infos, von daher sollte man sich das triggernde update m.E. sparen. Weiß aber nicht, wie das vorher war und wollte daher - jedenfalls im Moment - das Verhalten an der Stelle nicht ändern.

[Dr. Boris Neubert]

Danke! Ich schaue mir das noch an.

Ich habe versucht, beim primären Proxy 100 % abwärtskompatibel zu bleiben und nur die Möglichkeit für weitere Proxys (ohne Funktionen setFn, ...) zu ergänzen.

[Beta-User]

Wir sind uns 100% einig: Abwärtskompabilität muss gegeben sein - genau deswegen hat mich die Doppelung irritiert .

ohne Funktionen setFn, ...

Da wir eh' am Testen und Weiterentwickeln sind: Wäre es nicht sinnvoll, den set-Rückweg komfortabler auszulegen und/oder auch das Setzen der weiteren Readings automatisiert zuzulassen?

Hintergrund: Mutmaßlich ist der wesentliche Anwendungfall von rP (für den set-Weg) das "Vereinzeln" von mehrkanaligen Aktoren (v.a. Shelly mit Shelly-Modul oder OWDevice). Da kennt häufig der jeweilige Kanal ein on/off, und es gibt ein "set <proxyDev> <channel> on/off". Da muss der User im Moment eine Ladung Attribute setzen, damit er machen kann, was er eigentlich haben will...

Wenn gewünscht, kann ich die Tage mal schauen, ob ich den subDeviceProxy-Code ausschlachten kann und das hier einbauen. Der kann das, war allerdings beschränkt auf ein <proxyDev>. Das müßte man berücksichtigen, und die Option vorsehen, die Automatik auszuschalten (wenn setList gesetzt, und noch eine alternative Variante).

[Dr. Boris Neubert]

Das fände ich auch gut. Wenn du mal schauen willst, ob du den subDeviceProxy-Code verallgemeinern kannst (erfordert eine Syntaxänderung/-erweiterung bei den Attributen), ist das sicher nicht schlecht. Im Moment haben wieder meine anderen "Projekte" Vorrang, so dass ich mich nicht mit FHEM-Entwicklung kann.

Ich verstehe den ursprünglichen Anwendungsfall von rP genauso wie du.

[Beta-User]

 
Ich schaue mal.

Tendenziell sollte man auch ohne Attribute auskommen können bzw. die bisherige Funktionalität beibehalten.
Der damalige Code hat eigentlich auch nur die set-Optionen aus dem Hauptdevice unter dem gemappten Namen angeboten, frickelig wird es vielleicht für state....

Vielleicht sollten wir diesen Thread verschieben? Ist irgendwie keine "Ankündigung" mehr.

Testversion(en) würde ich dann über deine ins contrib-svn schubsen?

[Dr. Boris Neubert]

Nach Development verschoben ab da, wo es um Entwicklung ging.
Ja, überschreib im contrib.

Auch eine der unerwarteten Geschichten in FHEM, dass contrib bei einem update nicht aktualisiert wird.