Ecowitt API - diverse Wetterstationen

gent · 15 Dezember 2021, 20:52:55

Hallo,

ich bin vor einiger Zeit mal auf die Seite https://www.wetterstationsforum.info/wiki/doku.php?id=wiki:wetterstationen:ecowitt-stationen gestoßen. Da ich selber ein GW1000 (baugleich mit dem Froggit DP1500) habe, war ich schon immer interessiert an einer Integration in FHEM. Diese mache ich derzeit umständlich über einen zusätzlichen rPi mit weewx und mqtt. Jetzt wurde vor einiger Zeit endlich die Ecowitt API öffentlich gemacht:

https://osswww.ecowitt.net/uploads/20210716/WN1900%20GW1000,1100%20WH2680,2650%20telenet%20v1.6.0%20.pdf

Die Frage an alle, die hier mitlesen: Was braucht es, um daraus ein Modul zu bauen und geht das alleine mit der API-Dokumentation überhaupt? Hätte jemand überhaupt - neben mir - Interesse daran, sich damit näher zu beschäftigen? Alleine werde ich das leider nicht schaffen, also wenn jemand Zeit und Interesse hätte: Ich wäre mit dabei.

LG, Holger

sepo83 · 03 Februar 2022, 21:04:45

Hab selber eine WH2650 und hätte großes Interesse.

Vorteile:
* durch die direkte Client-Server Verbindung würde die (potentiell unsichere) zusätzliche FHEM-WebInstanz wegfallen
* wenn man die API komplett umsetzt kann man die WIFI-Station komplett in FHEM konfigurieren (inkl. WLAN Settings, Sensor-Kalibrierung, etc)
* man kann auch weitere angeschlossene Sensoren auslesen (z.B. weitere Temperatur-Sensoren von Frogit)

Wenn ich die Doku richtig verstehe ist das grundlegende Vorgehen zum auslesen der live SensorDaten auch gar nicht so schwer, wenn man die WIFI-Station bereits eingerichtet hat (sie also im WLAN Daten sendet). Dann wären die Schritte:
1. Fhem verbindet sich via TCP auf die WIFI-Station (Port 45000)
2. Fhem fragt aktiv die Daten mit einem konfigurierbaren Intervall ab (TCP-Paket mit CMD-Wort an WIFI-Station; WIFI antwortet mit einem Paket, welches die Sensor-Daten enthält); z.B:
a. Kapitel 3 Punkt 22) --> CMD_GW1000_LIVEDATA --> angeschlossene extra Sensoren
b. Kapitel 3 Punkt 25) --> CMD_READ_RAINDATA--> Regenmenge
c. Kapitel 3 Punkt 29) --> CMD_READ_SENSOR_ID --> Baterie, Sensor ID
d. Kapitel 3 Punkt 13) --> CMD_GET_SOILHUMIAD --> Feuchtigkeit
3. Fhem schreibt die Daten als Reading

Mit dem Programm Packet-Sender (https://packetsender.com/) kann ich grundsätzlich so von meinem PC zur WIFI Station kommunizieren; z.B. CMD_READ_SATION_MAC:
* senden via TCP an IP meiner WIFI-Station / Port 45000: ff ff 26 04 00 2a
* Antwort: FF FF 26 09 BC DD C2 A8 FF A4 D5 --> MAC Adresse = BC DD C2 A8 FF A4

Nun zu meinem Problem. Ich hab zwar ein grundlegendes Verständnis wie die Kommunikation läuft, bin aber kein wirklicher Perl-Programmierer. Für Unterstützung (zB CodeSnipets für TCP Verbindung; Packen und Entpacken von Paketen) wäre ich dankbar. Dann könnte ich evtl. eine erste Implementierung des Moduls machen.

kjmEjfu · 04 Februar 2022, 08:43:58

Zitat von: gent am 15 Dezember 2021, 20:52:55
Diese mache ich derzeit umständlich über einen zusätzlichen rPi mit weewx und mqtt.

weewx braucht man aber doch nur, wenn man damit auch die ganzen Übersichten (Webseiten) generieren möchte.
Ansonsten ist IMO https://loxwiki.atlassian.net/wiki/spaces/LOXBERRY/pages/1252524456/FOSHKplugin+-+generic+version die viel bessere Alternative. Erleichtert auch viel, wenn man die eigenen Daten an die vielen Wetterdienste weitergeben möchte. Führt auch noch Korrekturen durch. Hat man in einer halben Stunde am Laufen.
Ich würde das nicht alles in FHEM nachcoden wollen

sepo83 · 08 März 2022, 19:13:46

Ich hab eine erste Version eines FHEM-Moduls entwickelt, welches die Daten von der GW1000/WH2650 via TCP anfragt. Funktioniert bei mir auf den ersten Blick. Ich hab das ganze auf github veröffentlicht: https://github.com/sepo83/FHEM_GW1000_TCP

Bei meinen Tests gab es aber immer wieder Verbindungsabbrüche vom WH2650 ins WLAN, sodass ich die Daten jetzt direkt über SIGNALduino und 868MHz einlese. Das funktioniert aber nur mit der SIGNALduino-Version von Ralf9 (https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900).

Entsprechend würde hier nicht mehr aktiv weiter machen. Vielleicht kann ja jemand anderes noch was mit meiner Vorarbeit anfangen.

EDIT: Das Module braucht noch das perl-package IO::Socket::INET.

gent · 15 März 2022, 19:16:38

Zitat von: kjmEjfu am 04 Februar 2022, 08:43:58
weewx braucht man aber doch nur, wenn man damit auch die ganzen Übersichten (Webseiten) generieren möchte.
Ansonsten ist IMO https://loxwiki.atlassian.net/wiki/spaces/LOXBERRY/pages/1252524456/FOSHKplugin+-+generic+version die viel bessere Alternative. Erleichtert auch viel, wenn man die eigenen Daten an die vielen Wetterdienste weitergeben möchte. Führt auch noch Korrekturen durch. Hat man in einer halben Stunde am Laufen.
Ich würde das nicht alles in FHEM nachcoden wollen

Hi, und gibt's dafür auch eine Anleitung, wie man das dann in FHEM integriert? Die Installation scheint ja einfach zu sein, aber ich will die Werte der Station in FHEM als Reading sehen und diese nicht über den Umweg eines Wetterdienstes in FHEM anzeigen.

LG

gent · 15 März 2022, 19:17:55

Zitat von: sepo83 am 08 März 2022, 19:13:46
Ich hab eine erste Version eines FHEM-Moduls entwickelt, welches die Daten von der GW1000/WH2650 via TCP anfragt. Funktioniert bei mir auf den ersten Blick. Ich hab das ganze auf github veröffentlicht: https://github.com/sepo83/FHEM_GW1000_TCP

Bei meinen Tests gab es aber immer wieder Verbindungsabbrüche vom WH2650 ins WLAN, sodass ich die Daten jetzt direkt über SIGNALduino und 868MHz einlese. Das funktioniert aber nur mit der SIGNALduino-Version von Ralf9 (https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900).

Entsprechend würde hier nicht mehr aktiv weiter machen. Vielleicht kann ja jemand anderes noch was mit meiner Vorarbeit anfangen.

EDIT: Das Module braucht noch das perl-package IO::Socket::INET.

Vielen Dank. ich schau mir das gleich mal an.

LG

gent · 15 März 2022, 19:41:25

Hi sepo83,

schade, das sah schon vielversprechend aus, aber leider bekomme ich im log einen Fehler und dann ist FHEM nicht mehr erreichbar:

Code Auswählen


2022.03.15 19:31:15 2: GW1000_TCP <MYGW1000>: connected to server (192.168.178.184:45000)
2022.03.15 19:31:15 2: GW1000_TCP <MYGW1000>: sent data (size: 6):ffff2604002a
2022.03.15 19:31:15 2: GW1000_TCP <MYGW1000>: received response: ffff2609e8db849a08273f (255 255 38 9 232 219 132 154 8 39 63)
2022.03.15 19:31:15 2: GW1000_TCP <MYGW1000>: HEADER: 0xff 0xff; CMD: 0x26; SIZE: 9; CHECKSUM: 63; DATA: 232 219 132 154 8 39
2022.03.15 19:31:15 2: GW1000_TCP: Received CMD_READ_STATION_MAC (0x26). Unpacking data...
Undefined subroutine &main::ReadingsSingleUpdate called at ./FHEM/50_GW1000_TCP.pm line 442.

Ich weiß, dass Du das nicht weiterentwickeln willst, aber könntest Du mir bitte hierbei noch einmal helfen, damit ich dein Modul wenigsten einmal testen kann?

LG

gent · 16 März 2022, 18:37:01

Hab den Fehler selber gefunden:

Kleiner Schreibfehler in Zeile 442

Code Auswählen


		# ReadingsSingleUpdate($hash, "StationMac", sprintf("%x %x %x %x %x %x", @data), 1 );
		# ^ das R muss klein geschrieben werden

		readingsSingleUpdate($hash, "StationMac", sprintf("%x %x %x %x %x %x", @data), 1 );

Läuft jetzt mal soweit. Danke auch für die Erklärungen zu packetsender.

LG, Holger

fume · 17 März 2022, 09:51:59

Hallo

Danke für das Modul, Ich aber aber bei den Readings die Leerzeichen entfernt, dann werden sie in fhem auch richtig aktualisiert.
Ansonsten funktioniert es bisher super.

Grüsse Norbert

gent · 18 März 2022, 21:54:38

Hallo Norbert,

können wir uns dazu mal austauschen?

Viele Grüße,

Holger

fume · 20 März 2022, 22:01:44

Gerne
Ich habe in den Zeilen 57 bis 163 die Leerzeichen durch Unterstriche ersetzt, da Leerzeichen immer wieder Probleme in Readings machen, dann wird auch im Webfrontend aktualisiert.

Norbert

gent · 31 März 2022, 21:20:35

Hallo Norbert,

Danke Dir für die Info. Das passt jetzt.

LG, Holger

gent · 31 März 2022, 21:33:47

Zitat von: sepo83 am 08 März 2022, 19:13:46
Ich hab eine erste Version eines FHEM-Moduls entwickelt, welches die Daten von der GW1000/WH2650 via TCP anfragt. Funktioniert bei mir auf den ersten Blick. Ich hab das ganze auf github veröffentlicht: https://github.com/sepo83/FHEM_GW1000_TCP

Bei meinen Tests gab es aber immer wieder Verbindungsabbrüche vom WH2650 ins WLAN, sodass ich die Daten jetzt direkt über SIGNALduino und 868MHz einlese. Das funktioniert aber nur mit der SIGNALduino-Version von Ralf9 (https://forum.fhem.de/index.php/topic,111653.msg1058900.html#msg1058900).

Entsprechend würde hier nicht mehr aktiv weiter machen. Vielleicht kann ja jemand anderes noch was mit meiner Vorarbeit anfangen.

EDIT: Das Module braucht noch das perl-package IO::Socket::INET.

Hallo sepo83,

Das Modul ist echt gut. Du scheinst Dich ja auch auszukennen in der Modul-Entwicklung. Das Modul ist im Moment noch zu gesprächig im log. Kannst Du mir bitte verraten, wie ich das ändern kann? Verbose=0 bringt leider nichts.

Ich vermute, es liegt daran, dass Du manchmal einfach die Funktion Log verwendest, manchmal aber die Funktion Log3. Wenn man das einfach so ändern kann, weil Log3 den Verbose-Level berücksichtigt, dann schaffe ich das selber.

Oder muss da noch etwas programmiert werden, damit man nur Einträge im Log erhält, die man laut Verbode-Level auch haben will?

LG, Holger

sepo83 · 02 April 2022, 17:23:55

Hallo Holger,

freut mich, dass jemand meine Arbeit weiter führt...

Ich hab die Entwicklung des Moduls auf "halben Wege" abgebrochen. Entsprechend muss noch "aufgeräumt" werden

.
Ich denke du kannst die Log Funktionen ohne weiteres durch Log3 Funktionen ersetzen; natürlich Syntax beachten (siehe https://wiki.fhem.de/wiki/DevelopmentModuleAPI#Log3). Beispiel (ohne das jetzt ausprobiert zu haben) Zeile 340:
Alt:

Code Auswählen

Log 2, "GW1000_TCP <$hash->{name}>: connected to server ($hash->{I_GW1000_IP}:$hash->{I_GW1000_Port})" ;

Neu:

Code Auswählen

Log3, $name , 2, "connected to server ($hash->{I_GW1000_IP}:$hash->{I_GW1000_Port})" ;

Die Log Funktion müsste den Verbose-Level aber eigentlich auch richtig berücksichtigen (siehe https://wiki.fhem.de/wiki/DevelopmentModuleAPI#Log). Mein Vorschlag wäre alle Log-Aufrufe zu vereinheitlichen (also alle auf Log3) und nochmal bei jedem Aufruf das Log-Level auf "was sinnvolles" anzupassen.

Grüße,
Sebastian

gent · 04 April 2022, 23:45:50

Hallo Sebastian,

wieder was gelernt: log nimmt nur das global verbose Attribut, bei log3 kann man dann für ein einzelnes Device noch den verbose level angeben. Das ist nun auch geändert und funktioniert.

Außerdem habe ich noch ein paar "factor" geändert (z.B. Outdoor Temperature und Rain...)

Kann ich Dir mal die Änderungen schicken und Du checkst es in Git ein?

Grüße, Holger