Ecowitt API - diverse Wetterstationen

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

Vorheriges Thema - Nächstes Thema

Beta-User

#45
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...
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.

Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

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.
FHEM-Developer seit 2007, Mitgründer und Förder-Mitglied des FHEM e.V.
Bitte keine unaufgeforderten privaten Nachrichten!

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.
FHEM-Developer seit 2007, Mitgründer und Förder-Mitglied des FHEM e.V.
Bitte keine unaufgeforderten privaten Nachrichten!

Dr. Boris Neubert

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

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
FHEM-Developer seit 2007, Mitgründer und Förder-Mitglied des FHEM e.V.
Bitte keine unaufgeforderten privaten Nachrichten!

Dr. Boris Neubert

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

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.
FHEM-Developer seit 2007, Mitgründer und Förder-Mitglied des FHEM e.V.
Bitte keine unaufgeforderten privaten Nachrichten!

Beta-User

Zitat von: Dr. Boris Neubert am 08 Dezember 2025, 22:25:16@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 :) .
Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Beta-User

Nachtrag: sobald der Name geändert ist, könnte man das auch einchecken, du darfst gerne auch den (Mit-) Maintainer machen 🙂.
Server: HP-elitedesk@Debian 13, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors