gelöst : NotifyAbwesendIn3Min already defined, delete it first

Begonnen von Sauron, 12 März 2014, 15:11:51

Vorheriges Thema - Nächstes Thema

Sauron

#15
Zitat von: der-Lolo am 13 März 2014, 09:00:51
Guten Morgen Sauron,
ich fragte mich einfach noch warum es überhaupt zu dem doppeltem anlegen deiner at + definition kam, hier gäbe es zwei möglichkeiten - die erste wäre das der Schalter dir sein event "on" mehrfach liefert - das könntest du unterdrücken wenn du das attribut event-on-change für den schalter setzt. Dann wird wie der name schon sagt nur ein neues event generiert wenn es sich zum vorherigen event geändert hat. Der schalter also seinen state ändert.
......
Die zweite möglichkeit wäre das du den Taster innerhalb der definierten zeit mehrfach betätigt hast... dann wärst du die fehlerquelle ;-).

In dem Fall war es wohl zweitens. Seit ich es auf den Ubuntu umgezogen habe hatte ich das Problem nur noch sehr selten. Am Anfang hatte ich beobachtet als ich auf der Fritzbox war, dass der Druck auf einen Button in der Oberfläche (nicht der physikalische Schalter) immer zwei events auslöste, da hatte ich die Fehlermeldung dann ständig. Dass der define des @ nach der Zeit X wieder verschwindet war der Schlüssel der mir fehlte (hatte mich gewundert, warum es manchmal ging und manchmal nicht). Der Doppelaufruf war interessanter weise auch, wenn ich in einer Routine den set Programmtechnisch  { fhem ("set zurueck_melden off") }; setzte, die abhängige Methode wurde doppelt aufgerufen, wollte mich da noch darum kümmern ist aber vermutlich seit es auf Ubuntu läuft weg, zumindest nicht mehr reproduzierbar.

Zitat von: der-Lolo am 13 März 2014, 09:00:51
Dieses attribut macht oft sinn in FHEM da es einige Sensoren z.b. gibt die innerhalb einer gewissen zeit senden, auch ohne wertänderung. Ein temperatur sensor liefert z.b. alle drei minuten seine temperatur, auch wenn sie sich nicht geändert hat. Wenn du nun auf die temperatur triggerst kommt der trigger eben alle x minuten neu. wenn das attribut aktiv ist kommt das event nur wenn sich der trmperaturwert wirklich geändert hat.
Das ist eine Klasse info, das werde ich bei allen Tempertur und Fenstersensoren nachtragen, dann ist auch das ständige Klicken an der Dustabzugshaube gelöst.

Zitat von: der-Lolo am 13 März 2014, 09:00:51
Mit dem Schnipsel vom puschel schipperst du um das problem herum löst es aber meiner meinung nach nicht. Mal davon abgesehen das es ja eh "nur" um einen schönheitsfehler geht.
Das es nur Schönheit ist, wusste ich bis zum Posting noch nicht, der log bleibt so "sauber". 

Deudi

#16
ZitatDas ist eine Klasse info, das werde ich bei allen Tempertur und Fenstersensoren nachtragen, dann ist auch das ständige Klicken an der Dustabzugshaube gelöst.

Das Attribut event-on-change ist für einige geschwätzige Dinge eine nette Sache (z.B. YAMAHA_AVR, FBDECT) aber ich habe es für die Temperatursensoren und Thermostate wieder entfernt. Im Plot sieht es nämlich blöd aus, wenn zwischen zwei geänderten Werten eine direkte Verbindungslinie gemalt wird. Oder gibt es dafür eine andere Abhilfe?

Gruß Deudi
Gigabyte Brix, Ubuntu 16.04.3 LTS, Homematic, Z-Wave, EnOcean, Shelly@MQTT, SIGNALduino, JeeLink DAVIS-Sketch

der-Lolo

Abhilfe ist einfach - kein event on change benutzen, und stattdessen auf der ausführenden seite einen FILTER nutzen... sodass die schaltung nur anspricht wenn sie auch wirklich einen zustand ändern soll, das würde wahrscheinlich auch beim dunstabzugklicken helfen...
grundsätzlich muss man sich halt entscheiden, brauch man die werte die ein Sensor liefert auch in plots brauch oder eben nicht...
Es wird halt eine linie zwischen den letzten zwei werten erstellt, die dann mehr oder weniger schräg ausschaut...
Manchmal hilft event on change auch bei performance problemen...