Zusammenspiel von event-on-change-reading und event-min-interval?

[Tobias]

Hi,
ich habe einen Tür/Fensterkontakt (1wire, DS2413) den ich alle 10sek abfrage.
Ziel ist es nur dann ein event zu generieren, falls sich der Zustand ändert oder aber alle 30min einmal.
Dazu habe ich folgendes definiert:

Code Auswählen Erweitern

attr tuer event-on-change-reading A,B
attr tuer event-min-interval A:1800,B:1800

Aber irgendwie klappts nicht, es wird, falls die Tür zu bleibt, nach 30min kein event generiert.
Wo ist mein Denkfehler?

[Carsten]

Hallo,

wenn ich mich nicht irre, ist event-min-interval nicht dafür gedacht. Ich glaube, das hat Rudi eingebaut, um bei den Fritz!Dect200 Schaltern, die relativ häufig ihre Werte melden, zu verhindern, dass diese Meldungen das Protokoll vollmüllen. Daher wird defaultmäßig nur alle 2 Minuten ein Wert akzeptiert. Werte, die weniger als <event-min-interval> Sekunden nach dem letzten Wert gesendet werden, werden ignoriert. In deinem Fall würde eine Änderung von A oder B nur dann verarbeitet, wenn die letzte Änderung mindestens 30 Minuten her ist.

[Tobias]

hmm, schade... gibts Alternativen? Oder muss ich ein Attribut "event-max-interval" im fhem.pl erfinden?

[Rohan]

Hi Tobias,

ist zwar evtl. von hinten durch das Knie ins Auge, aber vlt. kann man das hier von der Grundidee entsprechend umwandeln:

1. Loggen bei Änderungen
2. Spätestens nach XYZ Sekunden

Umwandeln geht bestimmt; Frage ist nur, ob es nicht mit fhem-eigenen Mitteln einfacher geht, aber da sind andere gefragt.

Gruß
Thomas

[Tobias]

von der grundidee nicht schlecht, funktioniert aber nur mit einem(!) Sensor da es nur eine(!) globale Variable ist. Es wird merkwüdige Effekte Geben wenn mehrere Sensoreren dieselbe VAriable nutzen ;) ;)
Aber ich überleg mir noch etwas. Am besten wird es wohl sein die FnFunctions mit event-max-interval zu erweitern. Dann hat man etwas fhem-übergreifendes

[rudolfkoenig]

Ich meine ich habe das Problem (hoffentlich ohne Nebenwirkungen) behoben.

[Tobias]

Ich meine ich habe das Problem (hoffentlich ohne Nebenwirkungen) behoben.

kannst du das etwas genauer beschreiben? Was hast du wo und wann behoben?
gruss

[Bochi]

kannst du das etwas genauer beschreiben? Was hast du wo und wann behoben?

Das würde mich auch sehr interessieren :-)

Ich habe ein ähnliches Szenario, bei dem sich Dummy-Devices die Values für die userReadings per GetFileFromURL holen, und das würde ich auch gerne automatisiert ohne das Device togglen zu müssen alle 5 Minuten abfragen lassen. Ich habe ewig gegoogled etc aber leider keine Lösung dafür gefunden...

Danke und Gruß
Stefan

[rudolfkoenig]

Das ist mir zu hoch: dummy generiert keine events, hat dementsprechend auch kein event-min-interval/etc. als Attribut.

[Bochi]

Das ist mir zu hoch: dummy generiert keine events, hat dementsprechend auch kein event-min-interval/etc. als Attribut.

Hmm, dann habe ich möglicherweise etwas missverstanden. Ich lege meinen Plan mal genau dar:

Ich habe einen kleinen Serverschrank, in welchem ich Temperaturgesteuert die Lüfter mittels FS20 Steckdosen steuere.
Jeder Rechner in dem Schrank hat einen httpd laufen und liefert über

Code Auswählen Erweitern

 http://<server>/temp.txt

die aktuelle Temperatur.

Bislang habe ich einen cronjob + shellscript, welches alle 5 Minuten die Temperatur checkt und dementsprechend die Lüfter an/ausschält.

Jetzt hab ich mir gedacht ich könnte mal versuchen, das innerhalb von FHEM abzubilden. Also hab ich dummies für die verschienenden Rechner angelegt und denen mittels

Code Auswählen Erweitern

 # attr <server> userReadings temp { GetFileFromURL("http://<server>/temp.txt") }

ein Reading für die Temperatur hinzugefügt.

Jetzt habe ich jedoch offenbar event-on-change-reading falsch verstanden. Ich dachte, damit könnte man eine Regel erstellen, bei der zB. wenn die Temperatur (das Reading) sich ändert ein Script ausführen... Mist.

Wenn ein Dummy keine Events kann, dann ist der Weg, den ich hier einschlagen wollte von Anfang an zum Scheitern verurteilt, oder?

Gruß
Stefan

[Bochi]

Hmm, und nochwas, laut xmllist:

Code Auswählen Erweitern

<dummy name="xbmc" state="76" sets="*" attrs="room group comment alias eventMap userReadings loglevel:0,1,2,3,4,5,6 setList event-on-change-reading event-on-update-reading event-min-interval stateFormat devStateIcon group_map icon sortby structexclude webCmd">
  <INT key="NAME" value="xbmc"/>
  <INT key="NR" value="92"/>
  <INT key="STATE" value="76"/>
  <INT key="TYPE" value="dummy"/>
  <ATTR key="room" value="hidden"/>
  <STATE key="temp" value="76" measured="2013-05-07 09:05:15"/>
</dummy>

hat mein Dummy (das ist einer der Rechner, die ich angelegt hab) sehr wohl event-on-change/update-reading?

Gruß
Stefan

[rudolfkoenig]

Ok, da muss ich wohl klein beigeben: dummy generiert beim "set" doch ein Event, und in diesem Zusammenhang kann man diese Attribute verwenden. Die Attribute filtern anderweitig ausgeloeste Events, und erzeugen selbst keine. D.h. deine Loesung ist vmtl. praktikabel, die Ausfuehrung muss nur explicit durch irgendein set der dummy angestossen werden.

UserReading ist aber mAn umstaendlich: ich wuerde in einem at alle Daten abholen, und die Ergebnisse den unterschiedlichen dummys zuweisen.
Da diese Zuweisung ein event generiert, kann man das auch per FileLog einfangen und plotten.

[Tobias]

Hi,
ich möchte nochmal meinen "Wunsch"/Sollzustand formulieren.
1. jede Änderung des vorherigen wertes soll auf jeden Fall ein event auslösen
2. Bleibt der Wert bei Folgemessungen identisch, so soll nur alle 15min ein event generiert werden.
Ich habe jetzt testweise so gelöst. Zumindest funktioniert nun Punkt 2

Code Auswählen Erweitern

event-min-interval -> temperature:900,humidity:900,battery:3600
event-on-update-reading  -> humidity,temperature,battery
Allerdings scheint Punkt 1 nicht zu funktionieren. Ich habe "event-min-interval" so interpretiert, das Wertänderungen bezogen auf die letzte Messung unabhängig des eingestellten Intervalls sofort ein Event auslösen.
Hier mal das Log. Änderungen der Temperatur treffen auch nur im 15min Raster ein. Erwartet hätte ich die ÄnderungsWerte außerhalb des 15min Rasters

Logeinträge anzeigen

Code Auswählen Erweitern

get DbLog - - 2013-05-24 2013-05-25 Arbeitszimmer_EG_Raumtemp:temperature

2013-05-24_00:10:10 20.3
2013-05-24_00:25:47 20.3
2013-05-24_00:41:22 20.3
2013-05-24_00:56:59 20.3
2013-05-24_01:12:37 20.3
2013-05-24_01:28:14 20.2
2013-05-24_01:43:54 20.2
2013-05-24_02:00:34 20.2
2013-05-24_02:16:11 20.2
2013-05-24_02:31:51 20.2
2013-05-24_02:47:30 20.1
2013-05-24_03:03:10 20.1
2013-05-24_03:18:50 20.1
2013-05-24_03:34:29 20.1
2013-05-24_03:50:09 20.1
2013-05-24_04:06:48 20.1
2013-05-24_04:22:28 20.1
2013-05-24_04:38:08 20
2013-05-24_04:53:48 20
2013-05-24_05:09:28 20
2013-05-24_05:25:08 20
2013-05-24_05:40:50 20
2013-05-24_05:56:34 19.9
2013-05-24_06:12:16 20
2013-05-24_06:28:00 19.9
2013-05-24_06:43:42 19.9
2013-05-24_06:59:26 19.9
2013-05-24_07:16:09 19.9
2013-05-24_07:31:53 19.9
2013-05-24_07:48:34 19.9
2013-05-24_08:04:19 19.9
2013-05-24_08:20:04 19.9
2013-05-24_08:35:49 19.9
2013-05-24_08:51:34 20
2013-05-24_09:07:20 19.9
2013-05-24_09:24:06 19.9
2013-05-24_09:39:48 19.8
2013-05-24_09:55:28 19.9
#Arbeitszimmer_EG_Raumtemp:temperature:::
[/spoiler]

[justme1968]

wenn man einen dummy zusammen mit den user readings einsetzt ist es wichtig nicht per set den state zu setzen sondern seinen wert wirklich in ein reading zu schreiben. wenn man state verwendet wird das user reading immer ein event zeitversetzt zu spät aktualisiert weil fhem zuerst die userReadings aktualisiert und dann erst set aktualisiert. wärend die user readings aktualisiert werden hat state und damit Value() noch den alten wert! wenn man richtige readings stat state verwendet kann man dann auch ohne probleme mehr als nur ein reading in einem dummy haben.

wenn man statt set readingsSingleUpdate() verwendet gibt es das problem nicht. einen schönen STATE für die weboberfläche kann man sich dann mit stateFormat bauen.

Beispiel anzeigen

etwa so:

Code Auswählen Erweitern

define NiederschlagXXX dummy
attr NiederschlagXXX stateFormat {ReadingsVal($name,"niederschlag",0)}
attr NiederschlagXXX userReadings niederschlag differential {ReadingsVal($name,"niederschlag_cum",0)*3600}


Code Auswählen Erweitern

define getNiederschlagXXX at +*00:15:00 {
  my $niederschlag = getNiedschlag("XXX");

  my $hash =  $defs{NiederschlagXXX};
  readingsSingleUpdate($hash,"niederschlag_cum", $niederschlag, 1) if( defined($hash) );
} getNiederschlag() holt sich eine webseite mit GetHttpFile und gibt den darin gefunden jahresniederschlag zurück.
[/code]
das zweite problem ist das man ohne den patch hier Link dummys nicht vernünftig mit dbLog loggen kann.

dem wunsch das event-min-interval und event-on-update-reading in der von tobias gewünschten weise zusammen arbeiten kann ich mich aber nur anschliessen.

gruss
  andre

[Tobias]

ich glaube ich habe die Lösung.
Nach etwas längerem "lesen" der fhem.pl im Abschnitt der "ReadingsUpdate*" Funktionen muss man sowohl event-on-update als auch event-on-change definieren.

Code Auswählen Erweitern

event-min-interval -> temperature:900,humidity:900,battery:3600
event-on-update-reading  -> humidity,temperature,battery
event-on-change-reading  -> humidity,temperature,battery

Damit sieht es bei mir so aus:

Code Auswählen Erweitern

2013-05-24_12:16:42 19.9
2013-05-24_12:31:23 19.9
2013-05-24_14:39:10 20
Man sieht, das die 20°C genau 8min nach den letzten 19°C geloggt wurden, trotz einem MinInterval von 15min

Da müssen wir die commandref noch detaillieren ;)