Metainformationen zur Seite
Plugin-Daten
AutorOliver Engel
Logo
StatusSTABLE
Version0.09
Min. LB Version1.0
Release Downloadhttps://foshkplugin.phantasoft.de/files/loxberry-FOSHKplugin.zip
Pre-Release Downloadhttps://foshkplugin.phantasoft.de/files/loxberry-FOSHKplugin-0.0.10Beta.zip
BeschreibungDieses Plugin bindet verschiedene Wetterstationen des Hersteller Fine Offset Electronics (FOSHK) an einen Loxone-Miniserver (oder beliebige andere Zielsysteme) über UDP an.
Entwickelt wurde das Plugin für und mit einem Froggit DP1500 das baugleich auch unter dem Namen Ecowitt GW1000 verkauft wird.
SprachenEN, NL, SK, DE
Diskussionhttps://www.loxforum.com/forum/projektforen/loxberry/plugins/222662

FOSHKplugin

Version History...

Download

https://foshkplugin.phantasoft.de/files/loxberry-FOSHKplugin.zip (aktuelle stable-Version)

https://foshkplugin.phantasoft.de/files/loxberry-FOSHKplugin-0.0.10Beta.zip (aktuelle öffentliche Beta)

Funktion des Plugins

Weitere Funktionen / Konfigursationsoptionen

Neben der hier vorgestellten speziellen LoxBerry-Version des FOSHKplugins existiert auch noch eine "Generic"-Version, die auch auf anderen Systemen als dem LoxBerry läuft - sonst aber zu 100% identisch ist. Viele Beschreibungen und Erklärungen der einzelnen Funktionen und Konfigurationsmöglichkeiten finden sich in der Dokumentation der Generic-Version (und nicht hier): FOSHKplugin - generic version

Dieses Plugin bindet verschiedene Wetterstationen und -sensoren des Hersteller Fine Offset Electronics (FOSHK) an einen Loxone-Miniserver über UDP an. Unterstützt werden alle Geräte, bei denen sich ein eigener Server als Ziel zur Übermittlung der Daten im WU- oder Ecowitt-Format einrichten lässt.

Funktionen:

  • nimmt http-Nachrichten einer Wetterstation (DP1500, GW1000, HP1000SE, Sainlogic 7 in 1, ELV WS980WiFi, Eurochron EFWS 2900, ???) im WU- oder Ecowitt-Protokoll lokal über WLAN entgegen
  • erfordert keine Cloud-Dienste oder Internetverbindung
  • sendet per UDP die umgerechneten Werte an einen beliebigen Host oder per Broadcast ins Netz weiter
  • kann empfangene Werte per MQTT weiter senden
  • speichert auf Wunsch die umgerechneten Daten sortiert und/oder extrahiert als CSV
  • ermöglicht das Weiterversenden an bis zu 50 Server, die von der Station selbst nicht unterstützt werden (etwa Awekas, PWSWeather, Windy, wetter.com, weather365.net, Ambient Weather oder Luftdaten.info)
  • kann als Ecowitt-Relay dienen (Forward im Ecowitt-Protokoll - etwa für weewx oder PWS Dashboard oder Personal Weather Tablet oder andere Software, die Daten im Ecowitt-Format erfordert)
  • kann eingehende WU- , Ecowitt- und Ambient Weather-Nachrichten per UDP weiterleiten
  • kann Anfragen im WU-Protokoll beantworten
  • integrierter Webserver liefert per http den jeweils letzten Datensatz im UDP-, CSV-, RAW- und JSON-Format sowie als Webseite
  • erzeugt auf Wunsch eine Loxone-Vorlagendatei mit allen virtuellen In- und Outputs
  • stellt dem Plugin Weather4Loxone die Messwerte der lokalen Wetterstation direkt bereit
  • Anbindung an beliebige Datenbanksysteme über telegraf möglich
  • direkte Unterstützung von InfluxDB
  • erzeugt auf Wunsch eine Import-Datei für den automatischen Import der Daten in WSWin
  • für den Loxone-Betrieb ist keine weitere Software nötig (WS View nur zum Anlernen neuer Sensoren oder zur Konfiguration der Standard-Weiterleitungsdienste)
  • funktioniert auch ohne Loxone/LoxBerry als systemd-Dienst zur Anbindung anderer Systeme (generic FOSHKplugin)

Der Miniserver hat bei dieser Lösung relativ wenig zu tun; er muss keine Daten abholen oder Werte konvertieren - das Plugin sendet von sich aus die bereits umgewandelten Daten an den Miniserver, wann immer neue Messwerte von der Wetterstation eintreffen. Außerdem stehen die Messwerte auch beliebig anderen Diensten über diverse Schnittstellen zur Verfügung.

Der integrierte Webserver verarbeitet neben "updateweatherstation" zur Annahme eines Datensatzes im WU-Format (Weather Underground-Protokoll) auch andere http-Aufrufparameter im GET:

/CSVHDR die Feldbezeichnungen (der Header) des letzten Datensatzes werden als CSV semikolonsepariert ausgegeben. Wird zusätzlich units=e angegeben, erfolgt die Ausgabe der Felder für die imperialen Werte.
/CSV alle gemeldeten metrischen Werte des letzten Datensatzes werden als CSV semikolonsepariert ausgegeben (units=e liefert die imperialen Werte)
/UDP der letzte UDP-String wird per http ausgegeben; durch Zusatz von status innerhalb der URL erfolgt zusätzlich die Ausgabe der aktuellen Stati. 
/RAW der von der Wetterstation gelieferte Datensatz wird unverändert per http ausgegeben; Separator kann mit separator=Z geändert werden, wobei Z ein einzelnes Zeichen ist
/STRING der umgewandelte Datensatz sowie der aktuelle Status wird mit Separator ";" per http ausgegeben; per Zusatz von units=e in der URL erfolgt die Ausgabe mit den imp. Werten; Separator kann jeweils mit separator=Z geändert werden, wobei Z ein einzelnes Zeichen ist. Durch Zusatz von status innerhalb der URL erfolgt zusätzlich die Ausgabe der aktuellen Stati.

Beispiel: http://ipadresse:port/STRING?units=e?separator=, gibt die imp. Werte mit Komma als Separator aus
/JSON Ausgabe per http als JSON (standardmäßig metrisch; per Zusatz von units=e in der URL erfolgt die Ausgabe mit den imp. Werten). Durch Zusatz von status innerhalb der URL erfolgt zusätzlich die Ausgabe der aktuellen Stati.

Beispiel: http://ipadresse:port/JSON?units=m?status gibt alle metrischen Werte inkl. der aktuellen Stati als JSON aus
/realtime.txt Ausgabe per http als realtime.txt (Cumulus Export-File)
/clientraw.txt Ausgabe per http als clientraw.txt (Weather Display Export-File)
/getvalue?key=keyname gibt den Wert für den Schlüssel keyname aus - keyname darf ein RAW- oder umgewandelter Schlüssel sein - sinnvoll etwa für Abfragen etwa via curl oder wget

Beispiel: http://ipadresse:port/getvalue?key=windspeedmph gibt den Wert für den Schlüssel windspeedmph aus
/ (ohne) simple Webseite mit den aktuellen metrischen Daten in Tabellenform; durch Angabe von status auch mit nzeige der Statusmeldungen; gibt bei zusätzlicher Angabe von units=e Werte auch im US-System (inch, mph etc.) aus
/FOSHKplugin/state Status des Dienstes; wenn aktiv: "running"
/FOSHKplugin/status Anzeige der Statusmeldungen für Gewitter, Sturm, Batterie, Fehlen eines Sensors, Stations-Watchdog, … als simple Webseite
/FOSHKplugin/debug=enable aktiviert den Debug-Modus für erweiterte Meldungen im Logfile
/FOSHKplugin/debug=disable deaktiviert den Debug-Modus für erweiterte Meldungen im Logfile
/FOSHKplugin/pushover=enable temporäres Aktivieren der Push-Mitteilungen via Pushover - Pushover muss jedoch bereits korrekt konfiguriert sein
/FOSHKplugin/pushover=disable temporäres Deaktivieren der Push-Mitteilungen via Pushover
/FOSHKplugin/patchW4L "Patchen" einer Weather4Loxone-Installation (lokale Grabber-Scripte kopieren und lokalen Abruf durch W4L aktivieren)
/FOSHKplugin/recoverW4L Wiederherstellen der originalen Weather4Loxone-Konfiguration vor dem "Patchen"
/observations/current/json/units=m Rückmeldung eines WU-kompatiblen Datensatzes mit metrischen Werten (°C, kmh, mm, hPa)
/observations/current/json/units=e Rückmeldung des WU-kompatiblen Datensatzes mit imperialen Werten (°F, mph, in, inHg)
/w4l/current.dat Rückmeldung einer W4L-kompatiblen current.dat:
1617139459 		Tue, 30 Mar 2021 23:24:19 +0200 CET Europe/Berlin +0200 Hohen Neuendorf DE 52.669481 13.266531 53 8.2 8.2 92 Westsüdwest 256 0.0 0.0 8.2 1027.09 7.0 0.00 7.5 0 0.0 0.0

Bei Nutzung der Authentifizierung über AUTH_PWD im Config-File müssen sämtliche Requests mit einem angehängtem ?auth=[PASSKEY] ausgeführt werden. Einzig FOSHKplugin/state funktioniert auch ohne diese Authentifizierung. Sinnvoll ist dies, wenn FOSHKplugin nicht im sicheren lokalen Netzwerk sondern direkt im Internet - etwa auf einem Root-Server - arbeiten soll. Ohne diesen Sicherheitsmechanismus könnte sonst jedermann Daten einliefern oder Zustände abfragen oder ändern. Grundsätzlich rate ich jedoch vom Betrieb auf frei im Internet stehenden "unsicheren" Hosts ab.

Im POST-Modus werden Daten der Wetterstation im Ecowitt-Format angenommen, wenn in der URL das Schlüsselwort "report" enthalten ist. Da im Ecowitt-Format deutlich mehr Werte von der Wetterstation übertragen werden können (etwa die Batteriewerte der Sensoren), empfehle ich diese Betriebsart (die vom Plugin auch so bei WS-Set gesetzt wird).

Vergleich der von der Wetterstation übermittelten Werte zur ungefähr gleichen Zeit mit identischer Sensorausstattung zwischen WU- und Ecowitt-Format:

WU-Format: 

ID=id&PASSWORD=key&tempf=41.0&humidity=97&dewptf=40.3&windchillf=41.0&winddir=172&windspeedmph=0.00&windgustmph=0.00&rainin=0.000&dailyrainin=0.150&weeklyrainin=0.197&monthlyrainin=1.209&yearlyrainin=1.228&solarradiation=0.00&UV=0&indoortempf=74.8&indoorhumidity=38&baromin=29.695&soilmoisture=51&soilmoisture2=49&lowbatt=0&dateutc=now&softwaretype=GW1000A_V1.5.4&action=updateraw&realtime=1&rtfreq=5

Ecowitt-Format: 

PASSKEY=00010203040506070809101112131415&stationtype=GW1000A_V1.5.4&dateutc=2019-12-24+22:29:23&tempinf=74.7&humidityin=38&baromrelin=29.692&baromabsin=29.542&tempf=41.0&humidity=97&winddir=172&windspeedmph=0.00&windgustmph=0.00&maxdailygust=4.47&solarradiation=0.00&uv=0&rainratein=0.000&eventrainin=0.150&hourlyrainin=0.000&dailyrainin=0.150&weeklyrainin=0.197&monthlyrainin=1.209&yearlyrainin=1.228&totalrainin=1.228&temp2f=71.96&humidity2=43&temp3f=73.58&humidity3=41&soilmoisture1=51&soilmoisture2=49&wh65batt=0&batt2=0&batt3=0&soilbatt1=1.7&soilbatt2=1.7&freq=868M&model=GW1000_Pro

Im WU-Format fehlen nicht nur die Batteriewerte der Sensoren sondern auch die Temperatur- und Feuchtigkeitswerte der Innensensoren. Einige zusätzliche Sensoren (etwa Blitzsensor und Wassersensor) werden von WU überhaupt nicht unterstützt - diese fehlen in den WU-Daten also komplett. Dafür liefert das WU-Format aber den Taupunkt und Windchill von sich aus mit; bei Ecowitt müssen diese Werte via Schalter "optionale Berechnungen" durch das Plugin errechnet werden.

Installation

Grundsätzlich sollten initial die Sensoren über die App WS View angelernt und eingerichtet werden.

WS View-App aus dem jeweiligen Shop holen (siehe Links)

Wetterstation lt. Herstelleranleitung einrichten

Wenn soweit über die App alles funktioniert - Messdaten also innerhalb von WS View angezeigt werden - kann die Anbindung an Loxone erfolgen.

Im Hauptbildschirm des LoxBerry ist auf "Plugin-Verwaltung" zu klicken und der Link des loxberry-FOSHKplugin.zip unter "Installiere neues Plugin:" sowie die SecurePIN einzugeben und auf "Installation" zu klicken. Nach erfolgreicher Installation steht das FOSHKplugin unter Plugins in der Hauptübersicht zur weiteren Konfiguration und Aktivierung bereit.

Konfigurationsoptionen

Weitere Funktionen / Konfigursationsoptionen

Neben der hier vorgestellten speziellen LoxBerry-Version des FOSHKplugins existiert auch noch eine "Generic"-Version, die auch auf anderen Systemen als dem LoxBerry läuft - sonst aber zu 100% identisch ist. Viele Beschreibungen und Erklärungen der einzelnen Funktionen und Konfigurationsmöglichkeiten finden sich in der Dokumentation der Generic-Version (und nicht hier): FOSHKplugin - generic version

Alle erforderlichen Einstellungen werden bei der Installation bereits auf sinnvolle Werte gesetzt. Auf der Einstellungs-Seite sind die oberen Eingabe-Felder für die Loxone/LoxBerry-Konfiguration auszufüllen bzw. die automatisch vorgegebenen Werte ggf. anzupassen:

Die Konfiguration der Wetterstation erfolgt im unteren Bereich. Sind die dort einzugebenden Daten unbekannt, können diese über die jeweiligen " Erkenne "-Buttons abgefragt werden. Der zulässige Wertebereich für den Datenversand von der Wetterstation zum lokalen Server (Sende-Intervall) beträgt lt. WS View 16 bis 600 Sekunden. Über das Plugin lässt sich der Intervall aber auch auf eine Sekunde setzen (getestet am DP1500). Und tatsächlich kommen dann Messwerte im Sekundentakt an! Ich gehe aber davon aus, dass sich der Hersteller der App etwas mit diesen Limits gedacht hat und empfehle, innerhalb dieses Bereichs zu bleiben.

Nach einem weiteren "Speichern" sind die Konfigurationsdaten abgespeichert und die eigentliche Konfiguration des Plugins beendet. Nur die Wetterstation selbst muss noch von etwaigen Änderungen informiert werden.  Dies erfolgt über den Button "WS-Set" . Dabei wird in der Wetterstation der Wetter-Service Customized im Ecowitt-Protokoll mit dem hier konfigurierten Sende-Intervall zur IP-Adresse des LoxBerry auf den konfigurierten HTTP-Port aktiviert. Ein ggf. mit WS View modifizierter Path wird dabei überschrieben. FOSHKplugin setzt die ursprünglichen defaults - also /data/report/ - bei Ecowitt bzw. /weatherstation/updateweatherstation.php? bei WU. 

Mit dem Button "Restart" kann der systemd-Dienst des Plugins neugestartet werden. Änderungen an der Konfiguration werden erst nach einem Neustart des Dienstes aktiv.

Über "Vorlage" lässt sich die Loxone-Vorlagedatei downloaden. Darin enthalten sind sämtliche virtuellen In- und Outputs zur leichteren Integration im Miniserver.

Wichtig:  Die Änderung des HTTP-Ports oder der IP-Adresse des LoxBerry sowie des Sende-Intervalls erfordert das Speichern der Settings in der Wetterstation via Button WS-Set!

Unter  "Optionale Einstellungen" sind noch diverse Zusatzfunktionen konfigurierbar:

metrische Einheiten: wenn aktiviert erfolgt die Umrechnung der in US-Einheiten von der Wetterstation gelieferten Werte für UDP-Versand und CSV-Export direkt durch das Plugin

leere Werte überspringen: bei Aktivierung werden ggf. von der Wetterstation kommende Werte -9999 nicht per UDP an den Miniserver verschickt

nutze Loxone-Zeit: Über diesen Schalter wird festgelegt, ob eine Umrechnung der UTC-Zeit auf Loxone-Zeit erfolgen soll. Bei Aktivierung wird ein zusätzliches Feld loxtime im Loxone-kompatiblen Zeitformat (Sekunden seit 01.01.2009) angefügt.

optionale Berechnungen: Bei Aktivierung werden die Werte für Taupunkt, Windchill-Temperatur, Hitzeindex und gefühlte Temperatur und - sofern ein Feinstaubsensor DP200/WH41/WH43 vorhanden ist - der AQI-Wert aktuell und dessen 24h-Mittel aus den vorliegenden Messwerten errechnet und den von der Wetterstation kommenden Daten für die Export-Verarbeitung (UDP, WU, CSV, W4L, …) hinzugefügt. Dabei werden ggf. bereits von der Wetterstation kommende Werte NICHT überschrieben. Ist die Sturmwarnung aktiviert, erfolgt zusätzlich die Berechnung des Luftdrucktrends und der Luftdruckänderung (für die letzte Stunde sowie für die letzten 3 Stunden).

optionale Elemente: hängt einen String mit statischen Werten an die von der Wetterstation kommende Raw-Datenzeile an, ggf. vorhandene Variablennamen mit gleichen Namen werden dabei überschrieben. Sinnvoll, um ein paar Felder (wie Geolokalisierung: lat/lon/elev oder Ort: neighborhood) per UDP/WU/CSV/W4L etc. weiterzugegeben. Diese Felder durchlaufen die komplette Exportverarbeitung, tauchen somit in allen Ausgabeformaten auf. Diese Funktion kann auch dazu genutzt werden, um von der Wetterstation kommende Werte von der Weiterverarbeitung auszuschließen. Dazu muss hier einer Variablen ein leerer Wert zugewiesen werden (also: &variable3=&variable4=wert4) und "leere Werte überspringen" aktiviert sein.

Format: &variable1=wert1&variable2=wert2

Log-Dateien: Sind für die Inbetriebnahme sowie bei Problemen sehr nützlich. Man sollte jedoch abwägen, ob das dauerhafte Mitschreiben der Logs wirklich sinnvoll ist. Bei Einsatz einer SD-Karte als Speichermedium schreibt man sich sonst irgendwann die SD-Karte kaputt.
Vorallem das Export-Log kann - wenn ein sehr kurzer Intervall eingestellt ist, sehr schnell sehr groß werden, da für jede von der Wetterstation kommende Nachricht - je nach Konfiguration - eben auch ein Eintrag für UDP, Weiterleitung (FWD) und CSV erzeugt wird.

Zum Deaktivieren eines bestimmten Log-Files ist schlicht der Name der jeweiligen Datei zu entfernen.

Seit v0.08 ist es möglich, das Logging global über den Switch im Config-File Logging\LOG_ENABLE = True/False an- und abzuschalten.

Weiterleiten an: Es ist nur ein externes Ziel für den  Versand per "Customized Upload" in der Konfiguration einer Wetterstation vorhanden. Da wir dieses bereits für den LoxBerry nutzen, kann man hier eine Weiterleitung an einen zusätzlichen Dienst (etwa Awekas) einstellen. Aktuell unterstützt das Plugin 50 Weiterleitungsziele, wobei nur eines über die Weboberfläche zu konfigurieren ist. Die restlichen Ziele sind ggf. direkt über die Config-Datei einzurichten.

Bei der Angabe der URL ist zu beachten, dass vom Plugin nur die Messwerte hinzugefügt werden. Etwaige Authentifizierungen oder Update-Befehle müssen also bereits an dieser Stelle eingegeben werden. Für einen Upload zu Weather Underground (der natürlich auch direkt über die Wetterstation möglich ist) sähe eine solche Zeile also wie folgt aus:

https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php?ID=[meine ID]&PASSWORD=[mein Password]&action=updateraw&

Erfolgreich getestet habe ich hier den Versand an die Dienste Awekas, Windy und PWSWeather:

URL für Awekas: http://ws.awekas.at/weatherstation/updateweatherstation.php?ID=[awekasid]&PASSWORD=[awekaspassword]&

URL für Windy: https://stations.windy.com/pws/update/[windyAPIkey]?

URL für PWSWeather: http://www.pwsweather.com/pwsupdate/pwsupdate.php?ID=[PWS-ID]&PASSWORD=[PWS-Password]& (in Kürze offenbar https://pwsupdate.pwsweather.com/api/v1/submitwx?ID=[PWS-ID]&PASSWORD=[PWS-Password]&)

Andere WU-kompatible Dienste sollten ebenfalls funktionieren. Bleibt das Feld frei, erfolgt keine Weiterleitung.

Mit "Weiterleiten Format:" wird festgelegt, in welchem Format die weitergeleiteten Nachrichten der Wetterstation versandt werden sollen.

Für WU-kompatible Server sollte das WU-Format ausgewählt werden. Für andere Szenarien gibt es auch das UDPGET-Format, bei dem die ggf. umgewandelten metrischen Werte wie bei UDP (jedoch nicht durch Leerzeichen sondern durch html-konforme "&" separiert) verschickt werden. Darüber sollten sich virtuelle http-Eingänge realisieren lassen.

Weiter verbessert und ausgiebig getestet wurde das EW-Format. Dabei werden eingehende Nachrichten der Wetterstation in das Ecowitt-Format umgewandelt und im Ecowitt-Protokoll per HTTP-Post weiterversandt. Somit lassen sich darüber auch weitere Hosts per Ecowitt-Protokoll bedienen (Relay). Mit Typ RAW werden die eingehenden Daten ohne Konvertierung per http-get weitergeleitet. Um den originalen RAW-String ohne jegliche Erweiterung im EW-Format per POST zu versenden, bietet sich der Typ RAWEW an. Über RAWUDP können die RAW-Daten auch per UDP verschickt werden, dabei ist als FWD_URL dann destination-ip:destination-port anzugeben. Sollen weitere Ziele die verarbeiteten (und ggf. umgerechneten) Daten per UDP erhalten, ist der Forward-Typ UDP nützlich. Auch hier erfolgt die Angabe des Ziels über die FWD_URL mit destination-ip:destination-port. Ebenfalls können die für den Dienst luftdaten.info erforderlichen Werte eines vorhandenen Feinstaubsensors DP200/WH41/WH43 über den Typ LD gesendet werden: 

URL für Luftdaten: https://api.sensor.community/v1/push-sensor-data/

Die zur Anmeldung erforderliche Sensor-ID ist dazu im Config-File unter FWD_SID einzutragen. Als Intervall für das Senden der Feinstaubsensor-Werte sollte 150 Sekunden konfiguriert werden (FWD_INTERVAL = 150 im Config-File). Der Dienst erwartet neben dem PM2.5-Wert auch den PM10-Wert (den der Feinstaubsensor DP200/WH41/WH43 aber nicht liefern kann). Daher sendet das Plugin jeweils einen Dummy-Wert von 1 für PM10 mit.

Übersicht über die verschiedenen Forward-Möglichkeiten:

FWD_TYPE input-Format out-Transport out-Format
WU WU, EW, AMB GET Weather Underground (WU–>WU bzw. EW–>WU)
RAW WU, EW, AMB GET wie input (WU–>WU bzw. EW–>EW)
UDPGET WU, EW, AMB GET wie Ausgabe zu Loxone mit Header und ggf. Umrechnung jedoch URL-kompatibel mit "&" statt Leerzeichen
WC WU, EW, AMB GET Weathercloud
MT WU, EW, AMB GET Meteotemplate (API)
AMB WU, EW, AMB GET Ambient Weather
AWEKAS WU, EW, AMB GET Awekas (API)
WETTERCOM WU, EW, AMB GET wetter.com/Wetterarchiv (API)
EW WU, EW, AMB POST erweitertes Ecowitt (WU–>EW bzw. EW–>EW)
RAWEW WU, EW, AMB POST unverändertes Ecowitt (EW–>EW und WU–>EW)
LD WU, EW, AMB POST Luftdaten.info-Format (nur PM2.5, PM10, Temp, Humidity, rel. Pressure, abs. Presssure)
CSV WU, EW, AMB POST wie Ausgabe zu Loxone mit ggf. Umrechnung jedoch separiert mit Semikolon statt mit Leerzeichen und ohne Header
RAWCSV WU, EW, AMB POST wie input (WU–>WU bzw. EW–>EW) jedoch separiert mit Semikolon statt mit Leerzeichen
WEATHER365 WU, EW, AMB POST weather365.net API
UDP WU, EW, AMB UDP wie Ausgabe zu Loxone mit Header und ggf. Umrechnung per UDP (Ziel-IP:Port muss als FWD_URL deklariert werden)
RAWUDP WU, EW, AMB UDP wie input-Format jedoch Versand per UDP (EW→EW und WU–>WU)
REALTIMETXT WU, EW, AMB diverse sendet eine realtime.txt (Cumulus Export-Datei) via http(s)/POST oder per ftp(s) zu einem entfernten Ziel oder speichert die Datei im Dateisystem
CLIENTRAWTXT WU, EW, AMB diverse sendet eine clientraw.txt (Weather Display Export-Datei) via http(s)/POST oder per ftp(s) zu einem entfernten Ziel oder speichert die Datei im Dateisystem
CSVFILE WU, EW, AMB diverse sendet eine Datei FOSHKplugin.csv mit dem aktuellen Datensatz via http(s)/POST oder per ftp(s) zu einem entfernten Ziel oder speichert die Datei im Dateisystem
TXTFILE WU, EW, AMB diverse sendet eine Datei FOSHKplugin.txt mit dem aktuellen Datensatz via http(s)/POST oder per ftp(s) zu einem entfernten Ziel oder speichert die Datei im Dateisystem
RAWTEXT WU, EW, AMB diverse sendet eine Datei rawtext.txt mit dem aktuellen RAW-Datensatz via http(s)/POST oder per ftp(s) zu einem entfernten Ziel oder speichert die Datei im Dateisystem
MQTTMET WU, EW, AMB MQTT sendet eingehende Daten der Wetterstation per MQTT an einen MQTT-Broker im metrischen Format weiter
MQTTIMP WU, EW, AMB MQTT sendet eingehende Daten der Wetterstation per MQTT an einen MQTT-Broker im imperialen Maßsystem weiter
WSWIN WU, EW, AMB File speichert eine WSWin-kompatible wswin.csv im Dateisystem, die per Dateiüberwachung automatisiert von WSWin eingelesen werden kann
INFLUXMET WU, EW, AMB InfluxDB speichert den aktuellen Datensatz mit metrischen Werten in einer InfluxDB-Datenbank
INFLUXIMP WU, EW, AMB InfluxDB speichert den aktuellen Datensatz mit imperialen Werten in einer InfluxDB-Datenbank

Daten der unter "Felder ignorieren:" gepflegten Ignorierliste werden beim betreffenden Forward nicht versandt.

Mit "Weiterleiten Intervall" kann ein von der Wetterstation unabhängiger Intervall (in Sekunden) konfiguriert werden. Bleibt dieses Feld frei, erfolgt der Versand im Sende-Intervall der Wetterstation.

Als CSV speichern: Die Messergebnisse können zusätzlich als Kommaseparierte Datei (CSV) abgespeichert werden. Der Ablageort sowie der Dateiname wird hier angegeben. Auch hier gilt das bereits für Log-Dateien erwähnte Problem mit dem Schreiben auf SD-Karten. Hier sollte also ggf. ein besser geeignetes Medium (etwa NFS) gewählt werden.

Feldnamen für CSV: Hier werden alle im CSV gewünschten Felder - mit einem Separator (Semikolon, Komma oder Leerzeichen) getrennt - aufgeführt. Nicht alle Felder eines Datensatzes lohnen für eine Speicherung im CSV. So ändern sich die Inhalte der Felder SID, PASSKEY, freq oder model nur sehr selten.
Durch Weglassen dieser Feldnamen werden diese Felder somit von der Speicherung ausgeschlossen. Die Reihenfolge der Spalten im CSV-File ergibt sich aus der Reihenfolge der hier angegebenen Felder.

CSV Intervall: Hier kann ein eigener Zeitabstand für das Abspeichern eines Datensatzes im CSV definiert werden. Bleibt das Feld frei wird der Sende-Intervall der Wetterstation genutzt.

Der Intervall für CSV- und Weiterleitungs-Funktion kann nicht kleiner als der eingestellte Sende-Intervall der Wetterstation sein, da nur bei Eingang eines Datensatzes von der Wetterstation Daten zum Weiterverarbeiten vorliegen.

Interaktion mit Weather4Loxone

Das Plugin Weather4Loxone kann die Daten des FOSHK-Plugins direkt verwenden. Dabei werden die Daten des Wetterdienstes mit den lokal erfassten Daten des FOSHK-Plugins ersetzt. So kann man Forecast oder nicht selbst erfasste Daten über einen Wetterdienst nutzen, nutzt aber ansonsten in Weather4Lox die eigenen lokalen Daten.

In Weather4Lox muss dazu lediglich der FOSHK-Plugin Grabber aktiviert werden und die IP-Adresse und der Port des FOSHK-Plugins noch eingetragen werden:

Betrieb mehrerer Wetterstationen - Betrieb mehrerer paralleler FOSHKplugin-Installationen

Grundsätzlich ist FOSHKplugin dafür gedacht, EINE Wetterstation zu unterstützen. Es gab aber inzwischen schon 2 unabhängige Anfragen, ob man nicht mehrere parallele Installationen von FOSHKplugin auf einem LoxBerry installieren könnte, um damit die Daten mehrerer Wetterstationen verarbeiten zu können. Interessant ist dies vorallem, wenn die maximale Anzahl der durch die Station unterstützten Sensoren eines Typs (etwa Bodenfeuchtesensoren WH51) bereits erreicht ist, man aber weitere Sensoren dieses Typs benötigt und daher eine zweite Station kauft. Mit FOSHKplugin ab v0.09 ist diese Möglichkeit gegeben.

Anleitung:

Um FOSHKplugin unter eigenem Namen und mit separater Konfiguration parallel in einer weiteren Instanz auf dem LoxBerry zu installieren, sind folgende 4 Schritte nötig:

  1. ZIP-Datei des Plugins downloaden
  2. plugin.cfg aus der ZIP-Datei extrahieren
  3. plugin.cfg anpassen
    1. Hierzu mit einem Editor folgende Zeilen ändern - TITLE ist dabei der Name, unter dem das "neue" Plugin dann im LoxBerry erscheint und NAME und FOLDER bezeichnen den internen Namen und das Installationsverzeichnis.

Ich empfehle die Verwendung des Namens der sendenden Station als Suffix zu den bereits eingetragenen Werten - jedoch müssen diese Bezeichnungen LoxBerry-weit einmalig sein:
NAME=foshkplugin –> NAME=foshkplugin-gw1100
FOLDER=foshkplugin –> FOLDER=foshkplugin-gw1100
TITLE=FOSHKplugin –> TITLE=FOSHKplugin-GW1100

  1. geänderte plugin.cfg wieder in die ZIP-Datei einpacken, dabei die bereits vorhandene Datei überschreiben

Anschließend lässt sich dieses neue Plugin auf dem üblichen Weg in der Plugin-Verwaltung des Loxberry als Plugin installieren.

Zu beachten ist, das der parallele Betrieb von mehreren FOSHKplugin-Installationen tatsächlich getrennt erfolgt - jedes FOSHKplugin verweist also auf eine andere Wetterstation, hat einen eigenen Port zur Datenentgegennahme (HTTP-Port des LoxBerry) und erfordert auch einen separaten UDP-Sendeport (UDP-Port des Zielsystems) mit eigenen virtuellen Eingängen im Loxone-Miniserver. Bei der Plugin-Installation wird die jeweils zuerst gefundene Wetterstation in die Plugin-Konfiguration geschrieben - hier sollte also geprüft werden, ob die jeweiligen Plugins tatsächlich auf unterschiedliche Stationen verweisen (IP-Adresse der Station) und ggf. mit dem Button WS-Set die korrigierte Konfiguration in die Wetterstation geschrieben werden. Zur Steuerung des Plugins von Loxone aus ist der UDP-Port des Plugins (UDP-Port des LoxBerry) ebenfalls eindeutig (einmalig) zu konfigurieren.

Zusammengefasst:

UDP-Port des Zielsystems (der Port, auf dem der Loxone MS die eingehenden Daten erwartet)

HTTP-Port des LoxBerry (der Port, auf dem FOSHKplugin eingehende Daten der Wetterstation erwartet)

UDP-Port des LoxBerry (der Port, auf dem FOSHKplugin auf etwaige Steuerbefehle vom Loxone-MS lauscht) sowie

IP-Adresse der Station (die IP-Adresse zum Schreiben der Konfiguration in die Wetterstation)

sollten bei den einzelnen Plugin-Installationen unbedingt UNTERSCHIEDLICH sein!

Ich habe auch ein kleines Script cloneFOSHKplugin.bat gebastelt, das diese Änderungen mehr oder weniger automatisch vornehmen kann. Allerdings ist die Änderung der drei Einträge in der Datei plugin.cfg auch manuell sehr schnell gemacht. Das Script erzeugt aber ein Paket mit neuem Namen und sollte (!) weniger anfällig für etwaige Fehler sein.

Man kann sich den Link (oder das Script selbst) auf den Windows-Desktop packen und kann das ZIP-File des LoxBerry-Plugins FOSHKplugin per drag&drop einfach darauf fallenlassen.
Es sollte sich dann ein Dos-Fenster öffnen und nach NAME und TITLE des neu zu erstellenden - geclonten - Plugins fragen. Das fertige "geclonte" Paket findet sich anschließend dann an der Stelle, wo das Ursprungspaket war (vermutlich der Download-Ordner).

Im ZIP-File enthalten ist auch eine Textdatei cloneFOSHKplugin.txt mit weiteren Hinweisen zum Clonen des FOSHKplugin-LoxBerry-Plugins.

Roadmap

… ein paar Ideen habe ich noch; auf Eure Wünsche bin ich gespannt …

Fragen stellen und Fehler melden

Im Loxforum gibt es für dieses Plugin einen eigenen Thread:  https://www.loxforum.com/forum/projektforen/loxberry/plugins/222662 - ich und auch andere Plugin-Nutzer lesen dort mit und helfen gern bei Fragen und Problemen. Bitte aber immer mit möglichst genauer Fehlermeldung oder -beschreibung und Angabe der genutzten Version und Typ und Hersteller der Wetterstation und mit Screenshots und/oder Log-File-Ausschnitten zur Verdeutlichung des Problems. 

Hilfe zur Selbsthilfe

Wenn die Kommunikation zwischen Wetterstation und FOSHKplugin oder FOSHKplugin und Loxone-Server nicht klappt, bitte zuerst nochmal an die Arbeitsweise dieses Systems denken. Wir haben 3 Geräte im Einsatz mit folgendem Datenfluss:

Wetterstation      –> FOSHKplugin auf LoxBerry –> Loxone-Miniserver

Diese 3 Geräte haben unterschiedliche IP-Adressen und erfordern verschiedene Ports:

Wetterstation
mit IP-Adresse 1 		FOSHKplugin auf LoxBerry
mit IP-Adresse 2 		Loxone-Miniserver
mit IP-Adresse 3
http-Sendeport 1 –> http-Empfangsport 1
UDP-Sendeport 1 –> UDP-Empfangsport 2

Die Wetterstation sendet also die Sensordaten per http an den LoxBerry, auf dem das Plugin FOSHKplugin läuft. Dieses Plugin nimmt die Daten per http auf dem unter " HTTP-Port des LoxBerry: " konfigurierten Port entgegen, wandelt diese um und sendet den Datensatz dann per UDP an den unter " UDP-Port des Zielsystems: " konfigurierten Port an das unter " IP-Adresse des Zielsystems: " eingetragene Ziel (hier der Loxone-MS).
Das Ziel der Wetterstation ist also die IP-Adresse und der Port des LoxBerry. Und das Ziel des FOSHKplugin stellt der Loxone-Server dar. Diese IP-Adressen und Ports dürfen nicht verwechselt werden!

Ansonsten empfiehlt sich, die Problemforschung von der Quelle zum Ziel durchzuführen:

  1. Prüfen, ob die Sensordaten in der WS View-App angezeigt werden
  2. Prüfen der Einstellungen für den Customized Service in WS View.

Geh dazu bitte in die WS View App, wähle Deine Station und geh zu More und dann weiter zu Weather Services.
Mit viermal Next solltest Du zu den Einstellungen für den Customized Service gelangen.
Dort sollte dann Customized enabled und Protocol auf Ecowitt eingestellt sein.
Die angegebene IP-Adresse bei Server IP/Hostname sollte der IP-Adresse Deines LoxBerrys entsprechen und als Path sollte /data/report/ eingetragen sein.
Auch die Portnummer unter Port sollte dem im Plugin konfigurierten " HTTP-Port des LoxBerry " entsprechen.
Solltest Du die IP-Adresse Deines LoxBerry nicht kennen, klicke auf den Button " Erkenne LB " unter  "Optionale Einstellungen" des Plugins.

Sind die Daten im WS View soweit korrekt eingetragen, sollten - von etwaigen Netzwerkproblemen abgesehen - die Daten von der Wetterstation korrekt verschickt werden.

Dann ist FOSHKplugin/LoxBerry zu prüfen: Erster Anlaufpunkt bei Problemen sollte das interne Logging des FOSHKplugin sein. Unter  "Optionale Einstellungen" gibt es dazu 3 unterschiedliche Log-Files:

Im " Standard-Log " werden Start und Stopp des Plugins protokolliert. Auch etwaige Fehlermeldungen, Warnungen und eingehende Meldungen erscheinen dort.

Im " WS-Empfangs-Log " werden alle von der Wetterstation entgegengenommenen Daten (Rohdaten) mitgeschrieben.

Und im " Export-Log " erscheinen alle vom Plugin nach außen geschickte Daten - nebst etwaigen Export-spezifischen Fehlermeldungen.

Gibt es hier keinerlei Hinweise auf irgendwelche Probleme wird es knifflig, ich benötige dann die Log-Files und ggf. Screenshots sowie Hintergrundinformationen (LoxBerry-Version, Image oder selbstaufgezogen, echte Hardware oder virtuelle Maschine, andere Plugins, sonstige Seltsamkeiten) um helfen zu können. Hilfreich kann hier auch das LoxBerry-Apache-Log sein. Zu finden ist es im Log-Manager von LoxBerry unter " Apache Log ". Kommen jedoch Daten von der Wetterstation im " WS-Empfangs-Log " an, sind die Daten zumindest schonmal im Plugin.

Die Kommunikation zwischen FOSHKplugin und dem Zielsystem gilt es nun zu prüfen:

In den Einstellungen des FOSHKplugin ist also sicherzustellen, dass die unter " IP-Adresse des Zielsystems " angegebene Adresse tatsächlich die des Ziels (also der Loxone-Server) ist und dieses auch erreichbar ist. Desweiteren sollte der unter " UDP-Port des Zielsystems " angegebene Port wirklich der Port sein, auf dem das Zielsystem (Loxone-Server) die eingehenden Nachrichten an den virtuellen Eingängen erwartet.

Kompatible Wetterstationen

Es sollten alle Wetterstationen unterstützt sein, deren Konfiguration über die WS View-App erfolgt und bei der man ein benutzerdefiniertes Ziel eintragen kann (Weather Service: Customized). Eventuell funktioniert es sogar bei Stationen, die den Customized-Modus einfach nur ausblenden. Da ich diese Stationen jedoch nicht mit FOSHKplugin getestet habe, kann ich keine Gewähr dafür geben. Das müsste man ggf. auf eigene Gefahr ausprobieren.

Laut den verfügbaren Anleitungen sollten die Wetterstationen von Froggit WH3000 SE,  WH4000 SE und HP1000SE PRO - auch bei Übermittlung im Ecowitt-Format - mit FOSHKplugin kompatibel sein. 

Die Froggit WH2600 SE LAN überträgt wohl ausschließlich im WU-Format - ein customized Server ist aber einstellbar. Somit sollte auch diese Station mit FOSHKplugin funktionieren. Vermutlich muss man aber hier die Einstellung von Server, Port und Intervall in der App tätigen.

In den Anleitungen zur neuen WH5500 und WH6000 finde ich keine Informationen zur Einstellung eines Customized Servers. Somit werden diese Stationen wohl nicht mit FOSHKplugin funktionieren. Offenbar stammen diese Stationen auch nicht von FOSHK sondern vom chinesischen Hersteller CCL …

Sicher funktionieren sollten jedoch:

  • Froggit DP1500 (GW1000) uneingeschränkt - hier in Betrieb mit WH3000SE (WH65), DP50 (WH31), DP100 (WH51), WH41 (DP200), WH55 (DP70) und WH57 (DP60)
  • Ecowitt GW1000 da baugleich
  • Froggit HP1000SE PRO WiFI Wetterstation (aktuelle Version)
  • Sainlogic 7 in 1
  • WS980WiFi von ELV
  • Eurochron EFWS 2900

Noch ein Hinweis bzgl. Hersteller FOSHK und "kompatible" Wetterstationen:

Der chinesische Hersteller FOSHK verkauft seine Produkte an eine Vielzahl von Weiterverkäufern, die diese Geräte umlabeln (oder selbst das sogar lassen) und unter eigenem Namen anbieten. Inwieweit die Verkäufer dann tatsächlich noch irgendwelche Anpassungen vornehmen oder die Software beeinflussen, kann ich nicht sagen. Rein äußerlich sehen jedenfalls die Wetterstationen ELV Ventus W830, Sainlogic, ChiliTec, Conrad Eurochron EFWS 2900 oder Waldbeck Huygens der WH3000SE von Froggit sehr ähnlich. Die ELV WS980WiFi sieht einer Froggit WH4000 verdammt ähnlich und eine dnt WiFi-Wetterstation WeatherScreen PRO sieht doch beinahe wie eine HP1000SE von Froggit aus. In den zum Teil vorab verfügbaren Bedienungsanleitungen sollte man erkennen können, ob die Wetterstation einen Customized Weather Service (idealerweise im Ecowitt-Format) anbietet. Ist das gegeben, sollte die Anbindung via FOSHKplugin kein Problem darstellen.

Rechtliche Hinweise

Ich übernehme keine Garantien hinsichtlich des Einsatzes dieser Software - die Nutzung geschieht auf eigene Gefahr. Treffen Sie Entscheidungen die zu Personen- oder Sachschäden führen können niemals auf Grundlage dieser Software. Durch das Programm generierte Warnungen (z.B. Sturm oder Gewitter) können eintreffen. Das Fehlen dieser Warnungen impliziert jedoch nicht, dass diese Dinge nicht möglich sind.

Link zur Android-App WS View im Google PlayStore (externer Link)

Die WS View-App für Geräte mit dem Apfel (externer Link)

Die Icon-Sammlung, die Grundlage für das hier genutzte Icon ist (externer Link)

Das "generic"-Plugin falls eine LoxBerry-Installation nicht zur Verfügung steht (externer Link)