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

Consultant & Senior Software Engineer

12 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

  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

Schreibe einen Kommentar

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