Statistics Modul löscht Werte von Dewpoint Modul?

Begonnen von klausw, 25 Juni 2014, 16:49:27

Vorheriges Thema - Nächstes Thema

klausw

Hallo zusammen,

ich nutze schon eine Weile einen SHT21 Feuchtesensor.
Dieser gibt humidity, temperature und state als readings aus.
state ist in der art: T: 24.27 H: 43.6

Dann nutze ich das Modul Dewpoint um an das reading state noch den Taupunkt anzuhängen.
sieht dann wie folgt aus: T: 24.97 H: 47.6 D: 13.1

state wird ausserdem in ein logfile geschrieben

Wenn ich nun das Statistics Modul für dem SHT21 nutze dann verschwindet D: 13.1 wieder aus dem state. Im Logfile jedoch wird er weiterhin mit gespeichert.

sobald ich statistics für das sht21 lösche ist der Taupunkt auch wieder da?

Gibt es eine Lösung dafür?

Grüße
Klaus
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

rudolfkoenig

Ich habe das statistics Modul gerade ueberflogen, und ich vermute, dass das Problem daran liegt, dass statistics die readings*Update Funktionen verwendet. Eigentlich wundert es mich, dass es ueberhaupt funktioniert.

Module wie average, dewpoint und statistics duerfen eigentlich nur Werte zum $dev->{CHANGED} hinzufuegen, bzw. addEvent($dev, $event) aufrufen, da sie vermutlich selbst aus dem readingsEndUpdate aufgerufen wurden, und darauf waren die readings*Update Funktionen nicht vorbereitet.

tupol

Ist damit auch die Nutzung des "event-on-change-reading"-Filters & Co. möglich? Das war nämlich der Grund für die Nutzung von readings(Single|Bulk)Update.

Wenn man den dewpoint nicht ins state sondern in ein einzelnes Reading schreibt, funktioniert es übrigens.


rudolfkoenig

ZitatIst damit auch die Nutzung des "event-on-change-reading"-Filters & Co. möglich?
Nein.
Das sollte aber nicht immer tragisch sein, da man diese Filter auf die Quell-Readings anwenden kann.

tupol

Zitat von: rudolfkoenig am 25 Juni 2014, 19:25:20
Ich habe das statistics Modul gerade ueberflogen, und ich vermute, dass das Problem daran liegt, dass statistics die readings*Update Funktionen verwendet. Eigentlich wundert es mich, dass es ueberhaupt funktioniert.

Konkret sieht es so aus, dass eine weitere Eventrunde ausgelöst wird (unter Berücksichtigung des event-on-update-Filters :-) Die filtere ich dann aber im statistics-Modul raus, indem ich auf den Prefix achte.

rudolfkoenig

Das mit dem extra Runde ist mir schon klar, hat aber diverse Seiteneffekte, die nicht so einfach zu eliminieren sind.
Unter anderem stoert es Dewpoint (und vmtl auch average).

tupol

Ich denke, dass immer entweder statistics oder average genutzt wird. Dewpoint funktioniert bei mir, wenn man den Taupunkt in ein separates Reading schreibt. Zu dem Fehler scheint es nur beim Eintrag in state zu kommen. Warum D:... aus dem state wieder entfernt wird, ist mir aber nicht klar. In statistics aktualisiere ich nur die statReadings.

Wie ich den Filter von den Quell-Readings auf die statReadings anwenden soll, ist mir nicht klar. Die statReadings kommen bei einem Notify und stündlich. Ich filtere z.B. nur die statReadingsLast.

klausw

Zitat von: tupol am 06 Juli 2014, 15:15:10
Dewpoint funktioniert bei mir, wenn man den Taupunkt in ein separates Reading schreibt.

Stimmt, aber das nützt mir nicht so viel. Ich schreibe ausschließlich den state in ein Logfile (um Speicherplatz zu sparen).
Und alle Sensorinfos in einer Zeile finde ich auch sehr übersichtlich. ;)
RasPi B v2 mit FHEM 18B20 über 1Wire, LED PWM Treiber über I2C, Luchtdruck-, Feuchtesensor und ein paar Schalter/LED\'s zum testen
Module: RPI_GPIO, RPII2C, I2C_EEPROM, I2C_MCP23008, I2C_MCP23017, I2C_MCP342x, I2C_PCA9532, I2C_PCF8574, I2C_SHT21, I2C_BME280

tupol

Ich habe das dewpoint-Modul mal kurz überflogen. Wenn ich es richtig verstehe, dann schreibt es in Zeile 301 den Wert direkt in das Internal "STATE"
Die Anwendung der neuen updateReadings-Mechanismen im statistics-Modul führt wahrscheinlich dazu, dass das Reading "state" einige Sekunden später erneut in das Internal "STATE" übertragen wird.

Das ganze wäre zu lösen, indem das dewpoint-Modul auch in das Reading "state" schreibt.

Bei mir hat beim WS300 z.B. der folgende Eintrag in Zeile 302 geholfen:
      $dev->{READINGS}{state}{VAL} = $current;
      $dev->{READINGS}{state}{TIME} = $tn;

Außer dem obigen Problem, habe ich bisher noch keinen Einfluss auf anderer Module feststellen können. Ich bin damals davon ausgegangen, dass die neuen Notifies in einer Warteschlange aufgenommen und dann abgearbeitet würden. So wie ich Rudi verstehe, ist das aber nicht der Fall. Vielleicht lässt sich das ändern?

Gruß

tupol

ojb

Hallo Leute,

erst mal Danke an tupol für das Modul.

Ich hätte eine Frage zu Rudi's Anmerkung oben. Irgendwie klingt das so als würde 'statistics' eventuell ganz schlimme Sachen machen können.
Für mich ist Stabilität und Robustheit das A und O.

Gibt es neben den beschriebenen "Schönheitsfehlern" kritische Situationen beim Einsatz von 'statistcis'?

Danke und lieben Gruß
Oli
FHEM unter Debian auf Asus EEBox: KNX (Wetterstation, Rollläden, Beleuchtung), Maple-CUN (Temperatur und Feuchte über 1-Wire, Intertechno-Funksteckdosen), PV-Anlage mit Plenticore und BYD, Viessmann Wärmepumpe, 1-Wire (Temperatur, Feuchte, Stromverbrauch), Husquarna-Automower, ...

tupol

Also wenn Du was Stabiles und Robustes suchst, solltest Du keines meiner Module nutzen. Ich mach das aus Spass am Werkeln und da kann es schon mal Fehler geben. So wird es Dir aber überall in FHEM gehen.

Das oben beschriebene Problem ist jedoch kein Fehler von statistics, sondern ein unterschiedliches Verständnis, wie ein Hilfsmodul in die Werte anderer Module hineinschreiben soll. Ich nutze z.B nur den offiziellen Update-Mechanismus. dewpoint schreibt dagegen direkt in das STATE und das führt dann dazu, dass die Werte durch den offiziellen Update-Mechanimus von FHEM wieder gelöscht werden.

deeb

Hallo tupol,

ich möchte wegen einer Frage kein neues Thema starten und hoffe du liest hier mit.
Frage:
Ist es auch möglich von den Max- und Minwerten die das Statistikmodul ermittelt, den Zeitstempel (Datum + Uhrzeit) auszuwerten ? 
Wäre gut wenn ich wüsste ob und wie das gehen könnte.

Danke deeb