sensors-software
sensors-software copied to clipboard
opendata-stuttgart
BME280 pressure shows wrong values
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.
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 [email protected] 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.
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!
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":
- In der Konfiguration aktiviert man die Option und gibt die Höhe des Sensors über NN ein.
- Ausserdem könnte man hier die Darstellung Pa oder mBar wählen
- Daraus wird einmalig der Multiplikator als Korrekturwert errechnet.
- Zur Laufzeit werden dann einfach zwei Werte gesendet: der bisherige Sensorwert und der korrigierte Messwert.
Ich bevorzuge die Multiplikation gegenüber der Addition als Korrektur.
Was haltet Ihr davon?
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.
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.
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.
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:
- Einen optionalen Parameter "Höhe" in m auf der Config-Seite des Sensors
- Der Sensorwert wird unverändert übertragen.
- Der Parameter Höhe wird, wenn vorhanden, beim Übertragen der Daten mitgeliefert und gespeichert.
- Auf der /value-Seite des Sensors könnte über eine einfache Näherungsformel, (1hPa/8m) der grob korrigierte Luftdruck angezeigt werden (Das hätte ungefähr die Abweichung wie ein handelsübliches Barometer für daheim)
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:
- Die Auswertung auf Karten kann anhand der gelieferten Werte durch eine serverseitige Berechnung nach Gusto exakt bestimmt werden.
- Liegen keine gelieferten Höhendaten vor, kann über die Google-API die jeweilige Höhe bestimmt werden.
- Wir haben keine Datenverfälschung beim Speichern, eine spätere Korrekturberechnung ist möglich.
Nachteile: Der exakte vergleichbare Luftdruck für NN wird niemals bestimmt werden können.
- Die Lufttemperatur hat einen Einfluss, sie wird zwar mitgeliefert, aber wir kennen niemals örtliche Einflüsse wie direkte Sonnenbestrahlung oder Wärmeabstrahlung von Gebäuden
- Die Bestimmung der Höhe über die API kann nicht exakt sein, da die Koordinaten aufgrund Datenschutz unscharf sind. Eine Höhendifferenz von 100m könnte aufgrund der örtlichen Topografie sowie möglichen Aufstellorten/Höhen möglich sein.
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.
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 :(
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.
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.
Es scheint mir, als ob es schlicht "schlechte" BME280er gibt
- BME280 die nach "starker Lichteinstrahlung" abstürzen und powercycle benötigen (hier nicht Thema)
- 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)
- BME280, die nach ein paar Wochen gar keine Werte mehr liefern aus dem laufenden Betrieb heraus, auch nicht nach Powercycle (auch hier nicht Thema)
- 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.
Zumindest bei diesem hier ist also nicht (nur) ein "Höhenkorrektions-Problem", sondern schlicht ein völlig problematisches Ding, weil irgendwelche, aber schlechte Werte.
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.
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
- Wenn Sensorhöhe > 0 und eines der Flags gesetzt ist: dann reduziere den Luftdruck auf msl mit der barometrischen Höhenformel des DWD und sende das an die jew. API *zusätzliche Anzeige des "Luftdrucks msl" auch in den "aktuellen Werten" am Sensor und auf einem ggf angeschlossenen Display Aktueller Stand der Umsetzung: Flags und Höhenattribut ist implementiert, Umrechnung auf msl und Anzeige in den aktuellen Werten funktioniert (ESP8266, BME280), Übergabe an APIs vorbereitet aber noch nicht getestet... Test mit ESP32 folgt
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
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.
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"...
Bilder ...
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
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.
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 BME280_pressure (kommt von unserem Sensor), dann BME280_pressure_pa und BME280_pressure_hpa Nix einfacher als den korrigierten Wert mit BME280_pressure_hpa 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
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)
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
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.
