Timestamp bei unverändertem Reading behalten

[Loredo]

Hi,


ich verwende in vielen meiner Modulen sehr häufig eine if-Abfrage, bevor ich readingsBulkUpdate aufrufe. Zum Beispiel:

Code Auswählen Erweitern


readingsBulkUpdate($hash, "state", "on")
  if(ReadingsVal($hash, "state", "") ne "on");



Damit möchte ich zwei Dinge erreichen:


1. Es soll kein Event erzeugt werden, wenn sich der Wert nicht verändert hat, da es nur sehr selten Sinn macht, insbesondere bei Geräten, die gepollt werden. Nur bei Readings, bei denen ich explizit davon ausgehe, dass man einen Verlauf loggen möchte, lasse ich die if-Abfrage weg und überlasse dann event-on* komplett das Feld.
2. Ich möchte, dass {TIME} nur aktualisiert wird, wenn gleichzeitig auch eine Änderung erfolgt ist. Lasse ich die if-Abfrage weg, dann wird zwar je nach Usereinstellung mit event-on-* kein Event erzeugt, jedoch wird der Zeitwert trotzdem aktualisiert, was insbesondere bei gepollten Geräten auch nicht wirklich viel Sinn macht.


Da es aber überall wiederkehrender Code ist das Reading auf seinen bisherigen Wert hin zu prüfen frage ich mich: Kann ich diese Prüfung nicht einfach von readingsBulkUpdate erledigen lassen, beispielsweise wenn ich dort noch einen weiteren Parameter angebe, der dann die Änderungsprüfung für mich vornimmt? Gefühlt würden dadurch viele meiner Module um 20% weniger Quellcode haben...




Gruß
Julian

[justme1968]

dazu gibt es doch das timestamp-on-change-reading attribut.

gruss
  andre

[Loredo]

Das ist aber relativ neu, oder? Bei Bestandsmodulen würde das zu großer Verwirrung führen, wenn sich das Verhalten auf einmal komplett änderte. Da müssten ja nun auf einmal alle Benutzer Hand anlegen, um das ursprünglich gewohnte (und auch gewünschte) Verhalten wieder zu erlangen.
Das Attribut timestamp-on-change dabei fernzusteuern oder zu befüllen finde ich nicht so toll.



Außerdem bin ich ja ein Vertreter der Convenient-Fraktion (wie man weiß) und möchte das eigentlich aus dem Modul heraus steuern wenn ich weiß, dass Readings nur bei Änderung ein Event und auch den Timestamp geändert haben sollen. Aber soweit ich weiß machen diese Abfrage sehr viele Autoren in ihren Modulen (auch bei dir André hab ich's glaub ich - lobenswerter Weise wie ich finde - häufig gesehen).




Ich würde die event-on-* und timestamp-on* Attribute auch nur als Notnagel für den User sehen, wenn ihm das Modulverhalten nicht gefällt oder er eben individuell FHEM Resourcen einsparen möchte. In erster Linie finde ich sollte sich immer der Modulautor darüber Gedanken machen, wie und wann er Readings erzeugt, löscht und aktualisiert und ob er dabei Events auslöst und den Timestamp aktualisiert.


Für mich gehört es eben bei 95% aller Fälle dazu ein Reading nur zu aktualisieren, wenn es tatsächlich eine Änderung erfahren hat. Wenn ich mir aber meine if-Abfragen sparen will, dann muss ich in Kauf nehmen, dass sich der Timestamp alle 30 Sekunden bei _allen_ Readings ändert. Das ist ein Verhalten, was ich als Modulautor schon nicht will und IMHO wollen es die wenigsten Nutzer so haben. Ausgenommen Werte, die man statistisch erfassen will und bei denen man nicht nur die Änderung protokollieren möchte. Da fallen mir aber eben nur sowas wie Temperatur, Feuchtigkeits- sowie Verbrauchtswerte ein.

[rudolfkoenig]

event-on-change (wie alle Attribute) ist eigentlich fuer die Benutzer gedacht, nicht fuer die Modulautoren.

Zu Julians urspruenglicher Frage: bin noch unsicher, ob es Wert ist wegen einer relativ trivialen Aufgabe den Anzahl der readingsBulkUpdate Parameter zu erhoehen, und damit noch mehr Modulautoren verwirren. Einige verstehen schon jetzt nicht den letzten Parameter. Waere schlimm, wenn in deinem Modul eine zusaetzlich Funktion diese Abfrage macht?

Für mich gehört es eben bei 95% aller Fälle dazu ein Reading nur zu aktualisieren, wenn es tatsächlich eine Änderung erfahren hat.

Und mich beruhigt es, wenn ich weiss, dass bestimmte Daten immer noch gemeldet werden.
Das Modul muss ja deswegen noch lange kein Event generieren, siehe besagten Parameter.

[justme1968]

wie wäre es zusätzlich zu readingsBulkUpdate noch ein readingsBulkUpdateIfChanged einzubauen?

[Sidey]

Den Vorschlag mit einer weiteren ReadingsBulkUpdate Variante halte ich auch für am besten um bestehendes nicht zu ändern.

Allerdings müssen die Modulatoren dann auch erst mal darauf kommen, dass es diese Funktion gibt.

Grüße Sidey

[CoolTux]

Wenn sie Dokumentiert wird muss die Authoren nicht drauf kommen, nur drauf kommen wo essa stehen könnte 

[Loredo]

Und mich beruhigt es, wenn ich weiss, dass bestimmte Daten immer noch gemeldet werden.

Naja, ich programmiere meine Module deshalb lieber etwas Fehlertoleranter und Kommunikationsfreudiger. Wenn was nicht stimmt, sieht man das auch so und kann ansonsten davon ausgehen, dass alles in Ordnung ist.

wie wäre es zusätzlich zu readingsBulkUpdate noch ein readingsBulkUpdateIfChanged einzubauen?

Wäre auch ok, damit nicht jeder die gleiche Funktion in sein Modul einbaut. Aber mache ich natürlich gerne ansonsten, wenn es sonst wieder keiner braucht außer mir...

Allerdings müssen die Modulatoren dann auch erst mal darauf kommen, dass es diese Funktion gibt.

Naja der Unterschied ist ja nicht groß. Man könnte auch die bestehende Version mit einem weiteren, optionalen Parameter versehen oder gar den vorhandenen letzten Parameter so erweitern, dass man dort nicht nur 0 und 1 verwenden kann, sondern dann eben auch 2, um das Verhalten entsprechend zu ändern.
Eine Anpassung müsste ein Autor in jedem Fall vornehmen (wenn er wollte. ist ja alles kein muss...).

Wenn sie Dokumentiert wird muss die Authoren nicht drauf kommen, nur drauf kommen wo essa stehen könnte 

Naja über Änderungen bleibt man nicht unbedingt gut auf dem Laufenden, selbst wenn man die Subversion Commits recht aufmerksam verfolgt.

[CoolTux]

Meine Meinung dazu.
Es sollte dem User überlassen werden. Es gibt entsprechende Werkzeuge für den User. Vielleicht möchte der User das ein bestimmtes Reading einen neuen Timestamp auch ohne Änderung bekommt, um zu wissen das überhaupt noch was kommt.


Grüße

[Loredo]

Diese Grundsatzdiskussion wollte ich hier nich (schon wieder) führen.

In meinen Modulen bleibt das Verhalten so wie es ist. Ich lebe damit erstmal die if-Abfrage drin zu behalten und behelfe mir mit einer Modul-internen Helfer-Funktion, wenn ich mal Zeit habe das alles umzustellen.

Ich denke wir können die Diskussion hier beenden.

Danke.


Gruß

Julian

[CoolTux]

Ich wollte da jetzt nicht Diskutieren. Wollte nur kurz meine Meinung Kund tun 


Grüße

[Loredo]

Na ich kenn das ja.


Meine Philosophie ist eben, dass ein Modul brauchbar sein muss, nachdem ich ein define gemacht habe und ich nicht erst noch kompliziert überlegen muss, ob ich sowas wie event-on-* oder timestamp-on-* setzen sollte oder nicht und wenn ja wie setze ich es denn dann überhaupt richtig und sinnvoll... Das nehme ich meinen Nutzern gerne ab, denn ich habe mich tiefgehend mit dem Verhalten des zu steuernden Endgerätes befasst und kann das viel besser beurteilen, als jemand der hinterher nur die Readings in FHEM anguckt und einen set-Befehl schickt. Ich möchte von meinen Usern nicht verlangen müssen, dass sie sich quasi den Quellcode durchlesen müssen um zu verstehen, weshalb man hier und dort in jedem Fall kein Event haben will etc.

Ich (Entschuldigung) hasse jedes Modul das mich zwingt, dass ich mich als Anwender erstmal tiefer mit dessen Verhalten befassen und jede Menge Attribute setzen muss, damit es mir nicht das Logfile oder die Eventqueue zumüllt und sich Resourcen schonend und überhaupt so verhält, wie man das normal erwarten würde. Dann brauche ich kein Modul und kann mir selbst was zusammen hacken, wenn es mir hier keine Arbeit abnimmt.

Aber ich weiß ja inzwischen, dass ich mit meiner Philosophie der Einfachheit und Convenience für den Benutzer ziemlich alleine dastehe.
Da hats hier nur mal wieder eine Erinnerung dran gebraucht. Danke dafür.

[rudolfkoenig]

Habe readingsBulkUpdateIfChanged hinzugefuegt, bin ja schliesslich Dienstleister der Modulentwickler.

Aber ich weiß ja inzwischen, dass ich mit meiner Philosophie der Einfachheit und Convenience für den Benutzer ziemlich alleine dastehe.

Das ist subjektiv, und will vermutlich jeder von sich behaupten

[Sidey]

Hallo Loredo,

Du bist nicht alleine.
Ich sehe das Ähnlich, der Einstieg FHEM ist nicht gerade einfach.
Jemand der nur mal schnell was automatisieren will, darf sich erst mal mit PERL und jeder Menge unterschiedlicher Verhalten der Module beschäftigen.

Das Attribute dem Anwender gehören ist ja glaube ich Konsens.
Ich denke, es ist aber auch nicht verboten Attribute mit Sinnvollen Defaults zu belegen.
Das geht bei Geräten, welche via Autocreate angelegt werden einfacher, als bei Geräten, welche mittels Define angelegt werden.
Vielleicht schafft man es ja, zu erkennen wann ein Gerät erstmalig angelegt wurde und kann dann Attribute einmalig vorbelegen.

So hat hat der Erfahrene Anwender die Möglichkeit alles zu ändern und der 0815 Anwender hat gleich ein Gerät, das gut funktioniert und muss sich nicht mit den Details beschäftigen.

[Markus Bloch]

Habe readingsBulkUpdateIfChanged hinzugefuegt, bin ja schliesslich Dienstleister der Modulentwickler.

Als Dokumentationsdienstleister, habe ich die neue Funktion ebenfalls in die Wiki-Doku übernommen: http://www.fhemwiki.de/wiki/DevelopmentModuleAPI#Erzeugen_von_Readings_.2F_Events

Schaut mal bitte, ob das verständlich beschrieben ist.

Vielen Dank

Gruß
Markus