search

opendata-stuttgart / sensors-software

sourcecode for reading sensor data
566 stars 307 forks source link

BME280 pressure shows wrong values #102

Open dokape opened 7 years ago

dokape commented 7 years ago

Die vom Barometer gelieferten Werte sind auf Meereshöhe geeicht. Zwar liefert das Barometer den absoluten Wert am Aufstellort, ist dieser aber z.b. bei 400m über Normal-Null, dann liegt der angezeigte Wert um ca. 50hPa unter dem auf NormalNull bezogenen Luftdruck der Wetterkarten. Es fehlt in der Software sozusagen der für die Aufstellhöhe nötige Kompensationswert.

Vorschlag: Auf der Konfigseite des Feinstaubsensors für den BME280 (betrifft möglicherweise auch andere Barometer) einen Kompensationswert, am besten die Aufstellhöhe des Sensors in Metern über dem Meer, eintragen (mit GPS vom Handy heute kein Problem mehr) und dann entsprechend zum gelieferten absoluten Wert hinzuzählen.

Hier auch ein Link zur Erklärung vom DWD: http://www.dwd.de/DE/wetter/thema_des_tages/2014/11/21.html

Mein Aufstellort liegt bei knapp über 400m. Der Sensor misst einen Luftdruck von 965hPa, Der Wetterdienst liefert für die Region einen Wert von 1017hPa, was auch genau diese 50hPa Differenz für die 400m Höhe entsprechen würde.

BTW: Bei Einsatz des GPS Neo 6M könnte man die Höhendaten direkt beziehen.

rexfue commented 7 years ago

Ich bin der Meinung, dass wir diese Umrechnung der jeweiligen Auswerte-Software überlassen und somit den ESP nicht weiter belasten. Außerdem denke ich, dass nicht jeder weiß, wir hoch er liegt. Mit den Koordinaten (die vom Server ja mit übertragen werden), ist es mit Hilfe einer Google-Api kein Problem, die Höhe zu bekommen und dann kann die Auswertesoftware mit den Formeln (je nach gewünschter Genauigkeit) den Druck auf Seehöhe reduzieren.

Ich habe das in meiner Auswertung so gemacht, und es funktioniert prima (siehe http://feinstaub.rexfue.de/xxx mit xxx = Sensornummer)

On 8. Jul 2017, at 19:19, dokape notifications@github.com wrote:

Die vom Barometer gelieferten Werte sind auf Meereshöhe geeicht. Zwar liefert das Barometer den absoluten Wert am Aufstellort, ist dieser aber z.b. 400m über Normal-Null, dann liegt der angezeigte Wert um ca. 50hPa unter dem auf NormalNull bezogenen Luftdruck der Wetterkarten. Es fehlt in der Software sozusagen der für die Aufstellhöhe nötige Kompensationswert.

Vorschlag: Auf der Konfigseite für den BME280 (betrifft möglicherweise auch andere Barometer) einen Kompensationswert, am besten die Aufstellhöhe des Sensors in Metern über dem Meer, eintragen und dann entsprechend zum gelieferten absoluten Wert hinzuzählen.

Hier auch ein Link zur Erklärung vom DWD:

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/opendata-stuttgart/sensors-software/issues/102, or mute the thread https://github.com/notifications/unsubscribe-auth/AWTSh9FkzIBb3MnhLxp3JQMLsyF5CS6aks5sL7o0gaJpZM4ORz5G.

dokape commented 7 years ago

Ich denke nicht, dass die einmalige Addition zweier Werte alle 3 Minuten den ESP stark belastet. Die Kompensation kann auch nur für die Anzeige der Werte auf der Seite des ESP: IP/values Erfolgen, während die unkonpensierten Werte an die API übertragen werden. Die Abfrage über die Google API sehe ich kritisch, da die Position unscharf dargestellt wird. Haushöhe/Aufstellort und mögliche topographische starke Höhendifferenzen wie Steiler Berg/Hanglage sind dadurch nicht genau abbildbar.

Andererseits: wer den BME280 gezielt einsetzt, sollte in der Lage sein, die exakte Höhe genau bestimmen zu können.

Btw: Deine Auswerteseite ist interessant. Danke für den Link!

eeeRalf commented 6 years ago

Ich denke auch, dass ausreichend CPU-Leistung da ist. Ich stelle mir das Feature eher als Option vor: Als zusätzlicher "Messwert für meteorologische Darstellung":

Ich bevorzuge die Multiplikation gegenüber der Addition als Korrektur.

Was haltet Ihr davon?

dokape commented 6 years ago

Der "Offset" beim Luftdruck ist konstant. Es sind ca. 1hPa pro 8m. Bei Höhenangabe wäre dann Offset = Höhe/8 zu berechnen und der Offset als Konstante zur "Fehlmessung" zu addieren, um den Messwert für alle meteorologischen Angaben vergleichbar zu machen. Der derzeit bei mir auf 408m Höhe angezeigte Wert von 965hPa wäre ein Sturmtief. Ich muss 51 hPa hinzuzählen und dann liege ich auch bei den von den Wetterdiensten gelieferten 1016hPa. Die Multiplikation kann nicht funktionieren, weil es ein konstanter Offset ist. Man könnte auch bei den gesendeten Messwerten den Messwert liefern und dazu den optionalen Korrekturwert oder die Höhe über NN. Ich würde die Höhenangabe in m als Korrekturwert - wenn eingetragen und bekannt ist - verwenden. Bei Datensätzen ohne Höhenangabe kann wie rexfue erwähnte, dann über die Google-API eine Höhe an den Koordinaten annähernd bestimmt werden. Die API liefert ebenfalls in m, dann hätte man bei der späteren Auswertung weniger Umrechnungsaufwand.

Da die Verwendung von hPa üblich ist, schlage ich vor, diesen Wert zu behalten und keine Darstellung in Pa oder mBar anzubieten. Dies kann eine Auswertesoftware übernehmen.

eeeRalf commented 6 years ago

Ja, hPA ist in Ordnung.

Eine solche Lösung finde ich sinnvoll. Niemand ausser dem Besitzer kennt die jeweilige Höhe des Sensors. Und ohne dieses Wissen kann man nicht den Messwert richtig einschätzen.

Nachtrag: die Seite von rexfue finde ich genial! Eine tolle Lösung.

rexfue commented 6 years ago

Ich möchte hier nochmal einsteigen:

die Annahme, 8m für 1hPa ist nur für sehr überschlägige Rechnungen sinnvoll !

Der Luftdruck hängt natürlich auch von der aktuellen Temperatur ab. Und der Abfall über der Höhe ist nicht linear sonder exponentiell.

In dem Wikipedia-Artikel ‚Barometrische Höhenformel‘ (https://de.wikipedia.org/wiki/Barometrische_H%C3%B6henformel https://de.wikipedia.org/wiki/Barometrische_H%C3%B6henformel ) ist das Alles sehr schön erklärt. Zur Reduktion auf Meereshöhe verwende ich die Formel

Zitat: Bei etwas höheren Ansprüchen sollte zumindest die aktuelle Lufttemperatur berücksichtigt werden. Deren Einfluss zeigt folgendes Beispiel, in dem ein auf 500 m Höhe gemessener Luftdruck von 954,3 hPa mit der Höhenformel für linearen Temperaturverlauf (a = 0,0065 K/m) unter Annahme verschiedener Stationstemperaturen auf Meereshöhe reduziert wird:

Zitat Ende.

Um die Höhe genau zu bekommen, könnte man ja auch den Anwender bei der Anmeldung des Sensors, wo er eh seine Daten (Adresse etc). angeben muss, die Höhe mit eingeben lassen und dann kann die API mit den Koordinaten auch die Höhe übertragen. Und schon hat der auswertende Rechner Alles, was er braucht.

dokape commented 6 years ago

OK. Die Thematik ist etwas komplexer als ich beim ersten überfliegen annahm.

Eine Speicherung der Höhe zentral bei Anmeldung des Sensors sehe ich eher suboptimal. Es wird an mobilen Sensoren mit eigener GPS-Bestimmung gearbeitet. Bei diesen ist eine feste serverseitig gespeicherte Angabe der Höhe nicht sinnvoll. Für eine Lokale Auswertung, z.b. durch einen Raspi im heimischen Netz wäre dieser Wert auch nicht direkt zugreifbar.

Die genaue Bestimmung des auf NN reduzierten Luftdruckes für vergleichbare Ergebnisse wird in der Tat den ESP möglicherweise deutlich fordern.

Ich könnte mir daher folgende Änderung an der Software vorstellen:

Die Abweichung des auf der values-Seite angezeigten korrigierten Luftdrucks wäre schätzungsweise ebenfalls so genau/ungenau wie die anderen gemessenen Daten PM10, PM2,5, Feuchtigkeit und Temp. (5%?). Die Änderungen an der Software wären überschaubar und würden den ESP kaum belasten.

Das hätte folgende Vorteile:

Nachteile: Der exakte vergleichbare Luftdruck für NN wird niemals bestimmt werden können.

Das bedeutet, egal welche Formel wir zum berechnen einsetzen werden, wir haben zu viele Unbekannte, um eine exakte Luftdruckkorrektur zum vergleichen bestimmen zu können.

rexfue commented 6 years ago

Hört sich vernünftig und durchdacht an. Ich unterstütze die Vorschläge von @dokape. An GPS bei mobilen Sensoren hatte ich nicht gedacht :(

Adorfer commented 6 years ago

An GPS bei mobilen Sensoren hatte ich nicht gedacht Die Frage ist, ob GPS es besser oder schlechter macht.

Auch wenn es eine uralte Openstreetmap-Diskussion ist, die auch schon bei Freifunk immer wieder schmerzt: Die GPS-Genauigkeit ist systembedenkt um etwa den Faktor 3-5 schlechter als die lat/lon (Kugelsegmentschnitte von Peilungen die allesamt 'über Kopf' sind, Erde und auch die Atmosphare sind nur bedingt durchsichtig) Wenn man also in der Praxis eine Abweichung von 7m "zur Seite" hat, dann sind das mindestens 20m in der Höhe. Also statt z.B. 100m über NHN. d.h. der Wert pendelt ungewiss zwischen 80 und 120m. Damit hat man ein Rauschen von schätzungsweise 5hPa im Flachland. Und das bei gutem GPS-Empfang.

Lange Rede kurzer Sinn: bei einem mobilen Empfänger "in den Bergen" hat man kene andere Wahl als GPS einzubeziehen. Bei einem stationären Sensor sollte man jedoch besser nicht mit GPS arbeiten, sondern die Höhe aus einem möglichst offiziellen Kartenwerk holen (und eben nicht vom Handy ablesen). In der Norddeutschen Tiefebene ist die GPS-Höhe in fast jedem Fall schlechter als ein enmalig "daheim" eingetragener Wert.

dokape commented 6 years ago

Das schließt sich ja nicht aus: Ist der genaue Höhenwert bekannt, kann er per Hand in die Konfig-Datei eingetragen werden. Wird der Höhenwert durch das Neo 6m Modul ermittelt, wird dessen Wert genommen, wenn kein manueller Wert eingetragen ist. 5hPa Ungenauigkeit liegt bei einem Wert um die 1000hPa bei kleiner 1%. So genau ist weder die Messung des SDS011 noch des DHT22 noch des BME280. Analoge Messgeräte haben seit jeher gewisse Toleranzen. Wir neigen bei digitalen Messwerten gerne dazu, diese Werte als absolut genau zu nehmen, obwohl sie es gar nicht sind. Von daher denke ich, selbst eine Abweichung von 5hPa würde die Aussagefähigkeit der Messwerte nicht verschlechtern. Beim Luftdruck ist es vorrangig: Hochdruck- oder Tiefdruckgebiet? Wie schnell und stark fällt/steigt der Wert, wie gross ist das Delta innerhalb 50/100/500km.

Adorfer commented 6 years ago

Es scheint mir, als ob es schlicht "schlechte" BME280er gibt

  1. BME280 die nach "starker Lichteinstrahlung" abstürzen und powercycle benötigen (hier nicht Thema)
  2. BME280, die die trotz stabiler airrohr-fw (/099) und stabiler 3.3V (Oszi-Kontrolle) alle paar Stunden für ein paar Stunden nur 0-Werte liefern auf allen Sensoren. (hier nicht Thema)
  3. BME280, die nach ein paar Wochen gar keine Werte mehr liefern aus dem laufenden Betrieb heraus, auch nicht nach Powercycle (auch hier nicht Thema)
  4. BME280 mit starkem Rauschen und mit einem Offset beim Druck

Beide Sensoren hängen auf +/x 5m der gleichen Höhe, mit etwa 500m Abstand.

grafik grafik

Zumindest bei diesem hier ist also nicht (nur) ein "Höhenkorrektions-Problem", sondern schlicht ein völlig problematisches Ding, weil irgendwelche, aber schlechte Werte.

DeeKey commented 4 years ago

Is this still an issue? If not, please close this issue or add a documentation tag if there is a valuable information need to be saved.

tom-r commented 4 years ago

Inzwischen rechnet die sensor.community Seite den Luftdruckwert automatisch auf Meereshöhe um (wo auch immer die exake Sensorhöhe herkommt, vermutl. aus der Karte ... ). Aber nicht opensensemap, madavi.de oder die Feinstaubapp... Ich bin gerade dabei einen Prototypen zu implementieren: Attribut für "Sensorhöhe über msl" Wenn BEX280 oder BMP180 (=Luftdruckdaten vorhanden), und Sensorhöhe >0 : dann blende bei den API's für madavi.de, opensensmap und Feinstaubapp ein Flag "Umrechnung Luftdruck auf msl" ein

PS: ich habe im Vorfeld (gut 2 Woche lang) immer wieder mal die Sensorwerte (Luftdruck und Temperatur) meines Sensors mit der o.a. Formel per Skript auf msl umgerechnet und mit 2 "offiziellen" Wetterstationen in meiner Nähe verglichen. I.d.R. war die Abweichung <= 1hPa, obwohl der Sensor auf 985m msl ist und wir Inversionswetterlagen hatten (entspricht nicht der angenommenen, rechnerischen Temperaturverteilung und erzeugt damit Fehler)... Gruß, Thomas Wenn Euch das interessiert, einfach Bescheid geben, dann stelle ich einen PR.

Gruß, Thomas

ricki-z commented 4 years ago

Für die lokale Anzeige können wir das übernehmen. Madavi.de: die Daten liegen auf einem privaten Server. Ein neuer Wert würde die Daten der BMEs um ein Drittel wachsen lassen. OpenSenseMap: Hier werden für die Luftdaten-Sensoren bestimmte Werte erwartet. Es müssten also auch bei OpenSenseMap selbst Änderungen vorgenommen werden. Feinstaub-App: Siehe OpenSenseMap Es geht also nicht nur um eine Änderung der Firmware. Bei fast allen anderen Seiten müssten ebenfalls Änderungen vorgenommen werden.

tom-r commented 4 years ago

Nein, falsch verstanden. Die auf msl reduzierten Luftdruck-Daten werden nicht zusätzlich übergeben, sondern statt des Originalwerts. Damit sollte sich das änderungsfrei und ohne Datenzuwachs in die ganzen Portale integrieren lassen. Und wenn wirklich mal eines der Portale die Umrechnung anbietet, kann man über das Flag einfach wieder umschalten auf "Originaldaten"...

tom-r commented 4 years ago

Bilder ... Sensordaten_intern Sensorhöhe API_mit_msl Korrekte Texte folgen ... Was ich nicht will ist eine Abhängigkeit von irgendwelchen APIs zu erzeugen. Opensensemap kriegt ja heute schon die Umrechnung nicht gebacken (obwohl da ein Höhenfeld ist). Wenn Du andererseits heute auf Opensensemap schaust, dann findet sich da ein wildes Sammelsurium an Luftdruckdaten, mal auf msl reduziert, mal nicht... Bei der Feinstaubapp hab ich einen Feature-Request gestellt, der wurde aber mit Prio low eingestuft (so formuliere ich eine freundliche Absage auch immer ;-) ) Mit den Flags läßt sich die Umrechnung gezielt an und abschalten, pro API.... Sollte also Opensensemap doch mal soweit sein, dann läßt sich der Haken auch wieder einfach rausnehmen ... Gruß Thomas

ricki-z commented 4 years ago

Es gibt einen ganz einfachen Grund, die Roh-Daten zu speichern: Wenn ein Fehler in der Umrechnung ist oder eine bessere Umrechnung existiert (für die Umrechnung auf Meeresspiegel gibt es ja auch eine ganze Reihe), muss man nicht erst umständlich die alten Werte mit der bisherigen Formel zurückrechnen, sondern kann "einfach" die neue Formel nehmen. Wir haben das gleich zu Beginn unseres Projektes an anderer Stelle lernen dürfen. Deshalb gibt es beim PPD42NS eben nicht nur die PM10 und PM2.5 Werte in den Daten, sondern auch alle an der Berechnung dieser Werte beteiligten Parameter. Und ein optionales Senden der Roh- oder der umgerechneten Werte führt zu genau dem, was bei OpenSenseMap zu sehen ist.

tom-r commented 4 years ago

Ist OK, das war ein Angebot, ich will mich nicht aufdrängen. Die Frage die ich mit halt gestellt habe ist : Wer nutzt die Luftdruckdaten denn wirklich ? --> zu 95% der Sensoreigentümer, für seine Sensoren. Und mit unkorrigierten Werten kann ich halt nix anfangen. Mir war aber auch vorher nicht klar, daß die Rohdaten verschickt werden und die Luftdruckwerte in der Feinstaubapp oder OpenSenseMap für die Katz sind... Gestern abend hab' ich noch rausgefunden, daß OpenSenseMap eh schon 3 (Json) "Eingänge" für den BME280 hat, als _BME280pressure (kommt von unserem Sensor), dann _BME280_pressurepa und _BME280_pressurehpa Nix einfacher als den korrigierten Wert mit _BME280_pressurehpa zu übergeben und in der Sensorkonfig. auf OpenSenseMap die Luftdruck-Einheit hPa auszuwähen...

Sobald ich denn mal fertig bin, wird die Anpassung auf meinem Fork unter https://github.com/tom-r/sensors-software zu finden sein...

Gruß, Thomas

ricki-z commented 4 years ago

Die letzten Nachrichten komplett gelesen? Gegen eine lokale Umrechnung spricht überhaupt nichts. Lediglich für das Speichern der Daten auf den Servern sollten die Rohdaten versendet werden. Den Hauptgrund habe ich inder letzten Nachricht genannt. (Die meisten Nutzer, die die Daten ihrer Sensoren selbst auslesen, tun das über unsere API und nicht direkt vom Sensor. Dort bekommen Sie dann auch den umgerechneten Wert. Aktuell rufen mehrere hundert FHEM- und HomeAssistent-Systeme so die Daten ab inkl. umgerechnetem Druck)

tom-r commented 4 years ago

ich setze das auf Basis der aktuellen beta nochmal neu auf und generiere einen PR für den auf Meereshöhe reduzierten Luftdruck. Ich hab zum Testen grad noch ein paar Änderungen mehr in meiner Spielwiese. Dann vermischt sich da nix. Dauert aber ein bischen, frühestens nächsten Montag

networxnet commented 2 years ago

ich setze das auf Basis der aktuellen beta nochmal neu auf und generiere einen PR für den auf Meereshöhe reduzierten Luftdruck. Ich hab zum Testen grad noch ein paar Änderungen mehr in meiner Spielwiese. Dann vermischt sich da nix. Dauert aber ein bischen, frühestens nächsten Montag

Hallo Tom, hallo Rajko,

wollte mal horchen was aus dem Theme geworden ist? In der offz. FW ist ein Knopf ja bis heute nicht implementiert und in der Fork finde ich auch nichts.

Musste aber mittlerweile feststellen, dass der Weg über die sensor.communtiy nach HA relativ instabil ist. Daher halte ich einen solchen Knopf um die korrekten Werte direkt lokal zu haben nach wie vor für sinnvoll.

Wir haben dazu in den letzten Jahren auch immer wieder Anfragen aus unserer lokalen Community gehabt, da viele den Sensor auch als private kleine Wetterstation nutzen und natürlich immer mit den offiziellen Werten vergleichen.