Könnte man readingsSingleUpdate mit einem neuen Parameter versehen ("2"?), welche bewirkt, dass zwar der neue Wert gespeichert wird, ein Event aber nur erzeugt wird, wenn sich der Wert ändert (oder halt nur gespeichert, wenn es eine Änderung gibt).
if ($Wert ne ReadingsVal($name,"Wert",0))
{readingsSingleUpdate($hash, "Wert", $Wert ,1)}
else
{readingsSingleUpdate($hash, "Wert", $Wert ,0)}
Ist zwar von der Funktion ähnlich wie "event-on-change-reading", setzt aber weiter vorn an und erzeugt damit weniger Last.
Habe mir mal die fhem.pl angeschaut, in die sub readingsSingleUpdate müsste nur eine Zeile eingefügt werden, wenn mich meine rudimentären Perl-Kentnisse nicht trügen.
sub
readingsSingleUpdate($$$$)
{
my ($hash,$reading,$value,$dotrigger)= @_;
readingsBeginUpdate($hash);
if ($dotrigger == 2) {$dotrigger = ($value."" ne ReadingsVal($hash->{NAME},$readingName,""))}
my $rv = readingsBulkUpdate($hash,$reading,$value);
readingsEndUpdate($hash,$dotrigger);
return $rv;
}
Habe es auch gleich mal ausprobiert und zumindest ist mir Fhem nicht gleich um die Ohren geflogen ;).
Dagegen.
Ob ein Trigger ausgelöst werden muss, sollte der Modulentwickler an der Stelle seines Moduls entscheiden, an der er die Funktion readingsSingleUpdate() aufruft. Er hat dann die Möglichkeit, die Funktion mit einer 0 oder einer 1 am Ende aufzurufen.
Zitat von: betateilchen am 23 Januar 2016, 15:48:23sollte der Modulentwickler an der Stelle seines Moduls entscheiden, an der er die Funktion readingsSingleUpdate() aufruft
Macht er ja immer noch, nur mit einer Option mehr.
Der Sinn ist aber unklar. event-on-*-reading gibt dem User die Möglichkeit, die Events zu beeinflussen. So sollte es sein.
Interessant, zweimal "dagegen", aber mit entgegengesetzter Begründung ;).
Ich war bisher der Meinung, dass "event-on-*-reading" dazu dient, "schlecht" (für einen anderen Zweck!) programmierte Endgeräte für fhem "zum Schweigen" zu bringen.
Das hast du falsch verstanden.
Ach und die Begründungen sind nicht entgegen gesetzt.
Zitat von: marvin78 am 23 Januar 2016, 16:00:55
Der Sinn ist aber unklar. event-on-*-reading gibt dem User die Möglichkeit, die Events zu beeinflussen. So sollte es sein.
Das ist nicht die ursprüngliche Intention von event-on-.*-reading. Bei einem Watchdog brauch man zyklische Events dauerhaft, bei einem notify nur bei einer Änderung. Da FHEM aber nicht riechen kann, was der User möchte, muss der User sagen (bzw. konfigurieren) wie er die Events denn gerne hätte.
Dafür gibt es diese Attribute. Es gibt durchaus Einsatzszenarien, die solche zyklischen Events voraussetzen.
Der User ist also König und sollte daher wissen, wie er es denn gerne hätte, denn es stehen im alle Möglichkeiten zur Verfügung.
Gruß
Markus
Genau das habe ich gesagt. Ich habe keine Ahnung, wie du darin etwas anderes lesen konntest!? Das mit dem unklaren Sinn bezog sich auf den Beitrag vorher.
Ich nehme mal an, du hast den falschen user zitiert, andernfalls ist dein Beitrag "komisch".
Zitat von: Markus Bloch am 25 Januar 2016, 14:26:22Bei einem Watchdog brauch man zyklische Events dauerhaft
Das kann ich nachvollziehen.
Nur wiederspricht dann
readingsSingleUpdate mit
0 diesem.
Tut es nicht. Es gibt durchaus Readings (siehe Homematic), die nicht zwingend ein Event erzeugen müssen. Bei den Readings, die Events erzeugen können sollten, setzt der Entwickler die 1 und überlässt es dem User, wofür und wie er sie verwendet. Nutze ich sie in einem watchdog, setze ich event-on.* anders, als wenn ich sie im notify oder DOIF verwende usw. Was der User damit macht, kann der Autor nicht entscheiden, er kann aber sehr wohl entscheiden, bei welchen Readings Events sinnvoll sind. Bei den HM-Registern sind sie das ggf. zum Beispiel nicht (obwohl hier Events erzeugt werden, wenn ich das richtig in Erinnerung habe). Ich bleibe dabei: so sollte es sein.
Zitat von: Per am 25 Januar 2016, 14:44:01
Das kann ich nachvollziehen.
Nur wiederspricht dann readingsSingleUpdate mit 0 diesem.
Ich verstehe worauf du hinaus willst. Die 0 wurde vom Entwickler gewählt, weil dieses Reading nie ein Event erzeugen soll, da es keinen Sinn macht. Wie von marvin78 dargestellt ist das beispielsweise bei Registern so (HomeMatic, panStamp, ....) oder anderen konfigurativen Werten des Gerätes die nichts über den aktuellen Status aussagen. Zum Beispiel gilt dies bei Werten die nur nach explizitem zutun des Users erzeugt werden (getConfig, getRegister, ....), die aber nirgendswo regelmäßig ermittelt oder vom Gerät zyklisch oder auch nur bei Änderung übertragen werden.
Gruß
Markus