Teil 4 – Davis Vantage Pro 2 Wetterstation ohne Konsole und ohne Datenlogger betreiben

Nachdem wir in Teil 3 gesehen haben, dass die gewählte Hardware und die technischen Überlegungen grundsätzlich stimmen, gab es Schwierigkeiten hinsichtlich der Stabilität beim Einsatz des existierenden Github Projektes für das Adafruit Feather M0 Board. In diesem Teil möchte ich euch die Ergebnisse meiner radikalen Einschnitte im Quellcode präsentieren und auch ein paar Details zu kleinen Hardware-Erweiterungen erklären.

DS3231 – Precision RTC FeatherWing

Als ich vor einigen Tagen festgestellt habe, dass so ein Adafruit Board natürlich nicht ohne Weiteres das aktuelle Datum inklusive Uhrzeit ausgeben kann (da es diese Infos schlichtweg nicht hat), habe ich mich dazu entschlossen, die Hardware ein wenig zu erweitern. Die Adafruit Feather Boards lassen sich mit so genannten Wings bestücken. Ein solches ist z.B. die Echtzeituhr.

Solche Wings lassen sich mit den passenden Steckverbindern einfach auf das Feather Board stecken und können dann mit den entsprechenden Bibliotheken aus dem Arduino Sketch angesprochen werden. Kein großer Akt und wenige Minuten später hat man einen Unix Zeitstempel. Wofür eigentlich, fragt sich jetzt der eine oder andere? Ich möchte erreichen, dass der aktuelle Zeitstempel Teil der JSON Nachricht ist, die das fertige Feather Board nach dem Empfang von Datenpaketen der ISS generiert. Zum bisherigen Stand des Datenformats dann weiter unten mehr.

BMP388 – Precision Barometric Pressure

Da sich der Sensor zur Bestimmung des Luftdrucks in der Davis Konsole befindet, brauchen wir einen Sensor, der diese Arbeit für uns übernimmt, denn die Konsole soll ja gerade nicht Bestandteil unseres Aufbaus sein. Ein sehr aktueller und präziser Sensor ist Adafruit BMP388 – Precision Barometric Pressure and Altimeter.

Dieser kleine Sensor lässt sich nicht einfach aufstecken, da die benötigten Pins nicht aufeinander folgend am Feather Board zu finden sind. Ich habe zunächst Jumper Kabel genommen, diese einseitig (am Wing) gelötet und dann auf den Sensor gesteckt. Wieder entsprechende Bibliothek aus dem Arduino Sketch angesprochen und wenige Minuten später hat man den aktuellen Luftdruck. Diese Adafruit Teile sind ein echter “no brainer“ – großartig!

Auf Wunsch kann der Sensor übrigens auch die aktuelle Temperatur ermitteln. Ich gebe diese im ersten Schritt aber nicht aus, da ich noch nicht genau weiß wieviel Sinn es macht die (Innen-)Temperatur dort zu messen, wo ich das ganze später anbringen möchte. Nicht vergessen, wir wollen hier keine Konsole nachbauen. Diese Empfangseinheit kann überall liegen und soll lediglich die Daten im passenden und neutralen Format zur Verfügung stellen. Displays, die diese Daten dann zur Anzeige bringen, sollen völlig dezentral verteilt werden können. Üblicherweise wären das dann auch die Stellen, an denen die Innentemperatur ermittelt werden sollte.

868MHz Antenne & SMA Kabel

Früher oder später wird das alles sicherlich in einem kleinen Gehäuse ggf. sogar auf einer Hutschiene Platz finden müssen. Aus diesem Grund dachte ich mir, dass eine schraubbare 868MHz Antenne Sinn macht. Ich habe diese hier genommen.

Einige Bilder zum aktuellen Stand

Wie sieht denn das Ganze aktuell aus, worüber ich hier nun seit einigen Tagen schreibe? Die Hardware ist weiterhin sehr kompakt und sollte sich später einfach verstauen lassen…

Meine Aufräumaktion im Quellcode von HydroSense hat mir zum einen geholfen, die RFM69 Bibliothek von LowPowerLab im Grundsatz besser zu verstehen, zum anderen konnte ich aber auch über die diversen Implementierungen zur Davis ISS besser nachdenken. Das aktuelle Zwischenergebnis ist eine – für meine eingesetzte Hardware – deutlich stabilere Implementierung.

Ich muss mich allerdings noch um die Tatsache kümmern, dass durchaus auch Mal mehrere Pakete hintereinander verloren gehen können. Im Moment kommt meine Implementierung komplett aus dem Takt, wenn 3 und mehr Pakete am Stück verloren gehen. Das zieht die Statistik extrem nach unten und sollte verhindert werden.

Das JSON Objekt sieht Stand heute wie folgt aus:

Dabei werden die Sensoren für Windgeschwindigkeit, Windrichtung und Luftdruck immer ca. alle 2,5 Sekunden ausgegeben und zusätzlich jeweils ein weiterer Sensor, der durch die Davis ISS Logik bestimmt wird, wie in diesem Fall z.B. die Temperatur. An diesem Zustand habe und will ich auch nichts ändern, denn so ist die natürliche Arbeitsweise der Davis ISS.

openDavisISS v0.5

Nennen will ich das Ergebnis openDavisISS und veröffentlicht wird es natürlich auf Gitlab unter der GNU General Public License v3.0. Doch bevor ich den Quellcode in einer ersten Version 0.5 dort für alle zugänglich hochlade, möchte ich noch das Sync Problem lösen, falls mehrere Pakete in Folge verloren gehen. Außerdem wird der Code noch weiter aufgeräumt und dann denke ich kann dieser erste Teil der Kette als abgeschlossen betrachtet werden. Eine abschließende Einkaufsliste, weitere Hinweise zum Aufbau und den eigentlichen Quellcode gibt es dann also zusammen in Teil 5 dieser Folge von Beiträgen. Bis bald!

Veröffentlicht von

Artur Pajonk

Solution Architect & Tech Lover

19 Gedanken zu „Teil 4 – Davis Vantage Pro 2 Wetterstation ohne Konsole und ohne Datenlogger betreiben“

  1. Servus Arthur,

    sieht gut aus!
    Ich denke ich werde mal shoppen gehen 🙂

    Eine Frage noch, wie verarbeitetest du die Daten weiter?
    Ich möchte per Wifi (ESP8266 vermutlich) die Daten an eine im Internet befindliche MySQL Datenbank weitersenden und dann auch auf meiner Seite die Visualisierung (Highcharts) machen …

    LG,
    Andi

    1. Hallo Andi,

      das was Du vor hast sollte eigentlich technisch umsetzbar sein. Ich werde mich für die etwas „größere“ und vor allem lokale Variante entscheiden.

      Mein Plan ist, die Daten seriell an einem Raspberry Pi zu empfangen. Dort muss ich dann mal schauen wie es um die Leistung bestellt ist. Eigentlich würde ich darauf dann gerne VerneMQ hosten, für die direkte Datenübertragung an bestimmte Empfänger im Haus und eine PostgreSQL Datenbank für die Langzeit Auswertung von Daten. Diese PostgreSQL Datenbank soll dann auch einer Website als Quelle dienen, um die Wetterdaten in der direkten Nachbarschaft zur Verfügung zu stellen. Bis dahin ist aber glaube ich noch ein ganzer Weg zu gehen 😉

      Beste Grüße,
      Artur

  2. Das liest sich sehr interessant und ich freue mich auf Teil 5.
    Meine Davis Instalation scheint etwas größer weil ich noch eine Bodenfeuchtestation mit zwei bodensensoren, entsprechend zwei temperatursensoren und einem Blattfeuchtesensor habe.
    Meine ISS hat noch den UV- und Beleuchtungssensor. Ich hoffe das diese zusätzlichen Sensoren auch noch Eingang finden.

    Vielleicht darf ich als Datenbank eine spezielle zeitreihendatenbank für diesen Zweck empfehlen: InfluxDB. Spart viel Zeit und ggf auch Platz. Läuft auch super auf Raspi mit SSD für die Daten…
    1. Timestamp führt die DB in den Datensatz ein, so kann man NTP und GPS als absolute Zeitquellen verwenden und braucht kein RTC Featherwing mit dem inhärenten drift.
    2. aggregierungen können von der DB automatisch durchgeführt. Auch nachträglich können ganz schnell neue eingeführt werden.
    3. DB kann (nicht muss!!) automatisch bereinigt werden. Es interessiert ja nicht ein einzelner Messwert ein Monat später sondern die konsolidierten d.h. aggregierten Werte von zB einer Minute, Stunde und Tag.
    4. es gibt eine sehr schicke Auswertungsengine mit der selbst die so schicken Windrosen schnell und einfach erstellt sind.

    Ich bin auf InfluxDB durch einen Artikel bei Heise gestoßen: https://www.heise.de/ratgeber/InfluxDB-Spezialisierte-Datenbank-fuer-Messwerte-und-Logging-4314271.html

    Bisher habe ich seit 12 Jahren die Messwerte in einer MySQL Datenbank gesammelt und ich erwäge ernsthaft auch die Altdaten komplett auf InfluxDB zu migrieren und damit die separate Anwendung die bisher die Aggregierung durchführt zu streichen. Zum einen weil ich weniger Code pflegen muss aber vor allem weil Änderungen mit InfluxDB so viel einfacher und sicherer umgesetzt werden können dass ein separates Programm Unsinn ist.

    Gruß
    Richard

    1. Hallo Richard,
      das ist ein guter Tipp mit InfluxDB vor allem die Aggregierung würde einiges an Skripten sparen. Leider ist auf meinem preisgünstigen virtuellen online Server nur mySQL verfügbar, aber die ersten Arbeiten könnte ja eine InfluxDB auf dem Raspi machen und dann werden nur noch aggregierte Daten Synchronisiert.
      An der Nützlichkeit der RTC zweifle ich auch etwas. Mir scheint es sinnvoller die Daten so schnell es geht in die DB zu speichern. Den Timestamp kann ich dort auch setzten. Die Empfangseinheit holt die Daten von der ISS der Raspi kümmert sich um den Eintrag in die DB.

      Ich hoffe Teil fünf kommt bald! Freue mich schon sehr darauf.

    2. Hallo Richard,

      InfluxDB ist mir natürlich bekannt gewesen, dennoch habe ich mich aufgrund dieser kleinen „Case Study“ (https://portavita.github.io/2018-07-31-blog_influxdb_vs_postgresql) für PostgreSQL entschieden.

      Und natürlich kann jede Datenbank selbst Timestamps generieren, ebenso könnte das auch der Raspberry erledigen, sobald die Daten dort seriell angekommen sind, da ich aber Stand heute noch gar nicht weiß, welches System die Daten empfängt und verarbeitet, find ich es klüger den Zeitstempel bereits durch diesen FeatherWing generieren zu lassen. Stell Dir vor, es ist irgendwann ggf. gar nichts zwischen Feather Board und einem Display zur Anzeige der Daten, dann ist es doch wünschenswert auch zur Anzeige zu bringen, wann diese Daten vom Board empfangen wurden, oder?

      Da es sich zudem um die „Precision“ Variante handelt, ist das Thema „Drift“ absolut zu vernachlässigen. Wir sprechen hier nicht von Daten, die im Millisekunden Bereich exakt beschriftet sein müssen 😉

      Viele Grüße,
      Artur

      1. Huh, schon mehr als ein Jahr vergangen… Und dieses Jahr gibt es zu den leidlichen Pollen auch noch verdriessliche Viren 🙁 Ich hoffe allen geht es gut.
        Vielleicht hatte Artur sogar Zeit um sich während des Lockdowns um openDavisISS v0.5 zu kümmern und uns damit zu erfreuen nicht nur 10% der Pakete zu empfangen und zu verarbeiten…

        Bzgl Drift: Meine Station läuft gerade seit 5 Jahren ohne Unterbrechnung. Was wohl die „Precision“ RTC für eine Abweichnung nach der Zeit hätte? So ganz ohne konstante klimatische Bedingungen… Vermutlich sind wir sind uns einig dass eine quarzbasierte RTC nach der Zeit Fehler eher im Minuten- als im Milisekundenbereich hat. Und ja, man kann die RTC auch regelmässig über die serielle Schnittstelle korregieren. Aber wozu der Aufwand wenn da dann doch ein RasPi läuft der NTP so oder so hat?

        Bzgl Anzeige: ist es ggf nicht schicker den RasPi der die Daten seriell annimmt und lokal oder remote speichert mit einem Display auszustatten und diesen mit einem Grafana Dashboard zu beschicken das aus den aggregierten Daten aus der InfluxDB gespeist wird? Gemeinhin sagt doch eine aggregierte Grafik mehr als sich wild ändernde Zahlen. Mir gefällt dieses Detail sehr: https://grafana.com/grafana/plugins/fatcloud-windrose-panel
        Und dann kann man ja auch noch mosquito/MQTT damit lokal speisen um die Homeautomatisation mit vielen schönen Features bereichern zu können. Alles mit dem einen JSON Output deiner Implementierung und ohne viel zusätzlichem Code.

        Jeder hat andere Prioritäten und Prämissen und so würde es mir nie einfallen meine Zeitreihendaten – wozu die Wetterdaten ja gehören – nur auf einem öffentlichen Webserver zu speichern, aber – wie gesagt – jeder Jeck ist anders…

        Richard

  3. … noch etwas. Angesichts der unfassbar niedrigen Hardwarepreise ist es vielleicht zu überlegen, die Daten des RFM96 per wlan an den Raspi zu senden. Bei einem direkten Test konnte ich keine Verschlechterung des 868 MHz Empfangs bei eingeschaltetem wlan feststellen.

    1. Hallo Thomas,

      kann man natürlich so tun und sollte auch klappen. Ich persönlich akzeptiere allerdings schon die 868MHz Funkübertragung zur ISS eher zähneknirschend, da möchte ich ungern ganz bewusst eine Kaskadierung zweier Funkprokolle in Kauf nehmen 😉

      Außerdem habe ich im Haus an der Stelle, an der die Feather Board + Raspi Kombi mal installiert wird, sowieso LAN Anschluss aber grundsätzlich ist dagegen nichts einzuwenden. Man könnte statt des RTC Wing auch den LAN Wing nehmen und es ganz ohne Raspi probieren. Da stehen einem so ziemlich alle Wege offen.

      Viele Grüße,
      Artur

  4. Hallo Arthur,
    die Artikelserie finde ich sehr spannend und motiviert mich etwas tiefer zu graben. Bei mir läuft iobroker und eine homematic CCU auf einem raspi/opi. Nun würde ich gerne eine Wetterstation einbinden um dann Homematic-Komponenten bei gewissen Events fernzusteuern (z.B. Sonnenschutz einfahren bei Wind oder Regen). Leider fehlt mir das know how wie die Daten von dem von dir beschriebenen Board in verarbeitbarer Form auf die Homematic oder in den iobroker kommen.
    Ein wenig Erfahrung mit Arduino Sketches, JS in iobroker und Homematic-Skript habe ich mir im letzten Jahr erarbeitet, aber mit den Schnittstellen zwischen den Systemen fehlt doch die Erfahrung. Hast Du hierzu evtl. Ansatzpunkte die als „Dummy“-Leitfaden dienen könnten, oder hast aufgrund deines Projektes ggf. schon eine Lösung griffbereit?
    Bin gespannt wie es hier weitergeht. Würde gerne eine vernünftige Wetterstation erwerben, zögere aber solange mir die Idee fehlt wie ich die Daten ins System bekomme.

    Gruß Gerald

    1. Hallo Gerald,

      um die Anbindung an diverse Systeme kümmern wir uns am besten, wenn das erste Glied in der Kette, der Empfänger, sauber läuft und die Daten verarbeitet. Hier sind die genannten Arduino Projekte ein guter Startpunkt. Ich habe alles soweit zusammengestrichen und angepasst, dass es hoffentlich überschaubarer Programmcode wird. Das werde ich im Github zur Verfügung stellen. Danach kann dann jeder mal schauen, auf welchem Wege die Daten am besten in sein Smart Home kommen.

      Viele Grüße,
      Artur

  5. Hallo Artur,

    das liest sich extrem interessant und ich hoffe, dass es noch mit Teil fünf weitergeht. Eine kurze Frage hätte ich noch. Ist die oben verlinkte Version soweit verwendbar, oder soll da noch der erwähnte Fix rein?

    Gruß Gerald

    1. Hallo Gerald,

      also meine angepasste Version ist soweit voll funktionsfähig. Ich möchte nur noch zwei, drei Kleinigkeiten anpassen und werde diese dann unter der oben angegebenen Adresse im Github für alle zur Verfügung stellen.

      Grüße,
      Artur

  6. Hallo Artur,

    das Setup liest sich super!
    Gibt es bereits Fortschritte in Version 0.5 mit dem Sync/Paketverlust beim Empfangen von der ISS?

    VG, Mike

    1. Hallo Mike,

      ja, ich habe über die Feiertage eine Funktion implementiert, die einen „double hop“ macht. Was klügeres ist mir nicht eingefallen 🙂 Das sollte aber helfen schneller wieder den Rhythmus zu finden, falls einmal mehr als 3 Kanalwechsel in Folge nichts empfangen werden kann. Dummerweise stand meine Davis zu lange im dunklen Keller. Nun ist die Batterie leer und ich kann nicht testen. Ersatzbatterie ist schon bestellt und sollte morgen eintreffen…

      Viele Grüße,
      Artur

  7. Hallo Artur,
    herzlichen Dank für die mehr als detaillierte Einführung in dein interessantes Projektvorhaben – genau so etwas habe ich gesucht 😉 Wenn Du Unterstützung beim Testen benötigst, helfe ich gerne, habe die volle Ausbaustufe der VP2 mit zusätzlichem Bodensensor.
    Kann schon jetzt den ersten Codeentwurf kaum erwarten, sobald er auf Github ist, bestelle ich die Hardwarekomponenten.
    Viele Grüße
    Kai

  8. Hi Artur!

    Gibt’s schon Fortschritte für Teil 5? Ich bin sehr an deinem Code interessiert, die Hardware Seite hab ich aber ich bin einfach zu schlecht im programmieren um sowas dann in Code umzusetzen!

    LG
    Sebastian

  9. Hallo Artur

    Ich hatte gar nicht auf die von Dir referenzierte „Case Study“ reagiert. Der Author stellt sehr auf „Heavy Load“ ab und definiert in meiner Warnehmung nicht was er darunter versteht. Meinem Verständnis nach ging es hier um ca 1 Datensatz pro Sekunde. Ich betreibe hier seit Juni letzten Jahres InfluxDB und Mosquito als Docker Images auf einem RasPi 3 mit einer ca 50% höheren Schreiblast aus anderen Sensoren der Wohnung und gemeinhin höchstens einem akiven Client über Grafana auf einem zweiten RasPi. Ein Haushalt halt. Die Responsetime ist gemeinhin deutlich unter 1,5s. Nur bei der Windrose habe ich Zeiten bis 3s gemessen aber noch nie ein Paket verloren weil InfluxDB nicht schnell genug es aus dem MQTT abgeholt hätte. Auch bei einem Test wo drei Clients gleichzeiting die Windrose für unterschiedliche Zeiträume aufgerufen haben nicht, was real hier eigentlich nie passieren kann.
    Mein Ziel wenn Du deine Lösung veröffentlichst ist mit dem Feather-M0-RFM69 und einem Ehernet Wing die Daten direkt an Mosquito/MQTT zu senden. Ein lokales OLED Wing erwäge ich auch um den aktuellen Status anzuzeigen: DHCP, IP, MQTT und Daten bzgl der Datenübertragung von den Stationen (ISS, …), aber keine Wetterdaten. Dazu habe ich zwei RasPi mit Display in der Wohnung auf denen der Grafana Dashboard angezeigt wird und mich vor allem in fett rot erinnert wenn ich binnen 7 Tagen die Batterie der Station wechseln muss, was bisher der wesentliche Grund war warum ich Messdaten „verloren“ habe… :[

    Ich denke wir sind alle mehr als (pleased) wenn Du openDavisISS v0.5 veröffentlichst. ggf auch als work in progress einfach nur mit einer besseren Empfangsrate als 10%… Besser eine auch nur etwas bessere Lösung (und da scheinst Du ja deutlich darüber hinaus zu sein!) jetzt veröffentlichen als eine fast perfekte irgendwann…

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.