Ecowitt API - diverse Wetterstationen

Begonnen von gent, 15 Dezember 2021, 20:52:55

Vorheriges Thema - Nächstes Thema

gent

Gerade eben bei den Kollegen vom wetterstationsforum.info gelesen:

API* für alle auf www.ecowitt.net registrierten Konsolen

Seit Kurzem (Ende Februar 2022) hat Ecowitt die Definition seines API für den Cloud-Server ecowitt.net veröffentlicht/freigegeben. Jeder Benutzer kann damit aus der Ecowitt-Cloud die von seiner(n) Konsole(n) auf ecowitt.net im 5-Minuten-Intervall gespeicherten lokalen Wetterdaten mit Hilfe eines entsprechenden Programmes herunterladen. Manuell war das schon immer interaktiv auf der Webseite möglich.
Benötigt werden dazu ein API-Key (Schlüssel) und ein App-Key (Anwendungsschlüssel), die jeder registrierte Benutzer in seinem Konto erzeugen kann. Hinzu kommt noch die MAC Adresse der Konsole (siehe WS View [Plus] Geräteliste (Device List).
Damit kann man z.B. bei Datenverlust o.ä. die Daten der letzten 90 Tage im 5-Minuten-Intervall herunterladen.
Oder auch, wenn man seinen Datenlogger nicht 24/7 laufen lassen möchte und einem ein 5-minütiges Speicherintervall genügt.


Man braucht dazu auf seiner ecowit.net page unter dem User Profile einen API-Key und einen Application Key. Als Label kann man eingeben, was man will und bekommt die beiden Keys dann direkt angezeigt.

Mit folgendem Aufruf bekommt man die Daten als JSON zurück:

https://api.ecowitt.net/api/v3/device/real_time?application_key=APPLICATION_KEY&api_key=API_KEY&mac=YOUR_MAC_CODE_OF_DEVICE&call_back=all

Alle weiter Infos zur API hier : https://doc.ecowitt.net/web/#/apiv3en?page_id=1

Ich schaue mir das heute Abend mal an. Allerdings bin ich eigentlich für die Hausautomatisierung Verfechter von Cloud-Free Lösungen, daher finde ich das Modul von sepo83 prinzipiell besser, auch wenn hier noch etwas Finetuning nötig ist / war. Aber wer es lieber einfach haben will und die Werte ALLER Sensoren in FHEM haben will (nicht nur die über WU bereitgestellten Werte), dem kann hiermit geholfen werden.

Liebe Grüße, Holger
fhem auf rPi3 mit USB boot und M2, cul866 (hm), homebridge, FlowerSens, Shelly, Harmony, WemosD1, Sonoff/Tasmota, grafana, mqtt/mosquitto

Fistandantilus

Hi, wie ist denn der aktuelle Stand? Der Weg über TCP wäre mir grundsätzlich auch lieber, als erst alles in die Cloud zu schicken und von da wieder zu holen.
Wenn sepo83 nicht mehr weiterentwickelt, könnten wir das Ganze auch in einem neuen Repository weiterführen. Wir bräuchten halt jemanden, der das in die Hand nimmt :) Ich kann soweit möglich gern mit Testen und Supporten, bin aber ansonsten beruflich ziemlich eingespannt.

Viele Grüße, F.
Raspberry Pi 3 + FHEM + Smartvisu/Fronthem, CUL, HMLAN, Enocean USB300, Eltako (FAM14, FSB14, FSR,FTS14EM,Multisensor,...) - MySQL DB + 2.Raspberry für Heizungsregelung und 3. Raspberry als Alarmanlage

kjmEjfu

die aus meiner Sicht einfachste Variante ist ein "Plugin" zwischenzuschalten: https://loxwiki.atlassian.net/wiki/spaces/LOXBERRY/pages/1252524456/FOSHKplugin+-+generic+version
Das kommt zwar von LoxBerry, aber in der Generic Version läuft es ohne. Das konfiguriert man, lässt Ecowitt dorthin die Daten schicken und FOSHKplugin schiebt alles auf einen MQTT Server.
Hast damit Zugriff auf alle Daten und FOSHKplugin generiert sogar noch ein paar zusätzliche Daten.

(und wer will, setzt sich noch https://www.weewx.com/ auf und schiebt die Daten auch dorthin).
Migriere derzeit zu Home Assistant

gent

Hallo kjmEjfu, Fistandantilus

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.

Den Weg über TCP (zumindest in der Version, die sepo83 bereitgestellt hatte) legt bei mir sporadisch FHEM komplett lahm, weil es - im Falle das das GW1000 im WLAN mal nicht erreichbar ist - den Prozess nicht abbricht. War für mich also keine Lösung, da ich auch zu wenig von Fhem Modulentwicklung verstehe. Ein paar Dinge konnte ich ändern und auch nachvollziehen, aber das ganze "non blocking" umzuprogrammieren, daran fehlt es.

Das "neue" GW1000 (GW1500 ?) hat einen eigenen Webserver, weil ein ESP8266 mit mehr RAM verbaut und ich hoffe, dass man darüber die API auch direkt bekommt. Kann das aber nicht wirklich testen.

Im Moment läuft das über die API sehr gut, weil ich auch die App von Ecowitt nutze und mir 60 Sekunden update-time locker reichen. Schön ist, dass man über die API alle Werte aller Sensoren bekommt und nicht nur die, die WeatherUnderground versteht. Und genau das war auch mein Ziel.

Liebe Grüße, Holger
fhem auf rPi3 mit USB boot und M2, cul866 (hm), homebridge, FlowerSens, Shelly, Harmony, WemosD1, Sonoff/Tasmota, grafana, mqtt/mosquitto

kjmEjfu

Zitat von: gent am 11 Juli 2022, 22:56:44
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.

Rein um die Daten von Ecowitt Stationen nach FHEM zu nutzen, würde ich nur das FOSHKplugin nutzen. Das läuft Standalone und braucht wenig Konfiguration.
Das macht quasi nix anderes als Daten von der Ecowitt entgegen nehmen, etwas aufbereiten und an x (von einem selbst bestimmte) Dienste weiterleiten.
Migriere derzeit zu Home Assistant

LukeSky007

#20
Hallo zusammen,

ich habe gerade meine neue ecowitt mit GW2000  mit dem Modul konfiguriert.  Hat auf  Anhieb gelappt - Ich habe das GW2000  zuvor ins Netzwerk eingebunden.
Habe das Reading für die Firmware Version gefixt.

    elsif ($cmd == $GW1000_cmdMap{CMD_READ_FIRMWARE_VERSION}) {
        shift(@data);
        my $x = join '', map chr, @data;
        readingsSingleUpdate($hash, "Firmware Version", sprintf("%s" , $x), 1 );
    }

und die Aufrufe der Log  Methode nach  Log3   konvertiert.
Die Änderung findet Ihr in meinem github-fork
Gruß
Luke
FHEM 5.9 RasPi 3B+,  1x HM-MOD-RPI-PCB, 4x HM-LC-BL1-FM, 1x HM-ES-PMSw1-Pl-DN-R1, 3x HM-CC-RT-DN, 5x HM-SEC-SCo, 1x HM-LC-SW1-FM, 1x HM-SEC-MDIR-2, 1x HM-Sen-MDIR-O, 1x HM-WDS40-TH-I-2, ecowitt: GW200X , WS90, 4x WH51

minierm

#21
Hallo!
Seit zwei Tagen habe ich das Ecowitt Gateway GW1100 (plus Bodensensor), das ja einen eingebauten Webserver mitbringt.
Nachdem mein erster Versuch, die Seite mit Regex zu graben, fehlgeschlagen ist, hab ich im Netzwerktraffic die URL gefunden, die alle Daten bereitstellt:
get_livedata_info
Die liefert schönes JSON (Zentrale plus Bodenfeuchtigkeit):
{ "wh25": [{ "intemp": "26.0", "unit": "C", "inhumi": "48%", "abs": "949.9 hPa", "rel": "1014.9 hPa" }],
"ch_soil": [{ "channel": "1", "name": "", "battery": "0", "humidity": "30%" }] }


Als Device sieht es dann z.B. aus:
defmod Ecowitt_GW HTTPMOD http://192.168.178.187/get_livedata_info 30
attr Ecowitt_GW comment https://www.ecowitt.net
attr Ecowitt_GW event-on-change-reading .*
attr Ecowitt_GW extractAllJSON 1
attr Ecowitt_GW group Ecowitt,Wetter
attr Ecowitt_GW room Wetter
attr Ecowitt_GW showBody 0
attr Ecowitt_GW showError 1
attr Ecowitt_GW stateFormat wh25_01_intemp°; wh25_01_inhumi wh25_01_rel
attr Ecowitt_GW timeout 10


Mit Logfile:
defmod Log_Ecowitt FileLog ./log/Log_Ecowitt-%Y-%m.log Ecowitt_GW.*
attr Log_Ecowitt group SVG,Ecowitt,Wetter
attr Log_Ecowitt room Wetter


Die Sensoren kann man als ReadingsProxy definieren:
Bodenfeuchte:
defmod Ecowitt_Sensor_Soil_01 readingsProxy Ecowitt_GW:ch_soil_01_humidity
attr Ecowitt_Sensor_Soil_01 group Ecowitt,Wetter
attr Ecowitt_Sensor_Soil_01 room Wetter
attr Ecowitt_Sensor_Soil_01 userReadings battery {ReadingsVal("Ecowitt_GW", "ch_soil_01_battery", "")},\
channel {ReadingsNum("Ecowitt_GW", "ch_soil_01_channel", "")},\
name {ReadingsVal("Ecowitt_GW", "ch_soil_01_name", "")}


Temperatur:
defmod Ecowitt_Sensor_Aisle_01 readingsProxy Ecowitt_GW:ch_aisle_01_temp
attr Ecowitt_Sensor_Aisle_01 alias Carport
attr Ecowitt_Sensor_Aisle_01 comment Draussen Carport
attr Ecowitt_Sensor_Aisle_01 event-on-change-reading .*
attr Ecowitt_Sensor_Aisle_01 group Ecowitt,Wetter
attr Ecowitt_Sensor_Aisle_01 room Wetter,Wetterlage
attr Ecowitt_Sensor_Aisle_01 stateFormat state°; humidity
attr Ecowitt_Sensor_Aisle_01 userReadings battery     {ReadingsNum("Ecowitt_GW", "ch_aisle_01_battery", "")},\
channel     {ReadingsNum("Ecowitt_GW", "ch_aisle_01_channel", "")},\
humidity    {ReadingsVal("Ecowitt_GW", "ch_aisle_01_humidity", "")},\
temperature {sprintf("%s°", ReadingsVal("Ecowitt_GW", "ch_aisle_01_temp", "?"))},
name        {ReadingsVal("Ecowitt_GW", "ch_aisle_01_name", "")}


Nach dem Start des GW (Stromverbindung) muss man sich einmalig anmelden, um die Oberfläche freizuschalten. Dies trifft jedoch nicht auf die API zu, die ist immer verfügbar, also kein Problem. (Getestet ohne Passwort).
Eine Registrierung bei Ecowitt ist nicht notwendig.

Ecowitt ist damit mein drittes Funknetz neben Rademacher Duofern (Rollläden) und Zigbee (Sensoren).


LukeSky007

#22
Hallo zusammen,

ich habe das 50_GW1000_TCP.pm von @sepo83  auf  DevIo  umgestellt.
Mit meinem ecowitt GW200X  funktioniert das auch schon fast.
Der Temperaturwert  von der WS90 hat eine falsche Skalierung  (221,0  statt  22,1) 
könnte das mal einer mit einer anderen Station verifizieren?

Da ich hier keine Datei anhängen kann, wie schon beim
letzten Post der Link auf mein github-fork

Grüsse
Luke
FHEM 5.9 RasPi 3B+,  1x HM-MOD-RPI-PCB, 4x HM-LC-BL1-FM, 1x HM-ES-PMSw1-Pl-DN-R1, 3x HM-CC-RT-DN, 5x HM-SEC-SCo, 1x HM-LC-SW1-FM, 1x HM-SEC-MDIR-2, 1x HM-Sen-MDIR-O, 1x HM-WDS40-TH-I-2, ecowitt: GW200X , WS90, 4x WH51

LukeSky007

Hallo zusammen,

ich habe die Hilfe ergänzt, die "statischen" Readings werden asyncron  zu Anfang eingelesen.
in der Update-Schleife werden "aktuelle" Werte, ID's und Rain Werte abgefragt.
Gruß
Luke
FHEM 5.9 RasPi 3B+,  1x HM-MOD-RPI-PCB, 4x HM-LC-BL1-FM, 1x HM-ES-PMSw1-Pl-DN-R1, 3x HM-CC-RT-DN, 5x HM-SEC-SCo, 1x HM-LC-SW1-FM, 1x HM-SEC-MDIR-2, 1x HM-Sen-MDIR-O, 1x HM-WDS40-TH-I-2, ecowitt: GW200X , WS90, 4x WH51

miot

Nur zur Info da ich gerade d'rüber gestolpert bin.
Ich habe gestern ein Firmware Update in meiner Ecowitt GW auf die Version GW1100A_V2.2.3 durchgeführt. Diese liefert Werte für ein Device mit der Kennung 0x7b, welches in der Auflistung des Moduls jedoch unbekannt ist. Daraufhin meldet das Modul beim Update 'GW1000_TCP: Item (0x7b) is unknown. Skipping complete package!'

Bedauerlicherweise wird damit im Code nicht nur das Datenpaket geskipped sondern durch ein nachfolgendes 'return 1' die Update Schleife terminiert was dazu führt, dass der interne Timer nicht mehr initialisiert wird. Damit erfolgt nach Erhalt eines Datenpaketes für ein unbekanntes Device kein GetUpdate mehr.

Viele Grüße
Michael

LukeSky007

Hallo miot,
vielen Dank für die Rückmeldung. Habe momentan noch die Version GW2000A_V2.2.0  installiert.
Leider gibt es auf der ecoWitt Seite keinen direkten Download der neuesten GW2000 Firmware - oder
hast Du da einen brauchbaren Link?
Momentan zeigt das Webinterface eine aktuelle Version V2.2.4 an - auf die ich auch updaten werde.
Hast Du ein älteres Gateway?  Weil beim  GW2001 WittBoy  ist ein GW2000A  mit bei (was ich benutze).
Ich mach mal das Gateway - Update auf 2.2.4 und schaue dann mal nach dem Item (0x7b).

Grüße
Luke
FHEM 5.9 RasPi 3B+,  1x HM-MOD-RPI-PCB, 4x HM-LC-BL1-FM, 1x HM-ES-PMSw1-Pl-DN-R1, 3x HM-CC-RT-DN, 5x HM-SEC-SCo, 1x HM-LC-SW1-FM, 1x HM-SEC-MDIR-2, 1x HM-Sen-MDIR-O, 1x HM-WDS40-TH-I-2, ecowitt: GW200X , WS90, 4x WH51

LukeSky007

#26
Hallo zusammen,
nach dem Firmwareupdate auf 2.2.4  bekam ich auch die unbekannte Item-Id 0x7B in der Antwort auf das Kommando CMD_READ_RSTRAIN_TIME.
Habe die fehlenden ID's  von 0x7B bis 0x7F ergänzt.
Werde mal bei den ecoWitt Jungs nachfragen was diese Item's bedeuten.

Die neue Version habe ich auf meinem Fritz-NAS Onlinespeicher für Euch bereitgestellt, da das max. Anhang-Kontigent überschritten wäre.

@miot: bitte um Rückmeldung, ob das Problem bei Dir behoben ist.

Grüße Luke
FHEM 5.9 RasPi 3B+,  1x HM-MOD-RPI-PCB, 4x HM-LC-BL1-FM, 1x HM-ES-PMSw1-Pl-DN-R1, 3x HM-CC-RT-DN, 5x HM-SEC-SCo, 1x HM-LC-SW1-FM, 1x HM-SEC-MDIR-2, 1x HM-Sen-MDIR-O, 1x HM-WDS40-TH-I-2, ecowitt: GW200X , WS90, 4x WH51

miot

Hallo Luke,

das Problem hatte ich in dem Modul bei mir selbst behoben nachdem ich es entdeckt hatte und wollte nur einen Hinweis auf meine Entdeckung äußern.
Im Übrigen habe ich die Ecowitt Gateway GW1100 und nutze auch nur die dort vorhandene Firmware-Update-Funktion.

Viele Grüße
Michael

minierm

Zitat von: LukeSky007 am 04 September 2022, 21:59:52Der Temperaturwert  von der WS90 hat eine falsche Skalierung  (221,0  statt  22,1) 
Naja, falsche Skalierung...Was ein Programmierer halt tut, wenn man eine Nachkommastelle haben möchte aber Float scheut: Einfach auf Integer mappen :-)

Elektronikus

Hallo Allerseits,

ich habe seit kurzem die WeatherScreenPro und möchte die gerne einbinden.
Vielen Dank für die 50_GW1000_TCP. Ich habe das Device definiert und es scheint auch zu connecten, aber dann passiert nichts mehr und ich sehe auch keine weiteren events:
2023-10-31 11:56:59 GW1000_TCP WeatherScreen test
Ich habe mal das Test Kommando ausgelöst, aber dann pasiert auch nichts.
Muss ich die WeatherScreenPro irgendwie konfigurieren?
Wenn ich mein Handy benutze zum Testen kommen Messages wie:
ffff1200... was ich so interpretiere, das die Wetterstation was sendet