Reading auf anderes Device übertragen

[Superposchi]

Hallo, ich habe da mal eine Frage.

Ich würde gerne ein Reading "link" von einem Device auf ein anderes Device übertragen.
Prinzipiell fällt mir dazu UserReadings ein, doch leider aktualisiert UserReadings ja nur wenn das Ziel-Device aktualiisert wird.

Gibt es eine andere Möglichkeit oder kann man UserReadings so einstellen, dass er den Inhalt überträgt wenn er im Quell-Device geändert wird.
Andernfalls fällt mir nur ein Notify/DOIF ein, dass als Event link:.* benutzt und dann per setreading das Reading überträgt. Finde ich aber persönlich eher umständlich.

[Beta-User]

https://forum.fhem.de/index.php/topic,71806.0.html

[Superposchi]

Wenn du auch noch schreibst was ich davon nicht gemacht haben soll komme ich VIELLEICHT weiter.

[Beta-User]

Wenn ein FHEM-Device oder eine Automatisierung nicht so funktioniert, wie ihr euch das vorstellt, macht ein "list" aller beteiligten Devices und copy/pastet den Output in euren post

Noch konkreter: vom Quell- und Zieldevice.

Falls es letzteres nicht gibt heißt die Lösung vermutlich "readingsProxy"

[Superposchi]

"readingsProxy" sagt mir nichts, muss ich erst mal recherchieren.

Hab es jetzt provisorisch doch mit einem notify gemacht.

[Jamo]

Hallo Superposchi,
Ich helfe mir damit, auf dem Zieldevice etwas auszulösen, was ein refresh der Ziel-readings triggered.
Wenn es ein dummy ist, und der state ist uninteressant, mache ich z.B. ein "set dummy huhu". Alternativ ein "attr -silent Zieldevice stateFormat {<hier die berechnung mit den readings vom Quelldevice>}", falls ich den dummy state mit readings vom Quelldevice berechne.

Aber ja, dafür brauchst Du immer das event vom Quelldevice. Aber mit dem "set dummy huhu" muss man nicht alle readings mit setreading übertragen.

Ich habe auf z.B. dummies (mein Zieldevice) einige userreadings, die ich mithilfe von mehreren verschiedenen ReadingsVal('Quelldevice','Quellreading','nA') entweder berechne oder darstelle (darstellen das ist das was man auch mit ReadingsProxy lösen kann). Ich baue dann z.B. zur Anzeige im Zieldevice, einem Dummy, einen state mit stateFormat unter Einbeziehung der Readings von verschiedenen Quelldevices auf (wie gesagt ich benutze aber kein Readingsproxy).

Hoffe das hilft.

[Beta-User]

...solange es "nur" um Darstellung geht, mag es funktionieren, wenn man Werte kreuz und Quer hin- und herkopiert. Aber für die pure Darstellung ist readingsGroup die bessere Lösung.

Das Kopieren via notify hat aber einen gewaltigen Haken: es hängt nach meinem Verständnis vom Namen des Ausgangsdevices ab, ob ein darauf aufsetzender Eventhandler noch etwas von der Kopie mitbekommt oder nicht (es sei denn, man doppelt das Event, indem man einen Timer (sleep) dazwischenschaltet, was aber auch wieder unnötig Last erzeugt).

Kurz: Man kann das irgendwie hintricksen und machen, aber es ist eigentlich Murks. Was ich bei der ganzen Sache immer noch nicht verstanden habe: Warum muss man das überhaupt tun?!?

just my2ct...

[MadMax-FHEM]

Hallo Superposchi,
Ich helfe mir damit, auf dem Zieldevice etwas auszulösen, was ein refresh der Ziel-readings triggered.
Wenn es ein dummy ist, und der state ist uninteressant, mache ich z.B. ein "set dummy huhu". Alternativ ein "attr -silent Zieldevice stateFormat {<hier die berechnung mit den readings vom Quelldevice>}", falls ich den dummy state mit readings vom Quelldevice berechne.

Aber ja, dafür brauchst Du immer das event vom Quelldevice. Aber mit dem "set dummy huhu" muss man nicht alle readings mit setreading übertragen.

Ich habe auf z.B. dummies (mein Zieldevice) einige userreadings, die ich mithilfe von mehreren verschiedenen ReadingsVal('Quelldevice','Quellreading','nA') entweder berechne oder darstelle (darstellen das ist das was man auch mit ReadingsProxy lösen kann). Ich baue dann z.B. zur Anzeige im Zieldevice, einem Dummy, einen state mit stateFormat unter Einbeziehung der Readings von verschiedenen Quelldevices auf (wie gesagt ich benutze aber kein Readingsproxy).

Hoffe das hilft.

Wenn schon solche wilde Dinger hier "präsentiert" werden, dann zumindest mal eine etwas "angenehmere" Variante ohne hin-her-PingPong...

AUCH WENN DAS ZURECHT NICHT ZU EMPFEHLEN IST (wie geschrieben: eher damit vielleicht das ganz wilde Ding zumindest etwas weniger wild werden kann)

Code Auswählen Erweitern


attr QUELL-DEVICE userReadings transferred:TRIGGER-REGEX {my $value=($name,"QUELLREADINGNAME","Ersatzwert");;fhem("sleep 0.1;; setreading ZIELDEVICE ZIELREADINGNAME $value");;return "done"}

(Eingabe bzgl. Strichpunkte für RawDef)
EDIT: wichtig, das userReadings "hängt" am QUELLDevice, also dort wo der Wert entsteht, daher ist da dann nat. ein "Trigger" vorhanden

erzeugt beim QUELLDEVICE ein zusätzliches reading "transferred", dort sieht man dann, ob und wann "übertragen" wurde.

Und beim ZIELDEVICE ein (weiteres) Reading mit dem zu übertragenden Wert...
Das sleep ist notwendig, damit eine mögliche Rekursion (bei z.B. setreading auf DASSELBE Device) verhindert wird, ansonsten funktioniert das nicht...

@ALL (others): SORRY! Für diese Variante!

Gruß, Joachim

[betateilchen]

Hab es jetzt provisorisch doch mit einem notify gemacht.

Sowas würde ich IMMER über ein notify lösen. Das ist die nachvollziehbarste und flexibelste Lösung.

Ein userreading ist technisch betrachtet auch nichts anderes als eine Sonderform eines notify.
Gedacht für Leute, die es nicht schaffen, ein notify selbst anzulegen.

[MadMax-FHEM]

Sowas würde ich IMMER über ein notify lösen. Das ist die nachvollziehbarste und flexibelste Lösung.

Jep.

Ein userreading ist technisch betrachtet auch nichts anderes als eine Sonderform eines notify.
Gedacht für Leute, die es nicht schaffen, ein notify selbst anzulegen.

Wobei ja ein notify mit richtiger/guter Trigger-RegEx dank Eventmonitor recht einfach ist...
...das wird ja (sehr) oft bei userReadings einfach "ignoriert", also ein Trigger...

Gruß, Joachim

[Superposchi]

@betateilchen
also ich finde das UserReading wesentlich komplizierter als ein Notify. Habe halt nur in den Ohren, dass es geheißen hat, man solle zusätzliche Events vermeiden wenn es sich mit eigenen Readings lösen lässt.

@MadMax-FHEM
Interessant, muss ich ausprobieren. Das mit dem transferred ist Neu für mich.
Was genau ist denn "TRIGGER-REGEX"? Einfach ein Regex ala "<Device>:<Reading>:.*"

@Zum Hintergrund, dann wird es vielleicht etwas klarer:
Ich habe im FTUI ein Select-Widget mit dem verschiedene Radiostation ausgewählt werden können. Diese URL's schreibe ich dann in ein Reading für ein Webradio-Device (ich kann ja nur in ein Reading schreiben). Da ich das Webradio aber per FTUI auf meinen Nest-Devices mit Play url abspielen will, muss ich das Reading aus dem Webradio in jedes meiner Nest-Devices bekommen, damit ich es dann im FTUI weiterverarbeiten kann.

[MadMax-FHEM]

@MadMax-FHEM
Interessant, muss ich ausprobieren. Das mit dem transferred ist Neu für mich.

transferred ist nur MEIN Name des "lokalen" Readings (QUELLDEVICE), da kannst du (wie bei userReadings nachzulesen) nehmen was du willst. Wenn du mehr transferierst evtl. auch den Namen des "transferierten" Readings mit "einbauen": XYZReadingTransferred o.ä.

@MadMax-FHEM
Was genau ist denn "TRIGGER-REGEX"? Einfach ein Regex ala "<Device>:<Reading>:.*"

Naja wie halt bei einem notify auch bzw. wie halt bei userReadings nachzulesen.

Im Prinzip müsste es ja das Reading als Trigger-RegEx sein, welches übertragen werden soll, damit eben das userReadings nur genau dann "aufgerufen" wird, wenn eben was zu tun ist (wie bei einem [guten] notify halt auch)...

EDIT: hier ohne Device, also eher "nur" QuellReading (und weitere Einschränkung)...

userReadings
Komma getrennte Liste von benutzerdefinierten Readings. Jede Definition hat folgendes Format:

    <reading>[:<trigger>] [<modifier>] { <perl code> }

Diese benutzerdefinierte Readings werden bei jeder Aktualisierung der Gerätereadings gesetzt, indem das spezifizierte perl code { <perl code> } ausgeführt wird, und dessen Wert dem Reading zugewiesen wird. Falls <trigger> spezifiziert ist, dann findet diese Ausführung nur dann statt, falls einer der aktualisierten Readings dem regexp <trigger> entspricht (matched).
Beispiele:

    attr myEnergyMeter userReadings energy { ReadingsVal("myEnergyMeter","counters.A",0)/1250.0;; }
    attr myMultiMeter userReadings energy1:counters.A.* {ReadingsVal("myMultiMeter","counters.A",0)/1250.0}, energy2:counters.B.* {ReadingsVal("myMultiMeter","counters.B",0)/1250.0}

<modifier> kann die folgenden Werte haben:

    none: als ob man es gar nicht spezifiziert hätte.
    difference: das Reading wird auf die Differenz zw. dem aktuellen und dem vorherigen Wert gesetzt.
    differential: das Reading wird auf die Differenz zw. dem aktuellen und dem vorherigen Wert, geteilt durch die Sekunden zw. der aktuellen Zeit und der letzten Auswertung, sekundengenau. Kein Wert wird berechnet, falls der Unterschied unter eine Sekunde liegt.
    integral: das Gegenteil von differential. Das Ergebnis wird um das Produkt aus der Zeit-Differenz und der Durschnittswert der letzten zwei Readings erhöht.
    result += (time - timeold) * (oldval + value) / 2
    offset: wenn der aktuellen Wert kleiner als der vorherige Wert ist wird der vorherige Wert zum Reading addiert. Das Reading kann dann als offset verwendet werden um einen Zähler der durch Sromverlust zurückgesetzt wird zu korrigieren.
    monotonic: wenn die Differenz zw. dem aktuellen und dem vorherigen Wert positiv ist wird diese Differenz zum Reading addiert. Damit lässt sich von einem Zähler der bei Stromverlust zurückgesetzt wird ein monoton wachsender Zähler ableiten.

Beispiel:

    attr myPowerMeter userReadings power differential { ReadingsVal("myPowerMeter","counters.A",0)/1250.0}

Achtung:

    Falls difference oder differential spezifiziert ist, dann werden für die Berechnung ältere Werte benötigt, d.h. der Wert wird frühestens beim zweiten Änderung gesetzt.
    der Name der definierten Readings besteht aus alphanumerischen Zeichen, Unterstrich (_) und Minus-Zeichen (-).

Gruß, Joachim

[Beta-User]

"Gute" userReadings (über viele Fälle kann man in der Tat streiten) sind technisch jedem notify "vorgelagert", und die regex für <trigger> ist fast dieselbe wie für notify, aber mit zwei Ausnahmen: "<Device>:" muss man weglassen, weil es immer NUR um Events geht, die das Device betreffen, an dem das userReading "hängt", und "state" ist als Reading immer da (bei notify muss man das einschalten). Und wenn man eigentlich keinen Wert in dem userReading haben will, kann man auch (echtes!) undef zurückgeben ...

Unnötige Events zu vermeiden ist m.E. hilfreich, hier aber nur ein Teil der Wahrheit: wir befinden uns beim Setzen von Readings aus notify heraus bereits in einer "Event-loop", eine zusätzliche Event-loop gibt es nur, wenn man irgendwo einen Timer einbaut. Und damit man keine "Endlos-Event-Loops" baut, arbeitet fhem.pl eben die Eventhandler sequenziell ab, und wer zu früh dran ist, bekommt in der Folge eben uU. nicht mehr mit, was sich noch getan hat.

Was diese FTUI-Geschichte angeht: Kannst du nicht via data-get auf ein völlig anderes Device zugreifen als mit data-set? (Würde mal die FTUI-Spezialisten befragen...).

[Superposchi]

@Beta-User
Theoretisch ja, aber das Problem ist in der Übergabe als dialog begründet. Dort muss esbenfalls ja ein Device und ein Reading für die Variable angegeben werden und dort kann man nicht auf ein zweites Device zugreifen. Doch daran knabbere ich eh schon, da die Variablen nicht richtig aufgelöst werden innerhalb des Dialog-Widgets.

[Beta-User]

OK, das leuchtet sogar mir ein.
Vermutlich ist es in dem Fall dann egal, wie man das konkret löst und das notify kann dann doch durchaus weiter seinen Dienst tun...