vorschlag: neues attribut timestamp-on-change-reading

Begonnen von justme1968, 21 April 2016, 14:54:31

Vorheriges Thema - Nächstes Thema

Dr. Boris Neubert

#15
Zitat von: justme1968 am 23 April 2016, 10:21:59
bei der 'kleinen' variante bleibt jetzt die frage was der default sein soll. so wie bisher oder nur wenn es auch ein event gab. ich denke beides ist in sich konsistent aber letzteres ist der häufigere anwendungsfall. deshalb sollte das der default sein.

events die gefiltert werden 'verschwinden' dann sozusagen komplett.

Bin mir nicht sicher, ob Du das meinst, was ich herauslese. Unabhängig davon, ob der Default ist, den Timestamp nur bei einer Änderung des Readings oder bei einem Setzen des Readings zu aktualisieren, sollte der Mechanismus unabhängig davon sein, wie event-on-update-reading und event-on-change-reading gesetzt sind. Ich glaube, dass eine Kopplung der Mechanismen zu nicht mehr durchschaubarem Verhalten und noch schwerer wartbaren Code führt als jetzt schon.

Das Attribut würde wie folgt aufgerufen (ich schreibe das so, dass das gleich in die Commandref aufgenommen werden könnte):

Zitatattr <name> timestamp-on-change-reading reading1,reading2,reading3,...

The attribute takes a comma-separated list of readings. You may use regular expressions in that list.
For the listed readings of the device <name>, the timestamp is updated if and only if the value of the reading has changed. In other words: for a reading in the list, the timestamp of the reading is unchanged and remains at the time of the most recent change of the reading when the reading is updated but the new value is identical to the previous value. The list of readings can be empty.

Jetzt zur Frage des Defaults:

Variante 1: der Timestamp wird nur gesetzt, wenn sich der Wert des Readings geändert hat.

Zitat
When the attribute is not set, the default behavior is to change the timestamp for all readings of the given device <name> if and only if the value of the reading has changed. To achieve the opposite behavior, i.e. to always set the timestamp of any reading no matter if an update of the reading has changed its value or not, you have to set the attribute with an empty list:

attr <name> timestamp-on-change-reading

Variante 2: der Timestamp wird immer gesetzt, wenn der Wert des Readings ein Update erfahren hat.

Zitat
When the attribute is not set, the default behavior is to change the timestamp for all readings of the given device <name> whenever the reading is updated, no matter if its value has changed or not.

To achieve the opposite behavior, i.e. to only set the timestamp of any reading if an update of the reading has changed its value, you have to set the attribute:

attr <name> timestamp-on-change-reading .*

Variante 2 ist abwärtskompatibel und in sich schlüssig/intuitiv: ich muss das Attribut setzen und die Readings angeben, für die ich das erreichen will, was die Bezeichnung des Attributs aussagt: timestamp-on-change-reading. Ich kann das Default-Verhalten für alle Geräte mit

attr .* timestamp-on-change-reading .*

leicht umkehren.

Ich plädiere für Variante 2.

Viele Grüße
Boris



EDIT: es soll überall timestamp-on-change-reading heißen
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

rudolfkoenig

Zitatsollte der Mechanismus unabhängig davon sein, wie event-on-update-reading und event-on-change-reading gesetzt sind.
Ich bin auch dafuer. Die nachfolgenden Texte haben mich verwirrt, weil da von einem timestamp-on-update-reading die Rede war. Ich wuerde bei "timestamp-on-changed-reading" bleiben, und falls jemand sowas braucht, der soll es setzen. Falls ich was einchecken soll, bitte explizit sagen.

justme1968

timestamp-on-update-reading wäre die variants gewesen bei der der timestamp als default nur noch bei einem event aktualisiert wird und man mit dem attribut das bisherige verhalten wieder herstellen möchte. das scheinen wir inzwischen verworfen zu haben.

wenn das default verhalten bleibt und man die timestamps abschalten will wenn es kein event gibt wäre das attribut timestamp-on-change-reading.

das wäre dann der patch aus dem ersten post. ich schaue mir den patch noch mal und ob alles was diskutiert wurde schon drin steckt und auch ob man den weiter oben beschrieben fehler beim ersten anlegen nicht auch gleich weg bekommt.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Dr. Boris Neubert

Zitat von: rudolfkoenig am 24 April 2016, 19:18:25
Ich bin auch dafuer. Die nachfolgenden Texte haben mich verwirrt, weil da von einem timestamp-on-update-reading die Rede war. Ich wuerde bei "timestamp-on-changed-reading" bleiben, und falls jemand sowas braucht, der soll es setzen. Falls ich was einchecken soll, bitte explizit sagen.

Ich war beim Schreiben verwirrt. Es sollte "timestamp-on-change-reading" heißen. Ich habe meinen Beitrag angepasst. Ich hoffe, dass es jetzt verständlich ist.
Globaler Moderator, Developer, aktives Mitglied des FHEM e.V. (Marketing, Verwaltung)
Bitte keine unaufgeforderten privaten Nachrichten!

justme1968

anbei ein patch der den fehler beim filtern behebt wenn ein reading das erste mal angelegt wird, ansonsten das default verhalten beibehält und ein timestamp-on-change-reading attribut einführt.

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

Habs eingecheckt (bis auf das Entfernen der quiet Option von cancel in commandref_frame.html)

Sidey

Hallo allerseits,

bitte entschuldigt, das sich diesen 120 Tage alten Thread wieder reaktiviere.
Bringt aber meiner Meinung nach nichts, die Unklarheit in einem neuen Beitrag zu beantworten.

Ich habe mir den Thread durchgelesen und hatte dann ein gewisses Bild:

Zitat von: Dr. Boris Neubert am 23 April 2016, 11:21:27
Unabhängig davon, ob der Default ist, den Timestamp nur bei einer Änderung des Readings oder bei einem Setzen des Readings zu aktualisieren, sollte der Mechanismus unabhängig davon sein, wie event-on-update-reading und event-on-change-reading gesetzt sind. Ich glaube, dass eine Kopplung der Mechanismen zu nicht mehr durchschaubarem Verhalten und noch schwerer wartbaren Code führt als jetzt schon.

Zitat von: Dr. Boris Neubert am 23 April 2016, 11:21:27
Variante 2: der Timestamp wird immer gesetzt, wenn der Wert des Readings ein Update erfahren hat.

Variante 2 ist abwärtskompatibel und in sich schlüssig/intuitiv: ich muss das Attribut setzen und die Readings angeben, für die ich das erreichen will, was die Bezeichnung des Attributs aussagt: timestamp-on-change-reading. Ich kann das Default-Verhalten für alle Geräte mit

attr .* timestamp-on-change-reading .*

leicht umkehren.

Ich plädiere für Variante 2.




Zitat von: rudolfkoenig am 24 April 2016, 19:18:25
Ich bin auch dafuer. Die nachfolgenden Texte haben mich verwirrt, weil da von einem timestamp-on-update-reading die Rede war. Ich wuerde bei "timestamp-on-changed-reading" bleiben, und falls jemand sowas braucht, der soll es setzen. Falls ich was einchecken soll, bitte explizit sagen.


Vielleicht habe ich Tomaten auf den Augen, dann helft mir bitte. Wenn ich die Beitrag richtig verstehe, dann hat man doch sehr stark argumentiert, dass das Setzen eines Readings und das Auslösen eines Events unabhängig voneinander sein soll.

Als ich auf die Commandref aufmerksam gemacht wurde, habe ich gestaunt:
Zitat
timestamp-on-change-reading
Dieses Attribut enthält eine durch Kommata getrennte Liste von "readings". Wenn gesetzt, werden die Zeitstempel der gelisteten "readings" nicht aktualisiert wenn durch ein ebenfalls gesetztes event-on-change-reading für dieses "reading" kein Ereignis erzeugen würde.

timestamp-on-change-reading ist nicht unabhängig von event-on-change-reading implementiert.
Genauer gesagt, das Attribut alleine kann nicht verwendet werden.
Es wurde nicht Variante 2 implementiert und man kann es auch nicht leicht für alle Readings umkehren.

Bestimmt habe ich etwas übersehen oder etwas falsch interpretiert?
Wenn nicht, war das ein Versehen und keiner hat es gemerkt oder gab es noch einen weiteren Thread in dem die Funktionsweise des Attributes diskutiert wurde?

Gibt es irgendeinen sinnvollen Anwendungsfall, wofür man das eine Attribut mit dem anderen koppeln sollte?
Auf Anhieb ist mir nichts eingefallen, wieso man das nicht unabhängig voneinander setzen können sollte. Das wäre doch viel einfacher, als überall event-on-change-reading .* setzen zu müssen, wo man den timestamp nicht aktualisieren möchte.


Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker