Plugin-Daten
AutorOliver Engel
Logo
StatusSTABLE
Version0.09
Min. LB Version1.0
Release Downloadhttp://foshkplugin.phantasoft.de/files/loxberry-FOSHKplugin.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

Funktion des Plugins

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=mRückmeldung eines WU-kompatiblen Datensatzes mit metrischen Werten (°C, kmh, mm, hPa)
/observations/current/json/units=eRü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 +0200CETEurope/Berlin+0200Hohen NeuendorfDE52.66948113.266531538.28.292Westsüdwest2560.00.08.21027.097.00.007.500.00.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

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-Formatout-Transportout-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
CLIENTRAWTXTWU, 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.

Übersicht des GUI animierte Übersicht des GUI (mit Rollover-Hilfe)
{{plugins:foshkplugin:1240959366.png?h=250}}{{plugins:foshkplugin:1240959767.gif?h=250}}

Für einige (seltene) Einstellungen gibt es derzeit kein Web-Interface. Daher müssen diese Einstellungen direkt in der Config-Datei vollzogen werden. Diese Konfigurationsoptionen sind für den normalen Betrieb nicht nötig, können aber erweiterte Einsatzszenarien unterstützen.

Bei einer Standard-Installation befindet sich die Config-Datei foshkplugin.conf in /opt/loxberry/config/plugins/foshkplugin/. Diese Datei kann mit einem beliebigen Editor geändert werden. Sollten im Config-File diese Einträge nicht enthalten sein (was bei schon länger aktiven FOSHKplugin-Installationen möglich ist), können diese händisch nachgetragen werden. Oder man kopiert die entsprechenden Blöcke aus der default-Config im ZIP-File, über das das Plugin-Update installiert wurde.  Wichtig: Die geänderten Einstellungen werden erst nach einem Neustart des Plugins aktiv!

Über das LoxBerry-Web-Interface lässt sich ein Forward für den Versand an einen weiteren externen Server konfigurieren. Das ist hilfreich, wenn man z.B. seine Wetterdaten auch einem anderen Wetterdienst (etwa Awekas oder Windy) zur Verfügung stellen möchte.
Man kann mit diesem Plugin jedoch insgesamt 50 Weiterleitungsziele definieren. Dabei wird neben dem WU-Format (also eine Auswahl der Werte und ausschließlich im US-Maßsystem) für WU-kompatible Systeme auch ein Pseudo-UDP-Format mit metrischen Messwerten sowie der Versand an Systeme im Ecowitt-Protokoll unterstützt.
Im Config-File können dazu folgende Einträge getätigt werden:

[Forward-n]
FWD_URL =
FWD_TYPE = “„
FWD_IGNORE = “„
FWD_INTERVAL =
FWD_SID =
# neben Forward (per Webinterface konfigurierbar) werden auch Forward-1 bis Forward-9 unterstützt
# die URL des Zielsystems, etwaige Authentifizierungen sind bereits hier mit anzugeben
# hier wird zwischen WU,  UDPGET, EW, LD,  RAW, UDP und RAWUDP unterschieden; WU-format (default)
# eine Komma-separierte Liste der Felder, die nicht verschickt werden sollen
# der Intervall in Sekunden, in dem die Nachrichten verschickt werden sollen
# Sensor-ID für luftdaten.info

Daten der Ignorierliste FWD_IGNORE werden beim betreffenden Forward nicht versandt.

Die Ausgabezeile sähe dann z.B. bei FWD_TYPE=UDPGET so aus:

http://192.168.15.100/report?SID=FOSHKweather&dateutc=2020-01-02+14:16:38&loxtime=347210198&tempinc=23.2&humidityin=30&baromrelhpa=1023.91&baromabshpa=1018.79&tempc=5.0&humidity=58&winddir=160&windspeedkmh=0.0&windgustkmh=0.0&maxdailygust=3.6&solarradiation=18.60&uv=0&rainratemm=0.0&eventrainmm=0.0&hourlyrainmm=0.0&dailyrainmm=0.0&weeklyrainmm=0.0&monthlyrainmm=0.0&yearlyrainmm=0.0&totalrainmm=0.0&temp2c=22.3&humidity2=34&temp3c=23.3&humidity3=31&soilmoisture1=46&soilmoisture2=38&wh65batt=1&batt2=0&batt3=0&soilbatt1=1.7&soilbatt2=1.7&dewptc=-0.4&windchillc=5.0&feelslikec=5.0&heatindexc=3.1&country=DE&neighborhood=Hohen%20Neuendorf

Forward im WU-Format zu Awekas:

http://ws.awekas.at/weatherstation/updateweatherstation.php?ID=12345&PASSWORD=awekaspwd&dateutc=2020-01-03+11:04:33&indoortempf=73.0&indoorhumidity=31&baromin=29.994&baromabsin=29.843&tempf=41.5&humidity=84&winddir=149&windspeedmph=0.22&windgustmph=5.82&maxdailygust=9.17&solarRadiation=30.70&uv=0&rainratein=0.000&eventrainin=0.000&hourlyrainin=0.000&dailyrainin=0.000&weeklyrainin=0.000&monthlyrainin=0.000&yearlyrainin=0.000&totalrainin=0.000&temp2f=69.44&humidity2=39&temp3f=73.22&humidity3=32&soilmoisture1=46&soilmoisture2=40&wh65batt=1&batt2=0&batt3=0&soilbatt1=1.7&soilbatt2=1.7&dewpt=38.3&windChill=41.5&feelslike=41.5&heatIndex=39.3

Die standardmäßig aktivierte Prüfung des Eingangs von neuen Nachrichten von der Wetterstation sowie deren Intervall können im Config-File deaktiviert werden:

[Warning]
WSDOG_WARNING = True
WSDOG_INTERVAL = 3

# aktiviert (Standard) oder deaktiviert die Prüfung eingehender Daten von der Wetterstation
# Anzahl der Sende-Intervalle ohne Daten von der Wetterstation, bevor eine Warnung per Log/UDP erfolgt

Eine aktivierte Prüfung kann hilfreich sein um den Ausfall der Wetterstation frühzeitig zu bemerken.

Die Wetterstation sammelt die Daten aller Sensoren zusammen und verschickt diese als ein Datenpaket an FOSHKplugin. Wenn ein Sensor ausfällt, sendet die Wetterstation ohne weitere Hinweise eben alle zur Verfügung stehenden Daten.
Um nun den Ausfall eines spezifischen Sensors feststellen zu können gibt es die Liste SENSOR_MANDATORY, in die normalerweise von der Wetterstation kommende Felder eingetragen werden können. FOSHKplugin prüft das eingehende Datenpaket auf Vorhandensein der in dieser Liste enthaltenen Sensordaten und meldet bei aktivierter Prüfung  SENSOR_WARNING=True unter [Warning] das Fehlen per Log-Eintrag und per UDP.

SENSOR_WARNING = False
SENSOR_MANDATORY = „wh65batt“
# aktiviert/deaktivert die Sensor-Warn-Funktion (Standard: deaktiviert)
# eine kommaseparierte Liste von Feldern, die erwartet werden; bei Fehlen eines dieser Felder erfolgt eine Warnung

Somit lässt sich zeitnah der Ausfall eines Sensors feststellen. Zu beachten ist jedoch, dass fehlende Werte bei verschiedenen Sensoren von der Wetterstation zwischengespeichert und - trotz Ausfall des Sensors - noch weitere 10 Minuten weiter geschickt werden. Zumindest beim Wassersensor WH55, dem Bodenfeuchtesensor DP100/WH51 sowie dem Feinstaubsensor WH41/DP200 konnte ich diese Arbeitsweise feststellen. Weitere Sensoren habe ich noch nicht auf dieses Verhalten hin getestet. Man erhält also u.U. erst mit 10 Minuten Verspätung eine Info über den Ausfall eines Sensors.

Die Prüfung der verschiedenen Sensoren auf Batteriekapazität kann innerhalb von Loxone recht schnell kompliziert werden, da die übergebenen Werte von Fine Offset uneinheitlich geregelt sind. So gibt es Sensoren, die bei ausreichender Batteriekapazität im jeweiligen batt-Feld eine 0 mitsenden und andere, die den Batterie-Level (5..1) übertragen. Auch die verfügbare Spannung wird von manchen Sensoren übertragen.
Ab v0.06 gibt es die per default aktivierte Batteriewarnung, die bei Unterschreitung eines intern festgelegten Levels eine Warnung per UDP und im Log-File sendet. Diese Prüfung  kann mit BATTERY_WARNING=False unter [Warning] im Config-File abgeschaltet werden.

BATTERY_WARNING = True# aktiviert/deaktivert die Batterie-Warn-Funktion (Standard: aktiviert)

Innerhalb von Loxone kann dann bei Erkennung von FOSHK-batterywarning=1 festgestellt werden, dass ein Sensor demnächst keine ausreichende Batteriekapazität hat. Für die Feststellung um welchen Sensor es sich handelt ist entweder massiv mit der Befehlserkennung von Loxone zu basteln (diese zusätzliche Info über den betreffenden Sensor wird als Text übertragen) oder man schaut in der WS View-App oder im Log-File von FOSHKplugin nach.

Auch die per default aktive Sturmwarnung kann unter [Warning] mit False abgeschaltet oder ein anderer Schwellwert (default = 1.75 oder 3.75 in 3 Stunden) für den Anstieg/Abfall des Luftdrucks innerhalb einer Stunde und Zeit, nach der eine Entwarnung erfolgt, eingestellt werden:

STORM_WARNING = True
STORM_WARNDIFF = 1.75
STORM_WARNDIFF3H = 3.75
STORM_EXPIRE = 60
# aktiviert/deaktiviert die integrierte Sturmwarnung von FOSHKplugin (Standard: aktiv)
# Wertänderung in hPa pro Stunde ab dem das Plugin eine Warnung per Log/UDP ausgibt
# Wertänderung in hPa für 3 Stunden, die eine Warnung auslöst
# Sturmwarnung bleibt für 60 Minuten nach letzter Grenzwertunter-/überschreitung aktiv

Ist ein Blitzsensor WH57/DP60 vorhanden, erfolgt bei Erfüllung verschiedener Kriterien eine Gewitterwarnung. Diese Warnung kann im Config-File deaktiviert werden. Die Kriterien zur Auslösung dieser Warnung sind im Config-File konfigurierbar:

TSTORM_WARNING = True
TSTORM_WARNCOUNT = 1
TSTORM_WARNDIST = 20
TSTORM_EXPIRE = 30
# aktiviert/deaktiviert die integrierte Gewitterwarnung von FOSHKplugin (Standard: aktiv)
# Anzahl der detektierten Blitze ab der das Plugin eine Warnung per Log/UDP ausgibt
# Warnung erfolgt nur bei Detektion der Blitze innerhalb des hier eingestellten Bereiches (km)
# Zeit in Minuten nach letztem Blitz, bevor Warnung aufgehoben wird

Wenn ein Versand von UDP-Nachrichten an das Zielsystem grundsätzlich unterbunden werden soll (etwa, weil nur die Forward-/Relay-Funktion genutzt wird), lässt sich dies mit dem Schalter UDP_DISABLE realisieren. Eine Liste von Feldern, die nicht per UDP verschickt werden sollen, lässt sich unter UDP_IGNORE pflegen.

[Config]
UDP_ENABLE=False
UDP_IGNORE=
AUTH_PWD=

# deaktivert den Versand von UDP-Nachrichten (nicht aber RAWUDP als Forward)
# kommaseparierte Auswahl von Feldern, die nicht per UDP verschickt werden sollen
# optionales Password für ein- und ausgehende http-Anfragen. Wenn gesetzt werden ausschließlich Anfragen akzeptiert, die das Password in der URL enthalten. Im Ecowitt-Mode ist dafür der PASSKEY geeignet.

Die standardmäßig aktivierte Prüfung auf verfügbare Firmware-Updates für die Wetterstation kann im Bereich [Update] des Conf-Files angepasst werden:

[Update]
UPD_CHECK=True
UPD_INTERVAL=86400
UPD_URL=

# Update-Prüfung aktivieren/deaktiveren (default: aktiv)
# Intervall der Updateprüfung in Sekunden (default 86400 = 24h)
# Link zum Firmware-Update-Info-File (default: intern vorgegeben)

Fake-Mode
Die Werte für Außentemperatur und Luftfeuchte kommen normalerweise entweder von einem Kombisensor (WH65, WS80) oder dem dezidierten Außensensor WH32.
Steht aber weder ein Kombisensor noch ein WH32 zur Verfügung, können Werte eines beliebigen Innensensors DP50/WH31 (der sinnvollerweise dann natürlich außen mit entsprechenden Wetterschutz installiert werden sollte) als Werte des Außensensors ausgegeben werden.
Im Config-file ist dazu festzulegen, welcher Key für den jeweiligen Wert genutzt werden soll:

[Export]
OUT_TEMP=temp1f
OUT_HUM=humidity1

# ersetzt den keyname temp1f mit tempf
# ersetzt den keyname humidity1 mit humidity

Innerhalb von FOSHKplugin wird bei Eingang einer Ecowitt-Zeile von der Wetterstation dann einfach der Teilstring “&temp1f=“ durch „&tempf=“ sowie „&humidity1=“ durch „&humidity=“ ersetzt. Die Werte selbst bleiben bestehen.
Diese Einstellung ist global und wirkt sich somit auf alle Exports/Forwards/Ausgaben (außer bei RAW und RAWEW) von FOSHKplugin aus.
Die Wetterstation selbst weiss davon natürlich nichts - somit kennen die dort konfigurierten Dienste (Ecowitt, WU, WOW, etc.) weiterhin keine Außenwerte.
Möchte man die Werte des Innensensors als Außensensor-Werte auch für diese Dienste ausgeben, müssen die Dienste innerhalb der Wetterstation deaktiviert und stattdessen von FOSHKplugin durchgeführt werden. Dazu sind im Config-File entsprechende Forwards zu definieren (die eckigen Klammern sind dabei jeweils NICHT mit anzugeben):

WU:
[Forward-11]
FWD_INTERVAL = 300
FWD_URL = https://rtupdate.wunderground.com/weatherstation/updateweatherstation.php?ID=[WU-ID]&PASSWORD=[WU-Password]&action=updateraw&
FWD_TYPE = WU
EW:
[Forward-12]
FWD_INTERVAL = 300
FWD_URL = http://cdnrtpdate.ecowitt.net/data/report/
FWD_TYPE = EW
WOW:
[Forward-13]
FWD_INTERVAL = 300
FWD_URL = http://wow.metoffice.gov.uk/automaticreading?siteid=[siteid]&siteAuthenticationKey=[siteAuthenticationKey]&
FWD_TYPE = WU
Weathercloud:
[Forward-14]
FWD_INTERVAL = 300
FWD_URL = http://api.weathercloud.net/v01/set?wid=[weathercloudid]&key=[key]&
FWD_TYPE = WC
Meteotemplate:
[Forward-15]
FWD_INTERVAL = 60           # should be shorter than 5 minutes
FWD_URL = http://192.168.15.100/template/api.php?PASS=[meteotemplatepwd]&
FWD_TYPE = MT
#Awekas-API:
[Forward-16]
FWD_CMT = forward im Awekas-API-Format
FWD_TYPE = AWEKAS
FWD_URL = http://data.awekas.at/eingabe_pruefung.php?
FWD_SID = Awekas-ID
FWD_PWD = Awekas-password
FWD_INTERVAL = 60
FWD_ENABLE = True
#wetter.com-API:
[Forward-17]
FWD_CMT = wetter.com via API
FWD_TYPE = WETTERCOM
FWD_URL = http://interface.wetterarchiv.de/weather
FWD_SID = station-ID
FWD_PWD = station-password
FWD_INTERVAL = 300
FWD_ENABLE = True
#weather365-API:
[Forward-18]
FWD_CMT = weather365 via API
FWD_TYPE = WEATHER365
FWD_URL = https://channel1.weather365.net/stations/index.php
FWD_SID = station-ID
FWD_INTERVAL = 300
FWD_ENABLE = True
#realtime.txt:
[Forward-19]
FWD_CMT = export realtime.txt via ftp
FWD_TYPE = REALTIMETXT
FWD_URL = ftp://anydomain.de/httpdocs/mydomain.phantasoft.de/upload
FWD_SID = ftp-username
FWD_PWD = ftp-password
FWD_INTERVAL = 30
FWD_ENABLE = True
#clientraw.txt:
[Forward-20]
FWD_CMT = export clientraw.txt to filesystem
FWD_TYPE = CLIENTRAWTXT
FWD_URL = /some/path/anyhwere/in/filesystem/
FWD_INTERVAL = 30
FWD_ENABLE = True
#MQTT:
[Forward-21]
FWD_CMT = export via MQTT (metric)
FWD_TYPE = MQTTMET
FWD_URL = 192.168.15.236:1883@hierarchy%prefix
FWD_INTERVAL = 30
FWD_ENABLE = True
FWD_SID = username
FWD_PWD = password

Änderungen am Config-File wie auch Änderungen an der Konfiguration über das Web-Interface erfordern den Neustart des Plugins über den Restart-Button!

Einrichtung in der Loxone Config Software

Das Plugin generiert auf Wunsch durch Klick auf den Button Vorlage eine Vorlage-Datei mit einer Vielzahl von virtuellen In- und Outputs, die in Loxone importiert werden kann. Zu beachten ist, dass der IE11 leider Probleme mit dem Download der Vorlagen-Datei macht. Hier ist also ggf. ein anderer Browser zu nutzen. Erfolgreich getestet habe ich das hier mit Edge, FireFox und Chrome.

Auf Grundlage der UDP-Befehlserkennung können aber auch weitere Meldungen von der Wetterstation oder Befehle für die Wetterstation implementiert werden.

Aktuell werden innerhalb der Vorlagendatei folgende Werte als virtuelle (analoge) UDP-Inputs angeboten:

für das Gateway DP1500/GW1000:
FOSHK-humidityin
FOSHK-tempinc


Bodenfeuchtesensoren DP100/WH51:

FOSHK-soilbatt1..8 (Batteriewert in Volt)
FOSHK-soilmoisture1..8


Für die Innen-Temperatur/Feuchtigkeitsmesser DP50/WH31:

FOSHK-batt1..8 (Batterie-Status; 1 = Alarm, 0 = ok)
FOSHK-humidity1..8
FOSHK-temp1..8c


Für die Feinstaubsensoren DP200/WH41/WH43:

FOSHK-pm25_avg_24h_ch1..4
FOSHK-pm25_ch1..4
FOSHK-pm25batt1..4 (Batterie-Status; 5 = max)
FOSHK-pm25_AQI_ch1..4
FOSHK-pm25_AQI_avg_24h_ch1..4
FOSHK-pm25_AQIlvl_ch1..4 (Level 1..6)
FOSHK-pm25_AQIlvl_avg_24h_ch1..4 (Level 1..6)


Status/Betriebsanzeige/Tracker:

FOSHK-running (1 = gestartet, 0 = gestoppt)
FOSHK-loxtime (Loxone-Zeit)
FOSHK-wswarning (1=Wetterstation meldet sich nicht)
FOSHK-sensorwarning (1=Sensor fehlt)
FOSHK-batterywarning (1=Batteriewarnung)
FOSHK-stormwarning (1=Sturmwarnung)
FOSHK-tswarning (1=Gewitterwarnung)
FOSHK-updatewarning (1=Update für Wetterstation verfügbar)
FOSHK-co2warning (1=CO2-Wert ist über Limit)


Für den Blitzsensor WH57/DP60:

FOSHK-lightning (Entfernung letzter Blitz in km)
FOSHK-lightning_time (Zeit letzter Blitz Unixtime)
FOSHK-lightning_loxtime (Zeit letzter Blitz)
FOSHK-lightning_num (Anzahl Blitze)
FOSHK-wh57batt (Batterie-Status; 5 = max)


Für den Boden/Wasser-Temperatursensor WN34:

FOSHK-tf_chNc (Temperatur in °C wobei N=1..8)
FOSHK-tf_battN (Batteriewert; N=1..8)


Für den Blattfeuchtesensor WN35:

FOSHK-leafwetness_chN (Blattfeuchte-Level wobei N=1..8)
FOSHK-leafbattN (Batteriewert; N=1..8)
Für den Wassersensor WH55:
FOSHK-leak_ch1..4 (1=Alarm, 0=ok)
FOSHK-leakbatt1..4 (Batterie-Status; 5 = max)

Für den Luftqualitätssensor WH45:
FOSHK-co2lvl
FOSHK-pm25_AQI_co2
FOSHK-pm25_AQIlvl_co2
FOSHK-pm25_AQI_24h_co2
FOSHK-pm25_AQIlvl_24h_co2
FOSHK-pm10_AQI_co2
FOSHK-pm10_AQIlvl_co2
FOSHK-pm10_AQI_24h_co2
FOSHK-pm10_AQIlvl_24h_co2
FOSHK-co2_batt


Für die Außenmessstationen WH3000SE All-In-One oder
HP1000SE All-In-One (WH65):

FOSHK-baromabshpa
FOSHK-baromhpa
FOSHK-baromrelhpa
FOSHK-dailyrainmm
FOSHK-dewptc
FOSHK-eventrainmm
FOSHK-feelslikec
FOSHK-heatindexc
FOSHK-hourlyrainmm
FOSHK-monthlyrainmm
FOSHK-humidity
FOSHK-loxtime
FOSHK-maxdailygust
FOSHK-rainratemm
FOSHK-solarradiation
FOSHK-tempc
FOSHK-totalrainmm
FOSHK-uv
FOSHK-weeklyrainmm
FOSHK-wh65batt (ist 1 bei Batteriewarnung, sonst 0)
FOSHK-windchillc
FOSHK-winddir
FOSHK-windgustkmh
FOSHK-windspeedkmh
FOSHK-yearlyrainmm
FOSHK-ptrend1 (Luftdruck-Trend 1h: 2=stark steigend, 1=steigend, -1 fallend, -2 stark fallend)
FOSHK-pchange1 (Luftdruckänderung 1h in hPa)
FOSHK-ptrend3 (Luftdruck-Trend 3h: 2=stark steigend, 1=steigend, -1 fallend, -2 stark fallend)
FOSHK-pchange3 (Luftdruckänderung 3h in hPa)
FOSHK-wproglvl (Wetterprognose Level)2
FOSHK-wnowlvl (Level Wetter aktuell)2




Zusätzliche Eingänge für die W4L-Integration siehe weiter unten!

Die Namen der Keys im UDP-Datagram entsprechen obigen Namen ohne „FOSHK-“.

Level Wetterprognose und entsprechende Strings:

wprogtxt
wproglvl DE EN NL FR ES SK
0 Sturm mit Hagel storm with hail Storm met hagel Tempête de grêle Tormenta con granizo Búrka s krupobitím
1 Regen/Unwetter rain/storm Regen/storm Pluie / tempête Tormenta de lluvia Dáž?/búrka
2 regnerisch rainy regenachtig pluvieux lluvioso daždivý
3 baldiger Regen soon rain binnenkort regen bientôt la pluie pronto lloverá skoro dáž?
4 gleichbleibend constant constante constant constante konštantný
5 lange schön nice for a long time lang mooi longtemps belle continuo hermosa dlho krásne
6 schön & labil nice & unstable mooi en onstabiel beau et instable hermosa e inestable krásne a nestabilné
7 Sturmwarnung storm warning Storm waarschuwing Avertissement de tempête Aviso de tormenta Varovanie pred búrkou

Level Wetter aktuell und entsprechende Strings:

wnowtxt
wnowlvl DE EN NL FR ES SK
0 stürmisch, Regen stormy, rainy stormachtig, regen orageux, pluie tormentoso, lluvia búrky, dáž?
1 regnerisch rainy regenachtig pluvieux lluvioso daždivý
2 wechselhaft unstable veranderlijk changeable cambiable premenlivý
3 sonnig sunny zonnig ensoleillé soleado slne?no
4 trocken, Gewitter dry, thunderstorm droog, onweer sec, orage seco, tormenta suchá, búrka


Die Datenpunkte für Status/Betriebsanzeige/Tracker sind eventbasiert, sie kommen also nur bei einer Zustandsänderung. Diese Meldungen sind per Default aktiviert. Einzig SENSOR_WARNING muss manuell im Config-File aktiviert (True) und um die Liste der zu überwachenden Werte (SENSOR_MANDATORY) erweitert werden. Es empfiehlt sich, auch diese vrtuellen Eingänge innerhalb Loxone als Analogeingänge zu definieren. Dann bleibt der jeweils durch das Plugin gesetzte Status für Loxone aktiv.

Aktuell gibt es folgende digitale UDP-Ausgangsverbinder:

FOSHK-Reboot ermöglicht den Neustart des DP1500-Gateways von Loxone aus
FOSHK-Shutdown beendet das Plugin; wenn als systemd-Dienst gestartet, wird es erneut gestartet
FOSHK-getStatus fordert die aktuellen Statuswerte vom Plugin an (running, wswarning, sensorwarning, …)
FOSHK-debugOn aktiviert den Debug-Modus für erweitertes Logging
FOSHK-debugOff deaktiviert den Debug-Modus für erweitertes Logging
FOSHK-leakWarnOn aktiviert die Meldungen des Leckage-Sensors
FOSHK-leakWarnOffdeaktiviert die Meldungen des Leckage-Sensors
FOSHK-co2WarnOn aktiviert die Meldungen des CO2-Sensors
FOSHK-co2WarnOff deaktiviert die Meldungen des CO2-Sensors

Die Bedeutung der Ein- und Ausgänge sollte sich größtenteils aus den Namen ergeben. Diese basieren auf den ursprünglichen Feldnamen im Ecowitt-Format, bei dem ggf. die jeweils enthaltene Einheit geändert wurde. Zur Einbindung der Vorlagendatei in die Loxone-Konfiguration finden sich im LoxWiki sicher ein paar hilfreiche Hinweise.

Hinweis:
Es empfiehlt sich,  ungenutzte Ein- und Ausgänge aus der Loxone-Konfiguration zu löschen, da der Speicherplatz des Loxone Miniservers (zumindest v1) recht knapp bemessen ist.

Interaktion mit Weather4Loxone

Da es aktuell noch keine offizielle API-Schnittstelle zum W4L-Plugin gibt, muss vorerst auf den Loxone-Grabber im W4L-Plugin zurückgegriffen werden. Dabei werden die Daten der Wetterstation zu FOSHKplugin und von dort zum Loxone-Miniserver übertragen. Vom Miniserver kann sich das W4L-Plugin die Werte abholen, um sie per Cloud Weather Emulator / Webseite innerhalb Loxone ansprechend zu visualisieren. Entsprechende Namen für die erforderlichen virtuellen Eingänge sind in der Loxone-Vorlage bereits enthalten:

w4l_cur_hu
w4l_cur_pr
w4l_cur_prec_1hr
w4l_cur_prec_today
w4l_cur_sr
w4l_cur_tt
w4l_cur_uvi
w4l_cur_w_dir
w4l_cur_w_gu
w4l_cur_w_sp
w4l_cur_w_ch
w4l_cur_tt_fl
w4l_cur_dp
w4l_cur_hi

Durch „Patchen“ der W4L-Installation kann eine nahtlose Integration von FOSHKplugin in W4L ermöglicht werden.
Dabei entfällt das Hin- und Hergeschiebe der Messwerte; W4L fragt FOSHKplugin bzgl. der lokalen Wetterdaten ohne Umwege direkt ab.
Bei jedem Abruf der Wetterdaten via W4L werden die gerade aktuellen Daten der lokalen Wetterstation von W4L lokal zu Loxone übertragen. Dies erfolgt automatisch und ohne Konfigurationsänderung, wenn bisher W4L bereits im Einsatz war, da die bereits vorhandenen Variablen nur mit den lokalen Werten der Wetterstation überschrieben werden.
Der Loxone-Grabber innerhalb von W4L (und das Anlegen etwaiger Transfervariablen w4l_irgendwas) ist dann nur noch für spezielle Fälle nötig.

Bei aktiviertem FOSHKplugin reicht ein einmaliger Aufruf der URL

http://loxberry-ip:port/FOSHKplugin/patchW4L

um folgende Schritte auszuführen:

  • trägt Grabber-Daten in weather4lox.cfg ein (SERVER\LOCALGRABBER=1, SERVER\LOCALWUGRABBER=0 sowie LOCAL\URL=url und WULOCAL\URL=url)
  • erzeugt ein Backup von vorhandener w4l/bin/fetch.pl –> w4l/bin/fetch.pl.foshkbackup
  • erzeugt in vorhandener fetch.pl von W4L zwei neue Blöcke zum Aufruf der Scripte grabber_local.pl und grabber_wu-local.pl
  • kopiert aus bin\ die Scripte grabber_local.pl und grabber_wu-local.pl nach w4l/bin/

Auf Konsolenebene kann dies aber auch durch sudo -u loxberry foshkplugin.py -patchW4L bewerkstelligt werden.

Fortan erscheinen die lokalen Wetterdaten sowohl im Loxone-Emulator als auch auf der durch W4L erzeugten Wetterseite. Ebenso werden alle W4L-Variablen mit Werten der lokalen Wetterstation ersetzt.
Zu beachten ist, dass Loxone nur einmal pro Stunde seine Wetterdaten abruft, was sich von außen leider nicht ändern lässt.
Die von W4L generierte Wetterseite ist jedoch - je nach konfigurierten Intervall - aktuell(er).

Weiterhin gilt, dass W4L die lokalen Daten nur in dem Intervall abruft und somit aktualisiert, in dem es die Wetterdaten von Darksky oder Weatherbit abholt. Dieser Intervall darf seitens der Betreiber dieser Wetterdienste jedoch nicht beliebig kurz sein. Wenn aktuellere Daten in Loxone notwendig sind, sollten daher die übertragenen UDP-Werte von FOSHKplugin genutzt werden.

Ich habe hier einen W4L-Intervall des Abrufs der Wetterdaten von DarkSky durch W4L von 5 Minuten konfiguriert - somit werden alle 5 Minuten die lokalen Wetterdaten dem Loxone-Miniserver zur Verfügung gestellt und ich bleibe im Limit für die erlaubten Abfragen bei DarkSky.

Nach einem Update von Weather4Loxone muss dieses Patchen erneut durchgeführt werden da die „gepatchte“ Version von fetch.pl mit einer neuen Version des Scriptes vom W4L-Plugin überschrieben wird!

Deinstallation des „Eingriffs“ mit:
sudo -u loxberry foshkplugin.py -recoverW4L oder http://loxberry-ip:port/FOSHKplugin/recoverW4L

  • trägt Grabber-Daten in weather4lox.cfg aus (SERVER\LOCALGRABBER=1, SERVER\LOCALWUGRABBER=0 sowie LOCAL\URL=url und WULOCAL\URL=url)
  • löscht grabber_local.pl und grabber_wu-local.pl in w4l/bin/
  • benennt die Backup-Datei w4l/bin/fetch.pl.foshkbackup in w4l/bin/fetch.pl um

Achtung!
Der Plugin-Deinstallationsprozess der aktuellen LoxBerry-Version löscht zwar die Dateien w4l/bin/grabber_local.pl und w4l/bin/grabber_wu-local.pl und bennennt die w4l/bin/fetch.pl.foshkbackup wieder nach w4l/bin/fetch.pl um, trägt jedoch im weather4lox.cfg die erzeugten Konfigurationdsdaten nicht wieder aus! Das ist zwar unkritisch - widerspricht aber jeglicher Perfektion.
Daher bitte vor der eigentlichen Deinstallation des Plugins VORHER ein recoverW4l über bash oder den Aufruf des dafür vorbereiteten Links starten.
Mit einer zukünftigen Version von LoxBerry sollte es möglich werden, dass die interne Deinstallationsroutine des Plugins vor der eigentlichen Deinstallation des Plugins ablaufen kann. Das Plugin ist bereits darauf vorbereitet.

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 v0.09 (erscheint demnächst) 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 LoxBerr-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.