Ecowitt / Wunderground API für weather.hiveeyes.org nutzbar?

Die (WLAN-)Wetterstationen von froggit / Ecowitt bieten die Möglichkeit, die gemessenen Sensordaten an den eigenen Server zu schicken. Auf der Telemetrie-Strecke sendet dabei die Wetterstation die Daten per 868 MHz, das Gateway oder Display (mit eingebautem Geteway) empfängte diese und sendet sie per WLAN / Ethernet an den Server.

Dabei ist die API vorgegeben, in der Doku zur HP2000 steht:

Unterstützt das Hochladen auf Ihre individuelle Website, wenn die Website das gleiche Protokoll mit Wunderground oder Ecowitt hat.

Nun wäre spannend, ob wir die Ecowitt API direkt für weather.hiveeyes.org nutzen können bzw. was / wie viel wir umbauen müssten.

Bei einer ersten Suche der API-Dokumentation [keywords: Ecowitt API] findet man meist Verweise auf eine API für den Datenabruf von www.ecowitt.net. Wir wollen aber was anderes: Daten von unserer Wetterstation auf einen eigenen Server bekommen, also andere API.

Habe noch keine Wetterstation hier, sonst hätte ich einfach mal getestet. :-)

Aus der Doku der Display-Einheit HP2560_C, S. 50: Da Ecowitt oder Wunderground ausgewählt werden kann, scheinen die APIs nicht identisch zu sein.

[edit] Super Infos zu den APIs Ecowitt vs. Wunderground unter Ecowitt Wetterstationen [] dort steht z.B., dass Ecowitt per HTTP POST und Wunderground per HTTP GET die Daten verschickt, auch zur Eingabe von Server und path findet man hilfreiche Tipps!!

Alternative 1: Falls man die API für den eigenen Server nicht nutzen kann oder keine WLAN-Station hat, ist immer noch dieser (Um-)weg möglich: Direkt das Funksignal des Außensensors per RTL-SDR-Dongle abfangen und von dort weiter ins Netz.

Alternative 2: Wäre, die Daten an den Ecowitt-Server zu schicken und sie von dort via https://api.ecowitt.net/ wieder bei uns zu importieren.

Vermutlich macht es nur Sinn die Ecowitt-API zu nutzen, da nur sie alle Sensoren unterstützt, Wunderground scheint nur die Daten bereitzustellen, die Wunderground auch anzeigt, d.h. keine Bodenfeuchte / -temperatur. Klimadaten innen, …

Hier ein paar Code-Fundstücke, die das Ecowitt-Protokoll beherrschen

shell-skripte stellt das Projekt ⛅ WLAN-Wetterstation | WLAN-Wetterstation stellt auf github shell-Skripte bereit, die für Wetterdaten im "Wunderground/Ecowitt”-Format genutz werden können.
Die magic scheint sich in wetterstation.sub / ab Zeile 346 zu ereignen, doch etwas komplexer als nur POST-Datenpakete anzunehmen. :-(

Ein python repo unter https://github.com/iz0qwm/ecowitt_http_gateway/

Ein Generischer Übersetzungs-Server (?) ist FOSHKplugin - generic version [LoxBerry Wiki - BEYOND THE LIMITS] “is able to feed a MQTT broker” hört sich gut an, müsse aber seperat als service laufen.

Ggf. auch interessant, Diskussion auf Ecowitt API - diverse Wetterstationen, die zapfen dort das Gatway direkt per HTTP an und die Station liefert dann JSON, wäre eine 3. Alternative (nicht schön, da pull) falls das mit der API nichts wird.

Hi Clemens,

wenn Du magst, und das vielleicht ins Konzept passt, schau doch auch gern mal, ob die Anlage von WeeWX unterstützt wird. Das ist der FOSS Platzhirsch unter den Wetterstationsanbindungen, und kann die Daten über ein Plugin (dank an @weef) auch per MQTT versenden [1].

Die Standard-Ausgabe von WeeWX ist zwar ein wenig altbacken (Stand 2017), aber hier drüben bei The Beauty of Weather Information - #8 by Andreas hatte ich mal gesammelt, wie mit WeeWX ansprechendere/modernere Ausgaben zu erzeugen sind.

In dem dort gezeigten, von Ian Millard gepflegten Projekt, der Darstellung der Wetterdaten von Steeple Claydon, steckt schon ordentlich Liebe zum Detail drin.

Viele Grüße,
Andreas.


  1. Siehe Open weather data - #8 by Andreas und WeeWX — Kotori 0.27.0 documentation. ↩︎

1 Like

WeeWX habe ich mir bisher nicht genauer angesehen u.a. wegen dieser Anmerkungen im FHEM-Forum

beides hatte ich bereits im Einsatz. Viel zu kompliziert. Wenn Modul, dann Modul und ohne 3rd Party Tools. Alleine weewx so zu konfigurieren, dass es die korrekt umgerechneten Werte an fhem per mqtt schickt, war grauenhaft umzusetzen. Support = 0.

Stimmt, weewx ist die Hölle. Aber deshalb würde ich das nur im zweiten Schritt aufsetzen.

Nachteil von WeeWX – genauso wie von FOSHKplugin – ist, man muss beides lokal auf einem 24/7-on-Rechner installieren (wenn ich die Konzepte richtig verstanden habe). Hatte gehofft, dass man mit der angebotenen Ecowitt-API das nicht braucht.

Meine Station könnte unterstützt werden, das Display / Gateway ist offiziell ein HP1000SE PRO schaut dem HP2550 auf WeeWX: Supported Hardware allerdings sehr ähnlich. Die HP1000 wird auch gelistet, meine wäre die HP1000SE PRO 7-In-1 Ultra (gesamte Station).

Die Grafana-Darstellung von Ian Millard ist noch hübscher geworden als 2019 von dir verlinkt, wenn man an die Grafana-sourcen kömmen könnte … aber erst mal die Daten rein bekommen.

1 Like

Ja, ich verstehe Deinen Ansatz. »Einfach nur APIs verbinden« könnte komfortabler sein.

Wunderbar. Danke fürs Nachsehen!

Ja, das gefällt mir auch. Es ist übrigens kein Grafana, sondern eine standalone Web-Anwendung.

Ack ;].

1 Like

So, etwas schlauer! Scheint deutlich einfacher zu sein als gedacht! Bei der Wetterstation kann man ja einen eigenen Server als Exportziel angeben, wenn man das mit der Einstellung (am Display unter “protocol type”) Ecowitt macht verschickt die Station diese Daten als HTTP POST!

  • PASSKEY scheint 'ne eindeutige ID zu sein, allerdings nicht 1:1 die MAC des displays / Gateways, die muss man nämlich angeben, wenn man auf dem Ecowitt-Server ein Konto eröffnet, um dann “seine” Wetterstation zu grabben.

  • stationtype hmm, dachte die Firmware-Version der Station, kann aber nicht sein. Für meine wird auf der froggit-Seite Firmware V1.8.6 als letzte angeboten. [google] es gab mal eine Windows-Software zum Daten auslesen mit dem Namen “EasyWeather”, vielleicht hats damit zu tun

  • runtime scheint in Sekunden zu sein, der erste Datensatz: 456128, der zweite: 456189, also 61 Sekunden dazwischen, update-Intervall sind 60 Sekunden bei der Station eingestellt, sollte also passen.

  • dateutc timestamp der Messung in UTC, nicht local time

  • tempinf Innensensor Temperatur in Fahrenheit :-/

  • humidityin Innensensor Luftfeuchte

  • baromrelin / **baromabsin’ Innensensor Luftdruck, einmal relativ, einmal absolut, ist bei mir gerade identisch, da Auslieferungszustand.

  • tempf Außensensor (“die” Wetterstation) Temperatur, immer noch in °F

  • humidity Außensensor Luftfeuchte

  • winddir Windrichtung

  • windspeedmph Windgeschwindigkeit in mph

  • windgustmph auch wieder mph, Windgeschwindigkeit Böen

  • maxdailygust Höchstgeschwindigkeit Böen am Tag, vermutlich auch mph

  • solarradiation hmmm w/m2 ??

  • uv UV-Index

  • rainratein, eventrainin, hourlyrainin, dailyrainin, weeklyrainin, monthlyrainin, yearlyrainin alle Niederschlagsdaten in inch! nicht mm

  • temp1f, humidity1 ein weiterer kombinierte Temperatur / Feuchte-Sensor mit der ID #1, Temperatur immer noch in Fahrenheit

  • soilmoisture1, soilmoisture2 die beiden Bodefeuchte-Sensoren mit #1 und #2

  • tf_ch1 das müsste der Bodentemperaturfühler #1 sein

  • rrain_piezo, erain_piezo, vermutlich wie oben Rainrate und event rate hrain_piezo, drain_piezo, wrain_piezo, mrain_piezo, yrain_piezo, ist wohl hourly, daily, weekly, monthly, yearly, nix angegeben, sollte – wie oben – in inch sein

  • wh65batt, wh25batt, batt1, Bei den Batteriespannungen wird auch im Ecowitt-UI bei einigen Batterien / Akkus nur “normal” angegeben, WH65 ist vermutlich das Sensor-Arry (aka “the” station) bzw. ein Teil davon WH25 ist der Innen-T/H/P-Sensor, batt1 vermutlich der zweite momentan extern montiert T/H-Sensor. Auf Ecowitt gibt es noch das Haptic Array (Capacitor) mit 2.4 V das vermutlich in der Datenübertragung fehlt. ‘wh90batt’ => ‘3.04’ das Haptic Array (Battery). Die Station hat eine Stromversorgung mit 2x 1.5 V-AA-Batterien und einen LiPo / Capacitor, der vom integrieten Solarpanel aufgeladen wird.

  • soilbatt1, soilbatt2 sind die Bodenfeuchte-Sensoren (haben je eine AA-Zelle) ‘tf_batt1’ => ‘1.60’ muss dann der Boden-Temperatursensor sein.

  • freq wissen wir das nun auch, die Station überträgt die Daten mit 868 MHz.

  • model hier gibt es die Firmware-Version: V1.8.5, dann kann ich ja auf die V1.8.6 updaten, geht über SD-Karte.

Man könnte einfach alles per Kotori über die schon genutzte POST-Annahme schicken. Wie sinnvoll es ist dann immer alles zu speichern ist 'ne andere Frage.

Könnten wir der DB sagen, die Werte sind z.B. Fahrenheit in der DB und Grafana kann die Umrechung im frontend machen?

POST dump von 2 Datenübertragungen:

array (
  'PASSKEY' => 'B950C...[obliterated]',
  'stationtype' => 'EasyWeatherPro_V5.0.6',
  'runtime' => '456128',
  'dateutc' => '2023-02-20 16:02:19',
  'tempinf' => '69.8',
  'humidityin' => '47',
  'baromrelin' => '29.713',
  'baromabsin' => '29.713',
  'tempf' => '48.4',
  'humidity' => '80',
  'winddir' => '108',
  'windspeedmph' => '1.12',
  'windgustmph' => '4.92',
  'maxdailygust' => '12.97',
  'solarradiation' => '1.89',
  'uv' => '0',
  'rainratein' => '0.000',
  'eventrainin' => '0.000',
  'hourlyrainin' => '0.000',
  'dailyrainin' => '0.028',
  'weeklyrainin' => '0.098',
  'monthlyrainin' => '0.909',
  'yearlyrainin' => '0.909',
  'temp1f' => '45.0',
  'humidity1' => '90',
  'soilmoisture1' => '46',
  'soilmoisture2' => '53',
  'tf_ch1' => '41.9',
  'rrain_piezo' => '0.000',
  'erain_piezo' => '0.000',
  'hrain_piezo' => '0.000',
  'drain_piezo' => '0.028',
  'wrain_piezo' => '0.043',
  'mrain_piezo' => '0.492',
  'yrain_piezo' => '0.492',
  'wh65batt' => '0',
  'wh25batt' => '0',
  'batt1' => '0',
  'soilbatt1' => '1.6',
  'soilbatt2' => '1.6',
  'tf_batt1' => '1.60',
  'wh90batt' => '3.04',
  'freq' => '868M',
  'model' => 'HP1000SE-PRO_Pro_V1.8.5',
)
array (
  'PASSKEY' => 'B950C...[obliterated]',
  'stationtype' => 'EasyWeatherPro_V5.0.6',
  'runtime' => '456189',
  'dateutc' => '2023-02-20 16:03:20',
  'tempinf' => '69.8',
  'humidityin' => '47',
  'baromrelin' => '29.719',
  'baromabsin' => '29.719',
  'tempf' => '48.4',
  'humidity' => '80',
  'winddir' => '151',
  'windspeedmph' => '2.01',
  'windgustmph' => '4.47',
  'maxdailygust' => '12.97',
  'solarradiation' => '2.05',
  'uv' => '0',
  'rainratein' => '0.000',
  'eventrainin' => '0.000',
  'hourlyrainin' => '0.000',
  'dailyrainin' => '0.028',
  'weeklyrainin' => '0.098',
  'monthlyrainin' => '0.909',
  'yearlyrainin' => '0.909',
  'temp1f' => '45.0',
  'humidity1' => '90',
  'soilmoisture1' => '46',
  'soilmoisture2' => '53',
  'tf_ch1' => '41.9',
  'rrain_piezo' => '0.000',
  'erain_piezo' => '0.000',
  'hrain_piezo' => '0.000',
  'drain_piezo' => '0.028',
  'wrain_piezo' => '0.043',
  'mrain_piezo' => '0.492',
  'yrain_piezo' => '0.492',
  'wh65batt' => '0',
  'wh25batt' => '0',
  'batt1' => '0',
  'soilbatt1' => '1.6',
  'soilbatt2' => '1.6',
  'tf_batt1' => '1.60',
  'wh90batt' => '3.04',
  'freq' => '868M',
  'model' => 'HP1000SE-PRO_Pro_V1.8.5',
)
2 Likes

ick benenn mir meist den parameter mit der einheit, also temp_2m_c oder pressure_hpa. Ja, Umrechnen tu ich später denn beim Query-Kneten im Grafana.

Als “public Endpoint” am weather. haben wir ja eigentlich/vorallem/nur den MQTT-Endpoint. irgendeins Gerät bei Euch müsste diese Daten bekommen und dann als MQTT-Payload wegmorsen.

Wenn so nen dedizierter Rechner dazukommen muss, kann man auch gleich wieder über nen RTL-SDR nachdenken. Wäre ja mal gespannt wieviel rtl_433 davon schon versteht. EcoWitt taucht ja schon ein paar mal in den unterstützten Protokollen auf. @clemens wann bistn du da wieder/bissu da regelmäßig?

Was wäre denn mit ecowitt2mqtt?

1 Like

Mit dem HTTP DAQ Interface übernimmt Kotori eigentlich schon den Großteil der technischen Arbeit, und leitet die Daten ja ebenfalls nach MQTT durch. Dieser Teil von ecowitt2mqtt wäre also nicht unbedingt relevant.

Aber könnte jener Satz an Features interessant sein?

In addition to the data coming from a gateway, ecowitt2mqtt will automatically deduce and publish several additional, calculated data points if the requisite underlying data exists.

ecowitt2mqtt » Calculated Sensors

Interessant ecowitt2mqtt! Danke fürs Suchen und Finden, @Andreas! Das müsste ja auch nicht auf einem RasPi vor Ort laufen, wo versehentlich jemand den Stecker zieht oder anders “das Datenkabel” unterbricht, sondern es könnte auch auf 'nem hiveeyes-server laufen?

Die zusätzlich berechneten Werte sind auf jeden Fall spannend, z.B. Taupunkt, gefühlte Temperatur, wind chill, da es im Projekt auch um Klimafolgenbelastung von Menschen in der Stadt geht und da sind psychische oder “gefühlte” Temperaturen vs. physikalisch gemessene schon interessant. Die Werte könnten wir vermutlich auch mit Grafana berechnen, so ist es aber etwas komfortabler und die Sachen würden schon in der DB stehen und müssten nicht on the fly beim Panelaufruf berechnet werden.

Was ich ebenfalls nützlich finde:

Overriding Units for Data Categories
If you wish, you can change the unit for individual data categories.

Das Ecowitt-Gateway verschickt die Daten immer imperial, das ist auch nicht änderbar: Fahrenheit für Temperaturen, mph beim Wind, Niederschlag in inch, siehe posting #6 hier im thread. Auch das könnte man in Grafana bereinigen:

Komfortabler und weniger fehleranfällig wären sicher gleich Werte mit “richtigen” Einheiten in der InfluxDB zu haben.

Apropos “fehleranfällig” mit einer weiteren Transformationsstelle steigt die Komplexität unseres Systems und ggf. auch die Fehleranfälligkeit. Wenn das Ding allerdings auf unserem Server läuft, wäre der zusätzliche Komfortgewinn ggf. damit zu rechtfertigen.

Die WS90, die wir haben ist recht neu, ggf. sind noch nicht alle Felder in ecowitt2mqtt drinnen, wenn es da ein matching gibt, der Piezo-Regensensor ist der neue Teil:

[edit] Gerade nachgeschaut, der ist bereits integriert und tauch an diversen Stellen im Repo auf.

Bringt ecowitt2mqtt uns auch beim Problem mit dem PASSKEY weiter, sprich können wir sagen welche Datenfelder weitergegeben werden sollen / dürfen / müssen oder reicht der alles durch und wir hätten dieses Problem immer noch?

1 Like

:+1:

Oh. Ja!

Ja genau, ist kein Drama.

Das könnte man dann auch sehen. u.U. lässt sich dieses Thema an genau dieser Stelle auch besser lösen.

Unter Umständen ließe sich ecowitt2mqtt/ecowitt2mqtt/data.py at dev · bachya/ecowitt2mqtt · GitHub auch direkt im Kotori einhängen. So könnte man sich den Betrieb eines extra Dienstes sparen.

Eine komplette Installation hätte den Vorteil, dass wir upstream-Änderungen leichter integrieren können, so 1:1 werden wir die data.py von ecowitt2mqtt mit upstream-Kompatibilität vermutlich nicht hinbekommen, oder?

Eine Möglichkeit generisch (jenseits von Ecowitt-Wetterstationen), global oder basierend auf realm, network, gateway, node bestimmte Datenfelder nicht anzunehmen, sprich nicht in die Datenbank zu schreiben und nicht im feed auftauchen zu lassen, wäre auch ein hilfreiches stand alone feature für Kotori.

Zweifelsohne! Da gäbe es so einiges, was gerne “pro Kanal konfigurierbar” gemacht werden würde. Siehe z.B. gerade frisch:

TODO: Make timezone configurable per channel.

[DRAFT] DAQ: Assume naive human-readable timestamps w/o timezone information to be in UTC by amotl · Pull Request #124 · daq-tools/kotori · GitHub

Ja, Mist, ist mir auch gerade mit deinem Hinweis aufgefallen, dass Ecowitt UTC timestamped und das auch nicht änderbar ist, leider:

Immerhin ist es aus dem Variablenname ersichtlich, das value ist aber “blank”.

1 Like

Ja.

Naive datetime timestamp (local time treated as UTC).

[DRAFT] DAQ: Assume naive human-readable timestamps w/o timezone information to be in UTC by amotl · Pull Request #124 · daq-tools/kotori · GitHub

Du musst Dir keine Sorgen machen. Die Codequalität ist 1a, so dass es nicht schwer war, die entsprechende Dekodierungsroutine passend wiederzuverwenden. Die Software wird ziemlich gut gewartet und steht auf PyPI zur Verfügung (ecowitt2mqtt · PyPI), so dass auch die Einbindung kein Problem war.

So gefällt mir das jetzt eigentlich ganz gut:

Damit sind einfach weniger bewegliche Teile im Spiel, und wir bekommen trotzdem alles: die Anonymisierung der Daten, den Komfort der Einheitenumrechnung, die zusätzlich berechneten Werte, die Testabdeckung, und keinen zusätzlichen Installationsaufwand. :sparkles:

P.S.: Dank geht raus an Aaron Bach für ecowitt2mqtt [1] – starke Software! :100: :heart:


  1. GitHub - bachya/ecowitt2mqtt: Send data from Fine Offset weather stations (Ecowitt, Ambient Weather, Froggit, etc.) to MQTT! ↩︎

1 Like

Habe gerade nochmal nachgesehen. Die zusätzlich berechneten Werte sind standardmäßig angeschaltet.

1 Like