Messwerte filtern, Tasmota Readings reduzieren, DB nachträglich filtern, ...

Begonnen von gehrt, 14 September 2021, 10:18:02

Vorheriges Thema - Nächstes Thema

gehrt

Hallo zusammen,

ich habe stundenlang gesucht und bin nicht fündig geworden. Was ist gefunden habe ist teils zu speziell, teils zu lang zum Durcharbeiten. Die Doku liefert zwar Beispiele, erklärt diese aber (meist/oft?) nicht. Auch ist es nicht möglich solche Anfragen zu vermeiden, wenn man FHEM zwar einsetzt, jedoch nie die Tiefe in FHEM erreicht, weil es einfach laufen soll und man kein extremer Bastler / Entwickler ist, der ständig in FHEM arbeitet.

Ich habe mir einen ESP8266 basierten Stromzähler gebastelt, den ich per Tasmota in FHEM eingebunden habe. Ich würde gerne folgende Dinge machen:

- Die Unmengen an Tasmota-Readings ignorieren und löschen, bis auf die Werte, die ich brauche.
  Dazu habe ich nichts gefunden. Das ist weder einfach, noch selbst erklärend, noch irgendwo eindeutig findbar (behaupte ich mal)
- Ich würde gerne Messwert-Ausreißer ignorieren, im Graph und in der DB. Ausreißer sind ein generelles Thema in FHEM (zumindest für mich),
  die auch bei homematic und bei TX29 Temperatursensoren immer mal wieder vorkommen.
  Dazu finde ich auch wieder nur relativ Spezielles, nichts Generelles, was auf alles anwendbar wäre.
- Ich würde gerne Stromverbräuche nicht nur messen und protokollieren, sondern auch automatisch auswerten.
  - Stromverbrauch im Zeitraum von 7:00-23:00 Uhr und von 23:00-7:00 Uhr
    also Readings erzeugen, die das pro Datum anzeigen
  - Tagesstromverbrauch - z.B. Tabelle mit Werten der letzten 7 tage

Ich habe einen ISKRA MT691, der liefert den Zählerstand und die aktuelle Watt-Angabe. Ich habe den ElectricityCalculator gefunden, jedoch enthält der deutsche Wiki-Eintrag weder brauchbare noch eindeutige Informationen. Der englische Eintrag taugt leider auch nicht als Hilfestellung. Im Forum finde ich zum MT691 keine Informationen (nur eine Fundstelle).

Ich weiß ja, dass man hier teilweise recht schroff reagiert, falls Leute den Eindruck machen, sich vorher nicht umfassend informiert zu haben. Ich habe es versucht, es ist aber auch recht schwer. Nicht weil die Thematik an sich schwer wäre, sondern weil die Dokumentation es oft nicht möglich macht und es unfassbar viel Arbeit ist, aus den Forumsdiskussionen manchmal Informationen herauszufiltern, ohne den kompletten Thread, mit allen unwichtigen und falschen und nicht mehr richtigen/wichtigen Informationen, genauestens zu lesen. Hinterher ist mal oft weniger schlau als vorher ;-). So steht mit noch der 46 Seiten lange ElectricityCalculator-Thread bevor.

Ich wäre also froh, würde ich zielgerichtete Tipps bekommen.

Viele Grüße
Gehrt

MadMax-FHEM

Hallo Gehrt,

Zitat von: gehrt am 14 September 2021, 10:18:02
- Die Unmengen an Tasmota-Readings ignorieren und löschen, bis auf die Werte, die ich brauche.
  Dazu habe ich nichts gefunden. Das ist weder einfach, noch selbst erklärend, noch irgendwo eindeutig findbar (behaupte ich mal)

Ich nehme mal an eingebunden per mqtt?

Da bin ich auch kein Spezialist aber so wie ich das verstehe wird per readingList aus den empfangenen/zugeordneten Topic-Messages/-Daten eben Readings "erzeugt".
D.h. was du nicht willst einfach löschen bzw. halt anpassen.


Zitat von: gehrt am 14 September 2021, 10:18:02
- Ich würde gerne Messwert-Ausreißer ignorieren, im Graph und in der DB. Ausreißer sind ein generelles Thema in FHEM (zumindest für mich),
  die auch bei homematic und bei TX29 Temperatursensoren immer mal wieder vorkommen.
  Dazu finde ich auch wieder nur relativ Spezielles, nichts Generelles, was auf alles anwendbar wäre.
- Ich würde gerne Stromverbräuche nicht nur messen und protokollieren, sondern auch automatisch auswerten.
  - Stromverbrauch im Zeitraum von 7:00-23:00 Uhr und von 23:00-7:00 Uhr
    also Readings erzeugen, die das pro Datum anzeigen
  - Tagesstromverbrauch - z.B. Tabelle mit Werten der letzten 7 tage

Bzgl. Ausreisser würde ich ein userReadings anlegen (pro Messwert, der von Ausreissern befreit werden soll) und dort dann eben die Ausreisser "ausfiltern", also nur "gewünschte"/plausible Werte in das userReadings zurückliefern und dann statt dem Originalwert eben das userReadings loggen/auswerten weiter nutzen...

Bei Stromverbrauch Summieren etc. auch userReadings oder weitere Dinge wie z.b. statistic Modul usw.

Ich denke andere werden sicher weitere Vorschläge bringen...
...weil es halt leider/zum Glück (immer) mehrere Möglichkeiten gibt.

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Bzgl. dem Tasmota-"Readings-Schwemme"-Thema wäre es hilfreich, du würdest ein "list" liefern und ggf. mitteilen, welches IO-Modul du einsetzt.

Falls MQTT2_DEVICE+MQTT2_SERVER: einfach das "autocreate" (im DEVICE) auf 0 stellen und erst mal die Zeilen in readingList löschen, die die Infos bringen, die du nicht haben willst (vermutlich bleibt nur der "SENSOR"-Topic übrig). Falls da noch zu viel kommt: es gibt in json2nameValue() auch die Möglichkeit, Filter zu setzen. Details gehen aber nur auf Basis von einem list bzw. (in dem Fall besser) einer RAW-Definition (siehe unten in der Detailansicht)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Pfriemler

Tasmota liefert ein ganzes Bündel an topics (Datensatz- und Statussammlungen, Bsp. STATE, SENSOR, INFO1, INFO2...), von denen man die wenigsten wirklich braucht. Was wie oft passiert, kann man sich am Anfang direkt auf Tasmotas Webserver in der Konsole ansehen, das ist auch extrem hilfreich für die Fehlersuche. Eine Einarbeitung in die Funktionsweise von MQTT ist dringend empfohlen und höchst interessant.
Ich arbeite ja noch händisch mit MQTT (externer Broker auf dem Raspi) und händischer Anlage, dort kann man eigentlich sehr feingranuliert (aber auch alles andere als selbsterklärend) einstellen, welche topcis man "abonniert", also auswerten möchte. Ich bin sicher, dass es diese Mechanismen auch bei MQTT2 gibt. (Ich bin zu faul zum Umsteigen, never change a running system).

Im übrigen ist es aus meiner Sicht nicht unbedingt schädlich, viele Readings zu haben, auf meinem Raspi3 kann ich dadurch keine Performance-Einbußen ausmachen. Sehr empfehlenswert ist es aber, die Anzahl der generierten Events zu begrenzen, indem man die Attribut event-on-change-reading und event-on-update-reading seinen Bedürfnissen anpasst. Das entlastet FHEM dann wirklich.

Für die Ausreißer in den Daten empfehle ich zudem mal eine Suche nach der Ursache. Bei den LaCrosse-Sensoren kommt das hier eigentlich nie vor, weil ein Übertragungsfehler im Wert meist durch die Checksumme auffällt. Temperaturwerte glätte ich generell durch einen gleitenden Mittelwert (Routine in myUtils, Aufruf per userReading), bevor sie viertelstündlich per push in einer Datenbank landen (reicht mir). Ausreißer beim Stromzähler kann ich mir - außer durch Datenübertragungsfehler - aber weniger vorstellen.

Nachtrag: die statistischen Möglichkeiten verschiedener Fertigmodule haben mich auch erschlagen. Für eine Regenmengenauswertung lasse ich kurz nach Mitternacht ein "Programm" laufen, was die Mitternachtsstände der letzten Woche in einem Puffer (Readings im Device, rain0, rain1, rain2...) weiterschiebt und den Schnitt der letzten 3 bzw. 7 Tage ermittelt, ähnliche Zwischenspeicherung am Monatsanfang. Per userReading erfolgt eine aktuelle Berechnung für Kalendermonat und Tag. Für einzelne Geräte mag das reichen, bei mehreren wünscht man sich dann doch wieder ein Modul. Für einen Stromzähler könntest Du das auch ähnlich machen (also die Tagesverbräuche weiterschieben und das in einer readingsList anzeigen). Auch für die 23-Uhr / 7-Uhr -Messwerte würde ich jeweils dann eine kurze Routine laufen lassen, die entsprechende Readings setzt, die dann per FileLog oder DB automatisch geloggt werden.

Ausreißer könnte man alternativ gut durch den Vergleich mit vorigen Werten begrenzen (etwa dass ein Temperaturanstieg auf 0.2 Grad begrenzt wird, LaCrosse senden ja oft genug, dass ein echter Temperatursprung so dennoch recht zügig folgt).
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Sany

Hallo Gehrt,

ich verfolge einen etwas anderen Ansatz als die ersten beiden Vorredner zum Thema Readingsschwemme:
Ein neues Device, nehmen wir Deinen Tasmota zum Auslesen des Stromzählers:
- Device anlegen
- funktioniert es, also kommen Daten an?
- wenn ja, dann den Eventmonitor aufrufen mit Filter auf das Device, sprich: ich möchte nur die Events von diesem Device sehen.
- das Ganze eine Weile laufen lassen, u.U. mehrere stunden, jedenfalls solange Du bei allen Readings Änderungen/Wiederholungen gesehen hast.

Damit weißt Du erstmal, was alles von dem Device/Sensor/... kommen kann und wie oft.

Danach überlegst Du, welche Daten sind es wert oder nötig, gelogged zu werden, und welche sollen evtl. Trigger für irgendwas sein.
Ist diese Überlegung gemacht kommen 3 Attribute ins Spiel:
- event-on-change-Reading: alle hier eingetragenen Readings liefern nur noch events, wenn sich der Wert ändert. Bei einem Stromzähler werden sich W und kWh auf jeden Fall immer ändern (vermute mal, einen W-Wert von 0 für längere Zeit siehst Du nicht). Kommen hier sehr viele Werte, also z.B. sekündlich oder noch öfter, kann man weiter einschränken. Bei mir habe ich z.B. beim Power-Wert (W) 15 drangehängt, beim Energie-Wert (kWh) 333. Bedeutet: power muß sich um  mindestens 15W ändern, bevor ein Event erzeugt wird, Energie (kWh) muss sich um mindestens 333W ändern. Das reduziert die Menge an Events schon recht deutlich. Und die Werte, die am Ende übermittelt werden, sind genau genug.
Es gibt dann noch
- event-on-update-reading: hier kommen z.B. readings rein, die sich gar nicht änder, ich aber mitbekommen möchte, wenn sie wiederholt wurden. Bei meinem Stromzähler z.B. gibt es das Reading info. Dort kommt quasi nach dem Start des Sensors eine Meldung. Das werte ich dann aus, um mitzubekommen, wenn der Sensor neu gestartet wurde.
- event-min-interval: das benötigst Du bei readings, die z.B. mit event-on-change-reading auf Änderungen begrenzt sind, du aber doch, wenn der Wert sich nicht ändert, alle mindestens xx sec einen Event haben möchtest. Denke da z.B. an einen Lichtsensor, der Nachts nur 0 senden kann, und z.B. alle 15min einen Event fürs logging erzeugen soll. Oder bei einer PV-Anlage, die auch nur tagsüber etwas liefert. Das ist dann hilfreich, wenn Du die Werte-Readings z.B. per readingswatcher überwachst, um den Ausfall eines Sensors mitzubekommen. Wichtig zu wissen: der Sensor muß die Daten liefern, event-min-interval läßt nur alle xx sec eine Event durch, wenn sich der Wert nicht geändert hat. Sendet der Sensor nur alle 30min bekommst Du auch nur alle 30min den Event.

Damit hast Du die Flut der Events im System brauchbar reduziert. Und das ist gut für die Performance von fhem. Eine schlechtere Lösung wäre ein Device alle Readings als Events an fhem liefern zu lassen und beim Logging die Werte auszufiltern.


Zitat- Ich würde gerne Stromverbräuche nicht nur messen und protokollieren, sondern auch automatisch auswerten.
  - Stromverbrauch im Zeitraum von 7:00-23:00 Uhr und von 23:00-7:00 Uhr
    also Readings erzeugen, die das pro Datum anzeigen
so etwas habe ich mit einem DOIF gelöst. Vom Stromzähler wird zum Sonneaufgang und Sonnenuntergang jeweils der Zählerstand festgehlaten. Bei SonnenAufgang ziehe ich vom aktuellen Wert den Wert vom letzten Sonnenuntergang ab und erhalte den Verbrauch während der Nahct, entsprehend wird zum Sonnenuntergang der Wert vom letzten Sonnenaufgang vom aktuellen Wert abgezogen und ergibt den Verbrauch Tagsüber. Das wird gelogged und per Diagramm dargestellt, jeweils für die letzten 30 Tage.
Da gibt es unendlich Möglichkeiten, das sprngt jetzt diesen Rahmen, da machst Du später mal eigene Threads dafür auf.

Zu Ausreißern kann ich nicht viel sagen, habe ich irgendwie keine, oder sie stören nicht. Ausser vielleicht diese On-Wire temperatur-sensoren, die 85 Grad melden, wenn der Wert nicht ausgelesen werden konnte. Das kann man beim Logging abfangen, oder auch per Usereadings. Es gibt aber nicht unbedingt eine Universallösung.

Gruß

Sany

fhem auf Zotac ZBox nano als LXC auf Proxmox, weitere LXC mit ZigBee2MQTT, MariaDB und Grafana. Homematic, FS20, mySensors, MQTT2, Tasmota, Shelly, Z-Wave  ....

MadMax-FHEM

@Sany: Events zählen lassen geht mittels DOIF-Tools :)

Klar mal den Eventmonitor (eine Weile) öffnen, um zu sehen was da so kommt und auch ob man entsprechende Automatisierungen "ableiten" kann...
...aber zählen usw. würde ich (und mache ich auch) per DOIF-Tools machen lassen 8)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Sany

@MadMax-FHEM
Zitat@Sany: Events zählen lassen geht mittels DOIF-Tools
...aber zählen usw.
?? wo schreibe ich davon?

Zitatmal den Eventmonitor (eine Weile) öffnen, um zu sehen was da so kommt und auch ob man entsprechende Automatisierungen "ableiten" kann
genau darum geht es. Nur so erkennt man, was ein was-auch-immer überhaupt sendet (die Dokus sind da zu oft viel zu ungenau). Und daraus leitet man dann ab, welcher Event was steuert oder welcher Wert es wert ist, z.B. gelogged zu werden.

Aber völlig richtig: DOIF-tools eignet sich hervorragend, die Masse der Events im System zu überblicken.
fhem auf Zotac ZBox nano als LXC auf Proxmox, weitere LXC mit ZigBee2MQTT, MariaDB und Grafana. Homematic, FS20, mySensors, MQTT2, Tasmota, Shelly, Z-Wave  ....

Beta-User

...wie wäre es, wir lassen den TE erst mal seine Hausaufgaben machen?
- Unbedingt vor dem ersten Post lesen
- Welche Informationen sollte man bei Fragen zu MQTT-Geräten bereitstellen?
Ansonsten: Er hatte doch sehr klar den Wunsch formuliert, nur ganz bestimmte Readings zu bekommen. Das ist doch legitim.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

MadMax-FHEM

Zitat von: Sany am 14 September 2021, 14:48:57
@MadMax-FHEM?? wo schreibe ich davon?

Zitat von: Sany am 14 September 2021, 13:04:08
- das Ganze eine Weile laufen lassen, u.U. mehrere stunden, jedenfalls solange Du bei allen Readings Änderungen/Wiederholungen gesehen hast.

Damit weißt Du erstmal, was alles von dem Device/Sensor/... kommen kann und wie oft.

Könnte man schon als "zählen" (im weitesten Sinne) interpretieren... ;)

Ist aber doch nebensächlich...
...wollte ja hauptsächlich auf DOIF-Tools und die Möglichkeit sehr einfach einen Eventüberblick bekommen zu können hinweisen...

Aber wir sollten sinnvoll weitermachen:
Zitat von: Beta-User am 14 September 2021, 14:52:37
...wie wäre es, wir lassen den TE erst mal seine Hausaufgaben machen?
- Unbedingt vor dem ersten Post lesen
- Welche Informationen sollte man bei Fragen zu MQTT-Geräten bereitstellen?
Ansonsten: Er hatte doch sehr klar den Wunsch formuliert, nur ganz bestimmte Readings zu bekommen. Das ist doch legitim.

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

gehrt

Vielen Dank für die bisherigen Infos. Das reicht vielleicht erstmal als Input.