readingsSingleUpdate

[Per]

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).

Code Auswählen Erweitern

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.

[Per]

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.

Code Auswählen Erweitern

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 .

[betateilchen]

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.

[Per]

sollte 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.

[marvin78]

Der Sinn ist aber unklar. event-on-*-reading gibt dem User die Möglichkeit, die Events zu beeinflussen. So sollte es sein.

[Per]

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.

[marvin78]

Das hast du falsch verstanden.

Ach und die Begründungen sind nicht entgegen gesetzt. 

[Markus Bloch]

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

[marvin78]

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".

[Per]

Bei einem Watchdog brauch man zyklische Events dauerhaft

Das kann ich nachvollziehen.

Nur wiederspricht dann readingsSingleUpdate mit 0 diesem.

[marvin78]

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.

[Markus Bloch]

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