Hallo in die Runde,
bei Timing things on MicroPython for ESP32 und Untersuchung und Verbesserung des Timings bei der Ansteuerung der DS18B20 Sensoren unter MicroPython haben wir uns dem Thema bereits gewidmet.
Hier kann die Diskussion dazu gerne allgemein weitergeführt werden.
Viele Grüße,
Andreas.
Also einfach Messwerte zu ersetzen halte ich Anlysetechnisch für grenzwertig.
Korrekterweise sollte dann, wenn ein falscher Messwert vorliegt dieser eliminiert werden.
Im Sionne der Nachvollziehbarkeit ist ein interpolieren nicht wirklich toll …
Bei statistischen Auswertungen helfen mir dann eher ausgelassene Werte wie wahrscheinilche Werte, die nicht der Realität entsprechen.
Ansonsten müsste ich zählen wie oft ich genau diese Werte “manipuliere” und dies dann extra persistieren. Diesen Wert benötige ich dann um hinterher den Wahrheitsgehalt meiner Messdaten einschätzen zu können.
Ich habe auf meinem Schreibtisch den Testaufbau mit BME280, HX711 und 5 mal DS18B20 und messe alle 5 sec mit dem FiPy. Das ganze liegt unberührt in einer Pappschachtel, damit sich die Temperatur nicht ändert.
Jetzt messe ich mit dem BME280 11000 mal t, p und h und erhalte 33000 saubere Messwerte ohne Ausreisser. Diese entsprechen auch der Wetterstation, die mit im Raum ist.
Jetzt hat aber der HX711 von den 11000 Messwerten 5 mal Ausreisser geliefert. Das mag zwar als nicht viel erscheinen, sieht aber in der Anzeige seht unschön aus. Statistisch ist es eher irrelevant.
Wenn der HX711 in Sekunde 5, 10, 15, 20 immer 10.1 kg liefert, in Sekunde 25 aber -95.3 kg, dann in Sekunde 30, 35, 40 aber wieder 10.1 kg, dann sage ich, der Wert von Sekunde 25 ist einfach falsch und ersetze ihn durch den Wert von Sekunde 20.
Ich glaube nicht, dass das wissenschaftlich falsch ist.
Es kommt doch nicht auf glauben oder nicht glauben an.
Im Bereich Data Analytics etc. ist es grundsätzlich bei der Datenerhebung ein tabu Daten zu verfälschen … was de facto mit einer Mittelwertbildung geschiecht.
Wenn man jetzt in eine Zeitscheibe hineindrillt sagen wir 1 Minute , dann hat da dieser Messwert eine hohe Relevanz.
Betrachte ich Tagesscheiben eben nicht … Dann sollte man aber bei der Datenerhebung aber diese Daten weg lassen… oder man eliminiert die in irgendeiner ETL Schicht. jmo.
Wie ich schon mal gesagt habe, finde ich es auch eher kontraproduktiv wenn man die Rohdaten schön rechnet. Außerdem können unsere Virtualisierungen sehr gut mit fehlenden Datensätzen umgehen.
Bei 5 Sekunden messintervall and mag ist zwar nicht so dramatisch sein, aber wenn wir aufgrund von Datenmenge oder Strom sparen auf längere Messzyklen hochgehen. Ist es dann doch schon entscheidend ob sich ein Wert innerhalb von 10 Minuten oder 20 Minuten geändert hat.
Die beste Möglichkeit die ich sehe wäre allerdings noch einen zweiten messversuch zu starten um einen richtigen Wert zu erhalten.
Das Messintervall ist natürlich entscheidend bei der Betrachtung der Ausreisser.
Wenn wir bei einem Bienenstock jede Stunde messen und dass Gewicht ändert sich um 5 kg, dann kann man nicht genau von einem Ausreisser ausgehen.
Wenn sich aber das angezeigte Gewicht bei meinem Testaufbau innerhalb von 5 Sekunden von 10.1 auf -95.3 und zurück auf 10.1 kg ändert, dann glaube ich nicht nur, dass es ein Fehler ist, sondern ich bin mir ganz sicher.
Mittelwertsubstitutionen oder das Ersetzen fehlender Werte duch den vorhergehenden Wert oder durch einen running Mittelwert oder Median sind in der Wissenschaft übliche Praxis. Es gibt Analyseverfahren für die man einen vollständigen Datensatz braucht, sonst funktionieren einige Metriken nicht.
Was aber auch richtig ist, so was sollte transparent erfolgen und man sollte wissen, wie viele Einzeldaten ersetzt wurden. Wenn das sehr viele sind, dann sagt das – gerade jetzt in der Anfangsphase – ja auch etwas über die Stabilität des Messaufbaus aus. Mein präferiertes Vorgehen wäre daher: Offensichtlich falsche Werte gar nicht zu übermitten, sondern da “missings” im Datensatz (also keine Werte) zu haben. Wie oben schon geschrieben kommen unsere Visualisierungslösungen damit gut klar und wir haben an dieser Stelle gar keinen Grund etwas zu ersetzen. Falsche Werte aussortieren (CRC-check nicht bestanden) macht die hiveeyes-Software bereits, afaik haben wir nur noch das Problem, dass manchmal Defaultwerte von 85 übertragen werden, wenn der Sensor zwar initialisiert wurde aber nicht Daten generieren konnte, d.h. die sollten wir noch durch Missings ersetzen, dann würden wir hier tatsächlich nur nur richtige Werte übertragen und wenn diese nicht berechnet werden können missings. Anders schaut es bei der hiverize-Software aus, dort ist der CRC-check noch nicht implementiert und daher werden auch “komische” Werte übertragen.
Eine andere Möglichkeit wäre auf Anzeigeebene offensichtlich falsche Werte auszuschließen. Besser fände ich allerdings erst mal den CRC-check einzubauen, das würde aber wieder ein Software-updaten auf dem FiPy bedeuten!
@Diren wollte sich eh die BOB-App vornehmen und hier bei der Anzeige offensichtliche Ausreißer glätten / eliminieren, damit auch ImkerInnen ohne Softwareupdate eine bessere Darstellung bekommen.
Das wäre auch mein Wunsch und bei einer Anzahl von überschaubaren Fehlwerten das sauberste Verfahren!