Even if the core task of the program is actually the conversion of incoming data from a weather station in WU or Ecowitt format to UDP for any target like Loxone Miniserver, it does offer a few functions that go beyond this.
This plugin connects various weather stations and sensors from the manufacturer Fine Offset Electronics (FOSHK) to a Loxone Miniserver or any other smarthome-system via UDP.
Actually all weather stations are supported where a custom server can be set up as a destination for transmitting the data in WU or Ecowitt format. If you can change or redirect the DNS server for the weather station, it works with any weather station which send it's data to Weather Underground or Ecowitt.
The "custom server" for the GW1000 (or HP2551C or WH2910) is configured remotely by FOSHKplugin itself. For other weather stations you have to configure the custom server via WS View or the manufacturer's configuration program.
Version 0.08 - 27.06.2021
- minor bugfixes
- extended debug options in the Loxone version (service.sh support and service.sh supzip - for automatic collection of debug data.)
- Better logging in the send log: the number of the forward is also logged in order to be able to find faulty blocks in the config file more easily
- Adaptable logging level - less logging with a view to the essentials
Logging can now be fine-tuned via Logging\LOG_LEVEL in the config file - with
- ALL, as before, all lines are logged
- INFO - all lines except ERROR, WARNING, INFO and OK are hidden
- WARNING - all lines except ERROR and WARNING and OK are hidden
- ERROR - only lines with ERROR and OK are output
For reasons of compatibility, ALL is preset - however, I recommend LOG_LEVEL INFO - so everything that was not successful is logged
- LOG_LEVEL can also be adjusted during operation via http://ipaddress:port/FOSHKplugin/loglevel=[ALL, INFO, WARNING, ERROR] - however, the value set in the config file applies again after a restart
- with Logging\LOG_ENABLE = False, logging can be switched off globally without making changes to the log file names
- more flexible firmware update check (duplicate options for broken Ecowitt-file)
- Increased transmission security with http(s) and ftp(s) forwards through transmission repetition:
3 attempts are now made to deliver the data; the second attempt takes place after 5 seconds and the third after another 10 seconds
however, it is not repeated if the return code indicates a local error (400..499)
- Support of forward via MQTT for both metric values (FWD_TYPE = MQTTMET) and imperial values (FWD_TYPE = MQTTIMP)
requires python3-setuptools and paho-mqtt (will be installed automatically)
MQTT broker is defined via the FWD_URL: ipaddress:port@hierarchy%prefix - topic name is the name of the key
- Support of the wetter.com API (still under weewx pseudonym)
- Support of the weather365.net API
- Support of the wettersektor.de API
- Possibility to export the data as realtime.txt or clientraw.txt per file, http(s), ftp(s) with FWD_Typ = REALTIMETXT or CLIENTRAWTXT (experimental)
the FWD_URL specifies whether the file should be posted via http(s), transferred via ftp(s) or stored as a file in the filesystem
a realtime.txt-compatible string can be queried and saved via http://ipaddress:portnumber/realtime.txt
a clientraw.txt-compatible string can be queried and saved via http://ipaddress:portnumber/clientraw.txt
- Storage as WSWin-compatible CSV file wswin.csv for automatic import by WSWin via file monitoring
the storage location must be readable (if necessary, writable) for Windows computers via the Samba share
the import can be done automatically and irregularly by WSWin - WSWin simply reads in all lines that have not yet been processed
no X-CSV is necessary
- Export option as text or CSV file with included key names per file, http(s) and ftp(s) with FWD_TYPE = TXTFILE or CSVFILE - existing files are overwritten; these formats can also be requested via http: ipaddress:port/FOSHKplugin.txt or .csv
- export as a text file with raw keys/values with FWD_TYPE = RAWTEXT - existing file will be overwritten on each interval
- separator for output via /STRING and /RAW can now be %20 (as a space) or a whole word in addition to a single character
- Calculation of the cloud height cloudf (in feet) or cloudm (in meters) implemented, Coordinates\ALT = True in the config file with height above sea level in meters required - requires EVAL_VALUES = True
- Sunshine duration sunhours implemented - shows the duration of the daily sunshine duration in hours (solarradiation >= 120W/m²) - requires EVAL_VALUES = True
- sunhours, co2 and leafwetness (for the coming WN34) supported in meteotemplate; sunhours also with Awekas-API
- Coordinates can be configured under Coordinates\ALT, LAT, LON
ALT is used to determine the cloud height (spread * 122)
LAT/LON are only used for transferring to the export formats Awekas-API, clientraw.txt and Weather365.net
- Config\UDP_MAXLEN (default = 2000) defines the maximum length of a UDP datagram
If the length of the packet to be sent is greater than specified, the packet is divided into several datagrams, each of which has an approximate length UDP_MAXLEN and contains the identifier SID=FOSHKweather at the beginning of each datagram.
The original line is separated in such a way that the key=value assignment is retained - the separation always takes place BEHIND UDP_MAXLEN the next time a space is found.
Values that contain spaces are surrounded by double quotation marks so that there is a possibility of parsing on the UDP server side.
Example neighborhood="New York City" for a value with spaces - but neighborhood=Berlin (without spaces)
- With Warning\CO2_WARNING = True a warning (UDP, http, log, Pushover) can be activated if the CO2 value is higher than the one configured under Warning\CO2_WARNLEVEL
- With Config\UDP_STATRESEND = n, a cycle time (n seconds) can be defined in which the warning messages are sent regardless of status changes
- Changes in ptrend1 and ptrend3 - if the air pressure rises or falls rapidly (+0.7 / -0.7 or +2/-2), a trend of 2 or -2 is output
- ptrend1, pchange1, ptrend3 and pchange3 are now also forwarded via Ecowitt (Type = EW) if EVAL_VALUES = True
pchange1 and pchange3 contain the difference between the current value and the value from 1 or 3 hours ago in inHg
- with CSV\CSV_DAYFILE = /path/to/filename.csv the creation of a additional daily CSV /path/to/filename.csv with the min/max values of the day and some day-wide calculations will be activated
- Parameters bool, status, units and separator are now possible for all requests (as far as it makes sense - so not e.g. with RAW)
- Query /JSON extended - generates a JSON with numerical boolean values when called with the parameter bool - can be extended with minmax, status and units
Example: http://ipaddress:portnumber/JSON?minmax&status&bool outputs the last data record with numerical boolean values 1/0 instead of strings True/False
- MQTTMET/MQTTIMP-Forward now outputs numerical boolean values (0/1 instead of False/True)
- InfluxDB support: both via pull (as JSON via telegraf) and natively (FWD_TYPE = INFLUXMET/INFLUXIMP) integrated
the database is specified in the FWD_URL line: FWD_URL = http://192.168.15.237:8086@Database creates a database Database on 192.168.15.237:8086
and transmits the data unencrypted at the configured interval; username and password can be transferred via FWD_SID and FWD_PWD
- Config-options Config\REBOOT_ENABLE and Config\RESTART_ENABLE to enable reboot of weather station and restarting the FOSHKplugin service (default: False = forbidden) on request
requests are http://ipaddress:port/FOSHKplugin/rebootWS to reboot the configured weather station
and http://ipaddress:port/FOSHKplugin/restartPlugin to restart the FOSHKplugin service
- New forward type RAWTEXT enables the storage of incoming values from the weather station as a text file locally in the file system and remotely via http(s)/POST and ftp(s)
- Firmware update status (updatewarning) is now updated immediately after receipt of new data from the updated weather station
- slightly improved installation routine generic-FOSHKplugin-install.sh - clarification of UDP server and port, interception of incorrect URL file names during update
- Adjustment for WH6006 (dateutc with "%3A" instead of ":", indoorhumidity)
Version 0.07 - 19.02.2021
- Fixed bug with IGNORE_EMPTY: UDP sending to Loxone did not work if IGNORE_EMPTY was deactivated
- Log output: "custom mode" renamed to "custom server"
- now sends the text OK to the sender in addition to the response code 200 when the data is received via http
- Bugfix: known issue regarding socket problems and Chrome hopefully solved - the socket should be released again after a 5 seconds timeout
- Troubleshooting thunderstorm warning (not every thunderstorm was reported)
- Bugfix: Program error with PM2.5 values above 500 fixed
- Bugfix: Handling of %20 in the dateutc field (e.g. from the WH2600 LAN)
- Config parsing made more robust with regard to Boolean values (mkBoolean)
- Forwards can now be activated/deactivated (FWD_ENABLE = True/False) and commented (FWD_CMT) in the config file
- Multi-instance: several instances of FOSHKplugin can now be operated in parallel - in different directories
- Support of the Ambient Weather format for incoming messages as well as forward (AMB/RAWAMB)
in the absence of yearlyrainin, totalrainin is used and in the absence of rainratein, hourlyrainin is used
- Forward input data in Weathercloud format via GET as type WC possible
- Forward input data in Meteotemplate format via GET as type MT possible
- Forward input data in Awekas format via GET as type AWEKAS possible
- support of WH45 (PM25, PM10, CO2 sensor) with additional AQI and CO2-level calculation
- Preparation for the new leaf wetness sensor WN35
- Thunderstorm warning: number of flashes (lcount) and min. and max. Distance (ldmin and ldmax) are transmitted
- Improvement with regard to TimeOut behavior; http now has a TimeOut of 8 and UDP of 3 seconds
- Ecowitt-Forward: if totalrain is available - but no yearlyrain, yearlyrain is automatically set with the value of totalrain
- New configuration option Export\OUT_TIME = True sets the time stamp of incoming messages from the weather station to the time of receipt
- fake mode now also activated for incoming messages in WU and Ambient Weather format
- an automatic restart in the event of missing data from the weather station can be configured via Warning\WSDOG_RESTART
- important status messages can now also be sent as push notification via pushover (update, sensor, watchdog, battery, storm and thunderstorm warnings)
- generic: display of all detected weather stations during installation via generic-FOSHKplugin-install.sh (-scanWS)
- Average value calculation (with EVAL_DATA = True) implemented for wind and wind direction, outputs windspdmph_avg10m, winddir_avg10m
- max gust calculation (with EVAL_DATA = True) implemented: windgustkmh_max10m
- Output of the lux value (solarradiation * 126.7) as field brightness (with EVAL_DATA = True)
- with Logging\IGNORE_LOG you can exclude lines from the logging in the standard log (comma-separated list of search words) - for example crondaemon
- With FWD_EXEC, a script can be specified for each forward that starts with the output string as a parameter and the last output line is used as the new output string for sending
- Value request: an http request http://ipaddress:portnumber/getvalue?key=[key] outputs the value for the key [key], whereby the key may be the RAW key as well as the converted key name
Example: curl http://192.168.15.236:8080/getvalue?key=windspeedmph outputs the value "1.34" of the wind speed mph key
in connection with FWD_EXEC, data from other instances can be queried and integrated
- In addition to the http-GET query /CSV and /CSVHDR with dynamic fields, /SSV and /SSVHDR with static fields are now also supported, based on the field description in CSV\CSV_FIELDS
thus the order of the fields is fixed; empty fields (with no content e.g. in the event of a sensor failure) are not skipped but are output as ""
- If Export \FIX_LIGHTNING is active (default), the last known values for lightning and lightning_time will be used as input data if the incoming values are missing
since the lightning data in the GW1000/DP1500 are not stored in the NVRAM, these values are lost when the device is restarted
- If Warning\LEAKAGE_WARNING is activated, warnings are issued via log, UDP, http or pushover (leakwarning) when a leak is detected
- a backup of foshkplugin.conf is created at every successful start (foshkplugin.conf.foshkbackup)
- Overview page http://ipaddress:portnumber outputs with "?units=e" values in American system of units (inch, mph, ...) ; can be combined with "/status"
Version 0.06 - 02.08.2020
- Revision of the storm warning function, output of air pressure trend 1h / 3h and value of change of air pressure 1h / 3h
- WU-Forward from AqPM2.5 if PM-sensor is present (only pm25_ch1 is forwarded!)
- AQI calculation activated with EVAL_DATA = True and existing DP200/WH41/43
- Experimental: Forward the PM2.5 value to luftdaten.info as type LD, the ID must be entered under FWD_SID in the config file
- Battery warning via log and UDP implemented; if the supplied batt value falls below an internally defined threshold, a warning is issued
- Fixed issue with output of the name of the sensor again supplying data (SENSOR_MANDATORY)
- The status of warnings for storms, thunderstorms, sensors and batteries are stored temporarily and are therefore retentive
- WU-Forward / JSON renaming from solar radiation to solar radiation
- WU-Forward / JSON support for soil moisture sensors
- WU-Forward: keys with empty value are not transmitted
- WU-Forward: Upload of dewptf (was dewpt) and rainin (was rainratein) fixed
- new formula for dew point calculation (dewpoint) active (requires math)
- now sends a response code 200 to the sender when http data is received
- UDP message for time at wswarning changed from "time:" to "time="
- for all get / post actions: check the return value 200..202 -> ok (was 200 only)
- Text errors in help fixed
- Update of generic-FOSHKplugin-install.sh; Fixed a bug when creating the conf file
- Forward of the input data possible without conversion via UDP as type RAWUDP
- Forward of the input data possible without conversion via EW / POST as type RAWEW
- Forward of output data in CSV-format via http/POST as type CSV
- Forward of input data without conversion via http/POST as type RAWCSV
- Forward of output data as for Loxone to another target/network via UDP - with additional status
- Forward timeout handling adjusted (now 3 seconds)
- Output language can be set via LANGUAGE = DE / EN etc. in the config file
- Plugin can be terminated with a UDP command and requested to send the current status (System.shutdown, Plugin.getStatus)
- debug mode enable/disable via UDP-command Plugin.debug=enable/disable
- Separator selectable on http-GET with /RAW
- new http-GET command /STRING to get the input-line via http with selectable separator
- status messages can now be queried in /JSON and when outputting via /STRING or /UDP
- simple authentication via AUTH_PWD implemented; data and requests are only accepted via http if the specified password is contained in the URL (hint: use the PASSKEY-string in Ecowitt-mode)
- hide PASSKEY-value in Log-Files if AUTH_PWD activated
- Handling of unnecessary quotation marks in the config file adjusted
- Preparation for upcoming soil/water temperature sensor WH34 (tf_chNc, tf_battN - where N = 1..8)
- Status also available via http/GET: http://ipaddress:portnumber/FOSHKplugin/status outputs status wswarning, sensorwarning, batterywarning, ...
- Fake mode implemented: Values of an indoor sensor (WH31 / DP50) can be output as values of an outdoor sensor WH32 (temperature, air humidity)
- Updatewarning implemented, reports an available update for the weather station via log/UDP and possibly via http
- For thunderstorm warnings, tswarning is now output as status instead of tstormwarning - Attention! This affects all outputs both via UDP and via http!
Version 0.05 - 26.04.2020
- Sturmwarnung bleibt für 60 Minuten nach letzter Grenzwertunter-/überschreitung aktiv; Zeitraum kann via STORM_EXPIRE im Config-File angepasst werden
- Übermittlung des UV-Wertes im WU-Format angepasst, nun in Großbuchstaben UV= statt uv=
- Patch-Funktion für Weather4Loxone ist nun unabhängig von der genutzten Weather4Loxone-Version (vorhandene fetch.pl wird nicht überschrieben sondern angepasst)
Version 0.04 - 20.02.2020
- default-config angepasst - Kommentare hinter Block nicht zulässig!
- verbesserte Buttons (CSS) - Schiebeschalter nun grau bei "off" und grün bei "on"
- erweiterte CGI-Debug-Funktion; default: off; enable mit $myDebug = 1 in der index.cgi
- myDebug für zusätzliche Debug-Informationen auch im Python-Programm implementiert (default: False)
- Beschreiben der Wetterstation via WS-Set sollte nun (endlich) vollumfänglich funktionieren
- Id & Key in den Einstellungen der Wetterstation werden ignoriert und nicht vom Plugin überschrieben
Version 0.03 - 18.01.2020
- USE_METRIC wieder funktional (jetzt also auch imperiale Werte per UDP und CSV möglich)
- weitere mögliche Probleme beim Setzen der Wetterstationsparameter via WS-Set behoben (Path wird nun immer auf defaults gesetzt)
- Prüfung der nutzbaren LoxBerry-Ports (http/udp) optimiert
- Kommunikation mit der Wetterstation überarbeitet - nun jeweils 5 Versuche bei Lesen und Schreiben
- besseres Logging/Debugging bei Fehlern bei Set-WS; "buntere" und besser parse-bare Log-Files; ### entfernt
- generic: conf-File - Vorlage und Hilfstexte überarbeitet
- Ignorierliste Forward\FWD_IGNORE für Forwards eingebaut: definiert - kommasepariert - Felder, die NICHT verschickt werden sollen
- Forward\FWD_TYPE=UDP/EW/RAW für http-Forward der Werte (UDP-Ausgabezeile) an andere Ziele als WU eingeführt
- nun bis zu 10 Forwards mit unterschiedlichen Einstellungen möglich (aktuell nur im Config-File zu pflegen: Forward-1..9 analog zu Forward)
- Watchdog: kommen seit 3*eingestelltem Intervall keine Werte von der Wetterstation, Fehler melden!
es erfolgt EINE Warnung und bei erneuter Übermittlung der Wetterstation eine Entwarnung im Log sowie per UDP:
SID=FOSHKweather wswarning=1 last=346611722
SID=FOSHKweather wswarning=0 last=346616459
standardmäßig aktiv; kann im Config-File deaktiviert werden: Warning\WSDOG_WARNING=False
Intervall kann im Config-File eingestellt werden: Warning\WSDOG_INTERVAL=3
Warnung auch in Loxone-Vorlage enthalten
- Alarm senden (Log, UDP) wenn Sensor (auch mehrere) keine Daten liefert (etwa weil Akku/Batterie leer)
SID=FOSHKweather sensorwarning=1 missed=wh65batt time=347196201
SID=FOSHKweather sensorwarning=1 back=wh65batt time=347196201
aktuell nur im Config-File zu pflegen:
Warning\SENSOR_WARNING=True sowie Warning\SENSOR_MANDATORY="wh65batt"
- Sturmwarnung: fällt oder steigt der Luftdruck um mehr als 1.75 Hektopascal in einer Stunde, erfolgt eine Warnung vor Starkwind/Sturm
es erfolgt EINE Warnung und bei Entspannung des Luftdrucks eine Entwarnung im Log und per UDP:
SID=FOSHKweather stormwarning=1 time=346611722
SID=FOSHKweather stormwarning=0 time=346616459
standardmäßig aktiv; kann im Config-File deaktiviert werden: Warning\STORM_WARNING=False
WarnDiff kann im Config-File eingestellt werden: Warning\STORM_WARNDIFF=1.75
Warnung auch in Loxone-Vorlage enthalten
- Vorbereitung Wassersensor WH55 und Blitzsensor WH57 (noch unklar ob lightning_time = timestring oder unixtime!)
- preupgrade-Script: Upgrade-Verzeichnisse werden nun auch ohne Elternverzeichnis angelegt (mkdir -p)
- preuninstall-script entfernt; Deinstallation erfolgt bei LoxBerry ab v188.8.131.52 im uninstall-Script
- Web-Oberfläche: Anzeige der Versionsnummer eingebaut (um Nachfragen zur verwendeten Version im Fehlerfall zu minimieren)
- UDP-Versand an das Zielsystem lässt sich mit UDP_ENABLE=False abschalten
- Ignorierliste für den UDP-Versand eingeführt: Config\UDP_IGNORE (nur im Config-File zu pflegen)
Version 0.02 - 28.12.2019
- ### aus FWD-Log-Nachricht entfernt
- Umrechnung temp1f in temp1c für Innensensor auf Kanal 1 implementiert
- Timeout bei sendReboot, setWSconfig und getWSINTERVAL von 1 auf 2 Sekunden erhöht (somit sollte WS-Set sicherer funktionieren)
- Probleme beim Setzen der Wetterstationsparameter via WS-Set behoben (Id & Key werden - wenn nicht schon vorhanden - gesetzt)
- Umstellung der LoxBerry-Versionsnummerierung damit zukünftig die Auto-Update-Funktion greifen kann
Version 0.01 - 15.12.2019
- erste öffentliche Version
- accepts http messages from a weather station (DP1500, GW1000, HP1000SE Pro, Sainlogic 7 in 1, ELV WS980WiFi, Eurochron EFWS 2900, ???) locally in WU or Ecowitt protocol via network
- supports custom server on stations from Ambient Weather
- does not require cloud services or internet connection
- sends the converted metric or imperial values via UDP to any host or via broadcast in the network
- is able to feed a MQTT broker
- connection to any database system possible via telegraf
- direct support of InfluxDB
- saves the converted or imperial data sorted and / or extracted as CSV
- enables forwarding to up to 50 servers that are not supported by the weather station itself (e.g. Awekas, PWSWeather, Windy or Luftdaten.info, but you could also use WU in a different interval)
- can feed Meteotemplate, Weathercloud, wetter.com and weather365.net
- may export incoming data to realtime.txt and clientraw.txt
- can serve as an Ecowitt relay (forward in Ecowitt protocol) for Personal Weather Tablet, weewx, PWS Dashboard and any other program expecting Ecowitt-data
- can forward incoming WU and Ecowitt messages via UDP - also as a broadcast - as they come in
- is able to convert between WU, Ecowitt and Ambient Weather format (within limits)
- can answer queries in WU protocol
- Integrated web server provides the last data record in http, UDP, CSV, RAW and JSON format as well as a simple website
- various watchdogs and warnings can be configured (battery, connection weather station and sensors, storm, thunderstorm, CO2-alert, leakage-alert ...)
- calculates some extra data (dew point, feelslike, AQI, ...)
- allows to gather specific values via http (getvalue)
- it creates an import file for the automatic import of the data into WSWin
- provides the Weather4Loxone plugin with the measured values from local weather station
- No additional software is required (WS View only for teaching new sensors or for configuring the standard forwarding services)
- also works without Loxone / LoxBerry as a systemd service on Linux-systems (a Raspi should be powerful enough) for connecting other systems ( generic-FOSHKplugin.zip )
- is free of charge
The target system (e.g. Loxone Miniserver) hardly needs resources with this solution; it does not have to fetch any data or convert values - the plugin automatically sends the already converted data to the Miniserver whenever new measured values arrive from the weather station.
In addition, the measured and partly calculated values are also available to any other services via various interfaces and forwards.
FOSHKplugin acts as a web server and returns different values depending on the requested URL.
In addition to "updateweatherstation" to accept a incoming data record in WU format (Weather Underground protocol) the integrated web server processes other http call parameters in GET: http://serverip:port/[URLpath]
|/CSVHDR||the field names (the header) of the last data record are output as CSV semicolon separated. If units=e is also specified, the fields for the imperial values are output.|
|/CSV||all reported metric values of the last data record are output as CSV semicolon separated (units=e supplies the imperial values)|
|/SSVHDR||the field names (the header) configured in CSV\CSV_FIELDS are output as CSV semicolon separated.|
|/SSV||all reported metric values of the last data record are output as CSV semicolon separated with fixed asignment based on CSV\CSV_FIELDS (units=e supplies the imperial values)|
|/UDP||the last UDP string is output via http; with additional ?status in URL the output will also include all status.|
|/RAW||the data set supplied by the weather station is output unchanged via http; separator can be changed with separator=Z, where Z is a single character|
|/STRING||output the converted data record and the current status separated with ";" via http; by adding units=e in the URL will output with the imp. values; separator can be changed with separator=Z, where Z is a single character. With additional ?status in URL the output will also include all status.|
example: http://ipadresse:port/STRING?units=e?separator=, will output imp. values with comma as separator
|/JSON||output via http as JSON (metric by default; by adding units=e in the URL, the output is made with the imp. values). With additional ?status in URL the output will also include all status (wswarning, sensorwarning, stormwarning, ...).|
|/realtime.txt||output a realtime.txt (Cumulus) file|
|/clientraw.txt||output a clientraw.txt (Weather Display) file|
|/getvalue?key=[keyname]||output the value only for given keyname; any keyname is allowed (RAW, converted); if keyname not found "" wil be output - usefull for processing values via curl or wget|
|/||simple website with the current metric data in tabular form - status includes all status-messages; additional units=e shows all values in imperial|
|/FOSHKplugin/state||status of the service; if active: "running"|
|/FOSHKplugin/status||status of the service, watchdog, missing sensor, battery, for storm, thunderstorm, ... as a simple webpage|
enable debug mode for extended messages in the log file
disable debug mode for extended messages in the log file
temporarily enable push notification via Pushover (configuration must exist!)
temporarily disable push notification via Pushover
|/FOSHKplugin/patchW4L||"Patch" a Weather4Loxone installation (copy local grabber scripts and activate local retrieval by W4L)|
|/FOSHKplugin/recoverW4L||Restore the original Weather4Loxone configuration before "patching"|
|/FOSHKplugin/rebootWS||reboot the connected weather station (Config\REBOOT_ENABLE has to be True)|
|/FOSHKplugin/restartPlugin||restart the running FISHKplugin service (Config\RESTART_ENABLE has to be True)|
|/observations/current/json/units=m||Feedback of a WU-compatible data record with metric values (°C, kmh, mm, hPa)|
|/observations/current/json/units=e||Feedback of the WU-compatible data record with imperial values (°F, mph, in, inHg)|
Feedback of a W4L-compatible current.dat:
If you have defined a PASSKEY in config-file to only accept incoming http-request containing this PASSKEY you always have to add something like ?auth=[PASSKEY] to the URL. The only exception is the call of FOSHKplugin/state - this works even without authentication. This is useful if FOSHKplugin should not work in a secure local network but directly on the Internet - for example on a root server. Without this security mechanism, anyone could otherwise submit data or query or change states. Basically, however, I advise against operating on "unsafe" hosts that are freely available on the Internet.
In POST mode, weather station data is accepted in Ecowitt format if the keyword "report" is contained in the URL. Since in Ecowitt format significantly more values can be transmitted from the weather station (such as the battery values of the sensors), I recommend this operating mode (which is also set by the plugin for WS-Set).
generic-FOSHKplugin.zip (current stable version v0.08)
# create a local directory
# sudo mkdir /opt/FOSHKplugin
# change into the created directory
# cd /opt/FOSHKplugin
# get the current version of the plugin via wget
# wget -N http://foshkplugin.phantasoft.de/files/generic-FOSHKplugin.zip
# or use a local zip-file
# unpack ZIP-File
# unzip generic-FOSHKplugin.zip
# Allow execute right for generic-FOSHKplugin-install.sh (this script)
# chmod u+x generic-FOSHKplugin-install.sh
# Run generic-FOSHKplugin-install.sh (this script)
# sudo ./generic-FOSHKplugin-install.sh --install
metric units - USE_METRIC:
If activated, the values for UDP dispatch and CSV export delivered by the weather station in US units are converted directly by the plugin
skip empty values - IGNORE_EMPTY:
When activated, values -9999 coming from the weather station may not be sent to the target machine via UDP
use Loxone time - LOX_TIME:
This switch determines whether the UTC time should be converted to the Loxone time. When activated, an additional field loxtime is added in Loxone-compatible time format (seconds since 01/01/2009).
optional calculations - EVAL_VALUES:
When activated, the values for dew point, wind chill temperature, heat index and perceived temperature and - if a particulate matter sensor DP200 / WH41 / WH43 is available - the current AQI value and its 24-hour average are calculated from the available measured values and those coming from the weather station Data for export processing (UDP, WU, CSV, W4L, ...) added. Values already coming from the weather station may NOT be overwritten. If the storm warning is activated, the air pressure trend and the change in air pressure are also calculated (for the last hour and for the last 3 hours).
optional elements - ADD_ITEMS:
appends a string with static values to the raw data line coming from the weather station; any existing variable names with the same name are overwritten. Useful to pass on a few fields (such as geolocation: lat / lon / elev or location: neighborhood) via UDP / WU / CSV / W4L etc. These fields go through the entire export processing and therefore appear in all output formats - except RAW-exports of course. This function can also be used to exclude values from the weather station from further processing. To do this, an empty value must be assigned to a variable (ie: &variable3=&variable4=value4) and "skip empty values" must be activated.
Are very useful for commissioning and in the event of problems. However, you should consider whether it is really sensible to keep a permanent log. If an SD card is used as the storage medium, the SD card will eventually be written down.
Especially the export log - if a very short interval is set - can quickly become very large, because for every message coming from the weather station - depending on the configuration - an entry for UDP, forwarding (FWD) and CSV is also generated.
To deactivate a specific log file, simply remove the name of the respective file.
From v0.08 on it is possible to switch logging on and off globally via the switch in the config file Logging\LOG_ENABLE = True/False (default: True).
Forwards - Forward-1..50:
There is only one external destination for sending via "Customized Upload" in the configuration of a weather station. Since we are already using this for FOSHKplugin, you can set a forwarding to an additional service (such as Awekas) here. The plugin currently supports 50 forwarding destinations via the config file.
From v0.07 you can enable/disable a Forward through FWD_ENABLE = True/False. In this way, all settings are retained, even if the forward is not currently required. FWD_ENABLE = False completely deactivates this forward until it is activated again with FWD_ENABLE = True.
For your own notes (for example what this forward is actually intended for) there is FWD_CMT, in which any string can be stored permanently after the equal sign.
When specifying the URL, please note that only the measured values are added by the plugin. Any authentications or update commands must therefore already be entered here.
For an upload to Weather Underground (which is of course also possible directly via the weather station), such a line would look like this:
I successfully tested the delivery to the services Awekas, Windy and PWSWeather:
URL for Awekas:
URL for Windy:
URL for PWSWeather:
Other WU-compatible services should also work.
If the field remains free, no forwarding takes place.
"FWD_TYPE" defines the format in which the forwarded messages are to be sent to the weather station.
The WU format should be selected for WU-compatible servers. For other scenarios there is also the UDPGET format, in which the possibly converted metric values are sent as with UDP (but not separated by spaces but by html-conforming "&"). Virtual http inputs should be possible with this.
The EW format is experimental. Incoming messages from the weather station are converted into the Ecowitt format and forwarded in the Ecowitt protocol via HTTP mail. This means that other hosts can also be operated using the Ecowitt protocol (relay).
With type RAW, the incoming data is forwarded via http-get without conversion. In order to send the original RAW string via POST without any extension in the EW format, the RAWEW type is recommended. The RAW data can also be sent via UDP via RAWUDP. Destination-ip: destination-port must then be specified as FWD_URL. If you need to send the output data to another destination via UDP you may use the FWD_TYPE UDP. The destination address and port are defined via destination-ip: port as FWD_URL.
The values of an existing particulate matter sensor DP200 / WH41 required for the luftdaten.info service can be sent via type LD:
URL for Luftdaten:
The sensor ID required for registration must be entered in the config file under FWD_SID. The interval for sending the particulate matter sensor values should be configured to 150 seconds (FWD_INTERVAL = 150 in the config file). In addition to the PM2.5 value, the service also expects the PM10 value (which the DP200 / WH41 particulate matter sensor cannot deliver). Therefore, the plugin sends a dummy value of 1 for PM10.
Overview of the different forward options:
|WU||WU, EW, AMB||GET||Weather Underground (WU-->WU or EW-->WU)|
|RAW||WU, EW, AMB||GET||like input (WU-->WU or EW-->EW)|
|UDPGET||WU, EW, AMB||GET||like output to Loxone with header and possibly conversion, however, URL-compatible with "&" instead of spaces|
|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||Wetterarchiv/wetter.com (API)|
|EW||WU, EW, AMB||POST||enhanced Ecowitt (WU-->EW or EW-->EW)|
|RAWEW||WU, EW, AMB||POST||untouched Ecowitt (EW-->EW or WU-->EW)|
|LD||WU, EW, AMB||POST||Luftdaten.info-Format (only PM2.5, PM10, Temp, Humidity, rel. Pressure, abs. Presssure)|
|CSV||WU, EW, AMB||POST||like output to Loxone with possibly conversion, with semicolon as separator instead of spaces but without header|
|RAWCSV||WU, EW, AMB||POST||like input (WU-->WU or EW-->EW), with semicolon as separator instead of spaces but without header|
|WEATHER365||WU, EW, AMB||POST||weather365.net API|
|UDP||WU, EW, AMB||UDP||like output to Loxone with header and possibly conversion via UDP (FWD_URL = destination:port)|
|RAWUDP||WU, EW, AMB||UDP||like input-Format but transmission via UDP (EW→EW via UDP or WU→WU via UDP)|
|REALTIMETXT||WU, EW, AMB||various||sends a realtime.txt (Cumulus export file) via http(s)/POST or ftp(s) to remote destinations or save the file locally in the filesystem|
|CLIENTRAWTXT||WU, EW, AMB||various||sends a clientraw.txt (Weather Display export file) via http(s)/POST or ftp(s) to remote destinations or save the file locally in the filesystem|
|CSVFILE||WU, EW, AMB||various||sends a CSV-file with current data only via http(s)/POST or ftp(s) to remote destinations or save the file locally in the filesystem|
|TXTFILE||WU, EW, AMB||various||sends a TXT-file with current data only via http(s)/POST or ftp(s) to remote destinations or save the file locally in the filesystem|
|RAWTEXT||WU, EW, AMB||various||sends a TXT-file with current raw data only via http(s)/POST or ftp(s) to remote destinations or save the file locally in the filesystem|
|MQTTMET||WU, EW, AMB||MQTT||sends incoming data in metric units to a MQTT-broker|
|MQTTIMP||WU, EW, AMB||MQTT||sends incoming data in imperial units to a MQTT-broker|
|WSWIN||WU, EW, AMB||File||saves a WSWin-compatible wswin.csv in the file system, which can be read in automatically by WSWin via file monitoring|
|INFLUXMET||WU, EW, AMB||InfluxDB||sends metric values to a InfluxDB database|
|INFLUXIMP||WU, EW, AMB||InfluxDB||sends imperial values to a InfluxDB database|
Data fields from the ignore list maintained under "FWD_IGNORE" are not sent for the relevant forward.
With "FWD_INTERVAL" an interval independent of the weather station can be configured (in seconds). If this field is left blank, it will be sent at the weather station's send interval.
Save as CSV:
The measurement results can also be saved as a comma-separated file (CSV). The storage location and the file name are specified under CSV_NAME. The problem with writing to SD cards already mentioned for log files also applies here. If necessary, a more suitable medium (such as NFS) should be selected here.
Field names for CSV - CSV_FIELDS:
All fields desired in the CSV are listed under CSV_FIELDS - separated by a separator (semicolon, comma or space).
Not all fields of a data record are worth saving in the CSV. The contents of the fields SID, PASSKEY, freq or model change very rarely.
By omitting these field names, these fields are excluded from storage. The order of the columns in the CSV file results from the order of the fields specified here.
CSV interval- CSV_INTERVAL:
Here you can define your own time interval for storing a data record in the CSV. If the field remains free, the transmission interval of the weather station is used.
The interval for the CSV and forwarding function cannot be smaller than the set transmission interval of the weather station, since data is only available for further processing when a data record is received from the weather station.
watchdog & warn-functions:
|report watchdog||WSDOG_WARNING||will warn if weather station did not report within 3 send-intervals (configurable)|
|sensor warning||SENSOR_WARNING||will warn if data for mandatory sensor (configurable list of fields e.g. wh65batt) is missed|
|battery warning||BATTERY_WARNING||will warn if battery level of all known sensors is critical (pre-defined)|
|storm warning||STORM_WARNING||will warn if air pressure rises/drops more than 1.75 hPa/hour or 3.75hPa/3hr with expiry time of 60 minutes (all values configurable)|
|thunderstorm warning||TSTORM_WARNING||will warn if lightning sensor WH57/DP60 present, count of lightnings is more than TSTORM_WARNCOUNT and distance is less or equal TSTORM_WARNDIST with expiry time of TSTORM_EXPIRE minutes (all values configurable)|
|firmware-update warning||UPD_CHECK||will warn if there's a new firmware for the weather station available|
|leakage warning||LEAK_WARNING||will warn if any WH55 reports a leak|
|CO2 warning||CO2_WARNING||reports an alarm when a WH45 reports a value above CO2_WARNLEVEL|
These warnings are issued - depending on the configuration - in the standard log file, via UDP and via pushover and can be queried via http (?status).
The rules for BATTERY_WARNING are predefined and not adjustable. A warning will be triggered if:
key = [wh65batt, lowbatt, wh26batt, wh25batt] and value = 1
key = batt and length(key) = 5 and value = 1
key = [wh57batt, pm25batt, leakbatt, co2_batt] and value < 2
key = [soilbatt, wh40batt * , wh68batt, tf_batt] and value <= 1.2 * with current hardware revision of WH40 there's no wh40batt at all
key = wh80batt and value < 2.3
and - if recognized as a Ambient Weather station:
isAmbientWeather and (batt in key or batleak in key) and value = 0
The values for outside temperature and humidity normally come from either a combination sensor (WH65, WS80) or the dedicated outside sensor WH32.
However, if neither a combination sensor nor a WH32 is available, values of any internal sensor DP50/WH31 (which should of course then be installed outside with appropriate weather protection) can be output as values ?of the external sensor.
In the config file you have to specify which key should be used for the respective value:
# exchange the keyname temp1f with tempf (or use temp2f, temp3f, ...)
# exchange the keyname humidity1 with humidity (or use humidity2, humidity3, ...)
Within FOSHKplugin, the substring "&temp1f =" is simply replaced by "&tempf =" and "&humidity1 =" by "&humidity =" when the Ecowitt line arrives from the weather station. The values themselves remain.
This setting is global and therefore affects all FOSHKplugin exports/forwards/outputs (except for RAW and RAWEW).
The weather station itself, of course, knows nothing of this - so the services configured there (Ecowitt, WU, WOW, etc.) still have no external values.
If you also want to output the values of the indoor sensor as outdoor sensor values for these services, the services within the weather station must be deactivated and carried out by FOSHKplugin instead.
Corresponding forwards must then be defined in the config file (the square brackets must not be included):
#InfluxDB metric export (use INFLUXIMP for imperial values)
After changes in the [Weatherstation] area, the new settings must be transferred to the weather station!
By calling ./foshkplugin.py -writeWSconfig, the weather station-specific values from config file are transmitted to the weather station and activated.
The names of the outgoing data points depend on the selected output system (metric or imperial). If USE_METRIC is active, the following data points are output to all configured exports (but not for format-specific forwards):
for Gateway DP1500/GW1000:
for water sensor WH55:
As output via UDP you will get this:
|SID=FOSHKweather dateutc=2020-06-01+13:35:54 loxtime=360257754 tempinc=27.0 humidityin=30 baromrelhpa=1022.59 baromabshpa=1017.51 tempc=25.1 humidity=30 winddir=273 windspeedkmh=1.43 windgustkmh=7.19 maxdailygust=18.36 solarradiation=677.62 uv=5 rainratemm=0.0 eventrainmm=0.0 hourlyrainmm=0.0 dailyrainmm=0.0 weeklyrainmm=0.0 monthlyrainmm=0.0 yearlyrainmm=206.4 totalrainmm=206.4 temp2c=23.3 humidity2=40 temp3c=24.8 humidity3=34 soilmoisture1=34 soilmoisture2=37 soilmoisture3=41 soilmoisture4=52 pm25_ch1=11.0 pm25_avg_24h_ch1=9.8 lightning_num=0 leak_ch1=0 wh65batt=0 batt2=0 batt3=0 soilbatt1=1.6 soilbatt2=1.6 soilbatt3=1.9 soilbatt4=1.9 pm25batt1=5 wh57batt=5 leakbatt1=5 dewptc=6.3 windchillc=25.1 feelslikec=25.1 heatindexc=24.4 pm25_AQI_ch1=46 pm25_AQIlvl_ch1=1 pm25_AQI_avg_24h_ch1=41 pm25_AQIlvl_avg_24h_ch1=1 ptrend1=-1 pchange1=-0.3 wnowlvl=3 wnowtxt=sonnig ptrend3=-1 pchange3=-1.42 wproglvl=3 wprogtxt="baldiger Regen"|
where you can easily pickup the required fields for further processing.
Activity and Tracker messages are event-based but also include the SID-token to state these messages are coming from FOSHKplugin:
SID=FOSHKweather stormwarning=1 time=351042104
SID=FOSHKweather stormwarning=0 time=351042135
SID=FOSHKweather tswarning=1 time=359550337
SID=FOSHKweather tswarning=0 time=359551236 start=359550337 end=359551236 last=359550330
SID=FOSHKweather wswarning=1 last=360086463 time=360086560
SID=FOSHKweather wswarning=0 last=360086567 time=360086590
SID=FOSHKweather sensorwarning=1 missed=pm25batt1 time=360169470
SID=FOSHKweather sensorwarning=0 back=pm25batt1 time=360170059
If LOX_TIME is deactivated, the Unixtime appears for all the given times instead of Loxone-time.
There are a some datapoints through which the plugin can be controlled via UDP:
|System.reboot||restart the GW1000/DP1500|
|Plugin.shutdown||shutdown FOSHKplugin - if started as a system service (systemd) it will be restarted some seconds later|
|Plugin.getstatus||requests the current status values from the plugin (running, wswarning, sensorwarning, ...)|
|Plugin.debug=enable||enable debug mode for some more information in log file|
|Plugin.debug=disable||disable debug mode|
By sending a string "SID=FOSHKplugin,System.reboot" the plugin causes the GW1000 to restart. If you send the string "SID=FOSHKplugin,Plugin.getstatus", the plugin replies with the current status values for wswarning, sensorwarning, stormwarning, ...
I do not assume any guarantees regarding the use of this software - use is at your own risk.
Never make decisions that can lead to personal injury or property damage on the basis of this software.
Warnings generated by the program (e.g. storm or thunderstorm) may occur. However, the absence of these warnings does not imply that these things are not possible.
There is a more extensive documentation, although more Loxone-specific and currently in german only: https://foshkplugin.phantasoft.de/
However, the Google translator should be helpful: https://translate.google.de/translate?hl=de&tab=rT&sl=de&tl=en&u=https%3A%2F%2Fwww.loxwiki.eu/display/LOXBERRY/FOSHKplugin
change sending interval to a shorter interval than 16 seconds
# open a console on your Linux-machine
# make sure you have Python & the libraries we need
sudo apt-get -y install --no-upgrade python3 python3-pip
pip3 install requests
# create a new dir somewhere
sudo mkdir /opt/FOSHKplugin
# change into this new dir
# get current version of FOSHKplugin
wget -N http://foshkplugin.phantasoft.de/files/generic-FOSHKplugin.zip
# unzip the file
# if you already know the ip address of the device you want to change you can skip next 3 steps
# the WS_PORT should always be 45000 on FOSHK-devices
# get ip address of weather station --> you will need this later as WS_IP
# get port of weather station --> you will need this later as WS_PORT
# get current sending interval - not needed; just for info or check
# now set the desired sending interval to 5 seconds - where WS_IP is the ip address of your GW1000 and WS_PORT the command port (probably 45000)
# example: the IP address of your GW1000 is 192.168.0.1, interval should be 5: ./foshkplugin.py -setWSinterval 192.168.0.1 45000 5
./foshkplugin.py -setWSinterval WS_IP WS_PORT 5
redistribute the Ecowitt stream of a GW1000 to several weewx
The GW1000 knows exactly ONE destination for a custom server upload. But if you want to feed several instances of weewx with the data from the GW1000, this also requires several GW1000.
Or you can simply use FOSHKplugin with just one GW1000 and let FOSHKpugin redistribute the incoming stream as you like!
FOSHKplugin knows 10 forwarding destinations - called Forwards.
A Forward-block must be created in the config file for each forward, in which the target, type and other conditions can be configured:
FWD_URL = # URL of destination
FWD_INTERVAL = # interval in seconds in which lines will be forwarded
FWD_IGNORE = "" # comma-separated list of fields to not forward
FWD_TYPE = "" # WU/UDP/LD/RAW/EW/RAWEW/RAWUDP - WU: WU-format; UDP: UDP-String will be forwarded (default); LD: PM2.5 luftdaten.info; EW: Ecowitt; RAWEW: Ecowitt untouched; RAW: as input; RAWUDP: RAW via UDP
FWD_SID = "" # SensorID for luftdaten.info
For the forwarding of the original Ecowitt stream, only the destination (FWD_URL) and the type (FWD_TYPE) have to be defined. The other parameters are optional.
If you want to operate 3 weewx instances with a GW1000, you have to enter the IP address of the FOSHKplugin host under Server IP / Hostname and the port number configured there (LBH_PORT) under Port via the WS View app.
/data/report/ should be configured as Path.
On FOSHKplugin-side you have to create 3 blocks that refer to the respective weewx instances:
FWD_URL = http://weewx-host1:weewx-port1 # URL of destination
FWD_TYPE = RAWEW # RAWEW: Ecowitt untouched
FWD_URL = http://weewx-host1:weewx-port2 # URL of destination
FWD_TYPE = RAWEW # RAWEW: Ecowitt untouched
FWD_URL = http://weewx-host1:weewx-port3 # URL of destination
FWD_TYPE = RAWEW # RAWEW: Ecowitt untouched
Don't forget to restart the systemd service after making changes to the config file: service foshkplugin restart.
As a result, when an Ecowitt string is received by the GW1000, it is forwarded in parallel and unprocessed to these defined forwards.
|GW1000-1 with ip address 192.168.1.1 configured in WS View:||Server IP / Hostname: 192.168.1.100||Port: 8001||Path: (none)|
|GW1000-2 with ip address 192.168.1.2 configured in WS View:||Server IP / Hostname: 192.168.1.100||Port: 8002||Path: (none)|
|GW1000-3 with ip address 192.168.1.3 configured in WS View:||Server IP / Hostname: 192.168.1.100||Port: 8003||Path: (none)|
You install FOSHKplugin on 192.168.1.100 with LBH_PORT 8080 and create these blocks in your foshkplugin.conf:
FWD_URL = http://192.168.1.100:8001
FWD_TYPE = RAWEW
# URL of destination
# RAWEW: Ecowitt untouched
FWD_URL = http://192.168.1.100:8002
FWD_TYPE = RAWEW
# URL of destination
# RAWEW: Ecowitt untouched
FWD_URL = http://192.168.1.100:8003
FWD_TYPE = RAWEW
# URL of destination
# RAWEW: Ecowitt untouched
restart the FOSHKplugin-service with sudo service foshkplugin restart
Afterwards you can remove GW1000-2 and GW1000-3 and reconfigure the remaining GW1000-1 with WS View to:
Server IP / Hostname: 192.168.1.100
Now the GW1000-1 sends the Ecowitt-Stream to FOSHKplugin which redistribute this to all 3 weewx-instances. Just with ONE GW1000.
Saving or further processing of incoming data sets (set-wise)
For further processing of the data from the weather station by other programs, it is recommended to use a cron job in which a shell script is started that fetches the last data record from FOSHKplugin as a string:
For example, to start this script every 30 seconds, simply set up two entries in cron:
Forwarding of the station data to an MQTT broker
With v0.08, the script-controlled way to send the data is no longer necessary - FOSHKplugin can forward the data directly to an MQTT server.
Both the metric and the imperial values (and names) can be transferred in 2 separate forwards. The forward to different brokers - also in different formats is possible - you then have to set up separate forwards.
FWD_EXEC can be used to intercept the data to be sent to the MQTT broker by any script right BEFORE sending. If necessary, the output data could be modified there. The last output line of the script is then taken by FOSHKplugin as the data intended to forward.
Basically, all available values of the weather station, any values calculated by EVAL_VALUES as well as the status messages and the min/max values are transferred to the MQTT broker.
As usual with forwards, individual fields can be excluded from sending via the ignore list FWD_IGNORE.
Metric names and values are sent with FWD_TYPE = MQTTMET and imperial names/values with FWD_TYPE = MQTTIMP.
In FWD_URL the MQTT broker address, the port and the topic are in the format
Port 1883 is set as the standard port. The default topic is FOSHKweather/Keyname. A prefix is optional and would be placed in front of the name of the key.
A possibly required user name and the specification of the password are made via FWD_SID (username) and FWD_PWD (password). FWD_INTERVAL defines how often the data is sent to the MQTT server. If this value remains free, every incoming data packet is sent from the weather station.
In the standard setting, all fields are sent to the MQTT broker via MQTT each time data is received from the weather station.
FWD_MQTTCYCLE can be used to specify that only changed data is transmitted via MQTT. The complete data record of the weather station is only transferred in the cycle of the number of minutes specified here.
FWD_MQTTCYCLE = 10 therefore means that the data is completely sent to the MQTT server every 10 minutes. In the intervening period, only the topics whose value / content have changed are transmitted.
This serves to minimize traffic while at the same time ensuring that all data is available at the destination.
Sending FOSHKplugin data (weather station data) to a MQTT-server (deprecated)
Because there was no native MQTT support up to version v0.08, the method described here was the only option of sending the data to an MQTT broker. This is still possible - but no longer necessary with v0.08 with its dedicated MQTT forward.
However, it is possible to publish on an MQTT server using a wrapper script. A cron job, a small bash script and the MQTT CLI are required.
The bash-script FOSHKplugin2mqtt.sh:
mosquitto_pub is used to publish the data - so you have to make sure that this program is available:
Installation of FOSHKplugin generic version for several PWT instances
Personal Weather Tablet (PWT) on an Android tablet is a very nice alternative to a dedicated console.
This means that old, disused tablets can still be put to good use. In custom server mode, PWT expects the weather station to deliver the Ecowitt data to the tablet. Since there is only the possibility of defining a single destination on the weather station, FOSHKplugin instead can receive this data and forward it to any other destination.
Required: 24/7 computer system (e.g. Raspberry Pi) with ssh access or local console for installation
1. Create a directory
2. Change to the directory
3. Download the installation file
4. Extract the installation file
5. Start the installation script
6. Initial configuration
In the square brackets there should already be meaningful defaults that can be selected with ENTER. However, you can also enter your own value in order to overwrite these defaults:
+++ FOSHKplugin +++ ip address of target system to send UDP-messages to :
Leave blank if no UDP forwarding is required, otherwise enter the IP address of the destination of the UDP messages.
+++ FOSHKplugin +++ udp port on target system :
Leave blank if no UDP forwarding is required, otherwise enter the UDP port of the target system.
+++ FOSHKplugin +++ ip address of local system [192.168.15.237]:
Enter the IP address of the local system, i.e. the device on which FOSHKplugin is to run (please do not use an IPv6 or localhost address).
+++ FOSHKplugin +++ http port on local system :
The local port on which the internal http server is started by FOSHKplugin, the default can be accepted with ENTER.
+++ FOSHKplugin +++ ip address of weather station [192.168.15.215]:
Please enter the IP address of the weather station here. This is generally found automatically.
+++ FOSHKplugin +++ command port of weather station :
The command port of the weather station. Here, too, the default 45000 (the default port for FOSHK weather stations) can be accepted with ENTER.
+++ FOSHKplugin +++ message-interval of weather station :
Enter the desired interval in seconds at which the weather station sends the data to FOSHKplugin. The default of 30 seconds can be accepted - however, other time intervals can also be used. Note that this is also the minimum time interval for forwards.
+++ FOSHKplugin +++ are these settings ok? (Y/N)
The settings made are accepted with Y. With N it can be configured again if an error is discovered.
+++ FOSHKplugin +++ do you want to write settings into the config-file? (Y/N)
With Y these settings are written into the config file (foshkplugin.conf).
+++ FOSHKplugin +++ do you want to write settings into the weather station? (Y/N)
With Y the required data (IP address and port of the target system from the perspective of the weather station, the interval and the data format Ecowitt) are written to the weather station.
+++ FOSHKplugin +++ do you want to enable and start the service? (Y/N)
With Y, a service (foshkplugin) is installed and started, which is started automatically every time the computer is restarted and which leads to the restart of FOSHKplugin within a few seconds even if the program crashes.
7. advanced configuration
The foshkplugin.conf file can be edited with any editor in order to make further settings. For forward operation, however, only the required forwards need to be entered.
The data received from the weather station are forwarded to other systems / programs via so-called forwards. A forward block is required for each desired forwarding, in which the target, format, interval and, if necessary, other forward-specific settings are specified.
A forward block is identified by [Forward-n] where n is a sequential number (1-50). This number must not be repeated within the config file.
Example of a forward to an installation of PWT on a device with the IP address 192.168.15.206:
Further forwards according to this template are possible:
Updating the generic FOSHKplugin to the current official release should be easily made:
- open an ssh shell to your server (or use local access)
- change to the directory in which FOSHKplugin is running
start the update process with
If you want to update to a specific (Beta) version you should append the filename:
The current settings in the config file are retained during the update; the service (if configured) will be restarted automatically.
Please use the usual updating way via Plugin-Administration for the LoxBerry-version of FOSHKplugin.
get push notifications for critical status changes on the smartphone/tablet
In addition to notification via UDP, availability as status via http and logging in the log file, important status changes (e.g. firmware update, sensor, watchdog, battery, storm and thunderstorm warnings) can also be sent to any mobile device (iOS , Android) as push notification, FOSHKplugin uses the API of Pushover.
Pushover is a one-time purchase app (no subscription!) that listens in the background for incoming messages from the pushover server.
If configured accordingly, FOSHKplugin sends these critical warnings via API call via the Internet to the Pushover cloud service, which then immediately searches for contact with the devices stored there and delivers the message immediately.
In the mobile device itself, these push notifications then arrive - depending on the setting - with or without sound and/or vibration or silently and are displayed both on the lock screen and in the notification bar. If available and configured accordingly, the notification LED also lights up or flashes.
With adjustable time schedules, you can specify the time periods during which the messages are sent silently within Pushover.
Besides the one-off purchase price for the app, there are no other hidden costs. At least if you stay below the free 7500 (!) notifications per month.
I've experimented with it for a few days now and I'm thrilled! The delivery takes place reliably and promptly - within a few (here 1-2) seconds (provided that the Internet is available).
- get the app Pushover from the respective store (Android, iOS)
- Start the Pushover app and assign credentials
- Log in via web browser: https://pushover.net/login
- Make a note of the key under "Your User Key", this must be specified for PO_USER in the FOSHKplugin config file foshkplugin.conf
- Generate an API token for FOSHKplugin under "Your Applications" (Create an Application / API Token) - the key specified under API Token/Key must be specified under PO_TOKEN in the FOSHKplugin config file - as app notification icon you could use this
- Adjust config foshkplugin.conf: Pushover\PO_ENABLE=True Pushover\PO_USER="Your User Key" and Pushover\PO_TOKEN=API-TOKEN:
PO_ENABLE = True
PO_USER = userkey
PO_TOKEN = token
It is not necessary to enter a URL under PO_URL. This setting would overwrite the internally predefined pushover URL.
- Restart FOSHKplugin
From now on there should be a push notification for all important status changes.
The sending of push messages is activated with the switch PO_ENABLE = True in the config file. Sending is deactivated by default (False).
Push notifications from FOSHKplugin can also be activated and deactivated during runtime, provided the correct credentials are stored in the config file.
This is done via http via any web browser by calling up the page http://ipaddress:port/FOSHKplugin/pushover=enable (activate) or http://ipaddress:port/FOSHKplugin/pushover=disable (deactivate). The port is the port specified in the config file under LBH_PORT.
This is also possible via the UDP interface of FOSHKplugin: sending "Plugin.pushover=enable" to the IP address of the host and the port on which FOSHKplugin is running (LBU_PORT in the config file) activates the sending; "Plugin.pushover=disable" deactivates this.
Any errors when sending push notifications as well as activating/deactivating during runtime are logged in the standard log file.
You'll get Pushover-notifications (if configured) in case of:
SENSOR_WARNING = True and a key (any key that is normally contained in the output string of the weather station, such as wh65batt, leakbatt1, soilbatt1, pm25batt1 ...) given in SENSOR_MANDATORY is missed in the incoming string from the weatherstation:
<WARNING> missing data for mandatory sensor [key]
<OK> mandatory data for sensor [key] is back again
BATTERY_WARNING = True and the battery level of all known sensors is below a defined threshold:
<WARNING> battery level for sensor(s) [key] is critical - please swap battery
<OK> battery level for all sensors is ok again
STORM_WARNING = True and air pressure is risen/dropped more than value given in STORM_WARNDIFF within one hour or more than value given in STORM_WARNDIFF3H within three hours:
<WARNING> possible storm - air pressure has risen/dropped more than [threshold] hPa within [count] hours! ([time/pressure before] --> [time/pressure now] diff: [difference] hPa)
<OK> storm warning cancelled after [duration] minutes ([time/pressure before] --> [time/pressure now] diff: [difference] hPa)
TSTORM_WARNING = True and WH57 present and at leas TSTORM_WARNCOUNT lighnings within TSTORM_WARNDIST km were detected:
<WARNING> thunderstorm recognized (start=[warntime])
<OK> thunderstorm warning cancelled after [duration] minutes (start=[warntime] end=[now] last=[last lightning time] lcount=[#lightnings] ldmin=[min. distance] ldmax=[max. distance] ldavg=[avg. distance])
WSDOG_WARNING = True and there were WSDOG_INTERVAL intervals no data received from weatherstation:
<WARNING> weather station has not reported data for more than [count] seconds (WSDOG_INTERVAL send-intervals)
<OK> weather station has reported data again
WSDOG_RESTART > WSDOG_INTERVAL and there's still no data from weatherstation:
<WARNING> weather station has not reported data for more than [count] seconds (WSDOG_INTERVAL send-intervals) - restarting
after a start of FOSHKplugin and afterwards every UPD_INTERVAL seconds if there's a newer firmware available for your weatherstation:
<WARNING> firmware update for [model] available - current: [current version] avail: [remote version] use the app [app name] to update!
Operation of multiple FOSHKplugin instances on one host
In some constellations it can make sense to operate several instances of FOSHKplugin in parallel - for example, to process data from several GW1000/DP1500/HP2551C.
Basically this is possible, but it does require a few points to be observed during the installation and, if necessary, a few adjustments to the configuration file foshkplugin.conf.
In any case, each instance must be installed in its own directory!
The http port (LBH_PORT) and the port for incoming UDP messages (LBU_PORT) must not be used more than once on a host. Therefore, a different http port and a different UDP port must be specified for each instance.
The installation routine generic-FOSHKplugin-install.sh automatically ensures that ports are not assigned twice.
By default, a service with the name foshkplugin is created, which can be started and stopped and which starts again automatically in the event of an unscheduled termination.
When running the installation script generic-FOSHKplugin-install.sh, however, a different name can be defined for the service.
Important: a different name must be selected for the service for each instance on the same host in order to be able to operate these different services in parallel!
I recommend naming all FOSHKplugin services with "foshkplugin" - followed by a serial number or a more specific description: for example foshkplugin-GW1 or foshkplugin-Location1.
If FOSHKplugin is also used to send UDP messages, it may be necessary to change the identifier for these messages so that the target system can assign the incoming messages.
Every outgoing UDP message contains a "SID = FOSHKweather" as an indicator of the data source. If you want to change this identifier, you can specify a different identifier in the config file under Config\DEF_SID.
When the UDP messages are parsed on the processing side, this can then be used as a trigger for further processing.
Alternatively, a distinction can also be made on the basis of the UDP port number (LOX_PORT).
This adjustment is not required for pure forward operation without UDP transmission.
Upload to Ambient Weather
Ambient Weather has a very modern web interface, a nice app, a connection to IFTTT, Amazon Alexa and Google Assistant and can be queried via API interface.
Access to this service requires that you also deliver your weather data there. This is possible with weather stations from Ambient Weather as well as with devices from third-party manufacturers.
A special license is required for operation with devices from third-party manufacturers: VW-ANET. This license is purchased once, is bound to a MAC address and can be used with FOSHKplugin to send data from an Ecowitt station to Ambient Weather.
To connect a GW1000 from Ecowitt (or Froggit DP1500) to Ambient Weather, the following steps are necessary:
- Registration with Ambient Weather - create an account at https://ambientweather.net/signin
- Purchase of the VW ANET license stating the MAC address of the GW1000 / DP1500 via https://www.ambientweather.com/amwevwamweac.html
Configuration of FOSHKplugin:
A new forward must be created in the config file:
The device is authenticated via the PASSKEY sent through the GW1000/DP1500 automatically, but can be adjusted in the config file with FWD_SID = [PASSKEY] if necessary.
From now on, FOSHKplugin also sends the incoming data from the GW1000/DP1500 to Ambient Weather.
No additional hardware or software is required.
Set up a forward to PWSDashboard
PWSDashboard is a website template that can be set up very quickly. It visualizes many sensors from the world of fine offset in an extremely beautiful way.
Since PWSDashboard receives data in Ecowitt format, FOSHKplugin actually only needs to set up a forward in Ecowitt format (FWD_TYPE EW or RAWEW):
The variable $passkey1 in the index.php in the web server directory pwsWDxx/data/report still has to be filled with the value transmitted under PASSKEY.
The easiest way to find the PASSKEY is in the FOSHKplugin-RAW-log file or copy it from the PWSDashboard log file pwsWDxx/data/report/ecco_stats.txt:
Also note the documentation from PWSDashboard for integration via the Ecowitt protocol.
Saving lightning values for the GW1000/DP1500 (WH2650/WH2600Pro)
With every restart and apparently after a certain time, the GW1000/DP1500 (probably also the WH2650/WH2600Pro) loses the values for the time of the last lightning (lightning_time) and its distance (lightning).
From this point on only empty values are sent instead of the actual values.
In the Ecowitt output string it looks like this:
With the option Export\FIX_LIGHTNING (enabled by default) FOSHKplugin writes these values with every change that does not contain "" as a value into the config-file as:
and uses these saved values when empty values are received from the weather station for all forwards and export to UDP/CSV/...
When the device is started up for the first time, these values are of course not known to FOSHKplugin. Therefore these values can be entered manually in the config file.
Ecowitt declares the time of the last lightning as Unixtime (UTC). The indication of the distance is saved in kilometers.
A service such as https://www.unixtime.de/ is recommended to calculate the corresponding Unixtime yourself. But you can also just look in the raw-log file and transfer the values.
modify outgoing data line
The FWD_EXEC function offers the option of editing, exchanging, deleting or adding further data for all data outgoing for this forward before it is actually sent.
In the config file, the line
must be entered in the corresponding forward block. Keep in mind to restart FOSHKplugin after any modification of the config file.
The output line generated for this forward is transferred to this script as a parameter.
With a shell script or another program, these data can be changed as required:
The last output of the script is then taken over by FOSHKplugin and sent to the destination specified under FWD_URL.
The user in whose context FOSHKplugin is running requires start permissions for the corresponding script.
Any errors when starting the script are recorded in the log file.
There is a timeout when processing the data! If there is no response from the started script within 10 seconds, FOSHKplugin sends the original string to the configured target instead!
Export of a Cumulus export file realtime.txt or clientraw.txt (Weather Display)
From version v0.08 FOSHKplugin supports forward as well as the storage or the retrieval of a realtime.txt and clientraw.txt. The pull-method can be controlled via cron by downloading from the URL http://ipaddress:port/realtime.txt:
curl -s -o realtime.txt
wget -Nq [-O /path/to/the/file/realtime.txt]
The forward supports both local storage in the file system and sending to a remote server via http(s)/POST or ftp(s). The form of storage is specified by the FWD_URL in the corresponding forward block.
If FWD_URL is specified as a path name, the file is stored in the specified interval (FWD_INTERVAL) at the specified location (FWD_URL) in the file system:
The owner of the generated realtime.txt and clientraw.txt corresponds to the user context in which FOSHKplugin is started. This user therefore needs the appropriate write rights in the target directory.
To save the realtime.txt/clientraw.txt file on a remote server, I recommend sending it via http(s):
On the server side, however, a php file upload.php is required to receive the incoming file and store it in the web server's file system:
Alternatively, you can also upload via ftp or ftps. For this purpose, the complete URI is specified in FWD_URL and the credentials are specified via FWD_SID (username) and FWD_PWD (password):
If the transport is to be TLS-secured (ftps), instead of ftp:// ftps:// must be used in the FWD URL.
It should be noted that not all fields in the realtime.txt and clientraw.txt are filled by FOSHKplugin.
Saving of daily values in a separate CSV file
For some evaluations it can be helpful to collect the minimum and maximum values of a day as well as other statistical values on a daily basis - together with the time of the respective occurrence.
This statistical data includes, for example, the time and amount of the heaviest rain during the day or the number of lightning strikes. But the minimum and maximum values with the respective time of the day could also be of interest for all temperature values.
FOSHKplugin has a new function for this in v0.08 that creates such a CSV file.
During the first transmission of the day by the weather station (this does not have to be exactly 00:00 but depends on the actual transmission interval of the station), the values and calculations of the last transmission (thus the last of the previous day) are written to the CSV file.
The CSV file only contains metric data and its structure (with semicolon as separator and comma as decimal point) can be processed with Excel (at least in the German version) without any problems.
In the configuration file foshkplugin.conf, a name for the file to be generated must be entered in the [CSV] area under CSV_DAYFILE:
If a new version of FOSHKplugin results in a new structure (e.g. because new fields have been added or the sorting has been changed), the previous file /path/to/anyfile.csv is automatically renamed to /path/to/anyfile-YYMMDDHHMMSS.csv. New data will then continue to be written to the file configured under CSV_DAYFILE - but with an updated header line.
The output file contains columns for all currently available (and announced) sensors. So it is not abnormal that some columns (sensors) do not contain readings. The goal was to create a CSV file that can be used for as long as possible. Therefore, subsequently added sensors had to be integrated in advance.
For a school project, my son was supposed to record the daily high and low temperatures over a period of one week.
With the data I had for all transimissions, it was difficult (laborious) to convert it to the individual day. With WSWin I could at least collect the data. But even there, unfortunately, only by hand per day and not as an overview per week (at least I did not find it).
Then I built this function in. If someone can still use that: all the better!
Exporting the weather data to WSWin
WSWin is an excellent weather data processing and visualization program from Werner Krenn, which currently lacks the direct support of Fine Offset WIFI stations.
However, it offers ways to import the data from the these stations - both manually and automatically.
WSWin's own file monitoring can be used for the automatic import. This is based on checking a file for changes in a directory to be defined and, if necessary, importing it.
FOSHKplugin offer with FWD_TYPE=WSWIN the creation of such a file - the manual creation/configuration of an X-CSV is not necessary - the values of this file are automatically imported and linked with the correct sensor IDs in WSWin.
A corresponding forward is recommended to generate the file for WSWin:
Since the minimum interval for WSWin is 60 seconds, the send interval under FWD_INTERVAL should also be set to at least 60 seconds. The path specified under FWD_URL should be a path that the Windows computer can access (via Samba). Alternatively, the file storage location may also be called up via curl/wget (e.g. via a batch file) if the storage location specified as FWD_URL can be reached via a web browser. The file name is always wswin.csv.
Attention! The file name is not to be entered here, but the local directory in which the wswin.csv file is stored. The last character of the FWD_URL should therefore be a "/" (slash).
Restarting FOSHKplugin after configuration changes
Changes to the configuration require the plugin to be restarted. In the Loxone version there is a "Restart" button that restarts the service.
Since the generic version currently does not have a web interface for operation, there are various other ways to restart the plugin:
From the console or via ssh - depending on the Linux distribution used:
In addition, FOSHKplugin from v0.08 can also be restarted via http/webbrowser or UDP if the RESTART_ENABLE switch in the [Config] area of the config file has been set to True.
If the switch is active, the service can be stopped (and automatically restarted by systemd) without further authentication. From anybody who is able to reach your system.
If FOSHKplugin is not started as a service but as a program, there is NO automatic restart of FOSHKplugin - the program is only terminated.
FOSHKplugin is restarted via the web browser with
where ipaddress is the hostname or IP address of the system running FOSHKplugin and port is the port configured as Config\LBH_PORT.
The string "SID = FOSHKplugin, Plugin.shutdown" must be sent via UDP to the port configured under LBU_PORT in order to terminate FOSHKplugin. It is then automatically restarted as a service by sytemd.
The upper and lower case is to be observed in all cases!
Please activate this switch only if you can ensure that no stranger has access to your FOSHKplugin installation.
Supplying a database with data from the weather station (pull method)
Since FOSHKplugin also answers HTTP requests from clients, the data can also be called up by FOSHKplugin in various formats.
Telegraf can retrieve this data at a specified interval and write it to various database systems. I use an InfluxDB database for this.
JSON is recommended as the import format. If the min/max data is also to be transferred in JSON, the optional parameter &minmax should be added to the URL.
If the status values are also of interest to the database, a &status can also be passed as parameter. With parameter &bool, the Boolean values are saved in JSON as True/False instead of 0/1.
A few settings are required in telegraf.conf:
Once the data is in the InfluxDB database, it can also be visualized very nicely with Grafana or Chronograf, for example.
versions in use while testing export to InfluxDB:
InfluxDB v1.6.4 (git: unknown unknown)
Version 7.5.5 (commit: b5190ee547, branch: HEAD)
Telegraf 1.18.2 (git: HEAD a6143722)
native connection to an InfluxDB database (push method)
With v0.08, FOSHKplugin can forward the weather station data directly to an InfluxDB database.
This requires a forward in the format INFLUXMET or INFLUXIMP - where MET stands for the metric and IMP for the data in the imperial format. The forward format is to be defined as usual with FWD_TYPE in the config.
The server address and database are specified here in the FWD_URL; If the InfluxDB server does not run under the standard port 8086, the correct port can be specified with a colon after the address. The name of the database is given after the @ sign. If the (existing) database requires authentication, the username and password must be entered as FWD_SID and FWD_PWD. If the connection to the database is to be made via SSL, an https:// must be entered instead of http://.
It is not necessary to create a database in advance. FOSHKplugin adds the data to an existing database and - if necessary - creates a new one with the name specified after @ if the database does not exist.
The min/max values are always part of the data transmission. If FWD_STATUS is set to True, the status values are also transferred in Boolean format True/False.
This is what a corresponding forward looks like:
If the data is contained in the InfluxDB database, graphical evaluations can be carried out very easily using Grafana or Chronograf.
As an experiment I realized this with Grafana.
versions in use while testing export to InfluxDB:
InfluxDB v1.6.4 (git: unknown unknown)
Version 7.5.5 (commit: b5190ee547, branch: HEAD)
Telegraf 1.18.2 (git: HEAD a6143722)
Log file handling
Log files are very useful for commissioning and in the event of problems.
All messages that are useful for assessing the status or troubleshooting are logged. Also the forward number is logged in order to be able to find faulty blocks in the config file more easily.
However, you should consider whether it is really sensible to keep a permanent log. If an SD card is used as the storage medium, the SD card will eventually be written down - an SD card can only tolerate a defined number of write operations.
Especially the export log - if a very short interval is set - can quickly become very large, because for every message coming from the weather station - depending on the configuration - an entry for UDP, each forwarding (FWD) and CSV is also generated.
We distinguish 3 different log files with different content:
Contains status messages when the FOSHKplugin is started and stopped, shows the parameters currently in use and logs error messages while running and incoming requests that do not come from the weather station itself. In normal operation in the internal local network, this log should not be particularly large.
Logs every (!) incoming line from the weather station. Depending on the selected transmission interval, this file can become very large very quickly - with a transmission interval of 16 seconds, 5400 lines can be stored per day, which, depending on the number of connected sensors, contain 1000 or more characters - that results in approx. 5MByte per day.
You should therefore urgently consider whether this logging really makes sense. I do this - simply to be able to find an explanation for a strange behavior in retrospect. However, my storage location for the log files is not an SD card but a file server connected via nfs.
The fastest growing log file with the largest space requirement - also mentioned as Export-log.
Every (!) line used in a forward is logged here. Each incoming line from the weather station is multiplied by a factor of ten, depending on the number of forwards.
With (currently possible) 50 forwards, 50 * 5MByte per day can accrue in the log level ALL. (That's 250MByte per day!)
I actually write that down here - in order to be able to examine the chain from weather station - FOSHKplugin - send destination for any problems in the event of an error. But as already mentioned above, my logging target is not an SD card but an uncritical hard drive in a server system.
For the normal user, it should not be necessary to write the messages that have been sent successfully.
There are a few options for creating and adjusting log files in the FOSHKplugin.
One can configure the log level (ALL, INFO, WARNING, ERROR), filter out lines with certain strings (LOG_IGNORE), completely (LOG_ENABLE = False) or partially deactivate logging (remove filenames for logfile, rawfile or sndfile).
The sharpest sword for limiting log expenditure is the log level via Logging\LOG_LEVEL in the config file.
You can fine-tune the messages depending on the importance:
- ALL, as before, all lines are logged
- INFO - all lines except ERROR, WARNING, INFO and OK are hidden
- WARNING - all lines except ERROR and WARNING and OK are hidden
- ERROR - only lines with ERROR and OK are output
For reasons of compatibility, ALL is preset - but I recommend LOG_LEVEL = INFO - so everything that was NOT successful is logged
Another approach is to hide recurring log lines in the standard log (logfile), for example for recurring queries via cron.
With Logging\IGNORE_LOG, lines can be excluded from the logging in the standard log. All lines that contain one of the strings specified there (comma-separated list of search words/strings) are not logged.
Individual log files can be deactivated by leaving their log file names empty:
deactivates the output of the raw log file - so the incoming lines from the weather station are not logged at all. However, the standard log foshkplugin.log and all outgoing lines are still logged.
So, to deactivate a specific log file, simply remove the name of the respective file.
From v0.08 it is possible to switch logging on and off globally via the switch in the config file Logging\LOG_ENABLE = True/False (default: True):
The names configured for logfile, rawfile and sndfile are retained. A change to True and a subsequent restart of FOSHKplugin then writes the originally configured log files again.
One final piece of advice on logging concerns the use of logrotate.
As the name of the program suggests, logrotate rotates the log files and shortens them if they exceed a specified size or age. It is part of the Linux distribution and can also be used for shortening or collecting and packing log files from FOSHKplugin.
Instructions for this should be found on the Internet. A first attempt could be this:
Just create the file /etc/logrotate.de/foshkplugin as user root and put the content in. Afterwards restart the logrotate service as root to make sure the new settings are in use: