Hi,
ich verwende in vielen meiner Modulen sehr häufig eine if-Abfrage, bevor ich readingsBulkUpdate aufrufe. Zum Beispiel:
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
dazu gibt es doch das timestamp-on-change-reading attribut.
gruss
andre
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.
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?
ZitatFü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.
wie wäre es zusätzlich zu readingsBulkUpdate noch ein readingsBulkUpdateIfChanged einzubauen?
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
Wenn sie Dokumentiert wird muss die Authoren nicht drauf kommen, nur drauf kommen wo essa stehen könnte ;D
Zitat von: rudolfkoenig am 10 Oktober 2016, 16:39:17
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.
Zitat von: justme1968 am 10 Oktober 2016, 17:28:33
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...
Zitat von: Sidey am 10 Oktober 2016, 18:31:01
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...).
Zitat von: CoolTux am 10 Oktober 2016, 18:33:27
Wenn sie Dokumentiert wird muss die Authoren nicht drauf kommen, nur drauf kommen wo essa stehen könnte ;D
Naja über Änderungen bleibt man nicht unbedingt gut auf dem Laufenden, selbst wenn man die Subversion Commits recht aufmerksam verfolgt.
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
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
Ich wollte da jetzt nicht Diskutieren. Wollte nur kurz meine Meinung Kund tun :)
Grüße
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.
Habe readingsBulkUpdateIfChanged hinzugefuegt, bin ja schliesslich Dienstleister der Modulentwickler.
ZitatAber 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 :)
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.
Zitat von: rudolfkoenig am 10 Oktober 2016, 19:54:25
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
Ich finde es ist verständlich genug.
Zitat von: rudolfkoenig am 10 Oktober 2016, 19:54:25
Habe readingsBulkUpdateIfChanged hinzugefuegt, bin ja schliesslich Dienstleister der Modulentwickler.
Zitat von: Markus Bloch am 10 Oktober 2016, 22:23:41
Als Dokumentationsdienstleister, habe ich die neue Funktion ebenfalls in die Wiki-Doku übernommen: http://www.fhemwiki.de/wiki/DevelopmentModuleAPI#Erzeugen_von_Readings_.2F_Events (http://www.fhemwiki.de/wiki/DevelopmentModuleAPI#Erzeugen_von_Readings_.2F_Events)
Vorbildlich, alle beide. Rühren.
Zitat von: Sidey am 10 Oktober 2016, 20:08:17
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.
Genau nach diesem Prinzip sind alle meine Module gestrickt.
Die Attribute werden initial in der define-Methode gesetzt und durch ein if($init_done){} abgesichert, damit sie anschließend nur vom Anwender verändert werden können.
die meinung das attribute dem anwender gehören teile ich.
aber auch das ein modul beim ersten define sinnvolle vorgaben machen sollte damit alles funktioniert. damit der anwender die defaults sehen und verstehen kann reicht es nicht den default parameter von AttrVal zu verwenden. der ist von aussen unsichtbar.
ein beispiel bei dem es nützlich wäre die defaults bei attributen sichtbar zu machen ist übrigens webCmd. one das das attribut gesetzt ist erscheinen bei manchen devices on und off in der raum übersicht und einsteiger fragen sich wie sie das weg bekommen. das man webCmd auf : setzen muss erschliesst sich nicht. wenn das on off als voreingestellt default wert im device sichtbar wäre und nach dem löschen für immer weg ist wäre das logischer.
mit etwas aufwand kann man auch das setzen von default attributen so implementieren das der anwender danach attribute ändern und komplett löschen kann ohne das er durch immer neu angelegte defaults gegängelt wird. um das in allen fällen zu erreichen reicht es aber nicht auf $init_done zu prüfen. das deckt z.b. den modify fall nicht ab.
darum wäre es schön wenn es einen einfacheren weg gäbe das erste interaktive define eines neuen devices zur laufzeit vom define beim einlesen aus der config zu unterscheiden. damit könnte man es einsteigern erleichtern defaults vorzugeben ohne diese (unabsichtlich) aufzuzwingen.
Dafür prüfst du zusätzlich auch das Vorhandensein von $hash->{OLDDEF}. Hab ich bisher aber auch noch nicht eingebaut und fürs TC Module vergessen...
wie es geht weiss ich ;). ich sage ja nur das man es leicht vergisst :).
Ich habe heute mein Modul umgebaut von Hyperion_readingsBulkUpdateIfChanged auf nur readingsBulkUpdate da ich die allgemeine Meinung teile dass die Erstellung der Readings vom User über event-on-*-reading selbst beeinflussbar sein soll.
Des Weiteren habe ich meinem Modul ein neues Attribut hyperionAttrRestore spendiert. Im ungesetzten Zustand werden die Default Attribute immer wieder gesetzt wenn sie vom User gelöscht werden. Wird das Attribut auf 0 gesetzt unterbleibt die Erstellung der Default Attribute.
Ich denke das ist ein machbarer Weg. Man könnte die Funktion auch umdrehen.
Eventuell wäre was Ähnliches auch was für ein globales Attribut?
Gruß
Dan
</Amen>
Bitte für diese Diskussion dann auch ein neues Thema öffnen, ist hier OT.
Gruß
Julian
@justme1968:
- warum man default-Attribute bei einem modify setzen sollte, habe ich nicht verstanden.
- webCmd bei on/off/desired-temp im Modul zu setzen waere auch meiner Ansicht besser, allerdings muss das jedes Modul machen. Und webCmd betrifft nur FHEMWEB, d.h. die Module wuerden fuer einen der Frontends Attribute setzen, aber nicht fuer FLOORPLAN, etc.
@DeeSPe: ein Modul, was von mir geloeschte Attribute wieder anlegt, wuerde mich in Wahnsinn treiben. Hilfe mag nett sein, aber der Modulautor soll fuer mich bitte kein Erzieher sein.
nein. man soll sie ja eben beim modify nicht setzen. das passiert aber wenn man nur $init_done prûft.
Zitat von: Loredo am 11 Oktober 2016, 02:06:31
</Amen>
Bitte für diese Diskussion dann auch ein neues Thema öffnen, ist hier OT.
Auch wenn OT fand ich die Diskussion sehr nützlich und hab mal geschaut wie Du es jetzt verbessert hast und es bei mir auch entsprechend angepasst.
Danke!!!
Zitat von: rudolfkoenig am 11 Oktober 2016, 08:15:39
@DeeSPe: ein Modul, was von mir geloeschte Attribute wieder anlegt, wuerde mich in Wahnsinn treiben. Hilfe mag nett sein, aber der Modulautor soll fuer mich bitte kein Erzieher sein.
Du hast absolut Recht! Habe mein Modul angepasst und lasse (nach Vorlage von Loredo) die default Attribute nur noch beim define mit anlegen.
Zitat von: justme1968 am 11 Oktober 2016, 08:22:09
nein. man soll sie ja eben beim modify nicht setzen. das passiert aber wenn man nur $init_done prûft.
Ich hoffe das passt endgültig mit Loredo's Vorlage:
if ($init_done && !defined $hash->{OLDDEF})Habe es in allen möglichen Situationen getestet (define/modify/restart) und es macht was es soll.
Gruß
Dan