search

RFD-FHEM / RFFHEM

Counterpart of SIGNALDuino, it's the code for FHEM to work with the data received from the uC
GNU General Public License v3.0
44 stars 33 forks source link

Diff too large - rejects all new sensor values for humidity and doesn't recover #585

Closed Antannah closed 5 years ago

Antannah commented 5 years ago

Expected Behavior

Sensor rejects single outliers, but after few values after a large step (maybe depending on time), new values will be accepted.

Actual Behavior

Sensor rejects all new values 2019.05.07 18:06:13 3: sduino_alt: se_bodenfeuchte4 ERROR - Hum diff too large (old 5, new 95, diff 90.0) 2019.05.07 18:04:13 2: sduino_alt: CUL_TCM97001 Unknown device Unknown, please define it 2019.05.07 18:03:54 3: sduino_alt: se_bodenfeuchte4 ERROR - Hum diff too large (old 5, new 95, diff 90.0) 2019.05.07 18:03:08 3: sduino_alt: se_bodenfeuchte4 ERROR - Hum diff too large (old 5, new 95, diff 90.0) 2019.05.07 18:02:22 3: sduino_alt: se_bodenfeuchte4 ERROR - Hum diff too large (old 5, new 95, diff 90.0) 2019.05.07 18:01:36 3: sduino_alt: se_bodenfeuchte4 ERROR - Hum diff too large (old 5, new 96, diff 91.0) 2019.05.07 18:00:49 3: sduino_alt: se_bodenfeuchte4 ERROR - Hum diff too large (old 5, new 96, diff 91.0) 2019.05.07 18:00:03 3: sduino_alt: se_bodenfeuchte4 ERROR - Hum diff too large (old 5, new 96, diff 91.0) 2019.05.07 17:57:45 3: sduino_alt: se_bodenfeuchte4 ERROR - Hum diff too large (old 5, new 96, diff 91.0)

Steps to Reproduce the Problem

  1. Take sensor from ground and restart it => this lead to 0 value in my case/obviously this value step was accepted
  2. Put back into the ground produces a large step wich gives the above error entries in the log.

Specifications

sidey79 commented 5 years ago

580

elektron-bbs commented 5 years ago

Dafür gibt es bei dem Sensor ein Attribut "max-deviation-hum". Allerdings sind in der Dropdown-Liste nur Werte bis maximal 50 vorgesehen. Du müsstest den Befehl selbst eingeben:

attr se_bodenfeuchte4 max-deviation-hum 99

Nach maximal 90 Minuten sollte sich das Problem allerdings auch von selbst beheben (Standardeinstellung: 1.0 % relative Feuchte pro Minute sind als Differenz zulässig).

Antannah commented 5 years ago

Ok, Danke, dann schließe ich mal.

sidey79 commented 5 years ago

@elektron-bbs

Die 99 gleicht ja einer Deaktivierung. Vielleicht sollten wir überlegen, den Standardwert bei der Feuchte etwas zu erhöhen. Vielleicht auf 5 oder sowas?

elektron-bbs commented 5 years ago

Naja, ich denke, das sollte jeder selbst entscheiden. Wir haben uns früher, bevor es diese Prüfung gab, immer über "Zacken" in den Diagrammen gewundert. So wird der Nutzer wenigstens darauf aufmerksam gemacht, das es diese Prüfung gibt. Ich persönlich musste im Laufe der Zeit bei 5 von 9 Sensoren den Standardwert hochsetzen.

Antannah commented 5 years ago

Ich schlage vor, generell die Steigung zu begrenzen, diese aber dafür einstellbar zu machen. Das kommt dann einer Glättung (Tiefpassfilter) gleich. Erreichen kann man das zwar ganz gut, durch einen gleitenden Mittelwert Filter, allerdings reagiert das bei der unsicheren Abtastrate (fehlende Messwerte) nicht schön. Man müsste es wohl so machen, dass man den Anstieg pro Minute als Attribut vorgibt. Anhand des Zeitunterschieds berechnet man damit den möglichen Anstieg oder Abfall und begrenzt den Messwert auf diesen Wert - Ich nehme an, so ist es auch mit der 1% pro Minute realisiert. Also wäre es gut, die 1% vorgeben zu können. Braucht man dann die Sache mit dem zulässigen Sprung wie durch max-deviation-hum definiert noch?

sidey79 commented 5 years ago

Die Idee finde ich auch viel besser, wenn wir die Steigungsrate anpassbar machen und den Zusatzwert eleminieren.

Irgendwas fällt uns bestimmt auch für bereits vorhandene Konfigurationen ein, die müssen auf die neue Funktionsweise angepasst werden.

elektron-bbs commented 5 years ago

Davon halte ich gar nichts. Die Messwerte müssen unverfälscht übernommen werden. Ich will ja keine geglätteten Kurven sehen, sondern reale Messwerte.

Die Idee hinter max-deviation-temp und max-deviation-hum ist, Streuungen durch falsch empfangene Bits auszusieben. Im SD-WS-Modul werden einige Sensoren ohne jegliche Prüfungen ausgewertet. Selbst bei CUL-WS, wo es gleich mehrere Prüfungen gibt, rutschen immer mal falsche Bits durch. Diese filtert die Erweiterung sehr zuverlässig aus.

sidey79 commented 5 years ago

Die Messwerte würden doch nicht geglättet werden.

Aktuell ist es beispielsweise so, dass ein Sensor der alle 3 minuten etwas sendet mit jeder Übertragung 3% verändern kann. Gibt es eine große Änderung des Messwertes, nehmen wir mal 5% an, dann wird diese erst nach 6 Minuten (wenn empfangen wurde) übernommen. Will man das schon nach 3 Minuten ermöglichen, muss man aktuell max-deviation von mindestens 2 konfigurieren.

Beispiel 2: Aktuell ist es beispielsweise so, dass ein Sensor der alle 3 minuten etwas sendet mit jeder Übertragung 3% verändern kann. Gibt es eine große Änderung des Messwertes, nehmen wir mal 50% an, dann wird diese erst nach 50 Minuten (wenn empfangen wurde) übernommen. Will man das schon nach 25 Minuten ermöglichen, muss man aktuell max-deviation von mindestens 25 konfigurieren, da 25minuten 1 % + die 25% die hinzuaddiert werden.

Der Vorschlag ist nun, nicht die 25% einfach hinzu zu addieren sondern die Änderungsrate pro Minute zu hinterlegen. z.B. 2%.

Die Messwerte werden ja weiterhin unverfälscht übernommen, es gibt dann nur die Möglichkeit die Änderungsrate pro Minute zu definieren, anstelle eine fixe Änderungsrate zu addieren.

elektron-bbs commented 5 years ago

OK, hatte ich missverstanden. Meine Sensoren senden alle ca. 3 Minuten. Bei einem Sensor am Vorlauf Heizung habe ich jetzt "max-deviation-temp" auf 30 eingestellt. Wenn ich dich richtig verstehe, müsste ich bei deiner Variante dann 10 K/min einstellen. Verpasst FHEM jetzt zwei Empfangspakete, sind das dann 9 Minuten, ergibt maximal erlaubte Abweichung 90 K - das ist ziemlich heftig. Bei der jetzigen Variante wären es nur 39 K und das halte ich noch für vertretbar. Das sich das System erst nach längerer Zeit wieder "fängt" ist im Normalfall verschmerzbar, da ja nur gelegenlich mal ein Empfangsfehler rein rutscht.

Mit so einem heftigen Sprung von 5 auf 95 habe ich natürlich nicht gerechnet. Der sollte aber im Normalfall auch nicht auftreten. Vieleicht doch besser nur die Dropdown-Liste erweitern für solche Sensoren oder die Prüfung abschaltbar gestalten.

Ralf9 commented 5 years ago

Ich würde es besser finden, wenn so wie auch beim SD_WS07 Modul die max-deviation nicht aktiv sind, wenn die Attribute nicht definiert sind. Ein Anfänger würde sich am Anfang leichter tun, es gibt einige Fälle wo die max-deviation stören.

Dies ist ein Fall aus dem Forum

Hallo zusammen, in der Sufu find ich keine Hilfe, deshalb probier ich es hier:

Ich hab eine Steuerung für mein Dachfenster im Bad aufgebaut und einen SIGNALDUINO mit CC1101 um Temperatur und Luftfeuchtigkeit im Raum zu messen. Nun stelle ich aber fest, dass unter Umständen die Feuchtigkeit schnell steigt (Beim Duschen zum Beispiel). Dann bekomm ich von meinem Signalduino die Meldung:

"ERROR - Hum diff too large (old 59, new 63, diff 4.0)"

Somit erkenne ich den zu hohen Wert der Feuchtigkeit nicht mehr...

Kann ich den Differenzwert ab dem ein Messwert als Fehler verworfen wird einstellen? Ich habNichts gefunden...

sidey79 commented 5 years ago

Der max-deviation Wert ist auch im SD_WS Modul nicht aktiv, wenn das Attribut nicht aktiviert wurde. Die Bezeichnung des Attributes vermittelt nur etwas anderes, was es tatsächlich macht.

Ralf9 commented 5 years ago

Wenn beim SD_WS Modul das Attribut nicht definiert wurde, dann ist der Wert 1

Beim SD_WS07 Modul gibt es diese Abfrage if (ReadingsVal($name, "temperature", undef) && (defined(AttrVal($hash->{NAME},"max-deviation-temp",undef)))) {

sidey79 commented 5 years ago

Ah das meinst Du.

In der Commandref steht bei beiden, dass der Standardwert 1 ist. Und das ist in beiden Modulen auch hinterlegt.

Ich hatte mir das immer wie folgt vorgestellt:

Standard ist, dass eine Abweichung von 1% oder 1°C pro Minute erlaubt ist. Will man mehr, kann man sich einen beliebigen Wert hinzuaddieren. Der eingestellte max Wert wird zu dem durch Zeitabstand errechneten Wert hinzugenommen. Das SD_WS_07 Modul vergleicht die Abweichung allerdings überhaupt nicht, wenn das Attribut nicht definiert wurde. Somit ist hier kein Standard gesetzt. Eventuell ist das bei SD_WS_07 auch nicht so nötig, wie beim SD_WS Modul :)

Denkbar ist ja auch, dass wir das Attribut nach jedem Define auf einen noch zu definierenden Wert stellen.

Ralf9 commented 5 years ago

Denkbar ist ja auch, dass wir das Attribut nach jedem Define auf einen noch zu definierenden Wert stellen.

Eine Möglichkeit wäre auch es beim Define auf den Wert Info zu setzen, wo bei einer Abweichung größer 1 nur informiert wird, z.B.

Info - Hum diff too large (old 59, new 63, diff 4.0), please set or delete the max-deviation-... Attribute (see Device specific help)

Nachtrag: es sollte eigentlich reichen, wenn beim Define die max-deviation-... Attribute nur bei den Sensoren ohne Prüfsumme gesetzt werden