Was ist besser/günstiger - userreadings oder notify mit setreading

[Loki]

Ich möchte in einem device verschiedene readings setzte .

Diese Readings basieren auf Berechnungen mit Werten anderer Readings.

Ich kann nun das Ganze als Userreading lösen und dort in Pearl-Teil die Berechnung machen, oder ein Notify definieren, das die Berechnung macht und per setreading das Ergebnis setzt.

Beide Wege funktionieren und führen zum gewünschten Ergebnis.

Die Frage ist nun, welches die bessere/günstigere Lösung im Hinblick auf Zeit/CPU ist?

[CoolTux]

Also mit Pearl wird das nicht gehen.

Empfehlung: Es gubt das Userreading nicht um sonst und Du solltest es auch verwenden. Dort kannst Du dann mit Perlcode arbeiten

[Loki]

Danke für Deine schnelle Antwort, jedoch hast Du meine Frage nicht verstanden.

Ich habe für beide Wege eine funktionierende Lösung.
Sowohl userreadings, als auch notify mit setreading klappt einwandfrei.

Ich möchte nur wissen, welcher der bessere Weg ist. 

[CoolTux]

Das ist eine Philosophie Frage. Wie gesagt, das userreading hat schon seinen Sinn und ich wurde persönlich es einem notify vorziehen

[Loki]

Ah, ok. Wenn sie dann technisch quasi gleichwertige Lösungen bieten, könntest du dann kurz erläutern, worin für Dich die Vor-,bzw. Nachteile liegen?

[CoolTux]

Du hast beim Userreading alles in einem Device statt ein weiteres zu kreieren. Mehr mag ich gerade darüber nicht nachdenken.

[Otto123]

Hi Loki,

kann sein das mir die Anderen jetzt ein paar klatschen: Aber mach Dir doch ein Benchmark und probier beides aus. 
attr global mseclog 1 würde Dir eine höhere Zeitauflösung im Log bieten.
Und eine Schleife - Vorsicht, legt dir FHEM lahm! - testet deinen Befehl ein paar mal.

Code Auswählen Erweitern

{my $i;;Log 1, "Anfang";;for($i=0;;$i<=10;;$i++) {fhem ("set Aktor01 toggle")};;Log 1, "Ende"}

Ob da etwas repräsentatives bei rauskommt weiß ich nicht. Aber ich wollte sowas schon lange mal probieren

Lustig ist zu sehen was FHEM tut, wenn man VOR dem set noch ein sleep einbaut 

Je länger ich drüber nachdenke, da bekommt man wahrscheinlich nur in speziellen Fällen sinnvolle Werte...
Aber vielleicht beantwortet man damit die Philosophie Frage

Gruß Otto

[Pfriemler]

Abgesehen davon, ob die Gretchenfrage "was ist effizienter" wohl nur bei täglich tausenden umzusetzenden Ereignissen überhaupt relevant sein dürfte, wenn FHEM nicht gerade auf einem Raspi Zero läuft, bleibt natürlich anzumerken, dass ein Userreading nur getriggert wird, wenn sich ein ein Event in diesem Device ergibt, währenddessen man mit setreading jederzeit in beliebige andere Devices schreiben kann.
Handelt es sich aber nur um automatische Umformungen und Zusatzinfos für dieses Device, bin ich ganz bei CoolTux. Jede externe Def weniger ist ein Gewinn für die Übersichtlichkeit. Finde ich.

[gotocu]

Habe gerade diesen Thread von Loki entdetckt. Genau das Selbe hab ich mich auch schon seit längerem gefragt.

Warum und wann "userreading" und warum und wann "notify" bzw. was ist mit "watchdog"?

[Christoph Morrison]

Warum und wann "userreading" und warum und wann "notify" bzw. was ist mit "watchdog"?

• userReading werden nur berechnet, wenn es ein Event im Device des userReading gibt, nicht bei anderen Events anderer Devices / des Systems.
• notify reagiert auf Events, auf die das definierte Muster passt, also (auch) auf Events anderer Devices.
• watchdog reagiert auf das Ausbleiben von Events, notify nicht.

[gotocu]

• userReading werden nur berechnet, wenn es ein Event im Device des userReading gibt, nicht bei anderen Events anderer Devices / des Systems.
• notify reagiert auf Events, auf die das definierte Muster passt, also (auch) auf Events anderer Devices.

Super vielen Dank für die Auflistung - d.h. im Schluß, dass es keinen Vorteil (bzw. keinen zwingenden) Grund für den Einsatz von userReadings gibt da alles auch (gleich performant) mittels notify gelöst werden kann ...?

[Christoph Morrison]

Super vielen Dank für die Auflistung - d.h. im Schluß, dass es keinen Vorteil (bzw. keinen zwingenden) Grund für den Einsatz von userReadings gibt da alles auch (gleich performant) mittels notify gelöst werden kann ...?

Über Performance habe ich ja nichts geschrieben, Benchmarks habe ich keine gemacht. Aber: notify und userReading sind ja nicht identisch. Es gibt also schon einen zwingenden Grund, notify zu verwenden, nämlich wenn ein Device auf den Event eines anderen reagieren soll - mit userReading funktioniert das nicht, eine Alternative wäre zu notify eher DOIF, das auch (in Teilen?) die Aufgaben von userReading übernehmen kann.

[frank]

so wie ich es verstanden habe, muss/soll man userreadings nutzen, wenn man durch events eines devices in diesem device readings erzeugen/manipulieren will.

notify versucht das zu unterbinden, um schleifen/loops zu verhindern. wenn es mit notify trotzdem funktioniert, hat man entweder glück gehabt, oder pech, falls es irgendwann nicht mehr geht.

den vorteil eines notify sehe ich hauptsächlich darin, dass man generisch mehrere devices "erschlagen" kann, die dieselbe funktion erhalten sollen. userreadings muss man in dem fall in jedes device einbauen.

[Christoph Morrison]

den vorteil eines notify sehe ich hauptsächlich darin, dass man generisch mehrere devices "erschlagen" kann, die dieselbe funktion erhalten sollen. userreadings muss man in dem fall in jedes device einbauen.

Ich benutze userReadings vor allem dort, wo ich abgeleitete Daten eines Devices benötige, z.B. um einen Wert umzurechnen (Wh in kWh, mA in A, etc.) oder ich Werte fortführen muss (z.B. gesamter Traffic meiner WAN-FritzBox).

notify praktisch gar nicht mehr, die habe ich alle nach und nach durch DOIF ersetzt.