Ecowitt API - diverse Wetterstationen

[Beta-User]

Hmmm, um Verwechslungen auszuschließen anbei nochmal meine aktuellste Version.

"Eigentlich" sollte das dasselbe sein wie aus 6/2024, abgesehen von etwas devStateIcon-Magie, bei der ich noch nicht richtig sicher bin, ob die Richtungsanzeige wirklich paßt...

Code Auswählen Erweitern

defmod WittBoy GW1000_TCP 192.168.1.123 45000
attr WittBoy devStateIcon { GW1000_TCP_devStateIcon($name) }

Ich habe auch das runde 2000-er und dachte erst mal, dass MQTT ja super und einfach sein müßte. Das Format der Daten war aber "grottig", weil das in der Weise übermittelt wurde, wie es auch an wunderground oder so geschickt wird. Sonst hätte ich den Aufwand gar nicht betrieben, das Modul zu renovieren .
Version war GW2000A_V3.1.8, jetzt gibt es mal ein update, dann funktioniert vermutlich nichts mehr...

PS:
Doch, geht auch mit Version GW2000A_V3.2.7 noch.
Meines hängt übrigens am LAN, nicht WLAN. Sollte aber keinen Unterschied machen.

[Dr. Boris Neubert]

Danke! Werde das dann ausprobieren mit FHEM und GW2000 im selben Netzwerk. Wenn das geht, wird das GW2000 wieder in das IoT-Netzwerk weggesperrt.

[Dr. Boris Neubert]

Erste Ergebnisse (ohne verbundene Wetterstation WS90):

• GW1000_TCP holt sich die Werte vom Gateway - ich sehe die Werte vom Innensensor und ein paar Interna.
• MQTT verbindet sich mit dem MQTT Broker (MQTT2_SERVER) in FHEM, sendet aber nichts. Ergäbe auch keinen Sinn, die Temperatur im eigenen Wohnzimmer (oder wo auch immer das Gateway steht) nach Wunderground zu übertragen, wenn MQTT nur die Kommunikation zu Wunderground repliziert.

Ich verbinde gelegentlich die WS90 und melde weitere Erkenntnisse.

[Dr. Boris Neubert]

So, das Ding läuft im IoT-Netzwerk mit dem Modul GW1000_TCP. 

MQTT ist aktiviert, verbindet sich auch alle 8 Sekunden mit FHEM, schickt aber keine Sensor-Daten (MQTT over TCP ist eingestellt). Geprüft mit verbose 5 am MQTT2_SERVER in FHEM und MQTT Explorer. @Beta-User: wie hast Du es hinbekommen, dass dein Gateway Sensor-Daten per MQTT sendet?

GW1000_TCP zeigt nicht alle Sensor-Daten an, die der Wittboy über das GW2000X in Live Data anzeigt. Es fehlen:

• Feels like (gefühlte Temperatur), in °C
• VPD (Vapor Pressure Deficit = Dampfdruckdefizit) in kPa (im Internet nachlesen)
• Dew point (Taupunkt), in °C
• Rain 24Hours (Niederschlag in den letzten 24 Stunden), in mm (nicht zu verwechseln mit Rain Day)
• Solar Irradiance (Sonneneinstrahlung), in W/m^2
• 10Min.Avg Wind Direction (durchschnittliche Windrichtung in den letzten 10 Minuten), in °

Wie muss ich das Modul anpassen, um diese Werte als Readings zu sehen?

Es gibt ein Reading namens Light. Das ist die Beleuchtungsstärke in lux mit einer Auflösung von 100 lux.

Ob Solar Irradiance daraus abgeleitet ist, nur in anderen Einheiten, oder eine eigene Messgröße? Tabelle (Arbeitszimmerlampe bei Nacht / bessere Werte ein anderes Mal bei Tag und draußen):

Light | Solar Irradiance / W/m^2 | Umrechnungsfaktor
1100.0 | 0.87 | 0.00079091
500.0 | 0.39 | 0.00078
400.0 | 0.32 | 0.0008
300.0 | 0.24 | 0.0008

Außerdem wird regelmäßig das Reading Unknown_SensorID aktualisiert. Was bedeutet das?

Das Attribut updateInterval sollte nur ein l (ell) am Ende haben.

Modul sollte einfach Ecowitt heißen. Ich würde mich freuen, wenn Du es offiziell eincheckst!

Herzlichen Dank für Deine Arbeit.

Viele Grüße
Boris

[Dr. Boris Neubert]

In der Freude des Erfolgs habe ich noch einen Blitzsensor WH57 gekauft. Als Readings bekomme ich derzeit zusätzlich:

Code Auswählen Erweitern

define wittboy GW1000_TCP ecowitt.......de 45000
...
#     2025-12-08 22:07:08   lightning_counter_for_the_day 8.0
#     2025-12-08 22:07:08   lightning_distance 5.0
#     2025-12-08 22:07:08   lightning_happened_time 1765228004.0
...
#     2025-12-08 22:07:08   unknown_1A_Batterie 5.0
#     2025-12-08 22:07:08   unknown_1A_ID   c892
#     2025-12-08 22:09:09   unknown_1A_Signal 4
#

unknown_1A_ müsste WH57_ werden.

lightning_happened_time ist der Zeitstempel in Sekunden seit der Epoche (Sekunden seit 01.01.1970). Dafür bräuchte man noch ein zusätzliches Reading für ein menschenlesbares Äquivalent (lightning_happend_time_formatted) und ein Event lightning_strike, dass erzeugt wird, wenn lightning_happened_time sich ändert, mit Wert von lightning_distance. Dann kann man aus dem FileLog heraus gleich auf lightning_strike einen Plot machen, der die Entfernung aller Blitze auf der Zeitachse plottet.

Und alle Readings, die auf _Batterie enden, sollten englisch auf _Battery enden.

@Beta-User: bitte sag, was Du von alledem implementieren willst, und was ich beisteuern soll.

[Beta-User]

@Beta-User: bitte sag, was Du von alledem implementieren willst, und was ich beisteuern soll.

Ich habe an dem Ausgangscode nur deswegen weitergebastelt, weil es die einfachste Variante war, dem Ding was brauchbares zu entlocken.
Im Moment komme ich nicht wirklich dazu, das zu debuggen und/oder neue Teile einzupflegen, den Namen zu ändern pi pa po. Von daher: Alles, was erledigt ist, ist willkommen!

Der Reihe nach:
Name - ECOWITT_GW_API? (Es gibt eine Reihe von Optionen, und das ist zwar lang, aber vielleicht für den "unbefangenen Betrachter" halbwegs verständlich?)

Anbei ein etwas "aufgeräumter" Code - da habe ich nur irgendwo zu viel weggeworfen, das wirft ein paar Fehler ins log, von denen ich nicht weiß, ob die vorher schon da waren (vermutlich nicht). Läuft aber prinzipiell, und ein diff zeigt, was tendenziell überflüssig ist. (Und meinen Coding-Style)
"Seit immer" habe ich auch einen unknown "Sensor", der nicht plausible Werte ("FF" und so) zeigt und physisch auch nicht da ist. Vermutlich ein Code-Käfer , der eigentlich auch nicht da sein müßte (aber auch nicht nachhaltig stört).

Der Code berücksichtigt, was Ecowitt über die API bekannt gegebenen hatte, Stand ist (vermutlich) der hier:
https://osswww.ecowitt.net/uploads/20220407/WN1900%20GW1000,1100%20WH2680,2650%20telenet%20v1.6.4.pdf
Falls es was neueres gibt (und sonst Verbesserungen wie das mit der Blitz-Zeit): gerne reinnehmen. Für solche "Sonderlocken" hat man schließlich Module .

[Beta-User]

Nachtrag: sobald der Name geändert ist, könnte man das auch einchecken, du darfst gerne auch den (Mit-) Maintainer machen 🙂.

[Dr. Boris Neubert]

Hallo,

ich habe das Modul als 59_ECOWITT_GW.pm eingespielt (das API fand ich nicht passend, viele andere Module nutzen auch ein API und nennen das nicht im Modulnamen).

Habe noch zwei Perl-Fehler rausgemacht, und updateInterval umbenannt.

Jetzt ist es also offiziell.

Die anderen Vorschläge arbeite ich nach und nach ein.

Viele Grüße
Boris

[Dr. Boris Neubert]

"Seit immer" habe ich auch einen unknown "Sensor", der nicht plausible Werte ("FF" und so) zeigt und physisch auch nicht da ist. Vermutlich ein Code-Käfer , der eigentlich auch nicht da sein müßte (aber auch nicht nachhaltig stört).

Es gibt eine Reihe mehr SensorIDs als in der API-Doku aufgeführt sind. Ich habe den Code so geändert, dass unbekannte, also nicht im Hash %ECOWITT_SensorID gelistete Sensoren beim ersten Auftreten mit Default-Werten dem Hash hinzugefügt werden. Das Hash habe ich außerdem um alle in der API-Doku genannten Sensortypen ergänzt. Ansonsten wird nämlich nicht der Rest vom Datagramm gelesen, was zu diesen nicht plausiblen Werten (FF) führt.

(noch nicht eingecheckt)

[Beta-User]

"Seit immer" habe ich auch einen unknown "Sensor", der nicht plausible Werte ("FF" und so) zeigt und physisch auch nicht da ist. Vermutlich ein Code-Käfer , der eigentlich auch nicht da sein müßte (aber auch nicht nachhaltig stört).

Es gibt eine Reihe mehr SensorIDs als in der API-Doku aufgeführt sind. Ich habe den Code so geändert, dass unbekannte, also nicht im Hash %ECOWITT_SensorID gelistete Sensoren beim ersten Auftreten mit Default-Werten dem Hash hinzugefügt werden. Das Hash habe ich außerdem um alle in der API-Doku genannten Sensortypen ergänzt. Ansonsten wird nämlich nicht der Rest vom Datagramm gelesen, was zu diesen nicht plausiblen Werten (FF) führt.

(noch nicht eingecheckt)

Thx, auch für's einchecken usw.!

Für unsere Merkliste: In der commandref war "GW1000" als getesteter GW-Typ korrekt und ist per search&replace einmal zu oft überschrieben worden, und wir könnten auch ein paar Querbezüge zu anderen Modulen mit aufnehmen (noch keine konkrete Idee, wie genau):

Zum einen sind die Funk-Sensoren afaik auch per Signalduino zu empfangen und zu dekodieren. Diese Option habe ich allerdings dann nicht weiter verfolgt, weil das Modul ja funktioniert hat ...
Zum anderen: HP1000 scheint für diese Art Gateway eine andere Option bereitzustellen, https://commandref.fhem.de/#HP1000, die vermutlich ähnliche (eingeschränkte?) Resultate liefert wie der MQTT-Weg (wenn man readingList-Code bastelt, um die Daten aufzubereiten).

Beim Starten scheinen noch ein paar "uninitialized value"-Meldungen da zu sein, vielleicht bekommen wir die bei Gelegenheit auch noch beseitigt.

[Dr. Boris Neubert]

Danke für Deine Rückmeldung.

Die zuviel ersetzten GW1000 hatte ich gestern Abend (hoffentlich alle) schon wiederhergestellt.

Die unitialized values beim Erststart habe ich auch gesehen, die Ursache muss ich suchen.

Sitze auch gerade wieder am Modul, nachdem ich gestern Abend wohl was falsch gemacht habe, und über Nacht nur ein Teil der ankommenden Werte auch in die Readings geschrieben wird. Den Blitzsensor und das neue Reading lightning_strike muss ich auch noch testen.

Wenn du Ideen für die Querverweise hast, baue ich sie gerne ein.

[Dr. Boris Neubert]

Zur Überbrückung der Wartezeit ein Foto von der Wetterstation nach Anbringung gestern - Dank an meinen Vater für die Konstruktion der Halterung!

[Beta-User]

Sieht gut aus.

Meine Außeneinheit hat ihren endgültigen Standort noch nicht gefunden.

Gibt es eigentlich sowas wie "best practices" für den Standort von Wetterstationen allgemein?

Logistisch optimal wäre eigentlich vorne an der Stirnseite der Garage, da wären nämlich 12V für die Heizung (falls man die mal wieder brauchen sollte...) ohne Aufhebens verfügbar.
Dafür bräuchte man aber eine optisch optimale Lösung (in Edelstahl) und das wäre leider etwas in der Senke, dafür aber mit dem relativ größmöglichen Abstand von anderen Gebäuden.
Seitlich auf der anderen Seite der Garage ginge auch, aber da ist der Abstand zu anderen Gebäuden kleiner.

Hmmm, vermutlich lasse ich das Ding doch erst mal oben im Garten und warte, ob der neue Nachbar seine Garage abreißen will.

[Dr. Boris Neubert]

Meine Außeneinheit hat ihren endgültigen Standort noch nicht gefunden.

Gibt es eigentlich sowas wie "best practices" für den Standort von Wetterstationen allgemein?

Meiner Meinung nach so frei stehend wie möglich, damit es zu keiner Tageszeit zu einer Beschattung kommt, und der Wind frei durchziehen kann.

Meine Wetterstation ist an der Garage angebracht. Es wird dort eine Kanalwirkung beim Wind zwischen den Häusern geben und auch eine Beschattung. Allerdings kann ich dort, falls ich das jemals möchte, Strom aus der Garage für die Heizung beziehen.

Befestigung: das Rohr ist ein eloxiertes Aluminiumrohr aus dem Baumarkt mit 25 mm Durchmesser und 1 m Länge. Das Rohr ist mit Rohrschellen aus Edelstahl mit Gummieinlagen an der Wand befestigt. Aufgrund des Dachüberstands reichte jedoch die Länge der Stockschrauben nicht aus, so dass noch ein Abstandshalter angefertigt werden musste. Das Rohr ist unten mit einem Korken aus einer Spirituosenflasche verschlossen, damit sich keine Insekten ansiedeln. Die Ausrichtung nach Norden geht gut mit einem Smartphone mit Kompass-App, das ich horizontal mit der Unterkante gegen die beiden Stege gehalten habe, zwischen denen sich die Nord-Markierung befindet.

[Dr. Boris Neubert]

Ich habe eine Version eingecheckt, die bis auf die unitialized values erst einmal tut, was sie soll. Plots anbei.

Die Zeitzonen bei den Unix-Timestamps sind inkonsistent, da musste ich noch herumprobieren.

Blitzerkennung geht jetzt mit einem synthetischen Reading lightning_strike, wodurch ich die Entfernung eines Blitzes loggen und plotten kann. Mangels Gewittern habe ich versucht, meine eigenen Blitze zu erzeugen. Ein Feuerzeug mit piezoelektrischem Zünder muss man ganz nah an den Sensor halten, um einen entfernten Blitz zu simulieren. Besser geht es, wenn man den Blitzsensor dicht an einen Lichtschalter hält, der eine größere Last schaltet, damit es einen ordentlichen Abreißfunken gibt. In der Nähe meines Laptops hatte der Inhouse-Testaufbau aus dem Rauschen heraus übrigens auch Blitze erkannt.

Ich bekomme keine Meldung für piezo_rain_hourly und folglich auch kein Reading für den Niederschlag in der letzten Stunde. Auch in der Weboberfläche des GW2000 wird kein entsprechender Wert angezeigt, wohl aber eine Rain Rate in mm/hr, was mir aber die momentane Rate des Niederschlags in Regenmenge pro Zeiteinheit zu sein scheint, wobei die Zeiteinheit, über die gemessen wird, nicht klar ist.