event-aggregator verhält sich nicht wie erwartet

[abc2006]

Hallo,
ich habe mal wieder Probleme mit event-aggregator.
Es gibt hier ein paar Themen, die beschreiben, dass das downsampling nicht wie erwartet funktioniert:
https://forum.fhem.de/index.php/topic,112837.msg1071798.html#msg1071798
https://forum.fhem.de/index.php/topic,113247.msg1075507.html#msg1075507

Leider hat noch niemand geantwortet. Fehlen Informationen? Wurde ein Fehler gemacht, der soo dumm ist, dass es keiner Antwort würdig ist? (Falls ja, würde ich das gerne ins Wiki aufnehmen, weil ich offensichtlich ja nicht der einzige bin, dem das nicht klar ist).
Oder hat einfach noch niemand die Threads gelesen, weil sie im falschen Forum gestellt wurden? (Deshalb poste ich jetzt nochmal hier)

Ist meine Annahme korrekt, dass bei Angabe eines Intervals, Events für *mindestens* dieses Intervall unterdrückt werden sollten?

Leider reichen meine Perl-Fähigkeiten bei weitem nicht aus, um fhem.pl und TimeSeries.pm so zu verstehen, dass ich nachvollziehen könnte, wo der Fehler liegt.

Danke für eure Unterstützung
Grüße,
Stephan

[rudolfkoenig]

Laut MAINTAINER.txt sollen Fragen bezeuglich TimeSeries.pm in der "FHEM Development" Abschnitt gestellt werden, das ist etwas ungluecklich, da normale Benutzer hier keine Schreibrechte haben, der Bereich ist fuer FHEM-Modul-API Diskussionen gedacht, und soll wenig Beitraege haben, damit es von jedem Entwickler abonniert wird.

Ich vermute, dass diese Funktionalitaet selten verwendet wird, und nur wenige ausser den Maintainer dazu was sagen koennen. Vmtl. sollte man sie per PM anschreiben.

[abc2006]

Ich vermute, dass diese Funktionalitaet selten verwendet wird, und nur wenige ausser den Maintainer dazu was sagen koennen. Vmtl. sollte man sie per PM anschreiben.

Okay, wenn sogar Du das sagst, mach ich das

Danke!

[Wzut]

Ich habe heute Vormittag mal mit deinem Beispiel etwas gespielt , Test Objekt war ein La_Crosse Sensor der alle 9 Sekunden seine Temp schickt.
Setze ich den event-aggregator mit deiner Syntax direkt auf das normale Reading temperature kommen die Events wie erwartet alle 120 Sekunden. Lege ich aber ein userReading temp2 an das den inhalt von temperature clont und dann den event-aggregator auf das userReading temp2, kommen die temp2 Events viel zu oft im Event Monitor.
D.h. genau wie bei dir. Lege ihn doch mal testweise um auf das echte Reading.

[abc2006]

Danke für deine Mühe.
Ich habe das soeben versucht. Allerdings ist es recht schwierig, weil ich kaum Devices habe, die "einfach so" etwas senden.
Die meisten Sachen frage ich ab.

Versucht habe ich es
Stromzaehler - Modul OBIS.
Den von dir beschriebenen Effekt konnte ich dabei nicht nachstellen.
Vielmehr ist es so, dass direkt nach dem setzen des attr für <reading> erstmal keine Events mehr kommen - und zwar recht deutlich *mindestens* <holdtime> sekunden lang nicht. Danach wird ein Wert berechnet (weiss nicht, ob er korrekt ist, aber dadurch dass ein ehemals integer auf einmal zwölf nachkommastellen hat, recht deutlich sichtbar.
Ab diesem Zeitpunkt springt der Timestamp von <reading> wieder synchron mit alle anderen readings mit.
Leider hab ich keinen LaCrosse, sonst würd ichs damit testen.

Ich hab mal ein DOIF gebaut. Kannst du das mal bei dir anlegen und gucken, wie sich das reading cmd verhält?
Bei mir fängt es bei 1 an zu zählen, geht dann im Sekundentakt auf 60 und bleibt dann bei 60 während weiterhin sekündlich aktualisiert wird. Ist das bei dir auch so?

Code Auswählen Erweitern


defmod DF_eventaggregator DOIF ([+1])\
()
attr DF_eventaggregator do always
attr DF_eventaggregator event-aggregator cmd:10:none:integral:60
attr DF_eventaggregator room x_devel


[Wzut]

dein DOIF habe ich nicht probiert denn IMHO ist da etwas faul im Staate Dänemark.
Ich habe das userReading gelöscht und bin wieder zurück auf temperatur und oh Wunder es schert sich nicht mehr um den aggregator.
Erst mittels eines FHEM Restarts fängt er wieder an zu arbeiten und das genau einmal, ist die erste Zeit um kommen die Events wieder so fröhlich als gäbe es ihn nicht.
Vllt muss da doch noch mal Rudi ran, denn aus dem antsprechendne Abschnitt in fhem.pl werde ich nicht ganz schlau.
Da wird ganz normal setreading und addEvent am Ende durchlaufen, ich hätte da jetzt einen vorzeitigen Ausstieg erwartet solange die Uhr tickt.

[abc2006]

fängt er wieder an zu arbeiten und das genau einmal, ist die erste Zeit um kommen die Events wieder so fröhlich als gäbe es ihn nicht.

Schön, dann sind wir uns beim (Fehler?)Bild zumindest einig

[Wzut]

Du bist TE und Developer, also schiebs rüber nach FHEM Development

[abc2006]

Hallo,
ich habe jensb angeschrieben und er hat geantwortet:

Leider ist er zur Zeit anderweitig eingebunden, schlägt aber folgenden Testcase vor:

Vermutlich hat das Problem auch nicht mit TimeSeries zu tun. Der Trigger für event-aggregator ist in fhem.pl. Man könnte einen Testcase verwenden, wo man ein reading und ein userreading mit den gleichen Daten versorgt und zusätzliches Logging in fhem.pl und TimeSeries einbaut. Das Ergebnis sollte das gleiche sein - ist es aber offensichtlich nicht.

Wichtig für alle Beteiligte wäre ein einfach nachzustellender Testcase. Vielleicht ist es möglich das Problem mit einem dummy-Device zu reproduzieren, indem man die Testwerte über die FHEM Kommandozeile mit "setreading" vorgibt.

Nun die Frage von mir:
Reicht mein DOIF als Testfall?
Ich habe den Eindruck, als würde das Problem beim Aufruf von TimeSeries aus der fhem.pl vermutet - kann da auch jemand anderes helfen?
Ich unterstütze gerne, soweit ich kann (und klare Aufgaben erhalte;)

Grüße,
Stephan

[rudolfkoenig]

- das obige Bespiel mit DOIF funktioniert zwar (im Sinne von: die Events schauen komisch aus), generiert aber 4 Events, die alle mit cmd Anfangen, das macht das Debuggen unnoetig schwer. Ich gehe davon aus, dass das Event cmd gemeint ist.
- dieses Event kommt 10 Sekunden lang nicht, danach wird, angefangen mit 10 (manchmal 11?), sekuendlich bis 62 hochgezaehlt, bei 62 bleibt die Zahl stehen, die Events kommen aber weiterhin.
- nach etwas debuggen in TimeSeries: elapsed() meldet ab 10 Sekunden immer true, weil $now - $self->{_t0} > 10 ist.
- ich gehe davon aus, dass _housekeeping() _t0 zuruecksetzen sollte, ueber trimToHoldTime().
- sie wird nach 60 Sek (holdTime) jede Sekunde aufgerufen, und erhoeht auch _t0, die ist aber immer 62 Sekunden hinter $now, und damit werden weiterhin Events generiert.

Und jetzt bin ich raus aus dem Spiel, ich weiss ja nichtmal, ob das ein Programm-, oder Parametriesierungsfehler ist.
Ich will es eigentlich auch nicht wissen, bin so schon fuer zu Vieles zustaendig.

[abc2006]

Als erstes ist mir aufgefallen, dass bei Änderung des <interval> des attributes event-aggregator, dieses nicht im TimeSeries ankommt.
Beispiel:

Code Auswählen Erweitern

attr <device> event-aggregator <reading>:10:<method>:<function>:<holdtime>
TimeSeries rechnet mit 10 Sekunden.

Code Auswählen Erweitern

attr <device> event-aggregator <reading>:15:<method>:<function>:<holdtime>
TimeSeries rechnet immer noch mit 10 Sekunden.

Meiner Meinung nach könnte das daran liegen, dass in der fhem.pl nur bei "nicht-vorhandensein" eines aggregators ein new->() angelegt wird.
Wenn sich danach die Parameter ändern, wird das nicht übergeben.
Betroffen davon sind ebenfalls <method> (none,const,linear) und <holdTime>
Die <funktion> hingegen dürfte nicht betroffen sein, da *alle berechnet werden und bei jeder aktualisierung lediglich der aktuelle Wert durch fhem.pl abgefragt wird.

Nach einem shutdown restart ist erstmal wieder alles synchron.

[abc2006]

Dann hab ich einen Vorschlag, die sub elapsed($$) umzubauen:

Code Auswählen Erweitern


sub elapsed($$) {
  my ($self, $t)= @_;

  if(defined($self->{autoreset}))
  {
if(defined($self->{lastEvent}))
{
if($t > $self->{lastEvent} + $self->{autoreset})
{
$self->{lastEvent} = $t;
return 1;
}else{
return 0;
}
}else{
$self->{lastEvent} = $t;
return 0;
}
} else {
return 1;
}
 
}



Hab versucht, das als patch-Datei hinzubekommen.
Alle meine Tests waren erfolgreich, ich kann aber nicht garantieren, dass ich alle Use-Cases abgedeckt habe...
Ich benutz das jetzt erstmal so, freu mich aber gerne über Rückmeldungen.

Grüße,
Stephan

[Wzut]

ich habe das jetzt an zwei Stellen auf dem Testsystem und das schaut nun viel besser aus als zuvor, werde das mal auf das aktive System rüber nehmen und separat loggen und in eine SVG packen.

Nur schau dir doch bitte mal deinen Code an, sind da nicht etwas viel else drin ?
Wenn du im if mit return am Ende eh aussteigst kann doch das nächste return ohne else direkt dahinter ?
IMHO müsste das auch schlanker so gehen :

Code Auswählen Erweitern

   if (defined($self->{autoreset})) {
if (defined($self->{lastEvent})) {
    if ($t > $self->{lastEvent} + $self->{autoreset}) {
$self->{lastEvent} = $t;
return 1;
    }
    return 0;
}
        $self->{lastEvent} = $t;
        return 0;
    }
    return 1;

[abc2006]

das schaut nun viel besser aus als zuvor

Danke, das nehm ich mal als Lob

Nur schau dir doch bitte mal deinen Code an, sind da nicht etwas viel else drin ?
Wenn du im if mit return am Ende eh aussteigst kann doch das nächste return ohne else direkt dahinter ?

Ich bin mir sicher, dass das schlanker geht.
Achso, jetzt hab ich auch verstanden, warum
Danke für den Hinweis, werd ich nochmal überarbeiten!

Grüße,
Stephan

[abc2006]

Hier die geänderte Version.
Grüße,
Stephan