[gelöst] event-on-change-reading geht nicht

[FhemPiUser]

hmm, stimmt, müsste gehen. teste ich mal, danke!

trotzdem nicht optimal, da die anderen zeitunkritischen sensoren unnötigerweise alle min-interval sekunden den gleichen wert schreiben...

[rudolfkoenig]

trotzdem nicht optimal, da die anderen zeitunkritischen sensoren unnötigerweise alle min-interval sekunden den gleichen wert schreiben...

@FhemPiUser: Wenn du einen gut getesteten Patch dafuer lieferst, werde ich es anschauen.

[FhemPiUser]

Ich habe mal im Code geschaut und mit Änderungen getestet (fhem.pl:13560/2017-03-01).

Aus meiner Sicht ist der "Fehler" in der if-Anweisung ab Zeile 4272, da dort bei event-min-interval nur dann changed=0 gesetzt wird und damit kein event generiert wird, wenn der Value sich NICHT ändert (da ist changed aufgrund einer Abfrage weiter oben in Zeile 4259 ohnehin schon 0). changed sollte aber auch auf 0 gesetzt werden, wenn sich der Wert ändert, das Interval aber noch nicht abgelaufen ist.

Außerdem sollte nicht automatisch bei Ablauf von event-min-interval changed auf 1 gesetzt werden, also ein Event generiert werden, sondern nur, wenn es auch eine Änderung des Values gab (was aber schon weiter oben abgefragt wird und da dann ggf. changed schon auf 1 gesetzt wurde).

Daher muss

Code Auswählen Erweitern

     
if($le && $now-$le < $minInt) {
  if(!$eocr || ($eocr && $value eq $readings->{VAL})){
    $changed = 0;
  } else {
    $hash->{".lastTime$reading"} = $now;
  }
} else {
  $hash->{".lastTime$reading"} = $now;
  $changed = 1 if($eocrExists);
}


ersetzt werden durch

Code Auswählen Erweitern

     
if($le && $now-$le < $minInt) {
  $changed = 0;
} else {
  $hash->{".lastTime$reading"} = $now;
}


Macht das Sinn für Euch? Bei meinen Tests hat es funktioniert...

[sfancy]

ich habe ein dummy device mit folgendem attributen:

Code Auswählen Erweitern

attr dev event-on-change-reading state
attr dev event-min-interval state:3


ausserdem ein paar userreadings.

auf dem dummy habe ich ein filelog mit folgendem output:

Code Auswählen Erweitern

2017-03-06_20:14:02 Arduino_Heizung_A4_temp 38
2017-03-06_20:14:07 Arduino_Heizung_A4_temp 38
2017-03-06_20:14:12 Arduino_Heizung_A4_temp 38

eigentlich dürften doch keine einträge mit gleichem wert hintereinander stehen. hat jemand eine idee woran das liegt?

Works as designed!
Zumindest sagt das so das Wiki https://wiki.fhem.de/wiki/Event-on-change-reading:

"In der Regel ist es sinnvoll, event-on-change-reading mit min-interval zu kombinieren, min-interval deshalb, damit von Zeit zu Zeit Einträge in das Logfile geschrieben werden (findet FHEM zu wenige Ereignisse pro betrachteter Zeitspanne, bleibt das Diagramm leer oder wird nur teilweise gezeichnet (Plotabriss))."

Und genau so verwende ich die beiden Attribute:

Code Auswählen Erweitern



attr Heizungsvorlauf event-min-interval .*:600
attr Heizungsvorlauf event-on-change-reading temperature:0.6



Das loggt bei Änderungen um min. 0,6 oder alle 600 Sekunden.

[FhemPiUser]

das ist für mich von der logik aber ein event-max-interval anstatt ein event-min-interval, denn dann sind
events ja max 600s auseinander, aber es gibt auch kürzere intervalle...

passt für mich auch nicht zusammen mit der fhem referenz beschreibung (s.o)...

man könnte natürlich neben min-interval ein max-interval attr einführen...

[rudolfkoenig]

@sfancy: danke fuer die Gedaechtnisstuetze, so war das auch gemeint: man will mitkriegen, wenn sich was aendert, und mindestens alle X Sekunden ein Lebenszeichen vom Geraet, wenn sich nichts aendert.

[FhemPiUser]

hi rudolf,

das passt für mich nicht mit der fhem referenz beschreibung zusammen

Code Auswählen Erweitern

event-min-interval:...Events will only be generated, if at least minInterval seconds elapsed since the last reading of the matched type...

mein vorschlag: man führt noch ein max-interval attr ein...

[rudolfkoenig]

Das Problem: die Stelle ist komplex. Es ist trivial fuer einen bestimmten (==deinen) Fall zu testen, aber es wird von vielen in kaum vorstellbaren Kombinationen verwendet, die sofort auf meinem Dach steigen, wenn das nicht mehr so funktioniert, wie bisher. Du kannst gerne einen Patch bauen, ich werde es aber nur dann aufnehmen, wenn ich Nebeneffekte auf Anhieb(!) ausschliessen kann. Ich habe mit csrfToken genug Kopfschmerzen, eine neue Baustelle fehlt mir nicht. Und bei csrfToken habe ich wenigstens eine valide Begruendung fuer die Kopfschmerzen.

[justme1968]

@FhemPiUser: achtung: max-intervall unterliegt einem denkfehler. fhem erzeugt keine events. nur der sensor tut das. wenn der sensor nichts sendet nützt auch ein max-interval nichts.

der name min-interval ist schon korrekt. es wird kein event erzeugt wenn das interval kleiner als min-interval ist. ein event wird also dann erzeugt wenn mindestens x sekunden vergangen sind.

[FhemPiUser]

@rudolfkoenig: ja, kann ich absolut nachvollziehen.

ich werde dann auch keine energie mehr in das thema stecken. auch wenn es nicht optimal ist kann ich auch mit der aktuellen variante leben.

ich würde allerdings empfehlen die fhem referenzbeschreibung nochmal anzupassen, die ist zumindest für mich nicht so, dass ich auf das tatsächliche verhalten kommen würde.

[rudolfkoenig]

ich würde allerdings empfehlen die fhem referenzbeschreibung nochmal anzupassen

Habe die Doku angepasst.

[FhemPiUser]

ok, danke.

habe jetzt das von mir gewünschte verhalten erreicht, indem ich ein notify und ein dummy zusätzlich zum eigentlichen device definiert habe, der dummy mit event-min-interval und das eigentliche device mit event-on-change-reading.