WXforum.net
Weather Station Hardware => Ambient Weather and Ecowitt and other Fine Offset clones => Topic started by: olicat on June 03, 2020, 04:05:28 AM
-
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, it does offer a few functions that go beyond this.
Maybe this program is useful for someone.
Do you want to integrate your weather station data in your smarthome system? FOSHKplugin knows many ways to do so!
If you've always been annoyed to only have ONE custom server - this could be the solution!
If you really need a shorter sending interval than 16 seconds - that is possible!
Would you like to change the sending interval to WU or just send a subset of data to an online provider? No problem.
Have you always wanted to contribute your PM2.5 data to global sensor network luftdaten.info / sensors.community? Built-in!
Want to use a WH31 instead of a WH32 outside while still sending outdoor temperature & humidity to any service? OK!
Do you still want to use WSWin for your analyzes? The CSV function makes it possible!
Searching for a possibility to feed Weather34 with Ecowitt data? Should work!
Would you like to upload your weather station data to your own server in order to process and present it yourself there? No problem!
Want to keep sending the lightning data to external services/programs on a GW1000 even when the device is restarted? FOSHKplugin replaces this data with the last valid values!
If you need your weather data as MQTT topics - FOSHKplugin will make this happen!
Is there a need to visualize or compare data from different sources together? Possible with the support of InfluxDB and Grafana!
With FOSHKplugin I feed several services with just one GW1000:
GW1000 -- custom server --> FOSHKplugin --> Loxone home automations system (UDP)
--> weewx (https://www.weewx.com/) (Ecowitt)
--> local PWSDashboard (Ecowitt)
--> remote PWSDashboard (https://wetter.phantasoft.de) (Ecowitt)
--> PWT Personal Weather Tablet (https://play.google.com/store/apps/details?id=today.cba.gw1000station&hl=de&gl=US) Android-app (Ecowitt) for 3 devices
--> Awekas (https://www.awekas.at/de/map.php) (WU)
--> Awekas (API)
--> Weather Underground (https://www.wunderground.com/dashboard/pws/IHOHEN41) (WU)
--> Windy (https://www.windy.com/station/pws-f069f97a?temp,52.220,13.707,9) (WU)
--> PWSweather (https://www.pwsweather.com/station/pws/ihohen44) (WU)
--> WOW (https://wow.metoffice.gov.uk/observations/details/20210319wnpwtgceoye6zd8pyyb96spukr) (WU)
--> Luftdaten.info (https://sensor.community/en/)
--> CSV (for further local analysis or import to WSWin via X-CSV)
--> Weathercloud (https://app.weathercloud.net/d7424455189#profile)
--> Meteotemplate (http://www.meteotemplate.com/) (via API)
--> Ambient Weather (https://ambientweather.net/dashboard/c6a4f228baea1e8caecc26d4f4b560bb) (API)
--> wetter.com (https://netzwerk.wetter.com/wetterstation/20755/) (API)
--> weather365.net (https://stations.meteo-services.com/fullscreen/#station8217) (API)
--> wettersektor.de (https://wettersektor.de) (API)
--> several other targets via clientraw.txt and realtime.txt like WND (https://www.wettermap.net/index.php) or wetternetzwerk.pro (https://wetternetzwerk.pro/#/wetterstation/79)
--> direct import into WSWin (https://www.pc-wetterstation.de/en1index.html) Weatherstation Operation- and Data Acquisition Software
--> feeding any MQTT broker
--> feeding InfluxDB (https://www.influxdata.com/products/influxdb/) to visualize (https://snapshot.raintank.io/dashboard/snapshot/Xulj17CGI4UrFEx1Hl2BtqT9Phi8PWIC?orgId=2&refresh=60s) data with e.g. Grafana (https://grafana.com/grafana/)
--> feeding WeatherWizz (https://www.weatherwizz.com/) in Ecowitt format
--> feeding APRS/CWOP (http://wxqa.com/) (from v0.09)
More are possible ...
Check the generic-version at https://foshkplugin.phantasoft.de/generic/ or if interested in LoxBerry-version at https://foshkplugin.phantasoft.de/
FOSHKplugin works with several weather stations from Fine Offset - not only the GW1000 or GW1100. Every station which is able to send its data via custom server function is supported (HP2551C, HP3500/3501, WH2650, WH2910, Ambient Weather WS 2000/5000, ...).
The program is not intended to serve as comprehensive weather observation or analysis software.
It's more about creating interfaces and keeping the data local.
Regards, Oliver
-
I have downloaded this and find an issue.
I have a GW1000 and two Ecowitt HP2551.
When I run the recipe found here (https://www.loxwiki.eu/display/LOXBERRY/FOSHKplugin+-+generic+version) I get the IP of the 2 consoles and never the GW1000.
./foshkplugin.py -getwsip
gary@tester:~/Downloads$ ./foshkplugin.py -getwsip
10.10.100.121
gary@tester:~/Downloads$ ./foshkplugin.py -getwsport
45000
gary@tester:~/Downloads$ ./foshkplugin.py -getwsip
10.10.100.122
gary@tester:~/Downloads$ ./foshkplugin.py -getwsport
45000
gary@tester:~/Downloads$ ./foshkplugin.py -getwsip
10.10.100.121
gary@tester:~/Downloads$ ./foshkplugin.py -getwsip
10.10.100.121
gary@tester:~/Downloads$ ./foshkplugin.py -getwsip
10.10.100.122
-
Hi!
Because I only own one device I was never able to check this with more than one device.
Sorry!
If you know the IP address of the device you want to change just use this IP in the last step.
Regards, Oliver
-
That's what I had hoped.
Thanks.
-
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 FOSHKplugin 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:
[Forward-n]
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.
(http://[attachment id=1 msg=407652][/attachment])
On FOSHKplugin-side you have to create 3 blocks that refer to the respective weewx instances:
[Forward-1]
FWD_URL = http://weewx-host1:weewx-port1 # URL of destination
FWD_TYPE = RAWEW # RAWEW: Ecowitt untouched
[Forward-2]
FWD_URL = http://weewx-host1:weewx-port2 # URL of destination
FWD_TYPE = RAWEW # RAWEW: Ecowitt untouched
[Forward-3]
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.
other recipes you may find here:
https://www.loxwiki.eu/pages/viewpage.action?pageId=72122803#FOSHKplugingenericversion-Recipes (https://www.loxwiki.eu/pages/viewpage.action?pageId=72122803#FOSHKplugingenericversion-Recipes)
Regards, Oliver
-
Oliver,
Will this work on a Ecowitt HP2550 clone which is sending Ecowitt data to my Weewx set up on a RPi?
I'm trying to install your FOSHKplugin - generic version on the same RPi as which Weewx is running.
I'm presently receiving data from the weather station (ip: 192.168.1.35) to my Weewx set up (ip: 192.168.1.151 on port 8085) and using the information to feed PWS on the net and locally to PWS_Dashboard - also set up on the Weewx Rpi which is working fine.
I would like to also send RAWEW data to 192.168.1.31 (Android Tablet to feed Da9L's program :grin:), but all my attempts have failed - some of my error messages below! :-(
Jun 19 11:59:40 weewx foshkplugin[16998]: <OK> FOSHKplugin v0.05 started
Jun 19 11:59:40 weewx foshkplugin[16998]: <ERROR> can not open http-socket 127.0.1.1:80
Jun 19 11:59:40 weewx foshkplugin[16998]: <OK> report watchdog activated, will warn if weather station did not report within 3 send-intervals
Jun 19 11:59:40 weewx foshkplugin[16998]: <OK> storm warning activated, will warn if air pressure rises/drops more than 1.75 hPa/hour with expiry time of 60 minutes
Jun 19 11:59:40 weewx foshkplugin[16998]: <OK> FOSHKplugin v0.05 stopped
Jun 19 12:03:20 weewx foshkplugin[17085]: <ERROR> can not open http-socket 192.168.1.151:80
Jun 19 12:03:20 weewx foshkplugin[17085]: <OK> report watchdog activated, will warn if weather station did not report within 3 send-intervals
Jun 19 12:03:20 weewx foshkplugin[17085]: <OK> storm warning activated, will warn if air pressure rises/drops more than 1.75 hPa/hour with expiry time of 60 minutes
Jun 19 12:03:20 weewx foshkplugin[17085]: <OK> FOSHKplugin v0.05 stopped
Jun 19 12:05:21 weewx foshkplugin[17142]: <OK> FOSHKplugin v0.05 started
Jun 19 12:05:21 weewx foshkplugin[17142]: <OK> local http-socket 192.168.1.151:8080 bound
Jun 19 12:05:21 weewx foshkplugin[17142]: <OK> report watchdog activated, will warn if weather station did not report within 3 send-intervals
Jun 19 12:05:21 weewx foshkplugin[17142]: <OK> storm warning activated, will warn if air pressure rises/drops more than 1.75 hPa/hour with expiry time of 60 minutes
Jun 19 12:05:21 weewx foshkplugin[17142]: <ERROR> sendUDP to : im except!
Jun 19 12:05:21 weewx foshkplugin[17142]: <OK> local UDP-socket 192.168.1.151:8085 bound
Jun 19 12:05:21 weewx foshkplugin[17142]: <OK> remote UDP: :
Any suggestions much appreciated.
Regards,
Andy
-
Hi Andy,
Will this work on a Ecowitt HP2550 clone which is sending Ecowitt data to my Weewx set up on a RPi?
Yes.
FOSHKplugin will work with every device sending WU or Ecowitt.
The automatic detection and remote configuration of the weather station may not work (in your case, it should). But the configuration in the config file is done with a few entries.
all my attempts have failed - some of my error messages below!
You are using version v0.05. You should definitely use the current Beta v0.06, because only there is the possibility of extended forwards like RAWEW:
https://foshkplugin.phantasoft.de/files/generic-FOSHKplugin-0.0.6Beta.zip
The configuration for the forwards should then look like this in your case:
# forward to weewx
[Forward-1]
FWD_TYPE = RAWEW
FWD_URL = http://192.168.1.151:8085/
# forward to PWT
[Forward-2]
FWD_TYPE = RAWEW
FWD_URL = http://192.168.1.31:8572/data/report/
Regards, Oliver
-
Hi Oliver,
Many thanks for the quick response and the pointer to update to the latest beta version which I did.
After installing 0.0.6 Beta and following your config for weewx & PWT I am very happy to say that all is running fine and all programs are updating [tup]
VMT for your assistance.
Regards,
Andy
-
You are welcome!
Of course, you can also operate several tablets with PWT in parallel with this solution (if you define a separate forward for each tablet).
Or (additionally) run any other software that Ecowitt expects. Maybe you still need a separate weewx instance for testing?
;-)
Regards, Oliver
-
Hi Oliver,
Quick question, How do you stop the logging with FOSHKplugin?
I've tried 'logging.getLogger foshkplugin', 'generic-FOSHKplugin-install.sh -logging' etc etc to no avail :-(
Your assistance much appreciated [tup]
regards,
Andy
-
Hi Andy,
simply comment out the three logging lines (sndfile, rawfile, logfile) in the config file.
Just write a # as first character in the line:
[Logging]
#sndfile = filename
#rawfile = filename
#logfile = filename
Regards, Oliver
-
Hi Andy,
simply comment out the three logging lines (sndfile, rawfile, logfile) in the config file.
Just write a # as first character in the line:
[Logging]
#sndfile = filename
#rawfile = filename
#logfile = filename
Regards, Oliver
Cheers Oliver, much appreciated :grin:
-
Hi Oliver,
Just tried the above '#' infront on the log files, and now getting a load of errors :-(
Jun 20 13:22:03 weewx foshkplugin[28075]: Exception in thread Thread-5:
Jun 20 13:22:03 weewx foshkplugin[28075]: Traceback (most recent call last):
Jun 20 13:22:03 weewx foshkplugin[28075]: File "/usr/lib/python3.7/threading.py", line 917, in _bootstrap_inner
Jun 20 13:22:03 weewx foshkplugin[28075]: self.run()
Jun 20 13:22:03 weewx foshkplugin[28075]: File "/usr/lib/python3.7/threading.py", line 865, in run
Jun 20 13:22:03 weewx foshkplugin[28075]: self._target(*self._args, **self._kwargs)
Jun 20 13:22:03 weewx foshkplugin[28075]: File "/opt/FOSHKplugin/foshkplugin.py", line 774, in forwardStringToEW
Jun 20 13:22:03 weewx foshkplugin[28075]: sndlogger.info(okstr + "FWD: " + url + " post: " + outstr + " : " + ret)
Jun 20 13:22:03 weewx foshkplugin[28075]: NameError: name 'sndlogger' is not defined
Jun 20 13:22:36 weewx foshkplugin[28075]: Exception in thread Thread-7:
Jun 20 13:22:36 weewx foshkplugin[28075]: Traceback (most recent call last):
Jun 20 13:22:36 weewx foshkplugin[28075]: File "/usr/lib/python3.7/threading.py", line 917, in _bootstrap_inner
Jun 20 13:22:36 weewx foshkplugin[28075]: self.run()
Jun 20 13:22:36 weewx foshkplugin[28075]: File "/usr/lib/python3.7/threading.py", line 865, in run
Jun 20 13:22:36 weewx foshkplugin[28075]: self._target(*self._args, **self._kwargs)
Jun 20 13:22:36 weewx foshkplugin[28075]: File "/opt/FOSHKplugin/foshkplugin.py", line 774, in forwardStringToEW
Jun 20 13:22:36 weewx foshkplugin[28075]: sndlogger.info(okstr + "FWD: " + url + " post: " + outstr + " : " + ret)
Jun 20 13:22:36 weewx foshkplugin[28075]: NameError: name 'sndlogger' is not defined
Jun 20 13:22:36 weewx foshkplugin[28075]: Exception in thread Thread-8:
Jun 20 13:22:36 weewx foshkplugin[28075]: Traceback (most recent call last):
Jun 20 13:22:36 weewx foshkplugin[28075]: File "/usr/lib/python3.7/threading.py", line 917, in _bootstrap_inner
Jun 20 13:22:36 weewx foshkplugin[28075]: self.run()
Jun 20 13:22:36 weewx foshkplugin[28075]: File "/usr/lib/python3.7/threading.py", line 865, in run
Jun 20 13:22:36 weewx foshkplugin[28075]: self._target(*self._args, **self._kwargs)
Jun 20 13:22:36 weewx foshkplugin[28075]: File "/opt/FOSHKplugin/foshkplugin.py", line 774, in forwardStringToEW
Jun 20 13:22:36 weewx foshkplugin[28075]: sndlogger.info(okstr + "FWD: " + url + " post: " + outstr + " : " + ret)
Jun 20 13:22:36 weewx foshkplugin[28075]: NameError: name 'sndlogger' is not defined
Jun 20 13:23:19 weewx foshkplugin[28075]: Exception in thread Thread-11:
Jun 20 13:23:19 weewx foshkplugin[28075]: Traceback (most recent call last):
Jun 20 13:23:19 weewx foshkplugin[28075]: File "/usr/lib/python3.7/threading.py", line 917, in _bootstrap_inner
Jun 20 13:23:19 weewx foshkplugin[28075]: self.run()
Jun 20 13:23:19 weewx foshkplugin[28075]: File "/usr/lib/python3.7/threading.py", line 865, in run
Jun 20 13:23:19 weewx foshkplugin[28075]: self._target(*self._args, **self._kwargs)
Jun 20 13:23:19 weewx foshkplugin[28075]: File "/opt/FOSHKplugin/foshkplugin.py", line 774, in forwardStringToEW
Jun 20 13:23:19 weewx foshkplugin[28075]: sndlogger.info(okstr + "FWD: " + url + " post: " + outstr + " : " + ret)
Jun 20 13:23:19 weewx foshkplugin[28075]: NameError: name 'sndlogger' is not defined
They just keep repeating - any ideas?
Regards,
Andy
-
Oops!
Sorry, this seems to be a bug in the Beta. I have to investigate ...
Till solution you could try to set all these logfiles to /dev/null:
[Logging]
sndfile = /dev/null
rawfile = /dev/null
logfile = /dev/null
Regards, Oliver
-
Hi Andy,
the problem was found and fixed (hopefully).
Please download the current Beta with fixed logging: https://foshkplugin.phantasoft.de/files/generic-FOSHKplugin-0.0.6Beta.zip (https://foshkplugin.phantasoft.de/files/generic-FOSHKplugin-0.0.6Beta.zip)
Depending on which beta you're on, you should get a
./generic-FOSHKplugin-install.sh -update generic-FOSHKplugin-0.0.6Beta.zipsufficient for an update installation while keeping the current configuration.
Thank you for finding&reporting!
:-)
Regards, Oliver
-
Hi Oliver,
All updated and seems to be running fine [tup]
Had to do it the long way as when I tried using sudo ./generic-FOSHKplugin-install.sh -upgrade 'filename_info_etc' it came up with a 'permission error' on a file or more?? - grey cells getting old, so sorry, cant remember which one/ones!! :-(
Regards, Andy
-
Checking out this very interesting software. I've downloaded the generic version and installed it/setup on a Raspberry Pi so that it can try to feed data into "Personal Weather Tablet" android app, and weewx (and possibly WU) using my Ecowitt WH31 as a WH32. Since there's apparently no more WH32's available on the planet.
I had weewx setup using the new API for the GW1000, so I reconfigured it back to the interceptor. I ran through the configuration of FOSHKplugin and pointed the UDP to my tablet IP/PORT shown on the app. I also setup a forwarder to the same Raspberry py URL port 8000.
I am using the WH31 on channel 1 and setup the configuration as such:
[Export]
EVAL_VALUES = True
ADD_ITEMS =
OUT_TEMP = temp1f
OUT_HUM = humidity1
For weewx I have the following
[Forward-1]
FWD_URL = http://192.168.0.182:8000/
FWD_TYPE = RAWEW
But I have a question. I do not have Nginx/Apache running a web server on my Pi, so will this still work as expected since it should still hit port 8000 where weewx is listening with the interceptor? It seems to be streaming data to weewx, but the outside temperature is still blank, and the extra "Temperature1" is still populated with my WH31 data. (parentheses added for this post only, not in the config file)
[Config]
LOX_IP = 192.168.0.177 (android tablet)
LOX_PORT = 8572 (android tablet)
LB_IP = 192.168.0.182 (Raspberry Pi)
LBU_PORT = 12340
LBH_PORT = 8080
LOX_TIME = False
USE_METRIC = False
IGNORE_EMPTY = True
UDP_ENABLE = True
UDP_IGNORE =
LANGUAGE = EN
AUTH_PWD =
For weewx Interceptor the following config:
[Interceptor]
# This section is for the network traffic interceptor driver.
# The driver to use:
driver = user.interceptor
# Specify the hardware device to capture. Options include:
# acurite-bridge - acurite internet bridge, smarthub, or access
# observer - fine offset WH2600/HP1000/HP1003, ambient WS2902
# lw30x - oregon scientific LW301/LW302
# lacrosse-bridge - lacrosse GW1000U/C84612 internet bridge
# ecowitt-client - any hardware that uses the ecowitt protocol
# wu-client - any hardware that uses the weather underground protocol
device_type = ecowitt-client
port = 8000
This is all pretty new to me, so hopefully I am not too confused :) Any help would be appreciated.
P.S. snd log data.
27.07.2020 11:50:43.341 UDP: SID=FOSHKweather PASSKEY=<removed> stationtype=GW1000B_V1.6.1 dateutc=2020-07-27+15:50:42 tempinf=72.9 humidityin=47 baromrelin=30.008 baromabsin=30.008 winddir=8 windspeedmph=2.46 windgustmph=5.82 maxdailygust=11.41 solarradiation=177.35 uv=1 rainratein=0.000 eventrainin=0.000 hourlyrainin=0.000 dailyrainin=0.000 weeklyrainin=0.000 monthlyrainin=0.020 yearlyrainin=0.020 totalrainin=0.020 tempf=87.26 humidity=70 lightning_time= lightning_num=0 lightning= wh68batt=1.80 wh40batt=1.6 batt1=0 wh57batt=5 freq=915M model=GW1000_Pro dewptf=76.3 windchillf=87.3 feelslikef=98.2 heatindexf=98.2
27.07.2020 11:50:43.371 FWD: http://192.168.0.182:8000/ post: PASSKEY=<removed>&stationtype=GW1000B_V1.6.1&dateutc=2020-07-27+15:50:42&tempinf=72.9&humidityin=47&baromrelin=30.008&baromabsin=30.008&winddir=8&windspeedmph=2.46&windgustmph=5.82&maxdailygust=11.41&solarradiation=177.35&uv=1&rainratein=0.000&eventrainin=0.000&hourlyrainin=0.000&dailyrainin=0.000&weeklyrainin=0.000&monthlyrainin=0.020&yearlyrainin=0.020&totalrainin=0.020&temp1f=87.26&humidity1=70&lightning_time=&lightning_num=0&lightning=&wh68batt=1.80&wh40batt=1.6&batt1=0&wh57batt=5&freq=915M&model=GW1000_Pro : 200
From weewx in debug=1 I am assuming that this data is coming from FOSHKplugin because the install modified my GW1000 setting to send to it vs. weewx.
Jul 27 11:51:45 raspberrypi weewx[13185] DEBUG user.interceptor: raw packet: {'dateTime': 1595865104, 'usUnits': 1, 'temperature_in': 72.9, 'humidity_in': 47.0, 'pressure': 30.011, 'wind_dir': 315.0, 'wind_speed': 3.8, 'wind_gust': 8.05, 'solar_radiation': 168.82, 'uv': 1.0, 'rain_rate': 0.0, 'rain_total': 0.02, 'temperature_1': 87.08, 'humidity_1': 70.0, 'wh40_battery': 1.6, 'battery_1': 0.0, 'rain': 0.0}
Jul 27 11:51:45 raspberrypi weewx[13185] DEBUG user.interceptor: mapped packet: {'dateTime': 1595865104, 'usUnits': 1, 'pressure': 30.011, 'inHumidity': 47.0, 'inTemp': 72.9, 'windSpeed': 3.8, 'windGust': 8.05, 'windDir': 315.0, 'radiation': 168.82, 'rain': 0.0, 'rainRate': 0.0, 'UV': 1.0, 'extraTemp1': 87.08, 'extraHumid1': 70.0}
-
Hi!
I do not have Nginx/Apache running a web server on my Pi, so will this still work as expected since it should still hit port 8000 where weewx is listening with the interceptor?
Yes.
You don't need any other software to do this. FOSHKplugin acts as a webserver for this specific task.
You should make sure to use v0.06Beta first. The older v0.05 does not have these nice features like fake-mode or EW-forward.
The fakeMode-feature is only possible as FWD_TYPE EW - RAWEW will really forward the incoming RAW-string. So just change the FDW_TYPE in all your forwards from RAWEW to EW. (Sorry, I should note this in documentation too.)
Regards, Oliver
-
Hi!
I do not have Nginx/Apache running a web server on my Pi, so will this still work as expected since it should still hit port 8000 where weewx is listening with the interceptor?
Yes.
You don't need any other software to do this. FOSHKplugin acts as a webserver for this specific task.
You should make sure to use v0.06Beta first. The older v0.05 does not have these nice features like fake-mode or EW-forward.
The fakeMode-feature is only possible as FWD_TYPE EW - RAWEW will really forward the incoming RAW-string. So just change the FDW_TYPE in all your forwards from RAWEW to EW. (Sorry, I should note this in documentation too.)
Regards, Oliver
Thanks for the quick reply,
I just installed this and did select the Beta. I also decided to try turning off WU in my GW1000 and enable it in FOSHKplugin and it is working showing my WH31 as my outdoor data. So I believe FOSHKplugin is at least working as intended.
My tablet (and tried my phone) are not picking up data for the Personal Weather Tablet. I tried adding the IP as a forwarder too w/o luck.
weewx is still receiving the WH31 as indoor. I wonder if there's a setting I need to make, or possibly changed when initially installing the interceptor or gw1000 API that is causing this problem.
https://www.wunderground.com/dashboard/pws/KINWESTH8 (https://www.wunderground.com/dashboard/pws/KINWESTH8)
-
Hi!
weewx is still receiving the WH31 as indoor.
Did you change the forward-type for this forward also to FWD_TYPE = EW?
Did you restart both FOSHKplugin and weewx?
Regards, Oliver
-
Hi!
weewx is still receiving the WH31 as indoor.
Did you change the forward-type for this forward also to FWD_TYPE = EW?
Did you restart both FOSHKplugin and weewx?
Regards, Oliver
I don't know what I did, I must have removed that section from config, but I added it back using EW and it is now working as expected. Thanks again for sticking with me through this :) Fantastic bit of software.
-
Hi!
After a few months of developing & testing I have finally released the v0.06 of FOSHKplugin.
This version corresponds to the latest version of the beta version from July 26th. - nevertheless I recommend installing this update:
open ssh-connection/console
cd /opt/FOSHKplugin # change into the FOSHKplugin-directory
sudo ./generic-FOSHKplugin-install.sh --upgrade
The existing configuration should be retained.
Attention!
One data point was changed during the beta phase! tstormwarning to report a thunderstorm has now become tswarning for easier parsing.
You may download the new version of FOSHKplugin as a generic version here (https://foshkplugin.phantasoft.de/files/generic-FOSHKplugin.zip).
The complete changelog and all available documentation can be found on the FOSHKplugin wiki page (https://foshkplugin.phantasoft.de/generic/).
Regards, Oliver
-
Hi Oli, I just moved with the Foshkplugin to my new Esprimo Nuc now and it runs great in a small size Proxmox Container, consuming in total 50MB RAM and almost 0% Processor...
Br,
Matthias
-
Hi!
it runs great in a small size Proxmox Container
Nice to hear and congrats on the new hardware!
BTW:
Next version of FOSHKplugin will also support forwarding to Meteotemplate (via API) and Weathercloud ...
Oliver
-
Hello Oliver,
I am building a solar powered remote weather station using the GW1000 and a Pi Zero W with a hotspot. I am experiencing the GW100 reconnecting to the WiFi every 10 minutes, apparently it is looking for a HTTP 200 OK from ecowitt.net
FOSHKplugin states no internet is required. Have you solved this issue?
Thanks!
Bill
-
Hi!
I am experiencing the GW100 reconnecting to the WiFi every 10 minutes, apparently it is looking for a HTTP 200 OK from ecowitt.net
I haven't noticed that before. But after you wrote that, I took a closer look at it.
My test GW1000 with firmware v1.6.1 is configured via WS View in such a way that, apart from the custom server, all other Internet-pointing services (WU, EW, WC, WOW) are deactivated.
In addition, I blocked the Internet traffic via the firewall at the gateway. Requests from the GW1000 to the Internet would be logged at the gateway, but not forwarded.
In fact, this GW1000 cuts the WIFI connection every 10 minutes, only to re-establish it a short time later (12 seconds).
Of course, this also results in a DHCP request. I did not check further whether any packets were lost during the renegotiation of the IP address.
During the observation period, however, I did not find any attempts by the GW1000 to call up any external servers - apart from NTP!
After a reboot, the GW1000 has the time 08/22/2019 10:00:00 - without internet access it cannot get the current time from cn.pool.ntp.org via NTP due to lack of internet access.
The messages sent via custom server would therefore have the wrong time!
Thus, for proper operation - since you unfortunately cannot configure the NTP server in WS View - you would have to direct the hostname cn.pool.ntp.org to a local NTP server via a local DNS.
I also don't know whether the DHCP client of the ESP8266 would make use of option 042 (transmission of the time server via DHCP) - unfortunately my router (Fritzbox) cannot send this by itself.
So I have now forbidden internet access for the GW1000 on the firewall except for NTP. After a reboot, he receives the correct time (unfortunately from an external source).
I will ask Lucy to make the time server configurable in the future - but I have little hope of a quick implementation.
I will also ask why the GW1000 interrupts the WLAN connection every 10 minutes when ecowitt.net is deactivated.
Apparently the GW1000 is testing the WIFI-connection by checking every 10 minutes whether a connection to ecowitt.net was successful. If not, the WIFI connection will be re-established as a precaution.
That's not a bad idea in the beginning. However, at FOSHK they obviously did not think that someone might not want to use or cannot use ecowitt.net.
As soon as I enable sending to Ecowitt via firewall again, the WIFI connection remains stable.
For someone who plans to use the GW1000 completely without the Internet, the only thing left for the time being is the use of a local DNS server, which redirects requests from the GW1000 for cdnrtpdate.ecowitt.net and cn.pool.ntp.org to internal services.
DNSmasq could be suitable for this ...
FOSHKplugin states no internet is required. Have you solved this issue?
FOSHKplugin does not need the Internet to make the data available locally or to convert it between the different formats.
The GW1000 currently requires access to an external NTP server because of the time and a successful connection to Ecowitt in order to satisfy the watchdog in the GW1000. Otherwise the WIFI connection will be re-established every 10 minutes.
It would be interesting to know whether the HP2551C or other devices from FOSHK/Ecowitt also causes these problems.
Greetings, Oliver
-
Thank you for so thoroughly confirming my observations.
I send the GW1000 observation data to WeeWx which then creates a wxnow.txt type file which is sent to an application called aprx, which transmits the data about 20 km via ham radio.
WeeWx is using the correct time and date so the output is correct regardless of the wrong time and date from the GW1000
When I saw that FOSHKplugin included an integrated web server I incorrectly thought it could be used to send the HTTP 200 OK to the GW1000. But it is not that simple.
Thank you again for looking into this.
-
Hi!
When I saw that FOSHKplugin included an integrated web server I incorrectly thought it could be used to send the HTTP 200 OK to the GW1000.
It does.
But of course only if FOSHKplugin receives the data from the GW1000. It cannot send such a response to requests to external addresses because it does not normally receive these requests.
However, if you redirect the hostname cdnrtpdate.ecowitt.net to FOSHKplugin via the local DNS server, FOSHKplugin responds with 200 and this answer should be sufficient to satisfy the watchdog. The WIFI should remain stable.
Oliver
-
Ahhh.... this could work. Tomorrow I'll install FOSHKplugin and rename my hotspot to cdnrtpdate.ecowitt.net and play with dnsmasq.
Thanks!
-
As usual, I was overthinking everything and got hung up on what you were asking for the UDP port for in the setup script. Once my wife broke through my engineer's analysis paralysis I skipped it and now I have the plugin sending to two instances of PWT, Ecowitt, and WU. I'll soon be hosting my Meteotemplate site on my Pi and forwarding to that as well.
Thanks for the great plugin.
-
Hi!
Congratulation!
hung up on what you were asking for the UDP port
Yes, unfortunately this is an omission in the current documentation, sorry! The UDP settings are not required for forward operation, so the default values are also empty. I'd better point it out. I will do that.
I'll soon be hosting my Meteotemplate site
Unfortunately, the forward to Meteotemplate is not yet possible with the currently available version v0.06. In the upcoming version v0.07, Meteotemplate will be fully supported via API interface. And there will be some other nice functions ...
Let me know if you can't wait and want to use a beta version of FOSHKplugin.
Oliver
-
Hi!
Congratulation!
hung up on what you were asking for the UDP port
Yes, unfortunately this is an omission in the current documentation, sorry! The UDP settings are not required for forward operation, so the default values are also empty. I'd better point it out. I will do that.
I'll soon be hosting my Meteotemplate site
Unfortunately, the forward to Meteotemplate is not yet possible with the currently available version v0.06. In the upcoming version v0.07, Meteotemplate will be fully supported via API interface. And there will be some other nice functions ...
Let me know if you can't wait and want to use a beta version of FOSHKplugin.
Oliver
I'm fine waiting for Meteotemplate compatibility as that's the lowest priority for me right now.
-
Hi!
The UDP settings are not required for forward operation, so the default values are also empty. I'd better point it out. I will do that.
There is a new recipe for Installation of FOSHKplugin generic version for several PWT instances in the recipes-section (https://www.loxwiki.eu/pages/viewpage.action?pageId=72122803#FOSHKplugingenericversion-Recipes) of FOSHKplugin.
There you will find a more detailed description of the steps required to install and configure FOSHKplugin to handle multiple PWT-instances.
I hope it helps.
Regards, Oliver
-
Hi!
The UDP settings are not required for forward operation, so the default values are also empty. I'd better point it out. I will do that.
There is a new recipe for Installation of FOSHKplugin generic version for several PWT instances in the recipes-section (https://www.loxwiki.eu/pages/viewpage.action?pageId=72122803#FOSHKplugingenericversion-Recipes) of FOSHKplugin.
There you will find a more detailed description of the steps required to install and configure FOSHKplugin to handle multiple PWT-instances.
I hope it helps.
Regards, Oliver
Thank you. I'm currently running two instances of PWT. The amount of time and work you put into this is just amazing.
-
Hi!
Because the public beta test for FOSHKplugin v0.07 will start shortly, I have provided a short update guide in the recipe section on the website (https://foshkplugin.phantasoft.de/generic/).
Maybe this is helpful for one or the other.
Oliver
-
Eagerly awaiting the beta.
-
Hi!
Eagerly awaiting the beta.
You have a PM.
If anyone is interested in a beta version, please contact me.
I'd like to get some feedback from the internal beta test before I launch the public beta test.
So far, Beta v0.07 seems to be working fine for a handful of people.
Oliver
-
(Edited because I just needed to reboot the Pi to get it working)
I'm testing the beta and forwarding to Meteotemplate. It's working just fine!
-
Hi!
If I enter the FWD_URL in my browser it successfully connects, but again, the API is never updated.
Your config seems to be ok so far. This is mine here:
[Forward-13]
FWD_CMT=Meteotemplate auf 15.100
FWD_URL=http://192.168.15.100/template/api.php?PASS=meteotemplate&
FWD_TYPE=MT
FWD_INTERVAL=30
FWD_ENABLE=True
Do you get any error in the FOSHKplugin logfile (sndfile)? At the end of each forward entry, the return code should be logged, separated by a colon.
Probably not - because you can use the URL in your browser. But who knows?
Do you have some special characters in your Meteotemplate password? There could be a problem with URL-encoding.
Do you have the APIViewer available for your Meteotemplate-installation? Do you see something strange there?
Please have a look to the Meteotemplate log file apiLog.txt in /var/www/template/cache/ (probably /var/www/weather/cache/ in your installation).
Maybe we can find an approach to problem solving there.
I once had the effect with Meteotemplate that the data was only displayed very late. After I set the interval in the forward to 30 seconds, this no longer occurred.
Here and on another location Meteotemplate is running fine via FOSHKplugin. Therefore it should be possible for you too.
Regards, Oliver
-
I rebooted the Pi and it started working just fine. I did restart the plugin after the config changes, but I guess the Pi wanted a reboot to be obstinate.
THANKS for all you work and help with FOSHk!
-
Does your plugin support the lightning detector? I'm not seeing any data for it.
To better clarify - I get thunderstorm warnings, but it's displaying anything in Meteotemplate.
-
Hi!
In Meteotemplate you should mark the missing additional sensors in Administration under "Extra Sensors" with "Save in Database".
But showing this data on the page is part of Meteotemplate. Perhaps this not supported yet.
Oliver
-
I have done that already. I will contact Jachym about actually displaying it. Thanks.
-
Hi!
Then please write what came out of it. My Meteotemplate installation is missing the lightning data also. (Whereby I also lack the extra sensors, the leakage sensors and the PM2.5 sensors.)
Oliver
-
So, I found a slightly roundabout way to get the lightning data in Meteotemplate. This also provides the PM2.5 and any other Ecowitt modules that you have.
It involves feeding the iz0qwm ecowitt_http_gateway from FOSHK. This gives not only the lightning, but all the other features of iz0qwm ecowitt_http_gateway, while still keeping everything that FOSHK does. This takes the place of the FOSHK Meteotemplate FWD. Here is the recipe that I used.
[Forward-1]
FWD_ENABLE = True
FWD_CMT = iz0qwm ecowitt_http_gateway
FWD_URL = http://xxx.xxx.xxx.xxx:80/weather/plugins/ecowitt/report/
FWD_INTERVAL = 30
FWD_IGNORE =
FWD_TYPE = RAWEW
FWD_SID =
FWD_STATUS = False
So now I am feeding 2 PWT instances, Meteotemplate, Ecowitt, WU, Weathercloud, and getting Pushover notifications.
-
Hi!
So, I found a slightly roundabout way to get the lightning data in Meteotemplate.
Nice!
I wasn't even aware that Meteotemplate can also process Ecowitt. Had I known, I would probably not have implemented API support ...
Although I don't understand why that doesn't work with FOSHKplugin. The lightning data are provided to Meteotemplate via API.
Meteotemplate also shows it in the API viewer.
At what point do you now see the lightning data on the Meteotemplate web interface?
Oliver
-
The iz0qwm ecowitt_http_gateway includes blocks to display the lightning and PM2.5, as well as a block that will show the WiFi signal strength and battery level of all the sensors.
-
Hi!
The iz0qwm ecowitt_http_gateway includes blocks to display the lightning and PM2.5
That makes sense.
FOSHKplugin does everything right on the API side, only Meteotemplate simply can't do anything with this data in the standard version.
Annoying!
I have now installed the blocks manually and after a few modifications to the database and the PHP files, I can now also see the lightning and PM2.5 data.
Meteotemplate will continue to be fed exclusively via FOSHKplugin (FWD_TYPE=MT).
:-)
Thanks for the hint!
After installing iz0qwm ecowitt_http_gateway (https://github.com/iz0qwm/ecowitt_http_gateway) you should probably be able to deliver the data via FOSHKplugin. The database should already be adjusted. And you also have the necessary blocks to display lightning, PM2.5 and modules.
Now I just have to take a look at what the red 0% bar on the right is all about ...
Greetings, Oliver
-
Corrected to say battery strength, not WiFi strength.
The red bar is reporting the battery strength from the sensors.
I believe the code starts around line 96 in the ecowittModulesBlock.php
-
Just got this up and working on my RaspPi4 as an EW protocol spass-through splitter ... easy install and config to feed a PWS tablet and Hubitat ... Very nice bit of middleware.
-
Thanks!
May I ask how you feed Hubitat with the data? Over UDP?
If you are interested in the current beta version v0.07, please let me know.
Oliver
-
Sure. Dead easy with this community driver. Very well written, it dynamically creates child devices for all your sensors. You just feed it a raw ecowitt stream. I could do it direct from the GW1000 but I also want the data to go to PWS so it does put Pi4 in the dependency chain but so be it.
https://community.hubitat.com/t/release-ecowitt-gw1000-wi-fi-gateway/38983
Context: I’m busy converting my SmartThings home automation over to a Hubitat Elevation C-7 and the latter is way better for enthusiasts.
And yes Oliver I’d defo be up for trying the beta, thanks.
Example no-code easy dashboards I just started to play with. Controllable too. Local execution.
[ You are not allowed to view attachments ]
-
Hi!
FOSHKplugin public beta testing for v0.07 has started.
There are several bug fixes and tons of new features in this version.
If interested:
https://foshkplugin.phantasoft.de/generic/ (https://foshkplugin.phantasoft.de/generic/)
Regards, Oliver
-
I've been running the v0.07 beta on a Pi 4 4Gb for around a month now and it's been working great.
I'm feeding two instances of Personal Weather Tablet, uploading to PWSWeather, uploading to WeatherCloud, feeding the Ecowitt Meteotemplate Plugin to power my Meteotemplate site, uploading to Windy.
I'm using the watchdog with Pushover to monitor that data is being received from the GW1000, getting sensor warnings if any data is missed, monitor sensor battery life, get storm and thunderstorm warnings.
I have not had any issues so far that were not caused by my failure to RTFM.
-
I've been running the v0.07 beta on a Pi 4 4Gb for around a month now and it's been working great.
I'm feeding two instances of Personal Weather Tablet, uploading to PWSWeather, uploading to WeatherCloud, feeding the Ecowitt Meteotemplate Plugin to power my Meteotemplate site, uploading to Windy.
I'm using the watchdog with Pushover to monitor that data is being received from the GW1000, getting sensor warnings if any data is missed, monitor sensor battery life, get storm and thunderstorm warnings.
I have not had any issues so far that were not caused by my failure to RTFM.
Likewise I’ve been running the beta fr couple of weeks and it’s rock solid thanks Oliver @olicat
I’ve been using Monit to watchdog my processes, and after reading this just went to check it to find Monit is not running. Oh, the irony.
-
Hi!
A new Beta-version v0.07Beta of FOSHKplugin is out now.
You may install this version over your current installation.
New in this Beta:
- Forward input data in Awekas format via GET as type AWEKAS possible
- 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 ""
Complete changelog as usual here (https://foshkplugin.phantasoft.de/generic/).
Unfortunately, I let myself be carried away by adding a few little things (see above).
So much for feature-freeze ...
;-)
But I think these new features could be helpful to some.
So please test this (again).
Regards, Oliver
-
Hi Oliver,
Thanks for the information on the update to v0.07 beta.
Ran the update, and as always working like a champ [tup]
Thank you for your hard work on this very useful program.
Andy
-
I have just ordered a GW1003 setup and want to use it with Weather Display, but I'd also like to use it with Personal Weather Tablet so have found this plugin. So my question is can this be done with the plugin and has anyone got Weather Display running with the plugin and if so what settings need to be used n WD?
Stuart
-
Hi!
If Weather Display supports the API of the GW1000 there's no need for FOSHKplugin at all. Just use the custom server to feed PWT and let use the API through WD.
But if WD also needs feeded via custom server (or in general you need more than one target for custom server) FOSHKplugin is able to feed as much custom servers you need.
It is just another forward in EW- or RAWEW-format.
Oliver
-
Not sure yet how WD accesses the GW1000, it looks like it just needs an IP address. Can't test anything yet as my WD is currently running my old station and I don't yet have my GW1000.
Stuart
-
Yes WD supports the GW1000 API. No need for "Customized" server upload.
-
Not sure yet how WD accesses the GW1000, it looks like it just needs an IP address. Can't test anything yet as my WD is currently running my old station and I don't yet have my GW1000.
Stuart
In the WD control panel you choose the respective station type and enter the IP address of your GW1000.
That's it. Very simple.
[ You are not allowed to view attachments ]
-
Hi!
A new Beta-version v0.07Beta of FOSHKplugin is out now.
You may install this version over your current installation.
New in this Beta:
- Leakage warning via UDP/http/pushover if WH55/DP70 is present and Warning\LEAKAGE_WARNING = True
- Export\FIX_LIGHTNING = True (default): use the last known values for lightning and lightning_time if GW1000 or HP2551C sends empty values
- Overview page http://ipaddress:portnumber/ shows in addition with "?units=e" all values in US metric system (inch, mph); can be combined with "/status"
- create a backup of foshkplugin.conf (foshkplugin.conf.foshkbackup) at every successful start
Complete changelog as usual here (https://foshkplugin.phantasoft.de/generic).
Have a nice weekend!
Regards, Oliver
-
Hi!
Something you could play with ...
modify outgoing data line (from v0.07) (https://www.loxwiki.eu/display/LOXBERRY/FOSHKplugin+-+generic+version#FOSHKplugingenericversion-FWD_EXEC)
Combined with the getvalue function, two (or more) different weather stations could be aggregated. Or integrate the values of your own sensors into the Ecowitt ecosystem.
Can you think of any interesting application scenarios?
I think that opens up new worlds ...
Oliver
-
Hi!
Something you could play with ...
modify outgoing data line (from v0.07) (https://www.loxwiki.eu/display/LOXBERRY/FOSHKplugin+-+generic+version#FOSHKplugingenericversion-FWD_EXEC)
Combined with the getvalue function, two (or more) different weather stations could be aggregated. Or integrate the values of your own sensors into the Ecowitt ecosystem.
Can you think of any interesting application scenarios?
I think that opens up new worlds ...
Oliver
Great idea! Could be used to implement logic and mappings (e.g. replace outdoor temp/humid with another sensor), or use backup sensors if one is failing to report / bad data quality errors etc.
One further idea - don’t know if this is possible but an idea I had was for the plugin to provide an option to get data from the GW1000 via API rather than waiting for the custom server push? That way you could use it to speed up reading data to the fastest sensor speeds for example, and still send it out via your various methods. I appreciate that’s a change to the event architecture but could be interesting.
-
Hi!
A new stable version v0.07 of FOSHKplugin (https://foshkplugin.phantasoft.de/generic/) is out now.
This version largely (but not completely) corresponds to the last public beta, so I recommend doing the update anyway in order to be really up to date.
As usual, the changelog can be found on this page (https://foshkplugin.phantasoft.de/generic/).
I hope you enjoy the new possibilities.
Regards, Oliver
-
Hi!
Is anyone interested in (and has a use case for) exporting the current weather data to realtime.txt (Cumulus) or clientraw.txt (WD) through FOSHKplugin?
With each incoming data record (Ecowitt, Ambient, WU) a corresponding file is generated and sent via ftp(s)/http(s) or stored in the filesystem.
The next version should get this functionality and I'm still looking for test options ...
Export of a Cumulus export file realtime.txt or clientraw.txt (Weather Display) - from v0.08 (https://www.loxwiki.eu/display/LOXBERRY/FOSHKplugin+-+generic+version#FOSHKplugingenericversion-realtime.txt)
Regards, Oliver
-
There is a Wordpress plugin (https://weather.station.software/) for displaying personal weather station information that uses the realtime.txt or clientraw.txt file as it's input - this would open that up as an option for users of FOSHKplugin.
-
Hi!
Is anyone interested in (and has a use case for) exporting the current weather data to realtime.txt (Cumulus) or clientraw.txt (WD) through FOSHKplugin?
With each incoming data record (Ecowitt, Ambient, WU) a corresponding file is generated and sent via ftp(s)/http(s) or stored in the filesystem.
The next version should get this functionality and I'm still looking for test options ...
Export of a Cumulus export file realtime.txt or clientraw.txt (Weather Display) - from v0.08 (https://www.loxwiki.eu/display/LOXBERRY/FOSHKplugin+-+generic+version#FOSHKplugingenericversion-realtime.txt)
Regards, Oliver
Most weather34 type templates can utilize those txt formats and if you can ftp directlly in real time up to a web host, then you would have a live data weather website. That would be great!
-
@olicat
Hi Oliver, I´m still on 0.06...
What is the best way to update to the newest version?
By the way, I´m wondering why the FOSHKplugin thread is not sticky on top...
It´s a great addition, for many purposes like a swiss army knife!
Best regards, Matthias
-
Hi Matthias,
What is the best way to update to the newest version?
please have a look to the recipes section under Updating a current FOSHKplugin generic installation (https://www.loxwiki.eu/display/LOXBERRY/FOSHKplugin+-+generic+version#FOSHKplugingenericversion-Update).
It´s a great addition, for many purposes like a swiss army knife!
Thanks. If you work with the custom server function, it can be quite helpful.
But not everyone needs it. However, there are many users who use software with API support for the GW1000 and therefore have no use for the custom server or FOSHKplugin at all.
I´m wondering why the FOSHKplugin thread is not sticky on top...
So far I haven't seen any need for it. As I said, I think it's niche software for special use cases and not necessarily of general interest.
But for me it can be sticky.
BTW:
I'm already working on the next version, which will bring some (hopefully) useful enhancements with it. Take a look at the Changelog (https://foshkplugin.phantasoft.de/generic/).
Regards, Oliver
-
Hi Oliver,
many thanks - I will look into it over the weekend.
Got now the first two DP30 Multi-Channel Temp cable sensors delivered.
I use your plugin to feed the DP1500 data into my NodeRed/Iobroker Home Automation.
Everything works flawlessly!
Now in April I get a 28KWp PV installed.
One DP30 sensor I will use then as Pool Thermometer.
Iobroker then to run the 200W Pool filter pump just during surplus energy generation over the day, not buying energy from the general provider.
The 2nd DP30 sensor could be used in case I also buy a solar pool heater to measure/compare the temperatures.
Br,
Matthias
Nice to see that your thread is sticked on top now!
-
Hi!
One DP30 sensor I will use then as Pool Thermometer.
[...]
The 2nd DP30 sensor could be used in case I also buy a solar pool heater to measure/compare the temperatures.
That will probably not affect you in this application scenario. Note, however, that the DP30 does not display or output temperatures above 60 ° C. There is a manufacturer cutoff.
Regards, Oliver
-
I´m now at 0.7...easy [tup]
sudo ./generic-FOSHKplugin-install.sh --update
Hope that the next lightning event will be stored/buffered by the plugin...
-
Hi!
Hope that the next lightning event will be stored/buffered by the plugin...
It will.
Of course you could fill in the last lightning if known to you.
Just insert the last distance and time in the config file under [Status]
[Status]
last_lightning = 20
last_lightning_time = 1615479869
last_lightning is the distance in km and last_lightning_time is the corresponding time stamp as unixdate.
You could have a look into your logfiles of last occurance and use these values.
All services supplied by FOSHKplugin then receive this lightning data.
Until the next lightning - that one (and all following) will be saved there automatically through FOSHKplugin.
Regards, Oliver
-
Hi Oliver,
thanks again for your hint. The last rare lighting for this season in S-H /Schleswig-Hostein was end of February, but the oldest log entry from March 14.
So I need to wait for the next thunder storm - no problem...
However, I´m very happy. PWSDashboard from Wim, Weewx, and Iobroker/NodeRed perfectly served by your plugin :grin: [tup]
Switched over to a potent HP Nuc (hp prodesk 400 g5) end of last year - a €400,- to €600,-machine, via mydealz/Mediamarkt for finally €200,- \:D/
Now everything seperated under Proxmox and backups and quick snapshots are so easy to perform:
[ You are not allowed to view attachments ]
-
@olicat
Back here now with regard to: https://www.weather-watch.com/smf/index.php/topic,70904.msg571091.html#msg571091
Have updated the foshkplugin to version 07 now and added follwing lines to the config (with reboot):
[Export]
EVAL_VALUES = True
ADD_ITEMS =
OUT_TEMP =
OUT_HUM =
FIX_LIGHTNING = True
[Status]
last_lightning = 20
last_lightning_time = 1615462200
StopTime = 1616513074
Output in the raw-foshkplugin.log:
23.03.2021 17:12:17.884 PASSKEY=xxx&stationtype=GW1000A_V1.6.6&dateutc=2021-03-23+16:12:17&tempinf=76.1&humidityin=34&baromrelin=30.215&baromabsin=30.168&tempf=46.0&humidity=82&winddir=233&windspeedmph=1.12&windgustmph=1.12&maxdailygust=9.17&solarradiation=43.31&uv=0&rainratein=0.000&eventrainin=0.000&hourlyrainin=0.000&dailyrainin=0.008&weeklyrainin=0.059&monthlyrainin=2.752&yearlyrainin=7.945&totalrainin=7.945&temp1f=3.74&temp2f=69.08&temp3f=53.42&humidity3=67&lightning_time=1615462200&lightning_num=0&lightning=20&wh65batt=0&batt1=0&batt2=0&batt3=0&wh57batt=3&freq=868M&model=GW1000_Pro&dewptf=40.9&windchillf=46.0&feelslikef=46.0&heatindexf=44.2&windspdmph_avg10m=0.7&winddir_avg10m=212&windgustmph_max10m=4.5&brightness=5487.4
But no last lightning data arriving/processed here...?:
https://www.fitzbek-wetter.de/pwsWDxx/index.php?lang=de-dl
Forward:
[Forward]
FWD_TYPE = RAWEW
FWD_INTERVAL = 16
FWD_URL = https://fitzbek-wetter.de/my path...
But then no lightning data arriving at pws dashboard:
a:36:{s:11:"stationtype";s:14:"GW1000A_V1.6.6";s:7:"dateutc";s:19:"2021-03-23 16:37:32";s:7:"tempinf";s:4:"76.3";s:10:"humidityin";s:2:"34";s:10:"baromrelin";s:6:"30.212";s:10:"baromabsin";s:6:"30.165";s:5:"tempf";s:4:"45.9";s:8:"humidity";s:2:"84";s:7:"winddir";s:3:"234";s:12:"windspeedmph";s:4:"0.67";s:11:"windgustmph";s:4:"2.24";s:12:"maxdailygust";s:4:"9.17";s:14:"solarradiation";s:5:"31.56";s:2:"uv";s:1:"0";s:10:"rainratein";s:5:"0.000";s:11:"eventrainin";s:5:"0.000";s:12:"hourlyrainin";s:5:"0.000";s:11:"dailyrainin";s:5:"0.008";s:12:"weeklyrainin";s:5:"0.059";s:13:"monthlyrainin";s:5:"2.752";s:12:"yearlyrainin";s:5:"7.945";s:11:"totalrainin";s:5:"7.945";s:6:"temp1f";s:4:"9.50";s:6:"temp2f";s:5:"69.08";s:6:"temp3f";s:5:"51.08";s:9:"humidity3";s:2:"67";s:14:[u][b]"lightning_time";s:0:"";s:13:"lightning_num";s:1:"0";s:9:"lightning";s:0:"";s:8:"[/b][/u]wh65batt";s:1:"0";s:5:"batt1";s:1:"0";s:5:"batt2";s:1:"0";s:5:"batt3";s:1:"0";s:8:"wh57batt";s:1:"3";s:4:"freq";s:4:"868M";s:5:"model";s:10:"GW1000_Pro";}
-
Hi Matthias,
For the analysis it would have been correct to look in the send log whether lightning_time is being sent from FOSHKplugin to PWSDashboard at all.
But you don't have to do that anymore ...
With the forward type RAWEW you send the unchanged incoming string - without any adjustments by FOSHKplugin. If you use the EW type instead, the lightning data stored by FOSHKplugin should be sent to PWSDashboard.
The documentation (https://foshkplugin.phantasoft.de/generic/) says:
RAWEW untouched Ecowitt (EW-->EW or WU-->EW)
EW enhanced Ecowitt (WU-->EW or EW-->EW)
So just change your FWD_TYPE = RAWEW to FWD_TYPE = EW and everything should be fine.
Regards, Oliver
-
Hi Oliver, perfect, fixed! Many thanks again!
Matthias
-
@olicat
I triend now some features in 0.07:
E.g., saving values to csv:
foshkplugin.conf:
[CSV]
CSV_NAME = /opt/FOSHKplugin/csv-test.csv
CSV_FIELDS = tempc;temp1f;temp2f;temp3f
CSV_INTERVAL = 60
In the output only tempc recorded?:
time;tempc;temp1f;temp2f;temp3f
28.03.2021 21:37:21;8,3;;;
28.03.2021 21:38:29;8,3;;;
28.03.2021 21:39:37;8,3;;;
Question and proposal to the logging:
[Logging]
enable_log = true/false<- Could you add this option?
logfile = /opt/FOSHKplugin/log-foshkplugin.log
rawfile = /opt/FOSHKplugin/raw-foshkplugin.log
sndfile = /opt/FOSHKplugin/snd-foshkplugin.log
Regards,
Matthias
-
Hi!
CSV_FIELDS = tempc;temp1f;temp2f;temp3f
You can not mix metric and imperial values there. If you would like to save the metric values in the CSV you have to use the metric keys instead:
CSV_FIELDS = tempc;temp1c;temp2c;temp3c
c = Celsius and f = Fahrenheit
enable_log = true/false<- Could you add this option?
I will think about it.
At the moment it is implemented in such a way that if a file name is given there, the respective logging is activated. If there is no file name, the corresponding logging does not take place. If you don't need to save the raw lines just disable the raw logging with "rawfile=".
With v0.8 the logging is definitely smarter. There are different log levels (such as with SNMP) that exclude different messages from being written to the log file:
- ALL, as before, all lines are logged
- INFO - all lines except ERROR, WARNING, INFO and OK are suppressed
- WARNING - all lines except ERROR and WARNING and OK are suppressed
- 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 or seems to be informational is logged
You can adjust the log level in runtime via a web browser:
http://ipaddress:port/FOSHKplugin/loglevel=info (or all, warning or error)
Regards, Oliver
-
Läuft! Working!
time tempc temp1c temp2c temp3c
28.03.2021 22:24:08 8.4 -16.5 20.9 10.6
Br,
Matthias
-
Hi!
Another outlook on the upcoming version v0.08 of FOSHKplugin (https://foshkplugin.phantasoft.de/generic/):
- 50 forwarding destinations for the custom server
- better logging with log levels
- Significantly better transmission security thanks to double repetition in the event of an error
- Support of a few more weather services (wetter.com (https://netzwerk.wetter.com/), weather365.net (https://stations.weather365.net/fullscreen/), wettersektor.de (https://wettersektor.de))
- Export as realtime.txt (Cumulus) and clientraw.txt (Weather Display) - thus support of further programs and services
- Export of the current data record as a TXT and/or CSV file - will be overwritten on each receive
- native support of MQTT - data can therefore be forwarded to an MQTT broker
- Calculation of additional values (cloudbase, sunhours, min/max values with time information)
- length of the UDP messages can be limited - with longer datagrams, several partial transmissions are sent
- When using a WH45, a push notification can be sent if the CO2 value exceeds a configurable limit
If you would like to urgently test one of the above functions, please send me a PM.
The public beta test will still take a moment to begin.
Regards, Oliver
-
Hi!
Another new feature of the upcoming version v0.08 of FOSHKplugin is the creation of a CSV file for WSWin (https://www.pc-wetterstation.de/en1index.html), which can be read in by WSWin directly - via file monitoring - without going through the complicated manual creation of an X-CSV.
If you would like to test this in advance, please contact me by PM.
Greetings, Oliver
-
Hi!
Another new feature that may be helpful is the creation of a daily CSV with the min/max values on a daily basis. The value and time are stored as a file for all minima and maxima of a day.
Have a look at "Saving of daily values in a separate CSV file" (the last point) in the recipes section:
https://www.loxwiki.eu/display/LOXBERRY/FOSHKplugin+-+generic+version#FOSHKplugingenericversion-CSV-dayfile
Oliver
-
Hi!
The public beta test for the new version of FOSHKplugin v0.08 has started.
I think there are some really useful new things in there. Have a look to the Version History (https://www.loxwiki.eu/display/LOXBERRY/FOSHKplugin+-+generic+version#FOSHKplugingenericversion-Changelog).
Users who do not urgently need the new functions can stay with the stable version v0.07 for the time being.
The public beta test is intended to find out any errors in use cases that are difficult to recreate by me and the internal test team.
This version has been running stable for a handful of people for a few weeks, so I don't expect any major problems.
To upgrade:
Change via ssh to the directory in which FOSHKplugin is running - according to my recommendations, it could be /opt/FOSHKplugin.
If you run FOSHKplugin as root, you can do the following commands without sudo - if you run FOSHKplugin in a certain user context, the specification of that user would be important so that the permissions are correct:
sudo -u username ./generic-FOSHKplugin-install.sh -upgrade generic-FOSHKplugin-0.0.8Beta.zip
sudo -u username ./generic-FOSHKplugin-install.sh -repair
The "repair" is important this time, because FOSHKplugin has to install two new packages via apt/pip to get MQTT support.
Let me know if there're any problems or you need some explanations of the new functions. Most things should already be described on the website (https://foshkplugin.phantasoft.de/generic/).
For first time (or parallel) installation just use this link (https://foshkplugin.phantasoft.de/files/generic-FOSHKplugin-0.0.8Beta.zip) and the common installation procedure.
LoxBerry users should download and install this version (https://foshkplugin.phantasoft.de/files/loxberry-FOSHKplugin-0.0.8Beta.zip) the usual LoxBerry-installation-way instead.
Have fun!
Regards, Oliver
-
It is possible to add update to databases like MySQL or InfluxDB?
Maybe multiple GW1000 can be managed using theyr passkey so only one FOSHKplugin can manage multiple GW1000.
-
Hi!
It is possible to add update to databases like MySQL or InfluxDB?
It is possible.
But I don't know which DBMS the user is using or what structure the database is in. If I commit to the support of InfluxDB, the desire for MySQL follows. And other users have the MS SQL Server in operation. A bottomless pit ...
In this respect, I only do CSV, ASCII and MQTT at first - everyone can feed the database of their choice from these formats.
However, if at some point I see a personal application here (or the desire of users gets louder), I take a closer look.
Maybe multiple GW1000 can be managed using theyr passkey so only one FOSHKplugin can manage multiple GW1000.
That would change the structure of the program so massively that it would make more sense to write a new application for it. I've already thought about it - it would be useful to compare values from different sensors or to merge and forward a selection of sensors. For example, if the WS80 on the GW1000-1 delivers a "strange" value, take the data from the WS68 from GW1000-2 instead.
For the server-side separation of weather data (any weather stations deliver data to a central point) I once made a small PHP script (https://foshkplugin.phantasoft.de/files/Ecowitt-WSWin.zip) for WSWin (https://www.pc-wetterstation.de/enindex.html) that stores the data in different CSVs.
This could of course also be expanded as required.
FOSHKplugin is intended to receive data from ONE weather station. However, any number of instances can be operated in parallel.
Regards, Oliver
-
InfluxDb is different, you don't have to build tables or anything else before putting data in.
The structure is created on the fly when you put data in.
So it would be more simpler.
But you are right, other people will ask for MySql, Postgres ar other classic DBMS.
-
Hi!
It is possible to add update to databases like MySQL or InfluxDB?
While playing on a connection to InfluxDB, I discovered and corrected two errors in the processing of the requests /STRING and /getvalue and extended /SSV and /SSVHDR to include the optional specification of a separator.
An updated beta is available for download (http://foshkplugin.phantasoft.de/files/generic-FOSHKplugin-0.0.8Beta.zip).
On the subject of database connection:
So far there is no direct connection to a specific SQL database.
However, there are innumerable ways to make the data from the weather station available to other programs via FOSHKplugin.
In addition to the support of the MQTT standard, which is supported by various connectors (https://diyi0t.com/visualize-mqtt-data-with-influxdb-and-grafana/), the http interface should be a good choice.
With a web browser you can just try a few things and see what you can do with this data and how you can transfer this data to the database system of your choice:
http://192.168.15.237:8080/STRING?status&minmax&separator=%20
http://192.168.15.237:8080/JSON?status&minmax
http://192.168.15.237:8080/SSV?separator=%20
Individual values can also be queried specifically:
http://192.168.15.237:8080/getvalue?key=tempf
192.168.15.237:8080 from these examples should be replaced by IP address:port of your host running FOSHKplugin.
Telegraf (https://www.influxdata.com/blog/json-to-influxdb-with-telegraf-and-starlark/) should, for example, be able to insert the data from FOSHKplugin into any DBMS - also in InfluxDB.
With cron, curl and some bash scripting (or corresponding tools under Windows), one should really be able to do anything.
With the script functionality (FWD_EXEC) all output formats of FOSHKplugin can be intercepted, changed and expanded before the actual output. So it is also possible to add values from your own DIY sensors or from other weather stations.
In the recipes section (https://www.loxwiki.eu/display/LOXBERRY/FOSHKplugin+-+generic+version#FOSHKplugingenericversion-Recipes) you should find a few more in-depth hints. Some more export formats are described here (https://www.loxwiki.eu/display/LOXBERRY/FOSHKplugin+-+generic+version#FOSHKplugingenericversion-Operation).
I am very interested in reports of experiences or success reports.
Regards, Oliver
-
I am using InfluxDB, telegraf and Grafana with configuration files taken from here
https://github.com/Slocan/weatherDashboard
In this way if all Ecowitt upload of my GW1000 and WN1900 push to it using telegraf and I collect all data from them but I can discriminate the data by the PASSKEY. All GW1000 push data to the same place, the same port, all GW1000 has the same configuration.
But I have only one Ecowitt upload per GW1000 so if I push to Influx I cannot push data in other sites. So FOSHKplugin can be a solution.
I wander if it will be possible for many GW1000 to puush data to only one FOSHKplugin. This way you avoid errors, eg on GW1000 pushing data to the wrong FOSHKplugin and adding another GW1000 or another station is more simple sicne the configuration is the same.
Unfortunately it is not simple for others stations different from the Ecowitt. If they use WiFi or ethernet you have the MAC address but this only if the connection is not only in the same lan but also in the same SSID because if you use a WiFi range extender the MAC can change.
Stations connected by USB or serial port must have an identifier assigned in some way.
There are two version of InfluxDB 1.8.x and 2.x, they differs a little. But since 2.0 was compiled only for 64 bit on the olds RaspberryPi you have to use the 1.8x
-
We're on the way ...
;-)
I'm able to feed InfluxDB from FOSHKplugin via telegraf and visualize its data with Grafana.
One can pull the weatherstation data on different ways - I use JSON here:
telegraf.conf
[[outputs.influxdb]]
urls = ["http://127.0.0.1:8086"]
database = "weatherstation"
[[inputs.http]]
urls = [
"http://192.168.15.237:8080/JSON?minmax&status&bool"
]
method = "GET"
timeout = "5s"
data_format = "json"
name_override = "weatherdata"
tag_keys = [
"PASSKEY"
]
interval = "30s"
See attached pic.
Currently I'm working on a direct connection to InfluxDB without telegraf. It looks very promising - but I'm not sure if it will make it in v0.08. In any case, the test has been running here since yesterday.
I wander if it will be possible for many GW1000 to puush data to only one FOSHKplugin.
Of course this is possible. In the standard, FOSHKplugin does not check where the data comes from and processes all incoming data according to the forward rules. Every configured forward is executed - regardless of the origin of the data.
Unfortunately it is not simple for others stations different from the Ecowitt.
That shouldn't be a major problem. With DIY sensors, you can simply send another PASSKEY along with it: PASSKEY=SENSOR1. In the case of data sent by the station in the WU protocol, there is at least one unique field: ID=WU-Id. I use this ID-field as an optional tag for InfluxDB.
If anyone is interested in the native connection to InfluxDB, please contact me. I could use a few testers, ideas and hints.
Regards, Oliver
-
Question about CSV dayfuìile.
I have this configuration
[CSV]
CSV_NAME =
CSV_FIELDS =
CSV_INTERVAL =
CSV_DAYFILE = /var/FOSHKplugin/GW1000_868_1.csv
but none file is created. The folder has these permissions rwxrwxrwx
Where is my mistake?
-
Hi!
With the dayfile you just have to be patient - it is written exactly once a day shortly after midnight.
This file only contains the values that are difficult to save in the "normal" CSV file: min/max values of the day and the corresponding times as well as the daily values for precipitation and lightning, (...).
If you want to log the values of each reception as CSV, the settings CSV_NAME, CSV_FIELDS and CSV_INTERVAL would have to be filled.
CSV_NAME specifies the name of the output file and CSV_INTERVAL specifies the interval. If CSV_INTERVAL remains empty, the station's send interval is used automatically.
In CSV_FIELDS you have to enter all field names that you want to have in the CSV. Keep in mind that these names are not the original names. In metric mode these are "converted" names (in --> mm, mph --> kmh, hpa instead of in).
For me (metric) it looks like this:
CSV_FIELDS = "PASSKEY;stationtype;dateutc;loxtime;tempinc;humidityin;baromrelhpa;baromabshpa;tempc;humidity;winddir;windspeedkmh;windgustkmh;maxdailygust;solarradiation;uv;rainratemm;eventrainmm;hourlyrainmm;dailyrainmm;weeklyrainmm;monthlyrainmm;yearlyrainmm;totalrainmm;temp1c;humidity1;temp2c;humidity2;temp3c;humidity3;temp4c;humidity4;temp8c;soilmoisture1;soilmoisture2;soilmoisture3;soilmoisture4;soilmoisture5;soilmoisture6;soilmoisture7;soilmoisture8;pm25_ch1;pm25_avg_24h_ch1;tc_co2;humi_co2;pm25_co2;pm25_24h_co2;pm10_co2;pm10_24h_co2;co2;co2_24h;lightning_time;lightning_loxtime;lightning_num;lightning;leak_ch1;leak_ch2;leak_ch3;wh65batt;batt1;batt2;batt3;batt4;batt8;soilbatt1;soilbatt2;soilbatt3;soilbatt4;soilbatt5;soilbatt6;soilbatt7;soilbatt8;pm25batt1;wh57batt;leakbatt1;leakbatt2;leakbatt3;co2_batt;freq;model;dewptc;windchillc;feelslikec;heatindexc;pm25_AQI_ch1;pm25_AQIlvl_ch1;pm25_AQI_avg_24h_ch1;pm25_AQIlvl_avg_24h_ch1;co2lvl;pm25_AQI_co2;pm25_AQIlvl_co2;pm25_AQI_24h_co2;pm25_AQIlvl_24h_co2;pm10_AQI_co2;pm10_AQIlvl_co2;pm10_AQI_24h_co2;pm10_AQIlvl_24h_co2;windspdkmh_avg10m;winddir_avg10m;windgustkmh_max10m;brightness;cloudm;sunhours;country;neighborhood;test;softwareType;stationID;tf_ch1c;tf_batt1;ptrend1;pchange1;wnowlvl;wnowtxt;ptrend3;pchange3;wproglvl;wprogtxt"
Regards, Oliver
-
Thank you very much.
I have another problem. It seems that configuration to forward to the PWSdashboard is incorrect. The PWSdashboard is on the same host as the plugin.
The conf is this one
[Forward]
FWD_ENABLE = True
FWD_CMT = To PWSdashboard at 192.168.1.35
FWD_URL = 192.168.1.35:80/pswWD/ecowitt/
FWD_INTERVAL =
FWD_IGNORE =
FWD_TYPE = RAWEW
FWD_SID =
FWD_PWD =
FWD_STATUS = True
FWD_EXEC =
in log I found
<ERROR> FWD-00: 192.168.1.35:80/pswWD/ecowitt/ post: PASSKEY=
Previous configuration was slighty different
FWD_URL = 192.168.1.35/pswWD/ecowittbut I got same error
<ERROR> FWD-00: 192.168.1.35/pswWD/ecowitt
I hope this is the last help I ask you.
-
Hi!
I would enter a http:// in the FWD_URL.
For me it looks like this:
[Forward-11]
FWD_TYPE = EW
FWD_ENABLE = True
FWD_INTERVAL = 30
FWD_CMT = PWSDashboard
FWD_URL = http://192.168.15.236:80/pwsWDxx/data/report/
Otherwise I recommend setting EW as the forward type. At least in the current version, PWSDashboard takes on a few extended fields - generated by FOSHKplugin - which the GW1000 itself does not provide. With RAWEW, only the values received from the weather station are forwarded. At EW also those calculated by FOSHKplugin.
Regards, Oliver
-
Hi Oliver,
Unfortunately it doesn't work, I tryed some different URLs
These were my tests
<ERROR> FWD-00: http://192.168.1.35:80/pswWD/ecowitt/ post: PASSKEY=
<ERROR> FWD-00: http://192.168.1.35:80/pswWD/ecowitt post: PASSKEY=
<ERROR> FWD-00: http://192.168.1.35:80/pswWD/ecowitt/index.php post: PASSKEY=
I beleve that the error is under my eyes but I am not able to see it!
I checked again the path and the passkey.
Edit: tested also these.
<ERROR> FWD-00: http://192.168.1.35/pswWD/ecowitt post: PASSKEY=
<ERROR> FWD-00: http://127.0.0.1/pswWD/ecowitt post: PASSKEY=
Edit2: also this
<ERROR> FWD-00: http://127.0.0.1/pswWD/ecowitt/ post: PASSKEY=
Edit3
with all my attempts I get 404 in the log So I am sure that apache is reached. But something different happens.
Checked path again and found the error!!!
FWD-00: http://127.0.0.1:80/pwsWD/ecowitt/
I wrote pswWD instead of pwsWD!!!
Sorry for my silly mistake!
-
Hi!
enable_log = true/false<- Could you add this option?
With next public beta of FOSHKplugin (and thus in v0.08) there will be a switch in the Config-file to enable/disable the logging globally:
LOG_ENABLE = True/False
which defaults to True. So you can keep the configuration of the log files and still switch off the logging.
Regards, Oliver
-
Hi!
There's a updated version of FOSHKplugin v0.08 available.
Since last public Beta there're some minor changes but a new key feature: direct support of InfluxDB!
Running a local InfluxDB-server and locally installed Grafana you may create a fine dashboard yourself. Easily!
You may arrange all graphs or compare any value with others and you are EVEN able to include sensor values from other systems that provide data according to InfluxDB in your considerations.
This makes it very easy to compare different weather stations or sensors of different types.
For the test (and because I've always wanted to evaluate the quality of the TFA shield (https://www.amazon.co.uk/TFA-Dostmann-98-1114-02-Sensor-White-10-2/dp/B017ILZF6C)) I compared the TFA weather protection against the original WH65 here as metric (https://snapshot.raintank.io/dashboard/snapshot/WJHaL8UN1zcn9O7egkJk8pzu0o9WsqSl) or here in imperial (https://snapshot.raintank.io/dashboard/snapshot/U782LPPBQEPl2hpi8FbEFf0tRTFN9OcM).
In summary: The TFA-Shield may protect against rain and wind. In direct sunlight, however, it performs significantly worse (5K!) than the shield built into the WH65.
Adding another sensor to this diagram is just a few clicks!
The chronological sequence can also be changed very easily with a click. So especially for people who would like to compare the various anemometers or temperature sensors with each other, InfluxDB together with Grafana or Chronograf is an extremely helpful tool. And FOSHKplugin can provide this data to the database.
Among the minor changes:
There's a new switch Logging\LOG_ENABLE to enable/disable the complete logging. The STRING output function did not work quite as expected. getvalue also apparently had problems finding keys from the other measurement system. I have now used the revision immediately to give all requests (where it makes sense) the possibility to also include minmax or status as an option and to change the separator via "separator=". The bool option is also new to output the Boolean values 0/1 as False/True.
A few examples to help you developing ideas about what is possible (replace IP address and port with your values):
get all values as JSON in metric system with True/False as state:
http://192.168.15.237:8080/JSON&minmax&boolstatus&units=m
get a string output for all metric values with a separator " - " between fields
http://192.168.15.237:8080/STRING&minmax&boolstatus&units=m&separator=%20-%20
same as UDP-output but for imperial values:
http://192.168.15.237:8080/UDP&minmax&boolstatus&units=e&separator=%20-%20
download the status only and save it locally with linefeed as status.txt
wget http://192.168.15.237:8080/FOSHKplugin/status/bool/separator=%0A -O status.txt
create a plain text file with all known data (each per line) from Windows cmd:
curl http://192.168.15.237:8080/FOSHKplugin?boolstatus^&minmax^&bool^&units=e^&separator=%0A -o complete-e.txt
just get the current state of todays (so far) max. temperature of sensor #4
curl http://192.168.15.237:8080/getvalue?key=temp4c_max -o temp4c_max.txt
To upgrade:
Change via ssh to the directory in which FOSHKplugin is running - according to my recommendations, it could be /opt/FOSHKplugin/.
If you run FOSHKplugin as root, you can do the following commands without "sudo -u username" - if you run FOSHKplugin in a certain user context, the specification of that user would be important so that the permissions are correct:
sudo -u username ./generic-FOSHKplugin-install.sh -upgrade generic-FOSHKplugin-0.0.8Beta.zip
sudo -u username ./generic-FOSHKplugin-install.sh -repair
The "repair" is important this time, because FOSHKplugin has to install a new package via apt/pip to get InfluxDB support.
Let me know if there're any problems or you need some explanations of the new functions. Most things should already be described on the website (https://foshkplugin.phantasoft.de/generic/).
For first time (or parallel) installation just use this link (https://foshkplugin.phantasoft.de/files/generic-FOSHKplugin-0.0.8Beta.zip).
LoxBerry users should download and install this version (https://foshkplugin.phantasoft.de/files/loxberry-FOSHKplugin-0.0.8Beta.zip) the usual LoxBerry-installation-way instead.
Have fun!
Regards, Oliver
-
:sad: Link goes to a 404 page.
But if I remove the Beta from the link it works
https://foshkplugin.phantasoft.de/files/generic-FOSHKplugin-0.0.8.zip (https://foshkplugin.phantasoft.de/files/generic-FOSHKplugin-0.0.8.zip)
:grin:
Edit: link updated so my link doesn't work anymore.
-
Hi Olicat, I wanted to suggest if you can implement a function to the plugin, that of setting the log deletion after certain time or when they exceed a certain size.
It would be possible?
Thank you.
Regards.
-
Hi!
Why not just use logrotate?
Oliver
-
Hi!
Why not just use logrotate?
Oliver
I don't know what way, I only know that it has been lit for a while more than 24 hours is the log files are over 5 mb, let's say a long time to go saturate the memory of the device,
for that I was asking if it was possible a programmed cancellation,
let's say that Have all plugins to avoid a separate script for cleaning.
-
Hi!
In response to current events, I wrote a post on the subject of logging "Log file handling" (https://www.loxwiki.eu/display/LOXBERRY/FOSHKplugin+-+generic+version#FOSHKplugingenericversion-Logging). Hopefully this is informative and helpful.
Regards, Oliver
-
Hi!
In response to current events, I wrote a post on the subject of logging "Log file handling" (https://www.loxwiki.eu/display/LOXBERRY/FOSHKplugin+-+generic+version#FOSHKplugingenericversion-Logging). Hopefully this is informative and helpful.
Regards, Oliver
Yes, thanks it was useful.
-
Hi!
There is a new public beta of FOSHKplugin v0.08.
In addition to minor bug fixes and optimizations, a few little things have been added:
- new config options REBOOT_ENABLE and RESTART_ENABLE - enable the weather station and FOSHKplugin to be restarted via http/UDP
- new forward type RAWTEXT enables the storage of incoming raw 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 receiving new data from the updated weather station
As usual, the complete changelog can be found here (https://foshkplugin.phantasoft.de/generic).
To upgrade:
Change via ssh to the directory in which FOSHKplugin is running - according to my recommendations, it could be /opt/FOSHKplugin/.
If you run FOSHKplugin as root, you can do the following commands without "sudo -u username" - if you run FOSHKplugin in a certain user context, the specification of that user would be important so that the permissions are correct:
sudo -u username ./generic-FOSHKplugin-install.sh -upgrade generic-FOSHKplugin-0.0.8Beta.zip
sudo -u username ./generic-FOSHKplugin-install.sh -repair
The "repair" is important if you come from a version prior v0.08Beta, because FOSHKplugin has to install a new package via apt/pip to get InfluxDB support.
If you are updating from a v0.08Beta the repair is not necessary. But it doesn't hurt either.
Let me know if there're any problems or you need some explanations of the new functions. Most things should already be described on the website (https://foshkplugin.phantasoft.de/generic/).
For first time (or parallel) installation just use this link (https://foshkplugin.phantasoft.de/files/generic-FOSHKplugin-0.0.8Beta.zip).
LoxBerry users should download and install this version (https://foshkplugin.phantasoft.de/files/loxberry-FOSHKplugin-0.0.8Beta.zip) the usual LoxBerry-installation-way instead.
Have fun and a nice weekend!
Regards, Oliver
-
Just updated from the previous 0.08beta.
I made a repair and it downloaded this file
https://files.pythonhosted.org/packages/0c/cd/1e2ec680ec7b09846dc6e605f5a7709dfb9d7128e51a026e7154e18a234e/urllib3-1.26.5-py2.py3-none-any.whl
maybe an update.
-
Hi!
maybe an update.
Indeed.
It is urllib3 - a Python library that is referenced by the requests library (which is used by FOSHKplugin).
But I have no idea why this library is stored in the FOSHKplugin directory.
On my test computers here, the Python package manager pip3 pulls the required libraries in the background and stores them properly where the libs belong. In any case, such libs do not belong in the FOSHKplugin directory.
So I don't find it fundamentally worrying.
But something seems to be wrong with your Python installation.
But as long as FOSHKplugin works so far, you may not necessarily have to take action.
I am curious to see whether other users will also notice this behavior
Regards, Oliver
-
Hi!
a slightly improved beta of FOSHKplugin v0.08 is now available for download. You may upgrade the usual way.
Changes:
- 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, absbaro)
No big deal - hope to release this version in the near future.
But I already have a few ideas (and these are already being worked on) for the next version: backup/restore of the station configuration and a function FWD_REMAP to be able to assign the values of other keys to output keys - if a forward target only supports 4 temperature sensors, for example, you could specify which of the sensors should be transmitted in the future.
As an an example:
Awekas only supports 4 additional temperature sensors. However, we in our Ecowitt world can transfer the temperature values of 8 WH31/WN30, 1 WH45 and (in the future) 8 WN34.
The remap function can then be used to specify that awekastemp1=WH34temp3, awekastemp2=WH31temp8 etc.
This also applies to the forwards to Ambient Weather, WSWin, Weathercloud, ... and includes other sensors (soil moisture, air quality, leaf wetness, ...) - so I think that's very desirable.
But that will probably only come with v0.09 - I finally want to celebrate a release again ...
;-)
Regards, Oliver
-
Some people has a GW1000 and one or more WH31, no WH32. It will possible to remap one of the WH31 as main temperature sensor to upload on Wunderground or other services?
Edit: I updated and made a repair. It downloaded
Downloading https://files.pythonhosted.org/packages/05/1b/0a0dece0e8aa492a6ec9e4ad2fe366b511558cdc73fd3abc82ba7348e875/certifi-2021.5.30-py2.py3-none-any.whl
-
Hi!
It will possible to remap one of the WH31 as main temperature sensor to upload on Wunderground or other services?
Yes.
But this function is already implemented.
Have a look in the docs regarding Fake-Mode (https://www.loxwiki.eu/display/LOXBERRY/FOSHKplugin+-+generic+version#FOSHKplugingenericversion-Fake-Mode).
You can already use a WH31 as a replacement for outdoor temp & humidity. This works globally.
The remap-function can limit this to dedicated forwards.
Oliver
-
Hi!
Spinoff from other thread (https://www.wxforum.net/index.php?topic=42108.msg430796#msg430796) regarding the new/to be released Ecowitt.net-API:
2. In the event for local storage, could someone share with my all the variables available? not just temperature and humidity, for example, rain amount and soil wetness, wind speed, wind avg etc. in addition to what is being called for below:
#!/bin/bash
tempf=`curl -s http://192.168.15.236:8080/getvalue?key=tempf`
tempc=`curl -s http://192.168.15.236:8080/getvalue?key=tempc`
echo current temp in °F: $tempf
echo current temp in °C: $tempc
Almost all available variables are documented on the FOSHKplugin-website (https://foshkplugin.phantasoft.de/generic).
But the question is what you are going to do.
Of course one could gather every single value in separate requests like in the example-script above.
But if you're interested in having more values there're better ways to gather them.
To receive the complete RAW-line you could request for example:
line=`curl -s http://192.168.15.236:8080/RAW`
The possibilities are diverse - it depends on the requirements.
You could also get the station data as JSON or CSV or STRING or ...
Since there can still be gaps in the documentation, I always suggest first looking at everything with about http://ipaddress:port/status&minmax as a website and then deciding what (which fieldnames) is required.
Have a look to the Demo-page with metric (http://foshkplugin.phantasoft.de/metric.html) and imperial (http://foshkplugin.phantasoft.de/imperial.html) values - these fields can be queried individually with http://ipaddress:port/getvalue?key=KEYNAME - depending on the existence of the respective sensors and the configuration.
Regards, Oliver
-
Hi!
FOSHKplugin (https://foshkplugin.phantasoft.de/generic/) v0.08 is released now.
This time it is a major update with countless innovations such as MQTT and InfluxDB support as well as new forward targets such as wetter.com, weather365.net, ... as well as the generation of realtime.txt and clientraw.txt and better support by WSWin.
Have a look at the "Version History" here (https://foshkplugin.phantasoft.de/generic/) for changes and improvements.
To upgrade:
Change via ssh to the directory in which FOSHKplugin is running - according to my recommendations, it could be /opt/FOSHKplugin.
If you run FOSHKplugin as root, you can do the following commands without sudo - if you run FOSHKplugin in a certain user context, the specification of that user would be important so that the permissions are correct:
sudo -u username ./generic-FOSHKplugin-install.sh -upgrade generic-FOSHKplugin-0.0.8Beta.zip
sudo -u username ./generic-FOSHKplugin-install.sh -repair
The "repair" is important this time, because FOSHKplugin has to install two new packages via apt/pip to get MQTT support.
If a beta of v0.08 was already installed, a new repair is not necessary.
Let me know if there're any problems or you need some explanations of the new functions. Most things should already be described on the website.
For first time (or parallel) installation just use this link and the common installation procedure.
LoxBerry users should download and install this version the usual LoxBerry-installation-way instead.
Have fun!
Regards, Oliver
-
Any chance for CWOP or APRS?
-
Hi!
Any chance for CWOP or APRS?
If there is an increased need and also corresponding format descriptions, I would be happy to take a look.
Are there any further requests in this regard?
Oliver
-
Any chance for CWOP or APRS?
Your Meteobridge does CWOP and APRS. Is there some reason it won't work for you?
-
Any chance for CWOP or APRS?
Your Meteobridge does CWOP and APRS. Is there some reason it won't work for you?
It works perfectly, but I'm trying to get away from it since after almost a year he still refuses to properly report lightning from Ecowitt. Right now CWOP and APRS is all that I'm using Meteobridge for.
-
Hi!
almost a year he still refuses to properly report lightning from Ecowitt.
Is there a definition for the transmission of lightning data in the APRS format or in CWOP? I haven't found that yet.
Does anyone have a link to the appropriate description?
Thanks!
Oliver
-
Hi!
almost a year he still refuses to properly report lightning from Ecowitt.
Is there a definition for the transmission of lightning data in the APRS format or in CWOP? I haven't found that yet.
Does anyone have a link to the appropriate description?
Thanks!
Oliver
APRS and CWOP do not report lightning.
Here's a link to my raw CWOP weather data: http://www.findu.com/cgi-bin/rawwx.cgi?call=KC5JIM
Here's a link to my CWOP report: http://www.findu.com/cgi-bin/wxpage.cgi?call=KC5JIM&last=240
-
Any chance for CWOP or APRS?
Your Meteobridge does CWOP and APRS. Is there some reason it won't work for you?
It works perfectly, but I'm trying to get away from it since after almost a year he still refuses to properly report lightning from Ecowitt. Right now CWOP and APRS is all that I'm using Meteobridge for.
The only thing Meteobridge is not doing completely correct for lightning meanwhile (this applies to users who have the outdoor sensors temp, wind and rain active) is that the lightning count is one (1) less per day than the real count of the WH57.
-
@olicat: see PM
-
Any chance for CWOP or APRS?
Your Meteobridge does CWOP and APRS. Is there some reason it won't work for you?
It works perfectly, but I'm trying to get away from it since after almost a year he still refuses to properly report lightning from Ecowitt. Right now CWOP and APRS is all that I'm using Meteobridge for.
The only thing Meteobridge is not doing completely correct for lightning meanwhile (this applies to users who have the outdoor sensors temp, wind and rain active) is that the lightning count is one (1) less per day than the real count of the WH57.
Right now Ecowitt shows 204 strikes for the day. Meteobridge shows 0. Meteobridge was right 45 minutes ago, then it just decided to stop. These are the last db entries (5 minutes increments) from Meteobridge sent to Meteotemplate for lightning: 203, 203, 203, 30, 11, 11, 0, 0. Somewhere along the line it decided that I was receiving "Anti-strikes" that reduce the total number of strikes detected. THAT is my problem. One less strike per day is meaningless, but turning 204 strikes into 0 strikes is not. I'm open to any suggestions of what I may be doing wrong.
-
Right now Ecowitt shows 204 strikes for the day. Meteobridge shows 0. Meteobridge was right 45 minutes ago, then it just decided to stop. These are the last db entries (5 minutes increments) from Meteobridge sent to Meteotemplate for lightning: 203, 203, 203, 30, 11, 11, 0, 0. Somewhere along the line it decided that I was receiving "Anti-strikes" that reduce the total number of strikes detected. THAT is my problem. One less strike per day is meaningless, but turning 204 strikes into 0 strikes is not. I'm open to any suggestions of what I may be doing wrong.
Maybe you are seeing the 'strikes in the last xx minutes' and not the 'strikes today' ( only a supposition, I know nothing about meteobridge )
-
Right now Ecowitt shows 204 strikes for the day. Meteobridge shows 0. Meteobridge was right 45 minutes ago, then it just decided to stop. These are the last db entries (5 minutes increments) from Meteobridge sent to Meteotemplate for lightning: 203, 203, 203, 30, 11, 11, 0, 0. Somewhere along the line it decided that I was receiving "Anti-strikes" that reduce the total number of strikes detected. THAT is my problem. One less strike per day is meaningless, but turning 204 strikes into 0 strikes is not. I'm open to any suggestions of what I may be doing wrong.
Maybe you are seeing the 'strikes in the last xx minutes' and not the 'strikes today' ( only a supposition, I know nothing about meteobridge )
Thanks for commenting - @kd7eir and me have moved and continued the discussion via PM as it is completely off-topic here. :-)
We will look into if and how Meteotemplate could play a role here, if the API string sent by Meteobridge needs modification etc.
If we don't find a solution, we will post in the Meteobridge board (in wxforum or/and in meteohub.com).
-
If we don't find a solution, we will post in the Meteobridge board (in wxforum or/and in meteohub.com).
I suggest to post the solution even in the case you find a solution.
-
If we don't find a solution, we will post in the Meteobridge board (in wxforum or/and in meteohub.com).
I suggest to post the solution even in the case you find a solution.
I will definitely post any solution. Asking for help publicly and then hoarding the answer is ridiculous.
-
I didn't mean to keep to solution secret - I only meant to say that when/if we are not successful with our assessments and tests, we will present the case to the Meteobridge fora.
If/when we find the solution, we will surely present it in the wxforum.
Now, for the next steps, @kd7eir will need to have a thunderstorm with a good number of strikes nearby ...
-
The culprit was not Meteobridge but a special block in Meteotemplate for depicting the lightning situation on a Meteotemplate (home)page. Meteobridge sends proper data, provided you use the proper API string with the proper selectors.
This block (lightningew) uses all three lightning values L (lightning count), LD (lightning distance) and LT ([last] lightning time stamp). In order to use it properly, you have to extend the database schema by two new columns for LD and LT (three new scripts to replace the old ones will do this job - they will also extend the MT database schema from 4 to 8 extra temperature, humidity, soil moisture and gas sensors (O3, SO2, NO2, CO2, CO)).
The way the update script of this block processes the data and also depicts a day-related history makes this saving of lightning count data happen. What is saved by the block is not the growing total count but the count per time slot (actual, 5 minutes, hour and day).
So what @kd7eir observed is just the result of how this Meteotemplate block works. No Meteobridge to blame.
By the way - the proper files for the database schema extension can be found at http://www.meteotemplate.com/forum/viewtopic.php?f=50&t=2064
-
The culprit was not Meteobridge but a special block in Meteotemplate for depicting the lightning situation on a Meteotemplate (home)page. Meteobridge sends proper data, provided you use the proper API string with the proper selectors.
This block (lightningew) uses all three lightning values L (lightning count), LD (lightning distance) and LT ([last] lightning time stamp). In order to use it properly, you have to extend the database schema by two new columns for LD and LT (three new scripts to replace the old ones will do this job - they will also extend the MT database schema from 4 to 8 extra temperature, humidity, soil moisture and gas sensors (O3, SO2, NO2, CO2, CO)).
The way the update script of this block processes the data and also depicts a day-related history makes this saving of lightning count data happen. What is saved by the block is not the growing total count but the count per time slot (actual, 5 minutes, hour and day).
So what @kd7eir observed is just the result of how this Meteotemplate block works. No Meteobridge to blame.
By the way - the proper files for the database schema extension can be found at http://www.meteotemplate.com/forum/viewtopic.php?f=50&t=2064
What is the api string that you are now using in MeteoBridge for Meteotemplate?
-
I guess you are mainly interested in the lightning portion:
....&L=[lgt0total-dmax.0:]&LD=[lgt0dist-lastval.0:]<=[lgt0dist-lasttime=epoch]&.....
the rest depends largely on what and how many sensors of which type you use.
-
I guess you are mainly interested in the lightning portion:
....&L=[lgt0total-dmax.0:]&LD=[lgt0dist-lastval.0:]<=[lgt0dist-lasttime=epoch]&.....
the rest depends largely on what and how many sensors of which type you use.
Thank you, that is exactly what I needed!
-
I guess you are mainly interested in the lightning portion:
....&L=[lgt0total-dmax.0:]&LD=[lgt0dist-lastval.0:]<=[lgt0dist-lasttime=epoch]&.....
the rest depends largely on what and how many sensors of which type you use.
Lightning is working fine now, thank you again for all your help!
-
I spoke too soon. I have FOSHK feeding one website, MB feeding another, and Ecowitt feeding Ecowitt.net. All of this comes from one GW1000, so the data is the same.
FOSHK rain fall = .48", Ecowitt rain fall = .48", MB rain fall = 0.00"
The rain rate is 2.91"/hr (seriously!) MB does show that correctly, but it still shows 0.00" for rain fall.
I learned my lesson. FOSHK is the absolute champion and FREE. MB is the absolute gutter and COSTS $76!
The only thing FOSHK does not do for me that MB does is APRS/CWOP, and that is 100% NOT a deal breaker. At least now I have an extra Pi4 available for use by something that works.
-
The only thing FOSHK does not do for me that MB does is APRS/CWOP, and that is 100% NOT a deal breaker. At least now I have an extra Pi4 available for use by something that works.
Put WeeWx on the Pi4, it does APRS/CWOP
-
Hi!
The only thing FOSHK does not do for me that MB does is APRS/CWOP
I have already looked at APRS as another forward target (feature) for FOSHKplugin. Sounds doable.
Are there any other interested parties?
Oliver
-
I spoke too soon. I have FOSHK feeding one website, MB feeding another, and Ecowitt feeding Ecowitt.net. All of this comes from one GW1000, so the data is the same.
FOSHK rain fall = .48", Ecowitt rain fall = .48", MB rain fall = 0.00"
The rain rate is 2.91"/hr (seriously!) MB does show that correctly, but it still shows 0.00" for rain fall.
I learned my lesson. FOSHK is the absolute champion and FREE. MB is the absolute gutter and COSTS $76!
The only thing FOSHK does not do for me that MB does is APRS/CWOP, and that is 100% NOT a deal breaker. At least now I have an extra Pi4 available for use by something that works.
As already said in the Meteobridge Forum https://forum.meteohub.de/viewtopic.php?f=61&t=15866&sid=ccfa5e699fc5905e2088aa47fa5ec696, where you have posted the same text
it's most likely not Meteobridge not working, what's needed is the proper use of the selectors to make Meteobridge send the data one wants to send
here it should be [rain0total-daysum:--] and [rain0rate-lastval:1] which will provide the desired result(s) (for Meteotemplate that's ...&R=[rain0total-daysum:--]&RR=[rain0rate-lastval:1]...
in a http request). Sorry to say that, MB does what you told it to do 8-) - you tell it the right thing the right way, it will do what's expected.
It's rewarding studying the MB WiKi section on selectors (https://www.meteobridge.com/wiki/index.php/Templates) - or asking more experienced users for help / solutions
-
I spoke too soon. I have FOSHK feeding one website, MB feeding another, and Ecowitt feeding Ecowitt.net. All of this comes from one GW1000, so the data is the same.
FOSHK rain fall = .48", Ecowitt rain fall = .48", MB rain fall = 0.00"
The rain rate is 2.91"/hr (seriously!) MB does show that correctly, but it still shows 0.00" for rain fall.
I learned my lesson. FOSHK is the absolute champion and FREE. MB is the absolute gutter and COSTS $76!
The only thing FOSHK does not do for me that MB does is APRS/CWOP, and that is 100% NOT a deal breaker. At least now I have an extra Pi4 available for use by something that works.
As already said in the Meteobridge Forum https://forum.meteohub.de/viewtopic.php?f=61&t=15866&sid=ccfa5e699fc5905e2088aa47fa5ec696, where you have posted the same text
it's most likely not Meteobridge not working, what's needed is the proper use of the selectors to make Meteobridge send the data one wants to send
here it should be [rain0total-daysum:--] and [rain0rate-lastval:1] which will provide the desired result(s) (for Meteotemplate that's ...&R=[rain0total-daysum:--]&RR=[rain0rate-lastval:1]...
in a http request). Sorry to say that, MB does what you told it to do 8-) - you tell it the right thing the right way, it will do what's expected.
It's rewarding studying the MB WiKi section on selectors (https://www.meteobridge.com/wiki/index.php/Templates) - or asking more experienced users for help / solutions
The site that MB is feeding is it's own Weather Dashboard, so the problem is 100% with MB. Even if it were not feeding it's own weather dashboard, those values you listed are already in my string, so that would not be the cause.
-
"it's own" Weather dashboard is a variant of the Weather34 dashboard, live data without history compared to the original W34 .
In my case the template works with MB without issues, shows all the proper values all the time , also during rain events.
Maybe something went wrong in the archiving process ...
Did you check the database history for that respective date for which no rain data is shown in the W34 dashboard ?
The MB system log would give more info (unless you rebooted and it started anew).
There could have been a conflict between a backup and the data archiving and the database was locked, or temporarily locked for some other reason.
Would be interesting to know.
What would be helpful is if you documented the situation with screen copies (from raw live data, min/ax, system log, hourly and (if activated) minute based history and the final issue - with time stamps).
Is this a one time observation or does it happen repeatedly (documentation !!!) ?
Complex software (and MB is a complex piece of software, much more complex than the FOSHKplugin or the weather34 template which are "broker" middleware or a front-end (both a nice piece too [tup])) is difficult to get 100% bug free. That's general knowledge.
The issue could also be with the sqlite database used by MB.
If you were with the weewx or CumulusMX communities, by the way also a very nice piece of software, both, but not bug free either, the first thing everybody asks for when you complain about something not working the way you expect is: system log, system log, system log ....: adequate documentation of the event. And that's professional issue management.
So let's do the same here. Just writing a value is such and such - or not such and such - is not helpful.
Product bashing neither.
So far, many of the issues you reported here have turned out to be user or handling issues and were related to other software and not MB issues (whereby MB is not 100% error/bug free !). They may have helped others not to hit certain obstacles - that's fine. The purpose of this community is meant to help each other. Also those who are not experts in handling with the weather hardware or software they purchased. And, it's also good to call a spade a spade - but this should be backed by documentation others can understand, verify and reconstruct the real or only pseudo bug.
I think that I can claim that I'm not biased here and do report MB bugs when I run into them - but always documented for the developer and the community to understand, verify and correct or avoid.
-
This may be relevant. I logged this issue on the Meteobridge forum on June 9:
[rain0total-daysum] error
I have a an event that is setup to run "before every full hour" and FTP a file to my hosted web server. The timestamps in the file show the minute as '59', so it is still within the hour.
The problem I have is that the [rain0total-daysum] seems to be reset to zero before the actual end of day. For example, yesterday in the 10:59pm (hour 23) file, the daily rain total was correctly shown as 12.3 mm, but the 11:59pm (hour 24) file shows the daily rain total as 0.0 mm. I would expect it to still show as 12.3 mm.
https://forum.meteohub.de/viewtopic.php?f=56&t=15772
(https://forum.meteohub.de/viewtopic.php?f=56&t=15772)
-
Gentlemen,
would you please continue the MB-specific questions in a different thread.
Users interested in FOSHKplugin will certainly find hardly any useful information when solving a problem with MeteoBridge.
This thread should actually (primarily) be about FOSHKplugin.
Thank you!
(and sorry!)
Oliver
-
Hello,
I think this is possible but I'm missing a step and hopefully someone can help me out.
What I understand is FOSHKplugin can translate AmbientWeather to Ecowitt. Ecowitt can then be picked up by the GW1000 driver in WeeWX.
I have a WS-5000 with a custom output URL configured, and I can go to my FOSHKplugin/Weewx system (http://192.168.1.13:8080) and I can see the output from the FOSHKplugin.
How do I bridge this final gap and tell FOSHKplugin to translate or do I just point the GW1000 driver to a certain URL?
I have a GW1100 on order if this won't work, but it seems like I'm only missing 1 step.
Thanks!
-
Hello,
I think this is possible but I'm missing a step and hopefully someone can help me out.
What I understand is FOSHKplugin can translate AmbientWeather to Ecowitt. Ecowitt can then be picked up by the GW1000 driver in WeeWX.
I have a WS-5000 with a custom output URL configured, and I can go to my FOSHKplugin/Weewx system (http://192.168.1.13:8080) and I can see the output from the FOSHKplugin.
How do I bridge this final gap and tell FOSHKplugin to translate or do I just point the GW1000 driver to a certain URL?
I have a GW1100 on order if this won't work, but it seems like I'm only missing 1 step.
Thanks!
In a nutshell: it won't work and you need your GW1100 to have weewx directly communicate with it through the GW1000 API. FOSHKplugin can convert formats but as far as I am aware it cannot emulate the GW1000 API which weewx works with together with its very stable GW1000 driver.
If you are only behind the basic sensors which the WH65 outdoor array provides, I could imagine that you could make FOSHKplug make emulate the custom server and weewx can receive its data via the Interceptor driver. But the interceptor driver is limited to the basic sensors, no extra sensors. By the way, this you could have already now without FOSHKplugin using in the WS-2000 console the WU protocol and set the interceptor driver to WU-client.
So again, if it's only about the basic sensors (indoor temp/hum, pressure; outdoor temp/hum; rain; wind; solar; UV), then one can also in a WS-2000 use the WU protocol and the interceptor driver with the WU-client settings (still path, interval, IP of the weewx server need to be configured in either the WS-2000 or via WSView app). You can also use FOSHKplugin sending Ambient protocol from your console, have it converted by FOSHKplugin to Ecowitt format and then use the weewx interceptor driver with ecowitt-client (but there's no added value in this unless you want to use FOSHKplugin for posting to more recipients which need Ecowitt protocol).
You want to get extra sensors (WH31-type, CO2, PM2.5, lightning etc.), the interceptor driver doesn't process them. Then you better use a GW1000/GW1100 and the weewx GW1000 API driver.
-
Hi!
How do I bridge this final gap and tell FOSHKplugin to translate or do I just point the GW1000 driver to a certain URL?
There's no way.
FOSHKplugin can actually convert data in the Ambient Weather protocol to Ecowitt and make it available to weewx, among other things.
This way, however, the GW1000 driver (https://github.com/gjr80/weewx-gw1000) cannot be used on the part of weewx, as it explicitly uses the API functions of the GW1000 and independently queries compatible devices.
Instead, you have to use the interceptor driver (https://github.com/matthewwall/weewx-interceptor), which receives and processes the Ecowitt messages coming from the weather station.
In FOSHKplugin you have to create a forward that converts the incoming Ambient messages to Ecowitt and forwards them to the configured port of weewx.
The default port for the weewx interceptor driver is 8000:
[Forward-9]
FWD_TYPE = RAWEW
FWD_URL = http://ipaddressOfWeeWX-host:8000
Regards, Oliver
-
Sorry Gyvate,
I have to correct you in this regard:
You want to get extra sensors (WH31-type, CO2, PM2.5, lightning etc.), the interceptor driver doesn't process them. Then you better use a GW1000/GW1100 and the weewx GW1000 API driver.
the WH31 and WH51 sensors are supported through weewx/Interceptor already. Same for WH41/43.
With some modifications (https://groups.google.com/g/weewx-user/c/mBzxCUCMAS4/m/GjJyIgx2BwAJ) some more sensors are possible like WH57 or WH55.
I always expected the Interceptor driver to get a major update. But this is still not the case.
So I also would - if the possibility exists - rather use the GW1000 API driver.
Regards, Oliver
-
There are some modifications to the driver available on GitHub, but none by the original author.
Some of the mods have other unwanted side effects. Found out myself the "hard" way.
Of course, if someone is familiar with Python coding, understands the logic of the program and the structure of the data sent/received, they can modify the Interceptor driver to also process the extra sensor data. "Just" extend the sensor map and add the corresponding coding ... It's no witchcraft. But you better thoroughly understand the whole program not to create other unwanted side effects.
With the GW1000 API driver in place, there is no big need for extending the interceptor driver to the full GW1000 sensor range. And the WS-5000 user number (or WS-2000 with extra sensors) doesn't seem to big large enough for creating "pressure".
At the end of the day a 30 US$ investment for the GW1100/GW1000 is in my opinion the cleaner approach (and comes with a hardware backup for your WS-2000/HP2551 console, just in case).
-
This way, however, the GW1000 driver (https://github.com/gjr80/weewx-gw1000) cannot be used on the part of weewx, as it explicitly uses the API functions of the GW1000 and independently queries compatible devices.
Instead, you have to use the interceptor driver (https://github.com/matthewwall/weewx-interceptor), which receives and processes the Ecowitt messages coming from the weather station.
In FOSHKplugin you have to create a forward that converts the incoming Ambient messages to Ecowitt and forwards them to the configured port of weewx.
The default port for the weewx interceptor driver is 8000:
[Forward-9]
FWD_TYPE = RAWEW
FWD_URL = http://ipaddressOfWeeWX-host:8000
Regards, Oliver
Thank you Oliver. I misunderstood how the GW1000 driver worked. I'll give the interceptor driver a try. Thank you for making such an awesome plugin and providing so much support for it too!
-
Hi!
Since some services only support a selection of sensors from the Fine Offset universe, I have long wanted to be able to specify more precisely which fields are used for a forward.
I now think I have found a way that makes this possible in an understandable way. Here is the link to the explanation of the remap function implemented in FOSHKplugin with the upcoming version v0.09.
Perhaps your questions or suggestions will result in improvements to the function and/or the documentation.
recipe Remapping keys/values (from v0.09) (https://www.loxwiki.eu/display/LOXBERRY/FOSHKplugin+-+generic+version#FOSHKplugingenericversion-remap)
I would be happy to receive suggestions for improvement or general comments. Or just take it as a teaser.
Regards, Oliver
-
Hi!
The only thing FOSHK does not do for me that MB does is APRS/CWOP, and that is 100% NOT a deal breaker.
With next version FOSHKplugin will also support APRS/CWOP (http://www.findu.com/cgi-bin/find.cgi?call=GW0126&units=metric).
;-)
It was implemented yesterday - now I'm testing this.
Notes, advice and suggestions for improvement are welcome!
Have a look to the recipe Sending weather station data via APRS/CWOP (from v0.09) (https://www.loxwiki.eu/display/LOXBERRY/FOSHKplugin+-+generic+version#FOSHKplugingenericversion-APRS).
Oliver
-
Hi!
The only thing FOSHK does not do for me that MB does is APRS/CWOP, and that is 100% NOT a deal breaker.
With next version FOSHKplugin will also support APRS/CWOP (http://www.findu.com/cgi-bin/find.cgi?call=GW0126&units=metric).
;-)
It was implemented yesterday - now I'm testing this.
Notes, advice and suggestions for improvement are welcome!
Have a look to the recipe Sending weather station data via APRS/CWOP (from v0.09) (https://www.loxwiki.eu/display/LOXBERRY/FOSHKplugin+-+generic+version#FOSHKplugingenericversion-APRS).
Oliver
Wonderful news!
-
Hi!
If anyone would like to test FOSHKplugin's APRS/CWOP support (or the other new features) please PM (https://www.wxforum.net/index.php?action=pm;sa=send;u=21701) me.
I have just received the first success report regarding APRS from a radio amateur. Thanks, @wxwol!
:-)
"killing" new features of upcoming FOSHKplugin v0.09:
- Leaf moisture level for Meteotemplate, WC, Awekas, Weather365 and WSWin - instead of 0..99 it is now sent as Davis-like level 0..15 (float)
- new, improved sun hours calculation sunhours (according to https://github.com/Jterrettaz/sunduration) with dynamic, location-dependent threshold value (thank you Werner!), requires Coordinates\LAT and Coordinates\LON
- new forward type EWUDP (https://www.loxwiki.eu/display/LOXBERRY/FOSHKplugin+-+generic+version#FOSHKplugingenericversion-PWTUDP) (UDPEW) - converts incoming EW, WU and AMB messages to Ecowitt/UDP (e.g. for Personal Weather Tablet/UDP broadcast listener)
- Remap function FWD_REMAP (https://www.loxwiki.eu/display/LOXBERRY/FOSHKplugin+-+generic+version#FOSHKplugingenericversion-remap) implemented - Output keys can now be defined with values of all known internal keys
- New forward type APRS enables data to be sent to CWOP (https://www.loxwiki.eu/display/LOXBERRY/FOSHKplugin+-+generic+version#FOSHKplugingenericversion-APRS)
These internal beta tests give me clear indications of any problems with the program itself, but also of gaps in the documentation.
Unfortunately, however, it cannot be completely ruled out that well-known functions may suddenly no longer work as before. The operation of beta software is therefore by no means without risk.
Even if I use this version in productive use without problems ...
I would be glad!
Thanks.
Oliver
-
APRS/CWOP is working perfectly for me. Thank you!
-
...
- new, improved sun hours calculation sunhours (according to https://github.com/Jterrettaz/sunduration) with dynamic, location-dependent threshold value (thank you Werner!), requires Coordinates\LAT and Coordinates\LON
....
Thanks.
Oliver
looks like this formula is much better than what's commonly used in stations, and it somehow (result-wise) seems to match with the findings and resulting table from an Austrian weather enthusiast: http://www.pete.at/wetter/Sonnenstunden_2021.htm (German only).
If the precision of this formula also used by Méteo France has really +/- 1% deviation only from a pyranometer, it's definitely much better than the common general 120 or 200 W/m2 threshold values.
However, nothing beats the measurements of direct sun radiation with a pyranometer or e.g. the Blake-Larsen SunRecorder which I personally use and which seems to have a similar formula inbuilt regarding longitude, latitude and time and day dependent azimuth to translate the electrical current from the photo cell in µA into sunshine seconds. Its measurements over 1 1/2 years now match nicely with corresponding minute based photos of the local sky.
But no doubt, Oliver's implementation of the new sun hour formula is a great step ahead for all those who can use FOSHKplugin =D>
-
Hi!
nothing beats the measurements of direct sun radiation with a pyranometer or e.g. the Blake-Larsen SunRecorder
I have already prepared the implementation of the Blake-Larsen SunRecorder in FOSHKplugin. However, since the Blake-Larsen SunRecorder requires a Windows computer, I put this development on hold for the time being. I don't want to run a Windows computer (or VM) 24/7 - especially for just one measured value. And I'm still hoping for an embedded solution where the value is simply output. Or a Linux solution based on software.
But you can already use the FWD_EXEC (https://www.loxwiki.eu/display/LOXBERRY/FOSHKplugin+-+generic+version#FOSHKplugingenericversion-FWD_EXEC) function (modify outgoing data line (exec)), to add any values to the Ecowitt stream or replace values with other sensors.
Oliver
-
APRS/CWOP working well here too, now running for a few days with no hiccups.
-
Hi, I write from Italy.
I bought a waldbeck halley 6 in 1 with an additional indoor temperature sensor (clone hp1000 from froggit)
I installed weewx and used the gw1000 IP driver.
I want the indoor sensor which should be a Wh32, as the main outdoor sensor, what to change in weewx?
-
I have never used weewx, however with FOSHKplugin you just add a couple of parameters to the configuration file and you are in business. I used an WH31_EP sensor outside until yesterday, which is normally seen as an indoor unit, and FOSHKplugin effortlessly reported it as an external unit.
-
Hi!
I'm not exactly sure what you're up to and what the starting position is.
If you really have a WH32, its value is taken automatically - a WH32 trumps the combination sensor. However, if you mean the sensor included in the bundle: This is a WH32B and therefore an indoor sensor.
Perhaps you really have a WH31 additional sensor and want to use this as the outdoor sensor.
First you have to be sure of the model.
Beside that:
I don't know if there's a remap functionality in weewx.
But this thread is FOSHKplugin specific and not for discussion of configuration problems with WeeWX.
Oliver
-
Ho aperto un topic specifico qui, se potete aiutarmi. Grazie.
https://www.wxforum.net/index.php?topic=43157.new#new
-
Ho aperto un topic specifico qui, se potete aiutarmi. Grazie.
https://www.wxforum.net/index.php?topic=43157.new#new
have a look at
https://www.wxforum.net/index.php?topic=43157.msg439582#msg439582
-
Hi!
The public beta test for the new version of FOSHKplugin v0.09 has started.
I think there are some really useful new things in there.
Highlights:
- FWD_REMAP - output keys can now be defined with values of all known internal keys
- APRS/CWOP support
- new forward type EWUDP to convert incoming weather station data to UDP for Personal Weather Tablet/UDP broadcast listener
- improved sunhours calculation
Have a look to the complete Version History (https://loxwiki.atlassian.net/wiki/spaces/LOXBERRY/pages/1252524456/FOSHKplugin+-+generic+version#Changelog).
Users who do not urgently need the new functions can stay with the stable version v0.08 for the time being.
The public beta test is intended to find out any errors in use cases that are difficult to recreate by me and the internal test team.
This version has been running stable for a handful of people for a few weeks, so I don't expect any major problems.
To upgrade:
Change via ssh to the directory in which FOSHKplugin is running - according to my recommendations, it could be /opt/FOSHKplugin/.
If you run FOSHKplugin as root, you can do the following commands without "sudo -u username" - if you run FOSHKplugin in a certain user context, the specification of that user would be important so that the permissions are correct:
sudo -u username ./generic-FOSHKplugin-install.sh -upgrade generic-FOSHKplugin-0.0.9Beta.zip
Let me know if there're any problems or you need some explanations of the new functions. Most things should already be described on the website.
For first time (or parallel) installation just use this link (https://foshkplugin.phantasoft.de/files/generic-FOSHKplugin-0.0.9Beta.zip).
LoxBerry users should download and install this (https://foshkplugin.phantasoft.de/files/loxberry-FOSHKplugin-0.0.9Beta.zip) version the usual LoxBerry-installation-way instead.
Have fun and Merry Christmas!
Regards, Oliver
-
My Pi was weird so I just did a clean install and everything is working great!
-
Hi Jim,
I have currently no clue what there's going on.
But first you could try a repair:
sudo ./generic-FOSHKplugin-install.sh -repairIf this still does not help, please send me the output of ls -lah from the FOSHKplugin install dir via PM.
Oliver
-
Can I ask if it is possible to add the upload to InfluxDB 2.0? The protocol seems different. I added the 1.0 compatibility but it seems that it doesn't work.
Happy New Year!
-
Hi!
InfluxDB 2 should be backwards compatible with 1.x. So it should work by now.
However, I am currently missing a corresponding test option. Perhaps there is a hint on the internet as to what InfluxDB v2 needs to be adjusted in order for it to work.
I will try to test it with InfluxDB 2 and adapt FOSHKplugin if necessary. With InfluxDB 1.8, FOSHKplugin runs here in a productive environment.
Do you get any error message while uploading to InfluxDB v2?
Happy new year!
Oliver
-
I checked and there is no error message on FOSHKplugin (or i was unable to find it).
But in Influxdb 2.0 they changed the interface. Now it has the web UI again (in 1.8 there is no web UI you should use Chronograph but previous versions had it) but you can't do all thing in it, for example you cannot create new user or simply manage them. I didn't find a place where I can see wich database can be accessed by an user.
So, I believe, there is simply a permission issue.
I switched from 1.8 on a RaspberryPi to a 2.0 on Windows because a SD crash on the raspy.
-
If you switched from FOSHKplugin + db on same 'board' to FOSHKplugin an a 'board' and db to a different 'board' it may be a firewall problem
-
Hi!
I checked and there is no error message on FOSHKplugin (or i was unable to find it).
You should have a look to the snd-foshkplugin.log log file and search for a message (for this specific forward FWD-xx) like:
03.01.2022 10:11:23.877 <ERROR> FWD-53: InfluxDB sending of 324 values to TestData@192.168.15.252:8086: 401: {"code":"unauthorized","message":"Unauthorized"} (3 tries)
In my example this is indeed a permission issue.
I just have installed the InfluxDB v2.1.1 on Windows but don't find the compatibility settings to configure nor the credentials for the database.
Have to investigate further ...
I switched from 1.8 on a RaspberryPi to a 2.0 on Windows because a SD crash on the raspy.
And there's no v1.8 for Windows available anymore?
Oliver
-
If you switched from FOSHKplugin + db on same 'board' to FOSHKplugin an a 'board' and db to a different 'board' it may be a firewall problem
Yes, I checked this too because the web UI was not reachable from another PC but I have an ESP8266 thet upload data without problems using the influxdb official library. Now I reach the web UI but it refuses to log me in. I have to search.
Also Grafana, in the same PC, cannot access to InfluxDB. I have to study more!
Hi!
And there's no v1.8 for Windows available anymore?
I wish to test the new 2.0 avoiding future switching but I believe that will install it also.
-
Hi!
There is another updated public beta (https://foshkplugin.phantasoft.de/files/generic-FOSHKplugin-0.0.9Beta.zip) of FOSHKplugin v0.09.
A few minor bugs have been fixed and the installation script of the generic version has been optimised regarding WSL (Windows Subsystem for Linux).
Additionally, a firmware problem with the current firmware version v2.1.0 of the GW2000 is bypassed - the key "runtime" is not transferred correctly from the GW2000.
As a new feature of this beta there is the display and output of the actual transmission interval and - if INTVL_WARNING = True - also a warning via Log/UDP/http/Pushover, if the actual (measured) transmission interval is 10% above the interval configured in the weather station (WS_INTERVAL).
The time interval in seconds between the current and the last transmission of the weather station is output as isintvl. The average value of the last 10 transmissions (without the largest and smallest interval) is output as isintvl10.
Using JSON, MQTT or InfluxDB, an analysis of the actual transmission rate of the weather station can thus be generated very easily.
Whether this function will be included in the final v0.09 release is not yet decided. I will gladly take your hints into account in my decision.
But now I urgently need such an analysis option - currently I have considerable (!) differences between configured and actual interval with both the HP3501 and the HP2551C.
An update from an existing public beta v0.09 is done by
sudo -u username ./generic-FOSHKplugin-install.sh -upgrade generic-FOSHKplugin-0.0.9Beta.zip
If there are problems or if you are upgrading from a previous version, you may need to run a one-time
sudo -u username ./generic-FOSHKplugin-install.sh -repair
should be executed. username is the name of the user in whose context FOSHKplugin is running.
Please test and report any problems or questions or wishes.
Thanks a lot and have a nice weekend!
Oliver
To the attachment:
The green and orange graphs show the measured interval of two GW1000s. This is set to 30 seconds and is also adhered to.
However, the yellow graph shows the measured interval of an HP3501, which is configured to 60 seconds. For unclear reasons, however, the interval is usually 90 seconds.
A similar behaviour is shown by an HP2551C (light blue) that is supposed to transmit every 30 seconds, but actually only does so every 40 seconds.
The red and dark blue curves show the interval over the last 10 transmissions.
For such graphics I needed the new key isintvl and isintvl10.
Maybe you can do something with them?
-
......
But now I urgently need such an analysis option - currently I have considerable (!) differences between configured and actual interval with both the HP3501 and the HP2551C.
.....
I had done tests myself after having noticed the discrepancy between the interval set in WSView and gaps between arrivals of the data packages - and compared to a GW1000 and a WS2320E.
Results:
- the GW1000/WH2650/GW2000 post accurately (with one additional second: 16s set, 17s factual, but that negligable)
- the gaps between postings of the HP2551 are much bigger - double the time or more
- the gaps between postings of the WS2320E are also bigger, but not as big as with the HP2551
On enquiry with Ecowitt they stated that the differences come from the different hardware used:
the GW1000 uses a SoC for the WiFi module, i.e. the WiFi SoC has its own processing faculty, whereas the other consoles use a WiFi modem which is managed by the central (and only) processor of the console. Obviously the workload is too high to finish the transmissions in time (or the modem doesn't have sufficient throughput capacity).
The WS2320E is closer to the set values in WS View than the HP2551. This can be explained by the different payload of a post (in my case): the WS2320E sends only the classical sensors (T/H/P in/outside, rain, wind, solar), that's all it reads and can send, whereas my HP2551 sends data for all of my sensors (about 30 - 40 values more than the WS2320E including the battery status).
The time gaps between transmissions were measured with FOSHKplugin (raw-foshkplugin.log) and the weewx interceptor driver (for control).
Maybe someone else could also have a look into this phenomenon and report back here, even using @olicat's need (temporary) feature in the new 0.09 Beta.
If it is really hardware related, then, however, nothing much that can be done about it.
-
There is another post ( a few months back, don't remember exactly ) about this custom upload interval stability of gw1000.
It was noted that it may be related to uploading to different online weather services.
Since then I disabled uploading to wu, set custom upload interval to 59" and find the uploading interval more stable.
This is yestarday graph ( uploading to ecowitt.net, and custom upload to my meteotemplate site )
[ You are not allowed to view attachments ]
This is last 1 June graph ( uploading to ecowitt.net, wu, and custom upload to my meteotemplate site, upload interval was set to 60 )
[ You are not allowed to view attachments ]
-
There is another post ( a few months back, don't remember exactly ) about this custom upload interval stability of gw1000.
It was noted that it may be related to uploading to different online weather services.
Since then I disabled uploading to wu, set custom upload interval to 59" and find the uploading interval more stable.
....
yes, but my tests were done inside the same local network and the receiving server has an i5-4 core processor and a SSD disk and a 1 Gbits/s network interface.
Unlike the weather servers of WU etc. there is no potential traffic congestion (locally or in the internet) or server overload.
Still the consoles show that time lag behaviour (except for GW1x00, GW2000, WH2650 - they show a constant interval on the sender and receiver end).
-
There is another post ( a few months back, don't remember exactly ) about this custom upload interval stability of gw1000.
It was noted that it may be related to uploading to different online weather services.
I think you're talking about my topic: https://www.wxforum.net/index.php?topic=42587.0
I already asked Ecowitt if they can do something about it, but they're not really responding to my emails. I have to chase them time by time to get an answer. If they respond with a 'no that's not possible' then this is fine, but then at least we know it.
-
from what they (Ecowitt) wrote it was clear that it is hardware related ... (see my earlier post)
the processing power and/or modem bandwidth is simply too small, especially when you have many sensors.
The later on upcoming sensor "inflation" might not yet have been considered in the design of the HP2551.
(the workaround, for the so far rather few users - compared to HP2551 consoles sold - who [think they] need exact timing for the custom server postings, is a GWxy00).
And I don't think they will make a big withdrawal and exchange program as it's done with cars and car parts.
In a new display console design they may consider this.
I assume that the WN19x0 console has a similar hardware setup as the GWxxxx devices.
Maybe some owners of this console can perform some tests with it
-
Hello everyone, I read this Post, but I am not very good at computers, just the basics. If I want to install FOSHKplugin what does it need as hardware in addition to my ASUS windows. Thank you.
-
Hi!
If I want to install FOSHKplugin what does it need as hardware in addition to my ASUS windows.
FOSHKplugin needs a Linux system running 24/7 to work as desired.
It should be possible to run it in a virtual machine on Windows - like WSL on Windows 10/11.
As dedicated hardware I recommend a Raspberry Pi 3B+ or 4.
There are also positive reports of an installation on a NAS.
Regards, Oliver
-
Hi!
If I want to install FOSHKplugin what does it need as hardware in addition to my ASUS windows.
FOSHKplugin needs a Linux system running 24/7 to work as desired.
It should be possible to run it in a virtual machine on Windows - like WSL on Windows 10/11.
As dedicated hardware I recommend a Raspberry Pi 3B+ or 4.
There are also positive reports of an installation on a NAS.
Regards, Oliver
This could be ran on any of the home automation packages too. (homeassistant, homebridge, hoobs)
-
Hello everyone, thank you for your answers, that's what I thought, I'll prepare all this soon.
-
Has anyone created a FOSHKplugin docker for raspberry? I'm a docker n00b, but it sure would be useful.
-
I just got an ambient weather WS-2000 earlier this week and while I was investigating how to get data out of it I ran across FOSHKPlugin. I had two main goals. One was to get data from the weather station to display on my all sky camera and the other was get the data (as much as is supported) into HomeKit. A forwarder for each was defined and I was off to the races. I was amazed at how quickly it all came together. Thanks for such a great piece of software!
This, however, led me to be more ambitious and I thought I'd try forwarding to APRS. I set up a forward that looked like this:
[Forward-2]
FWD_ENABLE = True
FWD_CMT = APRS
FWD_URL = rotate2.aprs.net
FWD_INTERVAL = 600
FWD_IGNORE =
FWD_TYPE = APRS
FWI_SID = AC4LT-13
FWD_PWD = <the not so secret passcode>
FWD_STATUS = False
FWD_MQTTCYCLE = 0
FWD_EXEC =
But, this isn't working. I'm getting REQERR in the send log. I don't know exactly what the data in the log should look like but I'm not seeing my callsign in there. Instead I get this:
rotate2.aprs.net:14580?SID=FOSHKweather&stationtype=AMBWeatherV4.3.2&dateutc=2022-02-10+19:41:23&tempinc=23.7&battin=1&humidityin=31&baromrelhpa=1011.72&baromabshpa=974.03&tempc=10.9&battout=1&humidity=31&winddir=282&winddir_avg10m=284&windspeedkmh=6.92&windspdkmh_avg10m=12.23&windgustkmh=20.12&maxdailygust=33.15&hourlyrainmm=0.0&eventrainmm=0.0&dailyrainmm=0.0&weeklyrainmm=0.0&monthlyrainmm=0.0&yearlyrainmm=0.0&solarradiation=96.69&uv=0&batt_co2=1&dewptc=-5.6&windchillc=10.9&feelslikec=10.9&heatindexc=8.8&windgustkmh_max10m=20.12&brightness=12250.6&cloudm=2377.0&sunhours=4.97&ptrend1=0&pchange1=0.0&wnowlvl=2&wnowtxt=wechselhaft
The SID=FOSHKweather seems suspicious and the data fields don't seem like right. I'm sure it's something I'm doing wrong but I don't see what.
Anyone have any ideas?
-
Hi!
Which version of FOSHKplugin did you install?
Is this v0.9 (public beta) already?
Because the former versions don't support APRS.
Oliver
-
Will the "FOSCHKplugin" allow me to use "weewx" and "Cumulus MX" from the "WS View app; with only one customized page?
"FOSCHKplugin" is installed; not configured. Does "weewx" find the "FOSCHKplugin" without additional configuration?
Running "weewx" on a Raspberry Pi, Model 3B+, 24/7 that currently is uploading data to "WU" and "CWOP."
Weather station is a Tycon Systems, TP3000WC.
William
-
Aha! I didn't realize there was a beta version and installed the version from this link (http://foshkplugin.phantasoft.de/files/generic-FOSHKplugin.zip) following along the instructions.
)
-
Hi!
Aha! I didn't realize there was a beta version and installed the version from this link
Then I understand why APRS does not work for you - that will only come with v0.09!
But you are welcome to use the public beta now - it contains APRS support and this beta is also very close to the release.
There are a few interesting new functions (such as the remapping of values and keys) in addition to the new support for APRS and EWUDP (such as for Personal Weather Tablet).
To update, please change to the installation directory of FOSHKplugin (/opt/FOSHKplugin/) on the console or via ssh and start there:
sudo -u username ./generic-FOSHKplugin-install.sh -upgrade generic-FOSHKplugin-0.0.9Beta.zip
Where username corresponds to the user name in whose context FOSHKplugin is running (e.g. owner of the log files).
The settings should remain the same.
The complete changelog can be found here (https://foshkplugin.phantasoft.de/gerenric/) under "Version History".
Regards, Oliver
-
Hi William!
Will the "FOSHKplugin" allow me to use "weewx" and "Cumulus MX" from the "WS View app; with only one customized page?
Yes, you can create almost any number of forwards (admittedly, there are only 100) with FOSHKplugin. One for weewx, one for CMX one for PWT one for ... etc.
Does "weewx" find the "FOSHKplugin" without additional configuration?
WeeWX expects the weather station to send the data itself to a specific IP address and the appropriate port.
When setting up FOSHKplugin, the required parameters (custom server settings) are automatically written into the weather station (do you want to write settings into the weather station? (Y/N)).
This can also be done again later with
sudo -u username ./generic-FOSHKplugin-install.sh -install
The weather station then sends the data to FOSHKplugin. And FOSHKplugin forwards the incoming data to all configured forwards.
So you need a forward in foshkplugin.conf that looks something like this:
[Forward-1]
FWD_URL = http://weewx-host:weewx-port # URL of destination
FWD_TYPE = RAWEW # RAWEW: Ecowitt untouched
Where weewx-host corresponds to the IP address of the computer on which weewx is running and weewx-port to the corresponding port.
For another forward to CMX you need another forward:
[Forward-2]
FWD_URL = http://cmx-host:cmx-port # URL of destination
FWD_TYPE = RAWEW # RAWEW: Ecowitt untouched
Here cmx-host corresponds to the IP address of the host on which CMX is running and cmx-port to the respective port.
I don't know exactly whether weewx and CMX also support the Ambient Weather format. If so, you could also specify AMB as FWD_TYPE.
Regards, Oliver
-
get the data (as much as is supported) into HomeKit
How do you get the data into HomeKit with FOSHKplugin? And which and for what reason?
I only ask this because there might be several ways to do this - and so far I haven't had any contact with HomeKit (I don't know anyone who uses FOSHKplugin for this either).
Oliver
-
Most of the home automation platforms now have ecowitt integrations. The issue is they all want that custom server field out of WS_view.
Where FOSHKplugin shines is WS_view to FOSHKplugin -> then to all other places (website custom feed as normal ecowitt repeater, homebridge/hoobs/homeassistant feed as normal ecowitt repeater, PWS, etc (non-ws_view weather sites).
-
Then I understand why APRS does not work for you - that will only come with v0.09!
Thanks for the instructions! Giving it a try now.
-
How do you get the data into HomeKit with FOSHKplugin? And which and for what reason?
I only ask this because there might be several ways to do this - and so far I haven't had any contact with HomeKit (I don't know anyone who uses FOSHKplugin for this either).
I'm almost embarrassed to say that the primary reason was so I could ask Siri what the temperature was in the back yard. Seems like a lot of work for that bit of payback. But, it was an interesting challenge!
Here's what I did:
FOSHKplugin -> MQTT (mosquitto) -> MQTTThing (Homebridge plugin)
Apple's Home app only seems to handle temperature, humidity and the light sensor but the Eve Home app handles more weather data. Might use the light sensor to aid in some lighting automation but mostly it was a learning experience to see what I could do. My primary goal was to get live weather data onto my all sky camera (http://home.ac4lt.org:9876/). That turned out to be pretty easy thanks to FOSHKplugin and some code on GitHub from xenophod.
-
Hi!
FOSHKplugin -> MQTT (mosquitto) -> MQTTThing (Homebridge plugin)
A good decision.
I am pleased that the MQTT feature is so well received - I had initially resisted it somewhat. But MQTT is now a quasi-standard in home automation.
And even the weather data can then be integrated via this.
Nice!
Oliver
-
@ Olicat
Rasp Pi has an ipAddress of 10.0.0.8; however, not sure what port it uses. WS View, customized settings: ip is 10.0.0.8, port is 8000 path = /, interval = 30 ; settings enable interceptor driver with ecowitt-client.
Confused about the WS View settings; do they change to whatever specified for LB_IP and LBU PORT or do they remain 10.0.0.8, 8000?
FOSHKplugin is running in weewx. I have no values set for LB_IP and LBU PORT.
Cumulus MX is not updating. FWD were set according to your earlier reply.
Thank you for your plugin and community support. Apologies for my confusion.
William
-
I am pleased that the MQTT feature is so well received - I had initially resisted it somewhat. But MQTT is now a quasi-standard in home automation.
Considering that before Tuesday I had never touched either FOSHKPlugin or MQTT, I'm amazed that came together so quickly and painlessly. It has me dreaming of building a new front end website for the all sky camera that brings together information from a variety of sources which could be a rabbit hole that could swallow me.
Alas, the APRS hookup is giving me a bit more grief. I did the 0.09 upgrade and the send log shows that it sent a message though I don't see anything showing up at a site like aprsdirect. I'm sure I can sort through that though. Of more concern is that FOSHKplugin stops processing messages from the weather station. I get the first message and then nothing after that. I removed all of my forwarders but the one sending to the allsky camera (a simple RAW forwarder) and the same thing happens. I see only the first push from the weather station in the raw long and then nothing.
I wiped the directory and installed 0.09 from scratch and got the same behavior. Wiped again and installed 0.08 and it's all behaving well for the RAW and MQTT forwarders.
This is on a recent Debian Bullseye VM install (5.10.0-11-amd64). I'm going to do another fresh install and see if I messed up somewhere along the line or if I can get some better info to feed back to you.
-
Hi!
Wiped again and installed 0.08 and it's all behaving well for the RAW and MQTT forwarders.
Probably you have to repair the installation of FOSHKplugin (once) after upgrading from v0.08 to v0.09.
Just start after the upgrade-installation a
/opt/FOSHKplugin/generic-FOSHKplugin-install.sh -repair
Otherwise, the log file will most likely also give a hint as to why FOSHKplugin is not working correctly.
Oliver
-
Appreciate the suggestions! Though in this case they didn't yield anything.
I did the repair (which didn't look like it changed anything). Restarted the service and I get one new entry in the raw log and then a few minutes later get the watchdog alert in the "log-" log that weather data hasn't been reported for more than 180 seconds. But nothing other than that. I have the log level set to ALL.
Is there anything else I can try or enable to get more details?
-
Oliver, I went looking in syslog and think I found the culprit:
--------
Feb 11 12:45:52 weathergirl foshkplugin[21416]: Exception occurred during processing of request from ('192.168.1.70', 21652)
Feb 11 12:45:52 weathergirl foshkplugin[21416]: Traceback (most recent call last):
Feb 11 12:45:52 weathergirl foshkplugin[21416]: File "/usr/lib/python3.9/socketserver.py", line 316, in _handle_request_noblock
Feb 11 12:45:52 weathergirl foshkplugin[21416]: self.process_request(request, client_address)
Feb 11 12:45:52 weathergirl foshkplugin[21416]: File "/usr/lib/python3.9/socketserver.py", line 347, in process_request
Feb 11 12:45:52 weathergirl foshkplugin[21416]: self.finish_request(request, client_address)
Feb 11 12:45:52 weathergirl foshkplugin[21416]: File "/usr/lib/python3.9/socketserver.py", line 360, in finish_request
Feb 11 12:45:52 weathergirl foshkplugin[21416]: self.RequestHandlerClass(request, client_address, self)
Feb 11 12:45:52 weathergirl foshkplugin[21416]: File "/usr/lib/python3.9/socketserver.py", line 720, in __init__
Feb 11 12:45:52 weathergirl foshkplugin[21416]: self.handle()
Feb 11 12:45:52 weathergirl foshkplugin[21416]: File "/usr/lib/python3.9/http/server.py", line 427, in handle
Feb 11 12:45:52 weathergirl foshkplugin[21416]: self.handle_one_request()
Feb 11 12:45:52 weathergirl foshkplugin[21416]: File "/usr/lib/python3.9/http/server.py", line 415, in handle_one_request
Feb 11 12:45:52 weathergirl foshkplugin[21416]: method()
Feb 11 12:45:52 weathergirl foshkplugin[21416]: File "/opt/FOSHKplugin/foshkplugin.py", line 4098, in do_GET
Feb 11 12:45:52 weathergirl foshkplugin[21416]: if INTVL_WARNING: # warn if measured interval is more than 10% above the agreed send interval
Feb 11 12:45:52 weathergirl foshkplugin[21416]: UnboundLocalError: local variable 'INTVL_WARNING' referenced before assignment
Feb 11 12:45:52 weathergirl foshkplugin[21416]: -----
-
Hi!
UnboundLocalError: local variable 'INTVL_WARNING' referenced before assignment
You have indeed found a bug that I hadn't noticed before!
However, it only occurs with GET (WU, Ambient) data deliveries, which I test a little less due to the lack of a Ambient Weather-Station.
Thanks for that!
This error is fixed in the new beta v0.09.
Please start the update procedure again:
sudo -u username ./generic-FOSHKplugin-install.sh -upgrade generic-FOSHKplugin-0.0.9Beta.zipThis should pull the updated beta from my server.
Hopefully that's all ...
Thanks and sorry!
For all others:
No need for updating the public beta v0.09 except you get your data from an Ambient Weather station.
But it doesn't hurt either.
Oliver
-
No worries, Oliver! Thank you for an amazing piece of software! Glad I could help you track down a bug. I'll give that update a try and let you know.
-
That does indeed solve that problem! Now I can return to figuring out the APRS stuff. I do have one (hopefully) last question for you on the RAW forwarder. Should that be forwarding all the fields from the weather station?
Here is the raw data starting after the PASSKEY field:
&dateutc=2022-02-11+18:27:58&tempinf=74.1&battin=1&humidityin=32&baromrelin=29.841&baromabsin=28.728&tempf=62.8&battout=1&humidity=27&winddir=247&winddir_avg10m=251&windspeedmph=8.5&windspdmph_avg10m=10.3&windgustmph=18.3&maxdailygust=20.6&hourlyrainin=0.000&eventrainin=0.000&dailyrainin=0.000&weeklyrainin=0.000&monthlyrainin=0.000&yearlyrainin=0.000&solarradiation=446.10&uv=4&batt_co2=1&isintvl=64&isintvl10=64&dewptf=28.3&windchillf=62.8&feelslikef=62.8&heatindexf=60.0&windgustmph_max10m=18.3&brightness=56520.9&cloudf=8891&sunhours=0.28
and then on the send log I don't see fields like dewptf in the output:
dateutc=2022-02-11+18:30:06&tempinf=74.1&battin=1&humidityin=32&baromrelin=29.835&baromabsin=28.722&tempf=62.6&battout=1&humidity=28&winddir=244&winddir_avg10m=251&windspeedmph=6.3&windspdmph_avg10m=10.3&windgustmph=18.3&maxdailygust=20.6&hourlyrainin=0.000&eventrainin=0.000&dailyrainin=0.000&weeklyrainin=0.000&monthlyrainin=0.000&yearlyrainin=0.000&solarradiation=446.49&uv=4&batt_co2=1
I'm not sure what expected behavior is. I based my code that consumes this on someone else's code which was set up to get the feed directly from the weather station console which is why I chose RAW as the forwarder but now that I (think) I have a better handle on how this is working I could probably change this to use a different forwarder type if that would be better.
-
Hi!
Should that be forwarding all the fields from the weather station?
Yes. All fields coming from the station should be delivered via http/GET (!) with FWD_TYPE = RAW.
As far as I know the dewptf is not part of the fields sent by the station itself. So FOSHKplugin does the calculation.
But all calculated fields will not be sent in FWD_TYPE = RAW or RAWEW.
So it depends on your needs:
If you want to forward the data in Ecowitt format (via http/POST) then you should use EW instead.
That's the way a Ecowitt station is sending data.
And if you would like to send the data in Ambient Weather format with http/GET (like a Ambient station) and all calculated fields you should use AMB.
Oliver
-
Hi!
Now I can return to figuring out the APRS stuff.
Regarding the APRS config please have a look to the receipt Sending weather station data via APRS/CWOP (from v0.09) (https://loxwiki.atlassian.net/wiki/spaces/LOXBERRY/pages/1252524456/FOSHKplugin+-+generic+version#APRS).
You will have to configure also the Coordinates-section of the Config-file.
Oliver
-
Hi William,
Confused about the WS View settings; do they change to whatever specified for LB_IP and LBU PORT or do they remain 10.0.0.8, 8000?
from the log I see that FOSHKplugin is not started at all because you did not configure it properly (the local http port is missing):
Feb 11 09:58:50 raspberrypi foshkplugin[3615]: <ERROR> can not open http-socket *:
While FOSHKplugin is not running, neither weewx nor CMX will be delivered with data.
WeeWX still gets the data from the weather station because the custom server settings still point to direct delivery to weewx.
You should now look at the settings in WS View again and make a note of them - they are later necessary for forwarding to weewx.
Then you should restart the complete configuration process of FOSHKplugin - including the download of the latest beta:
sudo -u username ./generic-FOSHKplugin-install.sh -upgrade generic-FOSHKplugin-0.0.9Beta.zip
You can skip the first two questions regarding UDP by pressing Enter. But it is important to specify the "ip address of local system" (10.0.0.8) and the "local http port" (probably 8080).
You should answer Y to the question about saving the configuration and writing the configuration to the weather station. Also when asked about starting as a service.
Afterwards the FOSHKplugin service should be running - so you may configure the weewx-forward in the foshkplugin.conf:
[Forward-1]
FWD_URL = http://10.0.0.8:8000 # URL of destination
FWD_TYPE = RAWEW # RAWEW: Ecowitt untouched
Then restart the service with:
sudo service foshkplugin restart
and weewx should get the data again. But now via FOSHKplugin.
Now you can take care of the configuration of the forwarding to CMX.
Oliver
-
Experiencing discrepancies between Weatherundergroud and CWOP. Including screen captures showing discrepancies; plus screen image of Forward from foshkplugin.conf.
https://www.wunderground.com/dashboard/pws/KININDIA548 (https://www.wunderground.com/dashboard/pws/KININDIA548)
William
-
Hi William,
Experiencing discrepancies between Weatherundergroud and CWOP.
I don't quite understand the objective of this forward.
If you want to transmit via APRS, the destination should be able to handle it.
However, you are sending via APRS protocol to a web server on http://10.0.0.8:8000 which looks more like the weewx destination.
This will not work!
Of course, you can also send via weewx to APRS. However, this configuration would then have to be set up in weewx.
If you want to send via FOSHKplugin to CWOP, please refer to the recipe (https://loxwiki.atlassian.net/wiki/spaces/LOXBERRY/pages/1252524456/FOSHKplugin+-+generic+version#APRS) "Sending weather station data via APRS/CWOP (from v0.09)":
[Forward-23]
FWD_TYPE = APRS
FWD_URL = cwop.aprs.net:14580
FWD_SID = CWOP-ID
FWD_PWD =
FWD_ENABLE = True
FWD_INTERVAL = 300
If you only have Forward-1 to weewx and this Forward-2 the data for your station at CWOP is not generated by FOSHKplugin and comes from another source.
Oliver
-
Hi!
Triggered by the last messages here, I have now put together a few possible solutions for self-help with known problems with FOSHKplugin as a recipe problem solving (https://loxwiki.atlassian.net/wiki/spaces/LOXBERRY/pages/1252524456/FOSHKplugin+-+generic+version#problemsolving).
Hope it helps.
Oliver
-
Hi
I wonder if it is possible to implement "max_wind_speed today" in FOSHKplugin in a future version. I use ecowitt upload in pwsdashboard, and max wind speed is displayed incorrectly. I think the reason is that there is no separate field for this.
Maximum gusts are displayed correctly
My testsite: https://www.alfmagne.no/RPi/ using ecowitt uopload
My mainsite: https://www.alfmagne.no/pwsWD/ using realtime.txt, and shows the correct wind speed.
Alf
-
Hi!
I wonder if it is possible to implement "max_wind_speed today" in FOSHKplugin in a future version.
In the Ecowitt format there is actually no definition for the max. wind speed of the day.
Therefore, PWSDashboard remembers the highest value it receives from the station (or from FOSHKplugin) and outputs this value as the maximum.
If this does not work for you (it should!) I can only recommend to ask in the PWSDashboard-Forum (https://www.weather-watch.com/smf/index.php/board,77.0.html) what could be the reason for this.
Who generates the realtime.txt for you?
Beside that:
FOSHKplugin calculates/saves various data and could also give this to the Ecowitt stream.
In this way, the minimum and maximum values of a day are also written for various parameters together with the corresponding times and, if desired and possible, also output in the output format.
But on the receiver side, this field must of course be known and processed.
This is difficult to realise outside the standard (here Ecowitt protocol).
For wind this would be e.g. windspeedmph_max and windspeedmph_max_time resp. windspeedkmh_max and windspeedkmh_max_time (I do not calculate minimum values in this case).
Just open a web browser and go to the url http://ipaddress:port/minmax&status&units=e (imperial) or http://ipaddress:port/minmax&status&units=m for metric units (ipaddress = host where FOSHKplugin is running and port its port). FOSHKplugin knows all these values and could of course make them available to other systems (and does so, if there is a corresponding possibility according to the format definition). EVAL_VAUES should be enabled in Config-file.
So:
Yes, FOSHKplugin could in future also output other values such as the max. wind speed of the current day in Ecowitt format. However, since there is currently no format definition for these extended fields, this will hardly be usable. Apart from that, I don't really see any need for PWSDashboard because it determines and saves the min/max values itself. But of course it should do this correctly.
Oliver
-
Who generates the realtime.txt for you?
It is actually FOSHKplugin that generates and uploads the realtime.txt file. In addition, I also run a cronjob that uploads data from the extra temp / hum sensor.
This is a combination that works well for me, but the best thing has of course been that the ecowitt upload works properly.
I will ask in the PWSDashboard-forum.
thank you Oliver [tup]
Alf
-
Can Foshkplugin forward to CumulusMX?
Tried this forward; does not wok:
[Forward-2]
FWD_ENABLE = True
FWD_CMT = Cumulus MX
FWD_URL = 10.0.0.146:8998/realtime.txt
FWD_INTERVAL = 60
FWD_IGNORE =
FWD_TYPE = EW
FWD_SID =
FWD_PWD =
FWD_STATUS = False
FWD_MQTTCYCLE = 0
FWD_EXEC =
Station type(required) is set to HTTP Upload (ecowitt).
10.0.0.146 is the computer runniing CumulsMX (Windows pc.)
Weewx is tunning on Raspberry Pi 10.0.0.8
William
-
Hi!
Can Foshkplugin forward to CumulusMX?
Yes.
CumulusMX can accept the data in Ecowitt format. You should therefore create a forward with FWD_TYPE EW or RAWEW.
Have a look here (https://cumulus.hosiene.co.uk/viewtopic.php?p=160261&sid=de53515302e604c857cd57e64eb8ab76#p160261).
You only need a forward in foshkplugin.conf like this:
[Forward-77]
FWD_URL = http://10.0.0.146:8998/station/ecowitt
FWD_TYPE = EW
FWD_CMT = for CMX
FOSHKplugin can also output a realtime.txt - but I don't know if and how you can import this file into CMX.
So far, I only know the realtime.txt as an output format.
Oliver
-
Issue with Cumulus MX
Entered forward as given in reply. Still no updates in Cumulus; however, using following customized, WS View settings
Attachment. Cumulus gets updates.
Changed from EW to RAWEW; no difference, no updates.
Cumulus Wizard setting? Interval setting?
William
-
Hi!
Issue with Cumulus MX
I have just installed CMX here and created another forward for CMX:
[Forward-77]
FWD_TYPE = EW
FWD_CMT = CMX
FWD_URL = http://192.168.15.252:8998/station/ecowitt
and entered HTTP-upload (Ecowitt) as the "Station type" in the CMX setup wizard.
The data was immediately displayed in the CMX dashboard!
The only thing I can currently imagine is that FOSHKplugin does not receive any data from the weather station. Then, of course, it cannot send any data to the forwards.
Please keep in mind:
The weather station sends data to FOSHKplugin and FOSHKplugin sends the received data to the forwards.
The IP address of FOSHKplugin and its port must therefore be entered in the WS View and the IP addresses and corresponding ports of the target systems in the forwards.
During the configuration with ./generic-FOSHKplugin-install.sh this should automatically be ensured.
So please check again in WS View whether the data configured there actually point to FOSHKplugin. Either enter the correct data manually in WS View or start on the shell of the FOSHKplugin host:
cd /opt/FOSHKplugin
sudo ./foshkplugin.py -scanWS
sudo ./foshkplugin.py -setwsconfig WS_IP WS_PORT LB_IP LBH_PORT WS_INTERVAL
sudo ./foshkplugin.py -writeWSconfig
where WS_IP is the IP address of the weather station, WS_PORT the port (45000), LB_IP the local IP address of FOSHKplugin host and LBH_PORT 8080 and WS_INTERVAL the desired transmission interval (in seconds).
Or just run ./generic-FOSHKplugin-install.sh again.
A good test to check the reception of data from the weather station in FOSHKplugin is to call the URL http://ipaddress:port/status&minmax in the web browser - where ipaddress is the IP address of the host on which FOSHKplugin is running and port is the corresponding port.
Oliver
-
Hi!
I wonder if it is possible to implement "max_wind_speed today" in FOSHKplugin in a future version.
Triggered by your post, I have implemented a change for the next public beta that allows you to add any values known to FOSHKplugin as a key/value pair to any output line.
This means that min/max values can also be forwarded - the target system just has to be able to handle them.
Example:
To additionally transmit the maximum value of the wind of the current day, a FWD_REMAP = wspeedmaxd=@windspeedmph_max in the corresponding forward definition is sufficient. The keyname (here wspeedmaxd) is freely definable.
And the possible values are quite extensive:
minmax_init 1645138810
baromrelin_min 29.1116
baromrelin_min_time 1645209363
baromrelin_max 29.7077
baromrelin_max_time 1645161720
humidity_min 60
humidity_min_time 1645221510
humidity_max 96
humidity_max_time 1645193872
tempf_min 37.8
tempf_min_time 1645162665
tempf_max 49.1
tempf_max_time 1645209057
windchillf_min 34.9
windchillf_min_time 1645165068
windchillf_max 49.1
windchillf_max_time 1645209057
heatindexf_min 35.2
heatindexf_min_time 1645162053
heatindexf_max 47.8
heatindexf_max_time 1645209057
feelslikef_min 34.9
feelslikef_min_time 1645165068
feelslikef_max 49.1
feelslikef_max_time 1645209057
dewptf_min 32.7
dewptf_min_time 1645149273
dewptf_max 46.6
dewptf_max_time 1645210012
tempinf_min 64.8
tempinf_min_time 1645167527
tempinf_max 72.1
tempinf_max_time 1645161175
humidityin_min 35
humidityin_min_time 1645166583
humidityin_max 48
humidityin_max_time 1645201740
temp1f_min 38.8
temp1f_min_time 1645165000
temp1f_max 47.5
temp1f_max_time 1645210624
humidity1_min 63
humidity1_min_time 1645221544
humidity1_max 88
humidity1_max_time 1645210505
temp2f_min 66.9
temp2f_min_time 1645167561
temp2f_max 71.4
temp2f_max_time 1645162410
humidity2_min 32
humidity2_min_time 1645167063
humidity2_max 38
humidity2_max_time 1645212137
temp3f_min 67.3
temp3f_min_time 1645169932
temp3f_max 72.0
temp3f_max_time 1645161175
humidity3_min 29
humidity3_min_time 1645166978
humidity3_max 39
humidity3_max_time 1645207419
temp4f_min 37.6
temp4f_min_time 1645162801
temp4f_max 48.6
temp4f_max_time 1645209108
humidity4_min 58
humidity4_min_time 1645221527
humidity4_max 96
humidity4_max_time 1645200125
temp5f_min 37.8
temp5f_min_time 1645162784
temp5f_max 48.7
temp5f_max_time 1645209465
humidity5_min 58
humidity5_min_time 1645221493
humidity5_max 94
humidity5_max_time 1645197439
temp6f_min 65.5
temp6f_min_time 1645168309
temp6f_max 72.0
temp6f_max_time 1645162955
humidity6_min 28
humidity6_min_time 1645166652
humidity6_max 41
humidity6_max_time 1645201366
temp8f_min 65.8
temp8f_min_time 1645167612
temp8f_max 72.1
temp8f_max_time 1645159388
tf_co2_min 67.1
tf_co2_min_time 1645170444
tf_co2_max 76.1
tf_co2_max_time 1645194936
humi_co2_min 26
humi_co2_min_time 1645166978
humi_co2_max 41
humi_co2_max_time 1645207351
tf_ch1c_min 4.9
tf_ch1c_min_time 1645171264
tf_ch1c_max 5.9
tf_ch1c_max_time 1645216391
tf_ch2c_min 18.5
tf_ch2c_min_time 1645167803
tf_ch2c_max 22.1
tf_ch2c_max_time 1645160034
tf_ch3c_min 17.3
tf_ch3c_min_time 1645167493
tf_ch3c_max 22.7
tf_ch3c_max_time 1645160017
tf_ch4c_min 17.6
tf_ch4c_min_time 1645167578
tf_ch4c_max 22.9
tf_ch4c_max_time 1645159269
windspeedmph_max 11.41
windspeedmph_max_time 1645218229
windgustmph_max 18.35
windgustmph_max_time 1645217158
solarradiation_min 0.0
solarradiation_min_time 1645138810
solarradiation_max 149.12
solarradiation_max_time 1645174631
uv_min 0
uv_min_time 1645138810
uv_max 1
uv_max_time 1645173793
sunmins 4.883333333333332
last_suntime 1645167768
last_suncheck 1645222937
osunmins 23
last_osuntime 1645175723
last_osuncheck 1645222937
nsunmins 4.883333333333332
last_nsuntime 1645167768
last_nsuncheck 1645222937
rainratein_min 0.0
rainratein_min_time 1645138810
rainratein_max 0.496
rainratein_max_time 1645210318
dailyrainin_min 0.0
dailyrainin_min_time 1645138810
dailyrainin_max 0.197
dailyrainin_max_time 1645216459
soilmoisture1_min 42
soilmoisture1_min_time 1645174288
soilmoisture1_max 44
soilmoisture1_max_time 1645138810
soilmoisture2_min 48
soilmoisture2_min_time 1645207113
soilmoisture2_max 53
soilmoisture2_max_time 1645138810
soilmoisture3_min 78
soilmoisture3_min_time 1645138810
soilmoisture3_max 79
soilmoisture3_max_time 1645139303
soilmoisture4_min 58
soilmoisture4_min_time 1645138844
soilmoisture4_max 60
soilmoisture4_max_time 1645210454
soilmoisture5_min 48
soilmoisture5_min_time 1645203832
soilmoisture5_max 51
soilmoisture5_max_time 1645144545
soilmoisture6_min 48
soilmoisture6_min_time 1645170751
soilmoisture6_max 56
soilmoisture6_max_time 1645210590
soilmoisture7_min 49
soilmoisture7_min_time 1645179857
soilmoisture7_max 53
soilmoisture7_max_time 1645211287
soilmoisture8_min 48
soilmoisture8_min_time 1645171366
soilmoisture8_max 52
soilmoisture8_max_time 1645211542
I will have to write a recipe from time to time on what exactly can be done with this and how it is done. In any case, the REMAP function is quite powerful - it can not only swap mappings (e.g. tempf=tempinf or soilmoisture1=soilmoisture5) but also remove keys, define new static mappings (e.g. name=Oliver) but also create completely new keys (e.g. max_uv_day=uv_max).
I always wanted to have that. Thank you!
Oliver
-
Continued issue with Cumulus MX. No updates.
Ran sudo ./foshkplugin.py -scanws; no device was found; automatic configuration from running install.sh fails the same.
Port 8080 appears to be closed according to "Open Port Tool."
WS_IP is the "weather station IP"; is this the IP address displayed in the WS View app, device list or is it the IP address of where weewx is running?
Apologies for trouble I am having Oliver.
William
-
Hi William,
Continued issue with Cumulus MX. No updates.
you don't have problems with CMX (yet) but with the installation of FOSHKplugin at all.
I'll try to help via PM now to keep this thread readable.
Oliver
-
Hi
Example:
To additionally transmit the maximum value of the wind of the current day, a FWD_REMAP = wspeedmaxd=@windspeedmph_max in the corresponding forward definition is sufficient. The keyname (here wspeedmaxd) is freely definable.
Tests FWD_REMAP in 0.0.9 Beta, but gets errors when I use FWD_REMAP = wspeedmaxd=@ windspeedmph_max.
Find this in snd-foshkplugin.log
<ERROR> FWD-00: Remap: problem while remapping wspeedmaxd with @windspeedmph_max
But if I use FWD_REMAP = wspeedmaxd=@windgustmph (or @windspeedmph) then it works. Tested several field names that have underscores, and none worked.
Alf
-
Hi Alf,
Tested several field names that have underscores, and none worked.
that's true - this is not yet released in the currently available public beta. I have to test this first here (and make some docs).
If you would like to do a pre-test for it, please send me a PM. Then I can give you the internal beta that already contains this feature.
Oliver
-
i'm trying to forward to WeatherWizz and not being successful.
This is the forward that I created that is not working:
FWD_ENABLE = True
FWD_CMT = This is a permanent comment field for notes on this forward
FWD_URL = api.weatherwizz.com/ew/update/BAE....NBI/HGZ...GW/
FWD_INTERVAL = 16
FWD_IGNORE =
FWD_TYPE = EW
The attachment shows what they expect in the custom server setup.
-
Hi Jim,
i'm trying to forward to WeatherWizz and not being successful.
I'm not sure if that has been changed but I send to port 8088 and everything seems to be ok:
[Forward-49]
FWD_CMT = weatherwizz-Test
FWD_URL = http://api.weatherwizz.com:8088/ew/update/THISBEFORE/ANDAFTER/
FWD_TYPE = EW
FWD_SID = 0102030405060708090A0B0C0D0E0F00
FWD_ENABLE = True
Port 80 is dedicated to the frontend I guess.
The port is also mentioned on the pic you have provided. So just use port 8088 within the url.
Oliver
-
What should be put in the FWD_SID?
-
Hi!
What should be put in the FWD_SID?
Whatever you want.
You can also omit the FWD_SID completely, then the original PASSKEY of the station is sent along.
Oliver
-
Still failing for some reason. Any ideas on what I can check?
-
Hi!
The missing http:// in your FW_URL you already have added?
Oliver
-
This is the forward:
[Forward-55]
FWD_ENABLE = True
FWD_CMT = Weatherwizz
FWD_URL = http://api.weatherwizz.com:8088/ew/update/BAEHxxxxXNBI/HGZxxxxGW/
FWD_INTERVAL = 16
FWD_TYPE = EW
FWD_SID = 0102030405060708090A0B0C0D0E0F00
FWD_ENABLE = True
-
Hi Jim,
you should delete one line "FWD_ENABLE = True" - it is doubled. But I'm not sure if this is the reason.
And I'm not sure in which interval Weatherwizz is expecting the data. Perhaps (probably) 16 sec is too frequent.
Beside that yor forward-section seems to be ok.
You should check for permission errors while calling the FWD_URL (with complete user/password) in a web browser.
If authentication is ok there should be an "Success" output.
In case of too frequent calls you may get an "Error - too many updates, slow down there!" and if you have a typo in username/password "Error - station not registered".
But you can also check these error messages in the snd logfile snd-foshkplugin.log of FOSHKplugin - just search for FWD-55 there:
sudo grep "FWD-55" /opt/FOSHKplugin/snd-foshkplugin.log
Which return code do you get?
200 means OK, 400 means ERROR
Oliver
-
FWD-55 is not found in snd-foshkplugin.log
I deleted the FWD and re-entered it with the same results unfortunately.
No need to give any more time to this, I was only doing it to try and
get my station accessible by Alexa, which is not vital.
-
Hi!
An anecdote ...
Recently I was standing in the paddock and about every 30 seconds I received a push notification from one of my weather stations that the actual transmission interval of the station was significantly higher than the agreed transmission interval:
FOSHKplugin
From FOSHKplugin on 2022-02-21 at 17:25
<WARNING> real sending interval (41) mismatches the interval set to the weather station (30)
* 192.168.15.216; 21.02.2022 17:25:08 *
In principle, I like to be informed about such things promptly - but in the paddock I couldn't do anything with this knowledge!
After a while, of course, these constant messages got on my nerves and I wanted to turn them off. FOSHKplugin offers - also at runtime - the switching on and off of various functions. This also includes the interval warning or the push notifications.
The push notification clearly stated the reason for the message, the time and even which weather station this problem actually concerned.
But of course I couldn't remember which of my countless FOSHKplugin instances I would have to make the corresponding change to!
And it also took me a few tries until I had typed the correct URL into the mobile browser: http://ipaddress:port/FOSHKplugin/intvlwarning=disable.
Then finally there was peace!
But I was so annoyed that I quickly made a few changes to FOSHKplugin when I got home.
With next public beta there will be a clickable link in every push notification to the web interface of the triggering FOSHKplugin:
FOSHKplugin
From FOSHKplugin on 2022-02-23 at 16:43
missing data for mandatory sensor soilbatt1
* 192.168.15.236 for ws@192.168.15.215; 23.02.2022 16:43:52 *
Where the 192.168.15.236 is a link to the corresponding FOSHKplugin.
There, one then lands on a page on which all (!) URLs for controlling FOSHKplugin are listed as clickable links. So two clicks to disable something or to restart the weatherstation.
I think some of you will be happy about that too.
By the way, the cause of these constant error messages was a programming error - I fixed it afterwards.
Oliver
-
Hi!
Errors in the FOSHKplugin config file are serious. In the worst case, FOSHKplugin will no longer start.
But errors can also occur when configuring additional forwards. Each forward section must be uniquely named and only exist once.
If, for example, [Forward-1] is stored twice, only the first one is used and the second one with the same name is automatically deleted - with all its contents.
Whenever I want to set up a new forward (and in the meantime 100 forwards are possible per FOSHKplugin instance!) it is important to find the next free number - to prevent the forward designation from being assigned twice.
Up to now, the search was done manually for me via the command:
code]grep "\[Forward-" /opt/FOSHKplugin/foshkplugin.conf|sort -V[/code]
All forwards in the config file will then be displayed, sorted sensibly, so that it is easier to find the next free number.
In the next version of FOSHKplugin there will be a routine that reports duplicate sections in the config file (and two or three other common problems) and outputs the next free number and the first free gap.
This should make the search for a free number a little easier in the future:
# ./foshkplugin.py -checkconfig
checking config file /opt/FOSHKplugin/foshkplugin.conf
free section: [Forward-26]
next section: [Forward-89]
This function is also already included in the upcoming new public beta version.
Oliver
-
Hi!
There is once again a new public beta for FOSHKplugin v0.09.
Besides fixing some bugs that were found, there are also a few new functions that need some time for testing:
- the pushover notifications now additionally show the reporting host with a direct link to the FOSHKplugin web interface
- the general help page via http://ipaddress:port/FOSHKplugin/help showing all http commands to control FOSHKplugin
- the parameter -checkConfig for foshkplugin.py to output the next free [Forward-n]-section
start with sudo -u username ./foshkplugin -checkConfig - FWD_REMAP can now access all variables known to FOSHKplugin - see recipe Remapping keys/values (from v0.09) (https://loxwiki.atlassian.net/wiki/spaces/LOXBERRY/pages/1252524456/FOSHKplugin+-+generic+version#remap)
so you can now generate your own keys in most output formats and assign values to them
Example:
If you want to output the max. wind speed of the day as key windmaxday, you only have to enter FWD_REMAP = windmaxday = @windspeedmph_max under FWD_REMAP of the respective forward.
several assignments must be separated by a comma: FWD_REMAP = tempf_max = @tempf_max,tempf_max_time = @tempf_max_time
so if the output is in Ecowitt or WU format today, &tempf_max=45.3&tempf_max_time=1645788080 would be appended to the output line - the page with all available variables that can be accessed in the FWD_REMAP function or via getvalue: http://ipaddress:port/FOSHKplugin/keyhelp
You are welcome to use this version as well and report any errors, problems or ambiguities.
Especially the -checkConfig option is used more often by me now. I think this is also helpful for you.
Once again I have decided to do a feature freeze. So now I just want to reduce bugs to finally release v0.09.
To update, please change to the installation directory of FOSHKplugin (/opt/FOSHKplugin/) on the console or via ssh and start there:
sudo -u username ./generic-FOSHKplugin-install.sh -upgrade generic-FOSHKplugin-0.0.9Beta.zip
Where username corresponds to the user name in whose context FOSHKplugin is running (e.g. owner of the log files).
The settings should remain the same.
Users updating from a version earlier than v0.09Beta may need to run
sudo -u username ./generic-FOSHKplugin-install.sh -repair
after installation to reload required libraries.
Have fun!
Oliver
-
Beta running fine, no issues at all.
-
To the beta testers of the GW2000/WS90:
There is a problem with the current beta version v0.09 of FOSHKplugin and the processing of the data of the GW2000 with firmware v2.1.1.
I have fixed the problem here now and will release a new public beta shortly.
If you don't want to wait that long: please contact me!
Oliver
-
Hi!
The changes for GW2000/WS90 compatibility were more extensive than expected - I still had to make adjustments in many places.
Therefore, a new public beta with a slightly modified range of functions will be released.
- Bug fixed: UDP_MAXLEN for defining the max. length of a UDP datagram was not considered
- Problem fixed with GW2000/WS90 transmission with firmware v2.1.1 (inverted commas in rfdata)
- new config option Logging\BUT_PRINT = False respects IGNORE_LOG also for output on console (default: True)
can also be changed at runtime with http://ipaddress:port/FOSHKplugin/printignored=disable/enable - new config option Weatherstation\WS90_CONVERT = True to convert the special keys for rain values of a WS90 into the conventional ones if only these rain values are present (default=True)
The rain values of a WS90 combination sensor are transmitted by the station with their own separate keys.
If this option is activated (WS90_CONVERT = True), they are converted - provided the WS90 is the only rain sensor in the system:
rrain_piezo --> rainratein
erain_piezo --> eventrainin
hrain_piezo --> hourlyrainin
drain_piezo --> dailyrainin
wrain_piezo --> wekklyrainin
mrain_piezo --> monthlyrainin
yrain_piezo --> yearlyrainin
If another rain sensor is present, the values of both rain sensors are used for further processing, with those of the classic sensor being output as rain values.
You may override this behaviour forward-specific with FWD_REPLACE - for adjustments to support multiple FOSHKplugin instances in the LoxBerry version, changes were necessary that could also affect the generic-version
Therefore I ask again for active participation in the public beta test and for feedback. Thank you very much!
To update, please change to the installation directory of FOSHKplugin (/opt/FOSHKplugin/) on the console or via ssh and start there:
sudo -u username ./generic-FOSHKplugin-install.sh -upgrade generic-FOSHKplugin-0.0.9Beta.zip
Where username corresponds to the user name in whose context FOSHKplugin is running (e.g. owner of the log files).
The settings should remain the same but it is always good to save them beforehand.
Users updating from a version earlier than v0.09Beta may need to run
sudo -u username ./generic-FOSHKplugin-install.sh -repair
after installation to reload required libraries.
Have a nice weekend!
Oliver
-
I get 403 forbidden :-(
-
Sorry, fixed!
Oliver
-
Hi!
A small adjustment for the next release ...
A frequently observed problem is that the "http://" in the FWD_URL is forgotten when creating a forward, although it is mandatory for http requests. Users are then surprised that the corresponding forwards do not work.
In the next public beta, FOSHKplugin will automatically repair these incorrect URLs and only report this once in the log:
<WARNING> FWD-52: URL must start with "http://" - adapted to http://192.168.15.100/gib/es/nicht/52/
By default, this functionality is activated - but can be deactivated with the switch Export\URL_REPAIR = False in the config file.
Regards, Oliver
-
Weatherwizz is now working just fine. All I did was delete the forward and re-create the forward and it worked!
-
Hi
Running FOSHKplugin v 0.09 beta, and has a couple of times seen that max gusts show two different values in PWS Dashboard.
When I run http://192.168.10.185:8080/minmax&status&units=m I get these values:
maxdailygust 29.52
windgustkmh_max 34.92
windgustkmh_max_time 1648595358
windgustkmh_max shows the correct value
any idea
Alf
-
Hi!
I am not sure if I have understood your problem correctly.
maxdailygust 29.52
windgustkmh_max 34.92
windgustkmh_max_time 1648595358
PWSDashboard accepts the key maxdailygust in the Ecowitt output from the weather station and displays its value as the daily maximum of the gusts. Wim is welcome to correct me if I am wrong.
This key is generated in the weather station and output via Ecowitt protocol - without any modification by FOSHKplugin.
During the min/max calculation by FOSHKplugin, it is checked in each received transmission whether the value windgustmph coming from the station is greater than the daily value known so far.
If this is the case, this value is saved together with the corresponding time as windgustkmh_max (or windgustmph_max) and output if necessary.
So if there are differences between maxdailygust and windgustmph_max already in FOSHKplugin, there is either a problem in the calculation of windgustkmh_max by FOSHKplugin or in the station when generating maxdailygust.
(Or I have not quite understood the generation of this value by the station - because I would assume the same procedure as with FOSHKplugin.)
I haven't observed this yet - but I haven't explicitly monitored it either. Whenever I check, both values are identical.
windgustkmh_max shows the correct value
How do you know that this value is correct and maxdailygust is wrong? Do you have an external reference?
Since this discrepancy is already obvious in the FOSHKplugin, PWSDashboard is ruled out as the cause. Because even here there would be a few more problem sources (https://www.weather-watch.com/smf/index.php/topic,72276.0.html).
BTW: By default, PWSDashboard does not process the key windgustmph_max generated by FOSHKplugin. However, you could change this by changing the PWS_livedata.php.
Oliver
-
. . .
PWSDashboard accepts the key maxdailygust in the Ecowitt output from the weather station and displays its value as the daily maximum of the gusts. Wim is welcome to correct me if I am wrong.
This key is generated in the weather station and output via Ecowitt protocol - without any modification by FOSHKplugin.
. . .
Hi Oliver,
Yes that is correct.
During the day the gust values "windgustmph" and "maxdailygust" are compared with the previous vales to have the max-gust-today value for the small block on the top-row.
The daily/monthly/yearly values are saved in the history file.
Checking the site a few minutes ago:
Dashboard wind/gust block
= > "Gust (Max)" 8.2 m/s comes from ecowitt file [maxdailygust] => 18.34 mph => 8.2 m/s
Todays history (small block) shows 9.7 m/s at 01:10 and during the day that value was in some way uploaded
The history pop-up shows also 9.7 m/s at 01:10
The graphs with WU show also 9.7 m/s at 01:10 and that is a separate upload directly from the station, I assume.
The FOSHKplugin windgustkmh_max value of 34.92 is also correctly showing 9.7 m/s
The current station value maxdailygust seems to low, maybe the clock is running incorrectly?
Its UTC time is correct but what is the timezone it is using?
Wim
-
How do you know that this value is correct and maxdailygust is wrong? Do you have an external reference?
My old laptop running weewx 4.7.0 and GW1000 API driver, and my HP2550 console show the same value as windgustkmh_max. (Time 1:09 local time)
This is not a big deal, just a little confusing
Alf
-
How do you know that this value is correct and maxdailygust is wrong? Do you have an external reference?
My old laptop running weewx 4.7.0 and GW1000 API driver, and my HP2550 console show the same value as windgustkmh_max. (Time 1:09 local time)
This is not a big deal, just a little confusing
Alf
Weewx and the console have their own time-setting. Weewx and the Dashboard use correct time to calculate high-lows.
Could you please check your GW1x00 device time setting?
Attached a screenshot of a GW1000 which is running 1 hour 50 minutes behind.
Maybe your device is also running with incorrect time?
Wim
-
Hi Wim
Could you please check your GW1x00 device time setting?
my GW1000 uses the correct time zone
see attached screenshot
Alf
-
Hi Alf,
my GW1000 uses the correct time zone
is the time as well as the time zone on the host running FOSHKplugin also correct?
Oliver
-
Hi Oliver
The reason for this is not the FOSHKplugin, but rather my hardware
I found the answer in the .csv file. See attached screenshot
Sorry to bother you with this
Alf
-
Would be interesting to understand why that happened.
The maxdailygust is generated by the ecowitt hardware ( so it is not a FOSHKplugin problem )
The only reason I can think ( for the maxdailygust to change at 8:03 ) is a power outage of your console/gateway ( which console/gateway are you using? ).
( the missed reception from the outdoor sensor should not cause this )
-
Hi!
is a power outage of your console/gateway
In fact, this would be a good explanation.
It's time for the key "runtime" also for the GW1000 (that's the station Alf uses).
The current firmware beta v1.7.0 seems to contain the key. This would make it very easy to determine whether the station has/was restarted or not.
Oliver
-
Hi!
is a power outage of your console/gateway
In fact, this would be a good explanation.
It's time for the key "runtime" also for the GW1000 (that's the station Alf uses).
The current firmware beta v1.7.0 seems to contain the key. This would make it very easy to determine whether the station has/was restarted or not.
Oliver
Yes, another thing we add ( to our hardware ) is a counter that increments each time the unit is power cycled ( it helps diagnose power problems when the counter increments too much quickly )
-
Hi Alf, is this occurring at the same time every day? if you answered that, I missed it.
Also I'm looking at the recording intervals, which to me, seem a little short, under 20 seconds, maybe that is OK, just curious
-
Hi Alf, is this occurring at the same time every day?
No, this happens randomly. Two or three times in the last couple of weeks.
Also I'm looking at the recording intervals, which to me, seem a little short
Only for a few days to check uv reading, otherwise I use cvs_dailyfile for the weather statistics
Alf
-
Hi!
After an incredibly long beta phase, I have finally released version v0.09 of FOSHKplugin (https://foshkplugin.phantasoft.de/generic/).
In addition to many bug fixes and optimisations as well as necessary adjustments for compatibility with new stations (GW1100, GW2000, WS1900) and sensors (WN34, WN35, WS90, AQIN), there is now also support for APRS/CWOP and, as a "killing" feature, the possibility of making any contents of fields available to other fields (FWD_REMAP).
The installation routine has also been significantly improved and FOSHKplugin has been made more error-tolerant overall - many "usual" problems during configuration are now automatically bypassed.
Furthermore, the improved sunshine hours calculation should now provide far more realistic values and it should now be even easier to run different instances of FOSHKplugin in parallel.
Have a look at the "Version History" here (https://foshkplugin.phantasoft.de/generic/) for a complete list of changes and improvements.
I recommend all users of FOSHKplugin (including beta testers) to update to this version. On the other hand, if your current version works without problems and you have no need for the new possibilities, you can of course stay with the previous version. It only makes it more difficult to get help if problems arise.
To upgrade:
Change via ssh to the directory in which FOSHKplugin is running - according to my recommendations, it could be /opt/FOSHKplugin.
If you run FOSHKplugin as root, you can do the following commands without sudo - if you run FOSHKplugin in a certain user context, the specification of that user would be important so that the permissions are correct:
Code: [Select]
sudo -u username ./generic-FOSHKplugin-install.sh -upgrade
Let me know if there're any problems or you need some explanations of the new functions. Most things should already be described on the website.
For first time (or parallel) installation just use this link (https://foshkplugin.phantasoft.de/files/generic-FOSHKplugin.zip) and the common installation procedure.
LoxBerry users should download and install this (https://foshkplugin.phantasoft.de/files/loxberry-FOSHKplugin.zip) version the usual LoxBerry-installation-way instead.
Have fun!
Regards, Oliver
-
Updated from beta yesterday and it's been problem-free.
-
Hello Jim,
Updated from beta yesterday and it's been problem-free.
thank you very much for the confirmation.
So far I haven't received any other (error) message or request. So it seems to be working.
That gives me some time for my other projects ...
;-)
Regards, Oliver
-
Hey olicat,
any chance to be able to connect it to InfluxDB 2?
Thanks
-
Hi!
Since InfluxDB2 should actually be backwards compatible with InfluxDB1, there are currently no concrete plans.
However, I always collect the wishes of the users and prioritise (also) according to them. In this respect, I can imagine that support may follow.
Oliver
-
I'm on a fresh influxdb2 install, and since this works with tokens, organizations and buckets, instead of username/pass/database, I'm out of ideas how could I feed the data to the database.
-
Hi!
Since InfluxDB2 should actually be backwards compatible with InfluxDB1, there are currently no concrete plans.
However, I always collect the wishes of the users and prioritise (also) according to them. In this respect, I can imagine that support may follow.
Oliver
sadly influxdb is pretty incompatible between version one and 2.
I took a look at the code.
On the github page https://github.com/influxdata/influxdb-python (https://github.com/influxdata/influxdb-python) it says that this library only supports Influxdb 1 and not 2.
It is suggested to use influxdb-client-python instead. For it to work The organization Token (password) and bucket would be needed. Maybe I will give it a try to implement it.
-
So I added another forward for influxdb2 and the needed dependencies.
[ You are not allowed to view attachments ]
@Oliver
I hope the support for influxdb2 makes into the next release.
Is there a way that FoshkPlugin resents data when my influxdb is back online after backup or maintenance?
[Forward-26]
FWD_CMT = InfluxDB 2 metric forward Testing
FWD_TYPE = INFLUXMET2
FWD_URL = http://server:port@myBucket
FWD_SID = myOrganization
FWD_PWD = "Token"
FWD_INTERVAL = 60
FWD_ENABLE = False
-
Hi!
That's exactly how I wanted to implement it. Thank you very much.
But I'll call the new forward types INFLUX2MET and INFLUX2IMP instead of INFLUXMET2 and INFLUXIMP2.
At the moment, however, I don't have the possibility to test it - I only have an InfluxDB1 server here.
Maybe I can set up an additional InfluxDB2 server for testing here before the next release. Then InfluxDB2 should also be implemented in FOSHKplugin.
But from your point of view, can this be used productively?
Otherwise, the new libraries for Influx2DB now explicitly require a Python version > 3.6.
Until now, I could also install FOSHKplugin on systems with e.g. Python 3.5.3. With integrated Influx2DB support, this would no longer work and I would exclude quite a few users.
I still have to think about whether I really want that or generally how to deal with this.
Oliver
-
Hi!
That's exactly how I wanted to implement it. Thank you very much.
But I'll call the new forward types INFLUX2MET and INFLUX2IMP instead of INFLUXMET2 and INFLUXIMP2.
At the moment, however, I don't have the possibility to test it - I only have an InfluxDB1 server here.
Maybe I can set up an additional InfluxDB2 server for testing here before the next release. Then InfluxDB2 should also be implemented in FOSHKplugin.
But from your point of view, can this be used productively?
Otherwise, the new libraries for Influx2DB now explicitly require a Python version > 3.6.
Until now, I could also install FOSHKplugin on systems with e.g. Python 3.5.3. With integrated Influx2DB support, this would no longer work and I would exclude quite a few users.
I still have to think about whether I really want that or generally how to deal with this.
Oliver
Yes your naming scheme certainly makes more sense.
After some thought changing the location of the bucket and the orginization. As it is much more likely to have multiple buckets than organizations. So buckets would be more similar to the username (fwd_sid)
[Forward-26]
FWD_CMT = InfluxDB 2 metric forward Testing
FWD_TYPE = INFLUX2MET
FWD_URL = http://server:port@myOrganization
FWD_SID = myBucket
FWD_PWD = "Token"
FWD_INTERVAL = 60
FWD_ENABLE = False
For testing I would suggest to simply spin up one with docker Compose.
Here is the one I am using. change ports and volumes to the ones that fit your system. After you run the docker login in and under Data/ApiTokens generate a read write token for your bucket.
I am also not so sure why the weather community seems so averse to docker. Programs like CumulusMX, weewx etc. would be 100 times more user friendly for non programmers. No need to worry about dependencies, mono installs, data directories and so on. Everyone could be up and running in 5 minutes. Including secure public webpages. Well that is slightly off topic. For Foshkplugin this would also be helpful for updates and multiple instances.
version: "3.5"
services:
influxdb2:
image: influxdb:latest
container_name: InfluxDBWeatherData
ports:
- "8086:8086"
volumes:
- "/mnt/user/appdata/InfluxDBWeatherData/data:/var/lib/influxdb2"
- "/mnt/user/appdata/InfluxDBWeatherData/config:/etc/influxdb2"
environment:
- DOCKER_INFLUXDB_INIT_MODE=setup
- DOCKER_INFLUXDB_INIT_USERNAME=YourAdmin
- DOCKER_INFLUXDB_INIT_PASSWORD=superSecretPassword
- DOCKER_INFLUXDB_INIT_ORG=myOrg
- DOCKER_INFLUXDB_INIT_BUCKET=WeatherData
restart: always
So far this is running fine for me. (besides the data loss due to my server with the influxdb running performing a backup)
[ You are not allowed to view attachments ]
From my understanding it should be possible to only provide this functionality for people with the appropriate python version. https://www.pythonpool.com/python-conditional-import/ (https://www.pythonpool.com/python-conditional-import/) Sadly python is not my primary programming language. So I would need to do some testing concerning what would be the best approach.
Some other points I have noticed about the code:
- I am not a big fan of having only one file with 6k lines of code. This means that an import like influxdbclient has to be loaded in the main execution script. While it is only necessary for one specific function.
- Your functions are doing too much and should be separated into several smaller functions that can be reused. For example in the forwardDictToInfluxDB function:
- The first 40 lines are just for preparing the data from generic data to the specific influxdb one.
- A further 20 lines are just for evaluating the URL. Which should ideally be done only once when ingesting the configuration file.
- The real sending method is then another 30 lines.
- Many variables are very short and therefore difficult to understand what they are supposed to do. In the function forwardDictToInfluxDB the variable d is not very clear what it should mean.
- I haven't found the code on github or another Version Control software yet. If you haven't played around with that yet i highly recommend to do that as the sheer amount of code and effort you have put into this makes it really a lot easier to work with.
-
I'd love to get FOSHKplugin in a docker to ride as an addon in HomeAssistant. I could repurpose a couple pi's =). I need to dig in and learn a bit.
-
Hi @olicat,
Thanks for sharing your work on FOSHKplugin. I'm trying to solve a problem that I believe I can with the REMAP functionality. So I have an Ecowitt Wittboy/GW2001 & WS90. It's configured via the Custom Server to forward to an instance of FOSHKplugin. Since it has a piezo rain gauge, the rain data comes in the EW format as the following variables:
&rrain_piezo=0.000
&erain_piezo=0.256
&hrain_piezo=0.000
&drain_piezo=0.256
&wrain_piezo=1.437
&mrain_piezo=8.736
&yrain_piezo=9.083
If I understand correctly I should be able to remap these with FOSHKplugin to the standard EW rain variables so that I can forward to "Personal Weather Tablet". Is this correct? However I cannot find a list of the FOSHKplugin internal variable names to successfully remap it.
For example with:
FWD_REMAP = @rainrate=@rrain_piezo
I get the error:
Remap: problem while remapping @rainrate with @rrain_piezo
Appreciate any assistance you can offer.
EDIT:
Got it working with the following:
FWD_REMAP = rainratein=@rrain_piezo,eventrainin=@erain_piezo,hourlyrainin=@hrain_piezo,dailyrainin=@drain_piezo,weeklyrainin=@wrain_piezo,monthlyrainin=@mrain_piezo,yearlyrainin=@yrain_piezo
Another question is about the "WeatherStation" section in the config file. Does this make FOSHKplugin use the Ecowitt API on the station instead of having to use the "Custom Server"?
Thanks,
Arthur
-
Hi!
I'm trying to solve a problem that I believe I can with the REMAP functionality.
In fact there is a problem with FOSHKplugin in v0.09, which will be fixed in the next version:
Changelog:
...
fixed: WS90 rain-handling - replacing the new names with the old ones now works correctly (e.g. "rrain_piezo" --> "rainratein")
...
Actually, it was intended that FOSHKplugin would automatically convert to the conventional names if only the new key names were available. Precisely to ensure compatibility with software that has not (yet) been adapted, such as PWT.
The default active option for this is
Weatherstation\WS90_CONVERT = True
If WS90_CONVERT is set, the conversion to the conventional names takes place:
rrain_piezo --> rainratein
erain_piezo --> eventrainin
hrain_piezo --> hourlyrainin
drain_piezo --> dailyrainin
wrain_piezo --> wekklyrainin
mrain_piezo --> monthlyrainin
yrain_piezo --> yearlyrainin
However, due to a silly bug in v0.09, this conversion does not happen. Sorry.
Fortunately, though, you can actually solve this with the FWD_REMAP function, as you've already done:
FWD_REMAP = rainratein=@rrain_piezo,eventrainin=@erain_piezo,hourlyrainin=@hrain_piezo,dailyrainin=@drain_piezo,weeklyrainin=@wrain_piezo,monthlyrainin=@mrain_piezo,yearlyrainin=@yrain_piezo
However, with the upcoming v0.10 this remap will work automatically - as originally intended for v0.09.
However I cannot find a list of the FOSHKplugin internal variable names to successfully remap it.
The available variable names are - depending on the available sensors - user specific. Therefore I didn't want to generate a static list of all possible key names (very large and not very helpful) but a dynamic overview of what is possible for each user. You can reach this overview page with all variable names that can be reached by FOSHKplugin (for you) with http://ipaddress:port/FOSHKplugin/keyhelp. This page is very helpful, especially for individual queries (getvalue) or for the remap function.
I would also like to point out the help page of FOSHKplugin: http://ipaddress:port/FOSHKplugin/help - which documents all http control and query options.
Regards, Oliver
-
Changelog:
...
fixed: WS90 rain-handling - replacing the new names with the old ones now works correctly (e.g. "rrain_piezo" --> "rainratein")
...
Actually, it was intended that FOSHKplugin would automatically convert to the conventional names if only the new key names were available. Precisely to ensure compatibility with software that has not (yet) been adapted, such as PWT.
The default active option for this is
Weatherstation\WS90_CONVERT = True
If WS90_CONVERT is set, the conversion to the conventional names takes place:
rrain_piezo --> rainratein
erain_piezo --> eventrainin
hrain_piezo --> hourlyrainin
drain_piezo --> dailyrainin
wrain_piezo --> wekklyrainin
mrain_piezo --> monthlyrainin
yrain_piezo --> yearlyrainin
However, due to a silly bug in v0.09, this conversion does not happen. Sorry.
Excellent, I look forward to the updated v0.10. Thanks for your work on such a useful tool! I'm about to make my install a bit more complicated ](*,) by installing another instance of FOSHKplugin to get around some firewalls.
Fortunately, though, you can actually solve this with the FWD_REMAP function, as you've already done:
FWD_REMAP = rainratein=@rrain_piezo,eventrainin=@erain_piezo,hourlyrainin=@hrain_piezo,dailyrainin=@drain_piezo,weeklyrainin=@wrain_piezo,monthlyrainin=@mrain_piezo,yearlyrainin=@yrain_piezo
However, with the upcoming v0.10 this remap will work automatically - as originally intended for v0.09.
It took a bit of troubleshooting and testing, but was able to figure it out. The WS90_CONVERT will make it a lot easier on new users. I think the WS90 may create some new weather enthusiasts since it's so compact and easy to set up.
The available variable names are - depending on the available sensors - user specific. Therefore I didn't want to generate a static list of all possible key names (very large and not very helpful) but a dynamic overview of what is possible for each user. You can reach this overview page with all variable names that can be reached by FOSHKplugin (for you) with http://ipaddress:port/FOSHKplugin/keyhelp. This page is very helpful, especially for individual queries (getvalue) or for the remap function.
I would also like to point out the help page of FOSHKplugin: http://ipaddress:port/FOSHKplugin/help - which documents all http control and query options.
Perfect, I didn't realize how "self documenting" FOSHkplugin is. These URLs are tremendously helpful, and I've made note of them for future use. There's a lot of good information in there that I can use to extend my use case of it.
Another question is about the "WeatherStation" section in the config file. Does this make FOSHKplugin use the Ecowitt API on the station instead of having to use the "Custom Server"?
Referring to the above question, can FOSHKplugin query the GW2000/WS90 API directly or does it just work with the "Custom Server"?
Thanks again,
Arthur
-
Hi!
I'm about to make my install a bit more complicated ](*,) by installing another instance of FOSHKplugin to get around some firewalls.
That should not be a problem.
I run about 8 or 9 instances in parallel on one host. As long as you don't get confused with the different directories, service names and ports, it works very well.
can FOSHKplugin query the GW2000/WS90 API directly or does it just work with the "Custom Server"?
FOSHKplugin only supports data reception via custom server.
The API functionality is not available for all devices and I wanted to have a solution that is as comprehensive as possible.
Oliver
-
Hi @olicat,
Where is the best forum to discuss suggestions about FOSHKplugin? Unless I hear otherwise, I'll just post about a possible bug here.
I've just recently set up a forward to "WeatherCloud". On FOSHKplugin 0.09, it seems that the FWD_REMAP does not seem to be working for WC.
[Forward-4]
FWD_ENABLE = True
FWD_CMT = WeatherCloud
FWD_INTERVAL = 60
FWD_URL = http://api.weathercloud.net/v01/set?wid=XX&key=XX&
FWD_TYPE = WC
FWD_REMAP = rainrate=@rrain_piezomm,et=@erain_piezomm,rain=@drain_piezomm
Here's the snd-foshkplugin.log with no foshkplugin.py modification (no rain data)
http://api.weathercloud.net/v01/set?wid=XX&key=XX&date=20220707&time=2115&tempin=265&humin=46&bar=10130&temp=295&hum=76&wdir=115&wspd=34&solarrad=2151&uvi=10&battery=54&pwrsply=54&temp1=262&hum1=43&temp2=270&hum2=44&temp3=250&hum3=47&temp4=349&hum4=50&pm25=4.0&noise=40&leafwet=0.5&dew=248&chill=295&heat=352&aqi=17&wspdavg=34&wdiravg=115&wspdhi=61&dewin=139&heatin=264&type=FOSHKplugin&ver=v0.09
In the interim I've made some temporary modifications to foshkplugin.py to capture these keys.
def forwardDictToWC(url,d_in,fwd_sid,fwd_pwd,script,nr,ignoreKeys,remapKeys):
|
<snip>
|
elif key == "drain_piezomm":
outstr += "rain=" + str(round(float(value)*10)) + "&"
elif key == "rrain_piezomm":
outstr += "rainrate=" + str(round(float(value)*10)) + "&"
elif key == "erain_piezomm":
outstr += "et=" + str(round(float(value)*10)) + "&"
|
<snip>
|
Here's the snd-foshkplugin.log with the foshkplugin.py modification (has rain data)
http://api.weathercloud.net/v01/set?wid=XX&key=XX&date=20220707&time=2119&tempin=268&humin=46&bar=10129&temp=296&hum=76&wdir=163&wspd=19&solarrad=4204&uvi=30&rainrate=0&et=40&rain=40&battery=54&pwrsply=54&temp1=264&hum1=44&temp2=272&hum2=44&temp3=254&hum3=47&temp4=349&hum4=50&pm25=4.0&noise=40&leafwet=0.3&dew=249&chill=296&heat=354&aqi=17&wspdavg=21&wdiravg=143&wspdhi=60&dewin=142&heatin=270&type=FOSHKplugin&ver=v0.09
Thanks for your help,
Arthur
-
Hi Arthur!
Where is the best forum to discuss suggestions about FOSHKplugin? Unless I hear otherwise, I'll just post about a possible bug here.
No problem - this is the best place to discuss these things.
it seems that the FWD_REMAP does not seem to be working for WC.
No.
The FWD_REMAP is just working a bit different.
But you have found an interesting thing that I haven't come across yet. And actually you wouldn't have noticed it either if v0.09 behaved exactly as it was intended.
Because when only operating a WS90 (without an additional WH40), FOSHKplugin should already change the rain values to the traditional names when receiving the data from the console and BEFORE converting to the metric system. Then the "new" keys would not exist at all but only the traditional names.
Due to an error, however, exactly this does not happen - the error has already been fixed in my internal beta v0.10.
However, when operating both the WS90 and a conventional rain sensor - i.e. when both forms of the keys are sent - your question also arises - at least with Weathercloud (and all other services that require metric values).
Because there you have to tell FOSHKplugin via FWD_REMAP which keys it should use to pass on to the respective service.
In this respect, here is a good opportunity to explain this better.
You can only exchange Ecowitt fields or (within limits) add new fields. The output format (as it is sent to the destination - here WC) is not decisive, but the input format (as it comes from the weather station).
A complicating factor in the case of WC is that not the original Ecowitt keys are used, but the metric ones. And these metric keys have a slightly different name than the imperial variables.
With your FWD_REMAP:
FWD_REMAP = rainrate=@rrain_piezomm,et=@erain_piezomm,rain=@drain_piezomm
you set the key rainrate to the value of rrain_piezomm. The conversion routine to WC, however, does not check for the key rainrate but searches for the key rainratemm in order to pass its value on to WC as rainrate.
FOSHKplugin also searches for the key dailyrainmm for the daily amount of rain and passes its value to WC as rain. Your rain in FWD_REMAP is therefore simply ignored.
A correct FWD_REMAP for Weathercloud if you want to use the data of the WS90 would therefore be:
FWD_REMAP = rainratemm=@rrain_piezomm,dailyrainmm=@drain_piezomm
What you mean by et=@erain_piezomm is not quite clear to me. In Weathercloud, et stands for evapotranspiration, which is neither sent by the console nor calculated (yet) by FOSHKplugin.
At least et says something completely different than the amount of rain of the current rain event. Therefore, it is not advisable to report the event rainfall amount as et to WeatherCloud.
But the fundamental problem is, that I have deactivated the forwarding of unknown keys in WeatherCloud due to a lack of experience. I don't know how WC reacts to unknown keys. Therefore, your et=@erain_piezomm is ignored and not transmitted.
But I've been planning to take a closer look at WC for a while and to use the 30-day trial period for the extended Plus service.
At least I could then finally test to what extent the sensor values for temp2, hum2, soiltemperature, soilmoisture, leafwetness and air quality, which are not included in the free Basic Plan, are correctly transmitted by FOSHKplugin.
Because that should actually work - only I have never tested it (of course I send this data - only I cannot see them on the WC page).
So far I have hoped in vain that these values will also be available in the free Basic Plan at some point.
At the moment, however, I want to finish the new version v0.10. I will probably not be able to take care of WC until the end of the year at the earliest. Sending data to WeatherCloud is not such a high priority for me because the Ecowitt consoles can do this by default (even if not as well as FOSHKplugin). In any case, I have not yet had any enquiries regarding FOSHKplugin and WeatherCloud. You're the first one - thanks!
Most people probably use the built-in data transfer to WC and don't realise that there is a better way.
Regards, Oliver
-
Hi Oliver,
Thanks for responding.
No.
The FWD_REMAP is just working a bit different.
But you have found an interesting thing that I haven't come across yet. And actually you wouldn't have noticed it either if v0.09 behaved exactly as it was intended.
Because when only operating a WS90 (without an additional WH40), FOSHKplugin should already change the rain values to the traditional names when receiving the data from the console and BEFORE converting to the metric system. Then the "new" keys would not exist at all but only the traditional names.
Due to an error, however, exactly this does not happen - the error has already been fixed in my internal beta v0.10.
Ah understood, I'm running into the same error that we discussed in my earlier post with Weatherstation\WS90_CONVERT = True
You can only exchange Ecowitt fields or (within limits) add new fields. The output format (as it is sent to the destination - here WC) is not decisive, but the input format (as it comes from the weather station).
A complicating factor in the case of WC is that not the original Ecowitt keys are used, but the metric ones. And these metric keys have a slightly different name than the imperial variables.
That's what I've run into, wanting to be able to arbitrarily assign fields. For fun I have mapped lightning strikes to the unused WC field "noise" so that it can be visualized. .
What you mean by et=@erain_piezomm is not quite clear to me. In Weathercloud, et stands for evapotranspiration, which is neither sent by the console nor calculated (yet) by FOSHKplugin.
At least et says something completely different than the amount of rain of the current rain event. Therefore, it is not advisable to report the event rainfall amount as et to WeatherCloud.
I misinterpreted "et" as the current rain event instead of evapotranspiration. So i got rid of it. Oops!
But the fundamental problem is, that I have deactivated the forwarding of unknown keys in WeatherCloud due to a lack of experience. I don't know how WC reacts to unknown keys. Therefore, your et=@erain_piezomm is ignored and not transmitted.
Is there any way that I can easily enable the forwarding of unknown keys? I've had a scan through the Python code to understand better how it works. Perhaps I can help shine some light on how WC works. More than happy to share anything I learn.
At least I could then finally test to what extent the sensor values for temp2, hum2, soiltemperature, soilmoisture, leafwetness and air quality, which are not included in the free Basic Plan, are correctly transmitted by FOSHKplugin.
Because that should actually work - only I have never tested it (of course I send this data - only I cannot see them on the WC page).
I managed to get Leafwetness displayed, but not air quality or the temp2, hum2 etc. I have a paid account with WC and have reached to to their support.
I also have the latest v1.0 API documentation that WC Support sent me, if you don't have it and would find it useful.
At the moment, however, I want to finish the new version v0.10.
:
I have not yet had any enquiries regarding FOSHKplugin and WeatherCloud. You're the first one - thanks!
Indeed keep on track with v0.10 and don't let me distract you. :grin: I like WCs interface and they seem to be actively developing and more willing to listen to users compared to some of the other services.
Thanks,
Arthur
-
Hi!
I have taken your request as an opportunity to raise various points again with WeatherCloud.
As soon as I have more information, I will get back to you.
Is there any way that I can easily enable the forwarding of unknown keys? I've had a scan through the Python code to understand better how it works.
In FOSHKplugin v0.9 you only may remap the known keys because I restrict the sending to keys available on WeatherCloud. So this is not easily changeable.
But of course you could make some modifications in your local code:
else:
if myDebug: logPrint("<DEBUG> forwardDictToWC: unknown field: " + str(key) + " with value: " + str(value))
outstr += str(key) + "=" + str(value) + "&"
With the line after else and logPrint all (!) incoming keys will be transferred to WeatherCloud.
I managed to get Leafwetness displayed, but not air quality or the temp2, hum2 etc.
Do you use a WH45? The data should - if possible - be sent to WeatherCloud.
Unfortunately, according to the available API documentation, there is still no field for the CO2 value, which is of course a shame for a CO2 sensor like the WH45.
temp2 and hum2 are currently not transmitted due to a misinterpretation of the API on my part. WeatherCloud expects the keys temp02 and hum02 (instead of temp2 and hum2).
This will be corrected in the next FOSHKplugin version.
In the meantime you could adapt the temp block in the forwardDictToWC function and insert the missing "0":
elif "temp" in key and len(key) == 6 and key[-1] == "c":
val = round(float(value)*10)
outstr += "temp" + "0" + str(int(key[4])+1) + "=" + str(val) + "&"
I like WCs interface and they seem to be actively developing and more willing to listen to users compared to some of the other services.
I am torn on this.
I like the graphic visualisation and especially the diverse language support.
On the other hand, contact and further development is rather slow. According to the blog, the last update (v10.1) was more than a year ago! The API documentation v1.0 that I have is also at least 15 months old.
In addition, unfortunately only very few sensors from the Ecowitt world are supported.
And even with the small selection of additional sensors supported (only one other T/H sensor, one soil moisture sensor, one leaf moisture sensor, one air quality sensor), a paid tariff is required to view them.
I was promised more fields a long time ago. But - see above - further development is not really rapid.
And basically, the free Ecowitt service offers much more than the rather expensive Pro tariff of 10 EUR/month at WeatherCloud.
But if you don't like the design, that won't help you, of course.
BTW: Do you already know my Comparison PDF for the different weather services and programmes with Ecowitt support (https://foshkplugin.phantasoft.de/files/Vergleich-Cloud-Software-FineOffset-EN.pdf)?
Maybe Ambient Weather would be something for you? Or Awekas?
Regards, Oliver
-
Hi,
I have taken your request as an opportunity to raise various points again with WeatherCloud.
As soon as I have more information, I will get back to you.
OK, that's cool. I got a response from them to some of my questions.
- No lighting data in the short or medium term
- Here are the additional Sensors that they support. Displayed automatically from the moment you upgrade your plan on a new Extra tab on your device page.
- 1 x Additional ambient temperature
- 1 x Additional ambient humidity
- 1 x Soil temperature
- 1 x Soil moisture
- 1 x Leaf wetness
- 1 x Air quality (PM2.5, PM10, CO, NO, NO2, SO2 and O3)
- 1 x Noise
So overall not very many at all.
In FOSHKplugin v0.9 you only may remap the known keys because I restrict the sending to keys available on WeatherCloud. So this is not easily changeable.
But of course you could make some modifications in your local code:
else:
if myDebug: logPrint("<DEBUG> forwardDictToWC: unknown field: " + str(key) + " with value: " + str(value))
outstr += str(key) + "=" + str(value) + "&"
With the line after else and logPrint all (!) incoming keys will be transferred to WeatherCloud.
Excellent, thanks for this direction. In the mean time I've modified my local code to do things like map my lighting strikes to the WC "noise" variable. Not perfect, but it's fun to do.
Do you use a WH45? The data should - if possible - be sent to WeatherCloud.
Unfortunately, according to the available API documentation, there is still no field for the CO2 value, which is of course a shame for a CO2 sensor like the WH45.
No I don't have the WH45, but I do have the WH41. I modified my local code to send the PM2.5 data from it to WC.
temp2 and hum2 are currently not transmitted due to a misinterpretation of the API on my part. WeatherCloud expects the keys temp02 and hum02 (instead of temp2 and hum2).
This will be corrected in the next FOSHKplugin version.
In the meantime you could adapt the temp block in the forwardDictToWC function and insert the missing "0":
That's exactly what I've done after reading the API now I have one of my WH31 T&H sensors data is now showing up. :grin: Also sending another WH31 T&H sensor to the "Temperature agro" field.
Likely not have too many modifications when you release v0.10 of FOSHKplugin.
I am torn on this.
I like the graphic visualisation and especially the diverse language support.
On the other hand, contact and further development is rather slow. According to the blog, the last update (v10.1) was more than a year ago! The API documentation v1.0 that I have is also at least 15 months old.
In addition, unfortunately only very few sensors from the Ecowitt world are supported.
And even with the small selection of additional sensors supported (only one other T/H sensor, one soil moisture sensor, one leaf moisture sensor, one air quality sensor), a paid tariff is required to view them.
I was promised more fields a long time ago. But - see above - further development is not really rapid.
BTW: Do you already know my Comparison PDF for the different weather services and programmes with Ecowitt support (https://foshkplugin.phantasoft.de/files/Vergleich-Cloud-Software-FineOffset-EN.pdf)?
Maybe Ambient Weather would be something for you? Or Awekas?
I hear you. I'm hoping WC will do some new development in the near future. If they don't then I'll abandon it when I am bored of it.
Indeed, I read the Comparison PDF last night and it really does give an excellent breakdown of the various services. I may look into Ambient Weather and see how much effort it takes to get the license and then integrated it.
I may just continue expanding my own WeeWX site and maybe implement CumulusMX.
Thanks,
Arthur
-
You can also take a look at meteotemplate ( see an example in my signature ), it now support all ecowitt sensors.
-
You can also take a look at meteotemplate ( see an example in my signature ), it now support all ecowitt sensors.
I've seen mention of Meteotemplate. Thanks for your suggestion. I'll have a look!
-
I am intrigued by this because I also would like to feed several devices from my HP2553. I downloaded the software but is there a fairly succinct summary of how to set it up etc. What does it run on, a raspberry pi maybe?
Right now, I feed my CumulusMX from my custom server but there is only one custom server. I would also like to feed PWT and maybe others.
I am totally new to this so would appreciate help. Thanks in advance.
Joe
-
yes, you can run it on a RapberryPi (with any Linux type operation system which has the systemd service implemented) or on a NAS, natively or in a Virtual Machine (e.g. Docker) etc.- it has to run 24/7.
The installation instructions should be clear.
https://loxwiki.atlassian.net/wiki/spaces/LOXBERRY/pages/1252524456/FOSHKplugin+-+generic+version
With CumulusMX you can have max three http posts/forwards - with FOSHKplugin up to 50, meanwhile even 100 as far as I know.
Beyond forwards you can convert formats, add information and do some console configuration.
FOSHKplugin is an information broker - for the principle see https://www.wxforum.net/index.php?topic=40730.0
section 7. data flow between sensors, consoles, application software and internet weather services
(the whole thread is a collection of background information regarding Ecowitt (clone) consoles and sensors)
-
Thanks Gyvate
There is quite a bit there but i will check it out and try installing on my rpi3. My ultimate goal at this point is to provide feeds from my HP2553 custom server to my CumulusMX and PWT. And then I'll go from there.
-
that would also work without FOSHKplugin (even though FOSHKplugin is a nice tool and your scenario would be much easier to implement)
HP2551 --> CMX, CMX --> PWT
However the translation from CMX to PWT will need some work - you have to figure out the content of the custom server string (use @olicats ear service).
Then create the http post string for CMX to forward to PWT: the skelton comes from ear - for the values you need to find the CMX webtags (see CMX Wiki - it's a bit hidden)
then you would have a string like
http://your-PWT-IP:8072/data/reportPASSKEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&stationtype=HP2551_V1.8.1&runtime=526615&dateutc=<CMX-webtag for date-time format:2022-07-18+10:38:25>&tempinf=<CMX-webtag for inside temp in F>&humidityin=<CMX-webtag for inside humidity>36&baromrelin=<CMX-webtag for rel air pressure in inches>&baromabsin=<>& ....&
by the way: "runtime" is not an important variable for PWT and can be left out
-
There is quite a bit there but i will check it out and try installing on my rpi3. My ultimate goal at this point is to provide feeds from my HP2553 custom server to my CumulusMX and PWT. And then I'll go from there.
Personally I use my GW2000 Custom Server to feed FOSHKplugin which then feeds PWT and a number of other services. I did go a bit crazy by forwarding to quite a few Weather Services. FOSHKplugin is a brilliant piece of software.
Here's a snippet of my foshkplugin.conf for my PWT Tablets that may help you get started. I have to remap the rain fields since I have a WS90 with the piezo rain gauge.
[Forward-1]
FWD_ENABLE = True
FWD_CMT = Amazon Fire 8 PWT
FWD_URL = http://X.X.X.X:8572/
FWD_INTERVAL = 16
FWD_IGNORE =
FWD_TYPE = EW
FWD_SID =
FWD_PWD =
FWD_REMAP = rainratein=@rrain_piezo,eventrainin=@erain_piezo,hourlyrainin=@hrain_piezo,dailyrainin=@drain_piezo,weeklyrainin=@wrain_piezo,monthlyrainin=@mrain_piezo,yearlyrainin=@yrain_piezo
FWD_STATUS = False
FWD_MQTTCYCLE = 0
FWD_EXEC =
[Forward-2]
FWD_ENABLE = True
FWD_CMT = Amazon Fire 10 PWT
FWD_URL = http://X.X.X.X:8572/
FWD_INTERVAL = 16
FWD_IGNORE =
FWD_TYPE = EW
FWD_SID =
FWD_PWD =
FWD_REMAP = rainratein=@rrain_piezo,eventrainin=@erain_piezo,hourlyrainin=@hrain_piezo,dailyrainin=@drain_piezo,weeklyrainin=@wrain_piezo,monthlyrainin=@mrain_piezo,yearlyrainin=@yrain_piezo
FWD_STATUS = False
FWD_MQTTCYCLE = 0
FWD_EXEC =
[Forward-3]
FWD_ENABLE = False
FWD_CMT = Phantasoft Ecowitt AutoResponder
FWD_URL = http://ear.phantasoft.de/data/report/
FWD_INTERVAL = 30
FWD_IGNORE =
FWD_TYPE = EW
FWD_SID =
FWD_PWD =
FWD_REMAP = rainratein=@rrain_piezo,eventrainin=@erain_piezo,hourlyrainin=@hrain_piezo,dailyrainin=@drain_piezo,weeklyrainin=@wrain_piezo,monthlyrainin=@mrain_piezo,yearlyrainin=@yrain_piezo
FWD_STATUS = False
FWD_MQTTCYCLE = 0
FWD_EXEC =
I don't use Cumulus, but came across the below in the FOSHKplugin documentation which should help you get it set for CumulusMX.
[Forward-77]
FWD_TYPE = EW
FWD_CMT = CMX
FWD_URL = http://192.168.15.252:8998/station/ecowitt
It's all so flexible and @Gyvate has a great suggestion too.
Using FOSHKplugin gives you another option such as:
HP2551 -> FOSHKplugin -> PWT & CMX
-
Hi
I need some help. I installed FOSHKp;ugin as a service and now I cannot run CumulusMX - the station cannot connect. I don't know how to disable FOXSHKplugin. I tried to systemctl stop FOXSHKplugin but the file was not found. Like an idiot, I installed FOX on the same pi as Cumulus. Plesae help.
-
Hi
I need some help. I installed FOSHKp;ugin as a service and now I cannot run CumulusMX - the station cannot connect. I don't know how to disable FOXSHKplugin. I tried to systemctl stop FOXSHKplugin but the file was not found. Like an idiot, I installed FOX on the same pi as Cumulus. Plesae help.
Oh no.
Try systemctl stop foshkplugin (all lowercase).
Them try restarting CumulusMX.
Post your configuration for FOSHKplugin here (remove any passwords or API keys etc.) and we can have a look.
-
Hi
I need some help. I installed FOSHKp;ugin as a service and now I cannot run CumulusMX - the station cannot connect. I don't know how to disable FOXSHKplugin. I tried to systemctl stop FOXSHKplugin but the file was not found. Like an idiot, I installed FOX on the same pi as Cumulus. Plesae help.
Oh no.
Try
root@ubuntu:~# systemctl stop foshkplugin
"foshkplugin" in all lowercase.
Or you can try manually with
root@ubuntu:~# ps -ax | grep foshk
You'll get something like:
2122 ? Ssl 27:36 /usr/bin/python3 -u /opt/FOSHKplugin/foshkplugin.py
303517 pts/0 S+ 0:00 grep --color=auto foshk
Then kill the foshkplugin.py process like this:
root@ubuntu:~# kill 2122
Where 2122 is the PID for the foshkplugin.py process. Yours will be a different PID)
Then try restarting CumulusMX.
Post your configuration for FOSHKplugin here (remove any passwords or API keys etc.) and we can have a look.
-
Cumulus did not start and this is embarrassing but I cannot find where I installed fox. What is the command to find a file in linux. I can't remember.
-
Cumulus did not start and this is embarrassing but I cannot find where I installed fox. What is the command to find a file in linux. I can't remember.
Try this:
root@ubuntu:~# find / -name foshkplugin.py
It should come up with something like this:
/opt/FOSHKplugin/foshkplugin.py
-
OK everyone. I fixed the problem and Cumulus is now starting. What was wrong was the path and port were wrong in the HP2553 custom server configuration. I guess I made erroneous entries when configuring fos (port 8080 and the wrong path. I did not realize that foshk would change entries in my 2553 but I guess it did. No wonder CMX did not start if the path and port were wrong!
Now I also looked everywhere on my pi and I cannot find the foshk directory, I guess doing these things late at night is not a good idea!
I think I will try this again from scratch when I am more fresh. Thanks for putting up with me LOL
Good night
-
the default directory for FOSHKplugin is /opt/FOSHKplugin
try the following command to locate your FOSHKplugin directory in your file system:
sudo find / -type d -name "FOSHKplugin"
on my system this produces the following output:
pi@NAS-Pi:~/FOSHKplugin $ sudo find / -type d -name "FOSHKplugin"
find: ‘/run/user/1000/gvfs’: Permission denied
find: ‘/proc/23750’: No such file or directory
/home/pi/FOSHKplugin
/mnt/TS-453A/Transfer/FOSHKplugin
and here we go
/home/pi/FOSHKplugin is my FOSHKplugin installation directory :-)
yours may be different - I intentionally chose /home/pi instead of /opt
and, by the way, there's no harm installing and running FOSHKplugin on the same server (RPi) as CMX ...
-
Gyvate
This is what I get.
I know what this is trying to do but don't know why the permission denied.
sudo find / -type d -name "FOSHKplugin"
find: ‘/run/user/1000/gvfs’: Permission denied
There is a /run/user/1000 tree and the gvfs folder is blank. I don't recall this at all. Anyway probably doesn't matter much. I am running the latest build of the raspberrry pi os.
-
Gyvate
This is what I get.
I know what this is trying to do but don't know why the permission denied.
sudo find / -type d -name "FOSHKplugin"
find: ‘/run/user/1000/gvfs’: Permission denied
There is a /run/user/1000 tree and the gvfs folder is blank. I don't recall this at all. Anyway probably doesn't matter much. I am running the latest build of the raspberrry pi os.
This
find: ‘/run/user/1000/gvfs’: Permission denied
will also appear but can be ignored - it just means that the command couldn't check any subdirectories due to missing permissions for the gvfs directory (or folder) - probably because it is empty - that's just part of the search process
but, if there is a subdirectory FOSHKplugin somewhere in the file system, its path will be displayed in one line - if you don't see anything, then there is no such directory and it got removed/deleted at some point (provided it was ever created)
the command may need some time to complete - so don't interrupt it with CTRL-C
-
Anyone feeding (successfully) data to the Home Assistant Ecowitt integration?
See the HA instruction attached
[ You are not allowed to view attachments ]
My foshkplugin config looks like this:
[Forward-6]
FWD_ENABLE = True
FWD_CMT = Sending to NEW home assistant ECOWITT format
FWD_URL = http://192.168.2.13:8123/api/webhook/3b1bbc5a752a1b30c50ffd6abd5a3901
FWD_INTERVAL =
FWD_IGNORE =
FWD_TYPE = EW
FWD_SID =
FWD_PWD =
FWD_STATUS = False
FWD_MQTTCYCLE = 0
FWD_EXEC =
-
it just wants the custom server functionality of your console being used to post its data to the HA.
The wording "DIY Upload servers" is technically correct but unfortunately confusing as it doesn't match the Header in the WSView Plus app, the WebUI or the display page of the console - there it's found under "Weather Services --> Customized".
One can clearly see that the integration hasn't been made by Ecowitt themselves but by someone else (which is not always helpful - especially as EW wasn't - so far - even not allowed to take the development lead even though they wanted - from there some strange things in this integration originate; but "people's wish is their kingdom of Heaven" they say).
Not that it doesn't work - I got it running on my NAS inside a Docker container - but it's not yet fully thought through I find (which also comes from ignoring the manufacturer's advise who knows their devices throughout and deeply). I'd say it's "work in progress" but already quite functional. Some of the "widgets" get still stuck regarding history every now and then, and design is always a matter of taste (doesn't fully meet mine), but it's imo +/- working.
As for FOSHKplugin, you simply need to create a FORWARD section to the IP, path, port - and don't forget to select a reasonable posting interval. It can e.g. display they full sensor data sent by a GW2000 with plenty of extra sensors including both traditional and piezo rain. Their naming is a bit confusing especially with the rain observations. Need to figure out what they mean by what they say. (to me it looks as if the developer technically created the entities but did not fully understand the functionality behind each observation and name).
EDIT: removed orthographic mistakes
-
Nice description.
What I understand, from your message is that the only thing from my config, posted above, I'm missing the FWD_INTERVAL value.
Even with a value set, I'm getting the following error:
Logger: homeassistant.components.webhook
Source: components/ecowitt/__init__.py:27
Integration: Webhook (documentation, issues)
First occurred: 7:38:30 AM (4 occurrences)
Last logged: 7:39:42 AM
Error processing webhook 3b1bbc5a752a1b30c50ffd6abd5a3901
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/webhook/__init__.py", line 129, in async_handle_webhook
response = await webhook["handler"](hass, webhook_id, request)
File "/usr/src/homeassistant/homeassistant/components/ecowitt/__init__.py", line 27, in handle_webhook
return await ecowitt.handler(request)
File "/usr/local/lib/python3.10/site-packages/aioecowitt/server.py", line 102, in handler
self.process_data(data)
File "/usr/local/lib/python3.10/site-packages/aioecowitt/server.py", line 51, in process_data
station = extract_station(data)
File "/usr/local/lib/python3.10/site-packages/aioecowitt/station.py", line 28, in extract_station
frequence = data.pop("freq")
KeyError: 'freq'
-
Hi!
This is more an HA integration than FOSHKplugin error.
Have a look here (https://github.com/home-assistant/core/issues/78464).
Oliver
-
Hi olicat,
that's what I wanted to hear, that my foshkplugin settings are correct. Thanks.
I just wonder how did Gyvate manage to get it to work on his side. Sorry for spamming around.
-
what's your WiFi firmware version of your console which posts to FOSHKplugin ?
Should be 1.6.4 - or 1.7.5/2.1.9/1.20 if your console is a GW1000, WH2650/GW1100, GW2000/WN19x0 console
If you are on a lower WiFi firmware version, it is possible that the console sends something the ecowitt-integration cannot decipher
-
I was on 1.6.1, just updated to 1.6.4. Having the same behavior.
-
any change if the FWD_TYPE in FOSHKplug is RAWEW instead of EW ?
And maybe you put a FWD_INTERVAL = 10
-
I just fired up a VM with the dev version of HA, and everything is working.
It looks like it takes some time until the fix is going to be pushed to the public.
Thanks for your help guys!
-
..... and it's me again.
I just noticed that the plugin website is showing a blank page.
I've looked into the logs, and could not identify anything that could cause the blank page.
Where else could I check?
-
Hi!
Which website do you mean?
If you mean the standard local FOSHKplugin page showing all the current data unter http://ipaddress:port it is always a good idea to add a status&minmax to the url: http://ipaddress:port/status&minmax.
This way there's anything shown even if the weather station does not send any data (anymore).
Just to check the installation ...
Perhaps FOSHKplugin is running fine but your weather station stopped sending for unknown reason?
Oliver
-
Hi Oliver,
as I remember I was accessing it without the trailing status&minmax, in my case: http://192.168.2.207:8080/
There were lots of info, I was able to see all the foshkplugin details.
Now, following your advice, with status&minmax I get the following data:
minmax_init 1667892874
sunmins 0
last_suntime
last_suncheck
running True
wswarning True
sensorwarning False
batterywarning False
stormwarning True
tswarning False
updatewarning False
leakwarning False
co2warning False
intvlwarning False
time 1667902015
-
Hi!
wswarning True
Your station has stopped transmitting.
Check whether sending via custom server with the required settings (server ip, port, path) is activated in the configuration of the weather station.
FOSHKplugin waits for incoming data - but receives nothing.
Oliver
-
That's strange.
I just replaced my old weather station, since some sensors died a few weeks ago.
I've set up all the settings for the customized server as on my old one.
I'm seeing this in the logs: Nov 08 10:36:59 foshk foshkplugin[1115]: post-request from 192.168.2.61: /
192.168.2.61 being the weather station.
-
Hi!
You should check the path setting again.
It should be /data/report/ - nothing else. In your case the path is currently just "/" - what is wrong.
Oliver
-
That was it. Thank you!
-
Hi!
In the next FOSHKplugin version, there will be a new function that might appeal to some people.
I at least use FOSHKplugin here for dozens of forwarding destinations. It works without having to worry about it. It simply runs.
The problem is more with the remote stations that are supposed to accept and process the weather data. If they are (temporarily) unavailable, it is difficult to notice.
FOSHKplugin then simply tries to send the valid data at the next interval.
Any errors are logged in the log file, but who looks at it every day without a reason?
I certainly don't!
In order to still receive information relatively promptly if a forward destination is not reachable for a longer period of time, as of v0.10 there is the possibility to be informed via push notification (Pushover).
After a configurable number of successive unsuccessful attempts, a push message is sent:
FOSHKplugin
From FOSHKplugin on 2022-11-09 at 19:10
forward FWD-17 (EW - PWT @Leo Tablet) was unsuccessful 10 times since FOSHKplugin start (last result: TIMEOUT)
* 192.168.15.236 for ws@192.168.15.215; 11-09-2022 19:10:32 *
or
FOSHKplugin
From FOSHKplugin on 2022-11-09 at 17:21
forward FWD-53 (INFLUX2MET - InfluxDB 2.x-Forward of metric values to LoxBerry) was unsuccessful 10 times since 09.11.2022 17:15:35 (last result: : Failed to establish a new connection: [Errno 113] No route to host)
* 192.168.15.237 for ws@192.168.15.221; 09.11.2022 17:21:13 *
Included are the forward designation (Forward-nn), the forward type (FWD_TYPE) and any forward comment (FWD_CMT) - together with the error message and the time of the last successful transmission.
This message is sent exactly ONCE after the number of failed attempts specified in the config file under Warning\FWD_WARNINT. The default value is 10.
With each successful attempt, the internal counter is reset - so you really only get a warning if the specified number of failed attempts occur after each other.
After a push message, another message is only generated for this forward if at least one forward was successful before and thus the internal counter was reset.
This function can be deactivated via Warning\FWD_WARNING = False in the config file.
As usual, however, this can also be deactivated at runtime via http (http://ipaddress:port/FOSHKplugin/fwdwarning=disable) or via UDP (Plugin.fwdwarning=disable) or activated via enable.
In addition, there is also a simple html page at http://ipaddress:port/FOSHKplugin/fwdstat that shows the status of all activated forwards. There you can see at a glance whether and since when a forward has been hanging and, if so, with what error message.
The dimensioning of FWD_WARNINT is not yet completely clear. The default is currently 10 - i.e. 10 unsuccessful attempts.
With a transmission interval to the target of 30 seconds, a warning would come after 5 minutes (10*30 seconds) - if the target could not be reached continuously.
If, however, the interval is 1 minute, the warning will only come after 10 minutes of uninterrupted inaccessibility.
And if the transmission interval is 10 minutes, a warning is only given after 10*10 minutes = 100 minutes.
Perhaps I should not specify FWD_WARNINT globally for all forwards, but allow a setting option per forward?
Or would it perhaps make more sense to specify a fixed time (such as 15 or 30 or 60 minutes) as a global setting?
What do you think? What do you think makes sense? What would you wish for?
And would you use this feature at all?
I don't know how many users actually use the push function (https://foshkplugin.phantasoft.de/generic/#push) of FOSHKplugin - I like the notification that a sensor's battery needs to be changed or a thunderstorm is coming or that a sensor no longer reports (e.g. because the cap of a WH51 has come off again).
Regards, Oliver
-
I definitely like this! I'd be interested in beta testing the new release when available.
-
Hi Oliver,
And would you use this feature at all?
I'm definitely interested in using this feature. Looking forward to the new version! Just able to give a quick response now, but will give it some thought and offer some additional feedback to your questions.
Also, happy to beta test if you're looking for it.
-
Hi!
I have revised the forward warning a bit more this night.
There is now a global variable Warning\FWD_WARNINT that specifies the number of failed forwards before a warning is issued via push notification.
In addition, an individual value can be configured in each forward with FWD_WARNINT. This setting overrides the global default for that specific forward and allows the warning to be disabled individually by setting FWD_WARNING = 0.
This way, the warning behaviour can optionally be configured separately for each forward.
On the forward status page, different font colours show at a glance the status of the forwards: black: everything is ok, orange: the last forward was unsuccessful and red: the number of successive unsuccessful attempts exceeds the defined warning limit:
[ You are not allowed to view attachments ]
In addition, the formatting of date and time in all outputs - such as CSV, LOG or even in the push notification - can now be adapted via another optional setting Config\DT_FORMAT. This can then be used to determine whether this should be output as 10.11.2022 17:34:20 or 10/11/2022 17:34:20 or 11/10/2022 05:34:20 pm or whatever.
Here, the internal possibilities of the time library (https://docs.python.org/3/library/time.html#time.strftime) in Python are simply used - for dd.mm.yyyy hh:mm:ss (as usual for Germany), one simply enters in the config file under [Config]:
DT_FORMAT = %d.%m.%Y %H:%M:%S
However, this is also the default that is used with the existing configuration. For UK/US users, these variables must be swapped somewhat.
I'm still thinking about what should be a sensible value for the number of failed forward attempts as a default before a warning is given. Weather services such as WOW sometimes have temporary problems accepting data. I don't want to trigger warnings too often.
Regards, Oliver
-
Perhaps I should not specify FWD_WARNINT globally for all forwards, but allow a setting option per forward?
Or would it perhaps make more sense to specify a fixed time (such as 15 or 30 or 60 minutes) as a global setting?
What do you think? What do you think makes sense? What would you wish for?
Our Network Management System does something similar with alerts occurring after a certain number of missed polls. There's the option to send repeating alerts, but I find it a bit too much to have repeating alerts. So it won't send a follow up alert unless things are reset by whatever caused the trigger being restored.
Having both a global setting, and an individual setting that overrides the global seems like it would be good.
-
Hi!
In the new FOSHKplugin version, it will be possible to temporarily store missed forwards to InfluxDB/InfluxDB2 and transfer them when the forward destination is available again.
Technically, all data that could not be delivered to the target (for example, because the server is not available) will be stored locally as files.
If the server is then accessible again at some point, all this data is subsequently sent.
The interesting question is for which other forward types this procedure would still make sense. Because only a few weather services allow the subsequent upload of outdated data.
Do you know which weather services do support this? Does anyone already have their own experience?
Is there anyone here who would like to test the extended InfluxDB/InfluxDB2 support as a pre-beta? Please PM me. Thanks!
Regards, Oliver
-
Would you happen to have an example of forwarding Ecowitt protocol to Home Assistant?
-
Hi!
HA is not directly supported by FOSHKplugin.
Either you use a MQTT forward (https://foshkplugin.phantasoft.de/generic#mqtt) or an EW forward and let the HA integration (https://www.home-assistant.io/integrations/ecowitt/) do the rest.
Oliver
-
Hi!
HA is not directly supported by FOSHKplugin.
Either you use a MQTT forward (https://foshkplugin.phantasoft.de/generic#mqtt) or an EW forward and let the HA integration (https://www.home-assistant.io/integrations/ecowitt/) do the rest.
Oliver
I should have been more clear. Here is the EW forward that I'm trying to setup, and it's not working. Do you see anything wrong with it?
[Forward-4]
FWD-ENABLE = True
FWD-TYPE = EW
FWD_CMT = Home Assistant
FWD_URL = http://192.168.0.80:8123/api/webhook/xxxxxxxxxxxxxxxxxxxxxxxxx
-
Hi!
You should use the underscore in FWD_TYPE and FWD_ENABLE not FWD-TYPE etc.
Oliver
-
Hi!
You should use the underscore in FWD_TYPE and FQD_ENABLE not FWD-TYPE etc.
Oliver
Thank you! I knew that this had to be a ME problem! Rather embarrassing since the correct syntax was above and below the mistakes!
-
Hi!
Another teaser ...
For all those who use several weather stations locally, the next version of FOSHKplugin offers a new feature for web-based searches.
With the URL http://ipaddress:port/FOSHKplugin/scanWS, all consoles accessible in the network segment are searched for via usual UDP broadcast and displayed as an overview page:
[ You are not allowed to view attachments ]
A click on the displayed ipaddress then leads directly to the WebUI of the console in question in a new browser tab - provided this console has a WebUI.
If I am unsure whether all consoles in the network are accessible or whether one has hung up, I use this option. Or if I need the MAC address for any API attempts.
Perhaps this is also interesting for other users.
If you would like to participate in the internal beta test to be able to use all the new functions a little earlier, please contact me by PM.
Most of the changes and enhancements are already described in the changelog (Version History). If there are any questions about the changelog: please ask! So I can see the need for further documentation.
This version has already been running here for months - the internal beta test is only to ensure that there are no major errors - for example during installation or update - and serves to maintain the documentation. This is because questions usually arise that I can then also answer immediately as documentation.
So I would be very happy to have a few testers.
Oliver
-
I'll be happy to test!
-
I've got .10 installed and it's working perfectly.
-
Hi!
Thank you very much for the feedback.
Would 2 or 3 more users like to test FOSHKplugin v0.10? Please get in touch. Thank you!
Oliver
-
Oliver I'd be more than happy to test for you. I have just installed it on my openSUSE system and got it working. Just two comments on an openSUSE system sudo is not configured by default and it's normal to run with su, also openSUSE does not use apt but 'zypper install' to install things. Fortunately it runs OK using su and all the required s/w was already installed.
Stuart
-
Hi!
I'd be more than happy to test for you.
Thanks for wanting to test FOSHKplugin!
I'm a bit dependent on the users - if there are no or hardly any volunteers, the release drags on forever because I have to test it all by myself.
Actually, the public beta test was supposed to start at Christmas - but I didn't have enough feedback from other users.
For the installation, I could query whether apt-get exists and if not, I could then install the required packages with zypper.
I could proceed analogously with sudo: if sudo exists, it is used, if not, it is not used.
This should at least allow the installation to go through without any problems.
I'll prepare this tonight and send you the link to the current pre-beta.
Oliver
-
Thanks Oliver. The issue with sudo is that it exists as a command but is not set up to work as default. Not sure if you can tell easily if it is setup.
Stuart
-
I'm waiting for the JAVA port. Don't hit me Oliver :)
-
Hi!
By now, the installation of FOSHKplugin v0.10 should also work on systems other than Debian-based. I have now successfully tested this with OpenSuse (thanks to @broadstairs) and Fedora.
Additionally, the package manager of Synology is supported - but I don't have a test possibility.
Is there anyone who would like to try FOSHKplugin on a Synology NAS? Please PM!
Otherwise, I am still looking for a user who would like to try out the new InfluxDB v2 support. It works here. But as usual, the devil is in the details - so I would like another test opportunity.
[offtopic]
I'm waiting for the JAVA port.
Incidentally, I already warned about Java as a "saviour" when it was introduced. A programming language for every device, harhar.
This extremely lame programming language, dependent on a commercial and proprietary big (!) runtime environment, is responsible for a multitude of "joys" in the IT world today (actually always have been).
Now that the corresponding support has also been removed from the last browser, I have to resort to an even more difficult crutch to operate numerous IP KVMs.
In my view, Java is not even a language that should be taught at the universities of this world. It would have been better to stick to Pascal or teach Python.
Java is dead (hopefully!).
[/offtopic]
Oliver
-
Hi Oliver,
So far my testing of v0.10 has gone well. I've just recently enabled Pushover notifications and they have been working flawlessly.
Speaking of Pushover, is it possible to alert on additional parameters? I'd be interested in alerts such as configurable temperature, rain rate & rain amount.
Thanks,
Arthur
-
Hi!
Thank you for the feedback. I don't hear any problems from the other testers either. So the public beta test can start soon.
However, I still have to take care of the installation on the Synology NAS (I have received offers for testing - thank you - I'll get back to you).
is it possible to alert on additional parameters?
So far, this is not yet possible.
This feature is actually already on my internal wish list (things that could still be done). So far, I have simply been missing the trigger - my own need.
In terms of content, however, this can quickly become very complex - because one may not want to receive a message based on a singular value, but on chained events. And you probably want to be able to define the text to be sent yourself.
I'm still tinkering with a definition language.
I'm also still thinking about how to prevent messages that are too frequent.
Let's say you want to receive a push message when the temperature drops below 0°C. But then you might receive this push message again and again - with every incoming data record (with temperature below 0°C).
So I have to buffer the status "already reported". And cancel the status again (temperature > 0°C) to be able to warn again later.
For each individual definition.
So I have it on my desk. But I can't promise that it will come in v0.10 ...
Oliver
-
So far, this is not yet possible.
This feature is actually already on my internal wish list (things that could still be done). So far, I have simply been missing the trigger - my own need.
In terms of content, however, this can quickly become very complex - because one may not want to receive a message based on a singular value, but on chained events. And you probably want to be able to define the text to be sent yourself.
I'm still tinkering with a definition language.
Thanks Oliver. Totally get how alerts can get out of hand. Wouldn't want it to become to "noisy". Happy to know that it's being thought of.
-
Hi!
I'd be interested in alerts such as configurable temperature, rain rate & rain amount.
Do you have a few examples under which conditions you would like to receive a push notification?
Is this more complex than temperature < x or rainrate > y or uvi > 10?
Anybody else needs this feature?
Oliver
-
Hi Oli,
I'd be interested in alerts such as configurable temperature, rain rate & rain amount.
Do you have a few examples under which conditions you would like to receive a push notification?
Is this more complex than temperature < x or rainrate > y or uvi > 10?
What's I've done for now is set up e-mails from Ecowitt to Pushover.
Some of the conditions that I have set in the Ecowitt alerts are:
temp > 90F
rainrate > 0.25in/hr
lightning < 10miles
indoor temp > 85F
They are currently have an interval of 1 hour. However it could potentially get noisy if one of these conditions remains after the hour has elapsed.
I like the way our Network Management System works. When an alert is triggered it does not repeat unless it first has been reset by the alert condition not meeting the threshold. There is an option for "escalation" which then allows you to send an alert every X time periods.
-
Hi!
I now have a first implementation of the custom push notifications in internal test mode.
Is this documentation (https://foshkplugin.phantasoft.de/generic#pocustom) understandable so far (open the topic custom push notifications (from v0.10))?
Are there any open questions or requests?
My current config looks like that:
[Pushover]
PO_ENABLE = True
PO_TOKEN = mytoken
PO_URL =
PO_USER = myuser
PO_CUSTOMWARNING = True
PO_CUSTOM = @tempc <= 2.5,Current temperature (@value°C) is equal or below 2.5°C!,False,
PO_CUSTOM1 = @tempc <= 3.5,Current temperature (@value°C) is equal or below 3.5°C!,False,
PO_CUSTOM5 = @tempf <= 32,Current temperature (@value°F) is equal or below 32°F!,False,
PO_CUSTOM18 = @sunshine > 0,There's sunshine now (@value)!,True,3600
PO_CUSTOM50 = @stationtype != GW1000A_V1.7.4,Update detected\, former version was v1.7.4 - now it's @value!
A special note on this:
lightning < 10miles
The consoles remember the distance of the last lightning permanently - the value is sent again with EVERY data transmission. Even over months ...
I have no idea yet how to build in a special treatment. In addition, FOSHKplugin actually has its own thunderstorm warning - so this custom rule should not be necessary.
Oliver
-
Hi Oli,
I now have a first implementation of the custom push notifications in internal test mode.
Is this documentation (https://foshkplugin.phantasoft.de/generic#pocustom) understandable so far (open the topic custom push notifications (from v0.10))?
Are there any open questions or requests?
Wow, this is fantastic. This looks great. I've taken a look at the documentation and it is understandable and clear.
PO_CUSTOM = @tempc <= 2.5,Current temperature (@value°C) is equal or below 2.5°C!,False,
PO_CUSTOM1 = @tempc <= 3.5,Current temperature (@value°C) is equal or below 3.5°C!,False,
PO_CUSTOM5 = @tempf <= 32,Current temperature (@value°F) is equal or below 32°F!,False,
PO_CUSTOM18 = @sunshine > 0,There's sunshine now (@value)!,True,3600
PO_CUSTOM50 = @stationtype != GW1000A_V1.7.4,Update detected\, former version was v1.7.4 - now it's @value!
PO_CUSTOMn = @key [<,<=,==,>,>=,<>,!=] value,message text,activation,hold time.
In the above configuration. What happens when you leave out the activation & hold time from the configuration?
A special note on this:
lightning < 10miles
The consoles remember the distance of the last lightning permanently - the value is sent again with EVERY data transmission. Even over months ...
I have no idea yet how to build in a special treatment. In addition, FOSHKplugin actually has its own thunderstorm warning - so this custom rule should not be necessary.
Totally understood. The current implementation works well as it is.
Does the v0.10 version that you've allowed me to test have this functionality?
Thanks for your continued work,
Arthur
-
Hi!
What happens when you leave out the activation & hold time from the configuration?
Perhaps I should describe this in more detail in the recipe?
Whereas more text usually tends to put users off. In any case, defaults are used when the corresponding information is missing:
The fields message text, activation and hold time are optional and are provided with the default values if not specified:
message text: "condition "condition" is given!" (condition corresponds to the comparison formula - for example @rainin > 0.55)
activation: True (thus this rule can also be deactivated with False if required)
hold time: 3600 (this corresponds to 1 hour)
Only the condition MUST be specified. But otherwise it doesn't make any sense.
Does the v0.10 version that you've allowed me to test have this functionality?
Not yet.
First of all, I want to test this myself for a while. I would be happy to make this pre-beta available to you (and other interested parties) again in the near future.
Oliver
-
Hi!
What happens when you leave out the activation & hold time from the configuration?
Perhaps I should describe this in more detail in the recipe?
Whereas more text usually tends to put users off. In any case, defaults are used when the corresponding information is missing:
The fields message text, activation and hold time are optional and are provided with the default values if not specified:
message text: "condition "condition" is given!" (condition corresponds to the comparison formula - for example @rainin > 0.55)
activation: True (thus this rule can also be deactivated with False if required)
hold time: 3600 (this corresponds to 1 hour)
Only the condition MUST be specified. But otherwise it doesn't make any sense.
Does the v0.10 version that you've allowed me to test have this functionality?
Not yet.
First of all, I want to test this myself for a while. I would be happy to make this pre-beta available to you (and other interested parties) again in the near future.
Oliver
I'll be happy to test when you are ready.
-
Perhaps I should describe this in more detail in the recipe?
Whereas more text usually tends to put users off. In any case, defaults are used when the corresponding information is missing:
I don't think you need to add more detail, it was my fault that I overlooked this section in the documentation. ](*,)
The fields message text, activation and hold time are optional and are provided with the default values if not specified:
message text: "condition "condition" is given!" (condition corresponds to the comparison formula - for example @rainin > 0.55)
activation: True (thus this rule can also be deactivated with False if required)
hold time: 3600 (this corresponds to 1 hour)
Only the condition MUST be specified. But otherwise it doesn't make any sense.
First of all, I want to test this myself for a while. I would be happy to make this pre-beta available to you (and other interested parties) again in the near future.
Understood, thank you.
I look forward to help continue testing.
-
Hi!
You both should have received a PM. Happy testing!
Oliver
-
You both should have received a PM. Happy testing!
Got the PM, and have it installed! Looks great so far; no installation issues. Custom notifications set up, tested and working.
-
Got it installed and have 3 notifications setup. Anxiously waiting...
-
Notifications triggered and worked perfectly.
-
Confirming that notifications are working as expected. Very intuitive to set up once I read the documentation fully. [tup]
-
Hi!
Thank you both for the feedback.
I now have a minor problem with the encoding (special characters when Perl and Python work together) in the LoxBerry version. This is still holding me back from a public beta. But hopefully I will get that fixed very soon.
I'm also tinkering with a sticker/banner solution - possibly for FOSHKplugin. Would something like that be interesting for you?
I see you both use a sticker for your weather data. What is important to you? What would you like to see there?
Here is a demo:
[ You are not allowed to view attachments ]
Size, background, logo, font size, font type and of course the inscription and content can be adjusted by the user. All keys (both metric and US system) of FOSHKplugin are supported.
The generated image can be stored locally in the file system or remotely via http or FTP.
Oliver
-
Thank you both for the feedback.
Happy to assist, and appreciate you allowing me to help out.
I now have a minor problem with the encoding (special characters when Perl and Python work together) in the LoxBerry version. This is still holding me back from a public beta. But hopefully I will get that fixed very soon.
[tup]
I'm also tinkering with a sticker/banner solution - possibly for FOSHKplugin. Would something like that be interesting for you?
I see you both use a sticker for your weather data. What is important to you? What would you like to see there?
Here is a demo:
[attachment id=1 msg=457150]
Size, background, logo, font size, font type and of course the inscription and content can be adjusted by the user. All keys (both metric and US system) of FOSHKplugin are supported.
The generated PNG can be stored locally in the file system or remotely via http or FTP.
Ooh, nice. I like the idea of the banner. I'm just using the WeatherCloud banner (it is not very flexible) because I don't have an alternative. So this looks like a really nice option with a lot of helpful content options.
-
... regarding banner & sticker ...
This is now running here in test mode. A few examples to illustrate the possibilities can be found here (https://foshkplugin.phantasoft.de/banner/).
I'll write a few lines of documentation now - maybe it will come with v0.10.
Interested?
Oliver
-
... regarding banner & sticker ...
This is now running here in test mode. A few examples to illustrate the possibilities can be found here (https://foshkplugin.phantasoft.de/banner/).
I'll write a few lines of documentation now - maybe it will come with v0.10.
Interested?
Oliver
Definitely interested. Looks great!
-
Hi!
Looks great!
Thanks.
The design itself has nothing to do with the way FOSHKplugin works - it only sets the corresponding data at the given coordinates. The basis is always suitable colour/font combinations and, if necessary, background images and superimposed logos. This can be a bit of work until you have moved all the values to the right positions or found suitable background images and logos. A practised handling of graphics programmes (and of course a good eye for design) is very helpful.
But maybe it doesn't always have to be so elaborate. And perhaps there would also be users who would share the corresponding banner definition with others. Perhaps we could also have a competition - but unfortunately I wouldn't have anything as a prize.
Especially for you: a sticker (very) inspired (https://foshkplugin.phantasoft.de/banner/#img/banner-mt.png) by your Meteotemplate sticker.
Here is the corresponding banner definition to see how it works:
[Banner]
image_name = banner-mt.png # filename
image_width = 800
image_height = 170
image_background = space.jpg # from https://pixabay.com/photos/astronomy-bright-constellation-dark-1867616/
dtime_format = "%b %d %Y, %I:%M %p"
header_font_name = verdana.ttf
header_font_color = white
header_font_size = 22
header_1 = 10,80,Hohen Neuendorf PWS\, Germany,,,,,,,,
line_font_name = verdana.ttf
line_font_color = white
line_font_size = 28
#line_1 = y, key_pos,key,val_pos,value,uni, key_pos,key,val_pos,value,uni, key_pos,key,val_pos,value,uni, key_pos,key,val_pos,value,uni, key_pos,key,val_pos,value,uni
line_1 = 50,,,120,tempf,,,,260,humidity,,,,360,baromrelin,,,,510,windspeedmph,,,,640,dailyrainin,,
special_font_name = verdanab.ttf
special_font_color = white
special_font_size = 10
special_1 = 90,140,TODAY,,,,255,TODAY,,,,395,3H,,,,505,MAX TODAY,,,,665,M/Y,,,,
special_2 = 10,660,$datetime,,,,
special_3 = 155,280,https://foshkplugin.phantasoft.de,,,
special_4 = 155,620,FOSHKplugin v0.10,,,
#logo_1 = y,x,name
logo_1 = 3,3,FEWtransKreis.png
logo_2 = 100,3,weather_station_generic.png
logo_3 = 100,730,foshkplugin.png
footer_font_name = verdana.ttf
footer_font_color = white
footer_font_size = 16
#footer_1 = y, key_pos,key,val_pos,value,uni, key_pos,key,val_pos,value,uni, key_pos,key,val_pos,value,uni, key_pos,key,val_pos,value,uni, key_pos,key,val_pos,value,uni
footer_1 = 108,,,110,tempf_min, / ,,,165,tempf_max,,,,250,humidity_min, / ,,,290,humidity_max,,,,390,ptrend3,,,,515,windgustmph_max,,,,620,monthlyrainin, / ,,,690,yearlyrainin,,
footer_2 = 130,140,°F,,,,270,%,,,,385,inHg,,,,520,mph,,,,670,in,,,,
In any case, the possibilities are already quite extensive in their current state. But there are still a number of limitations.
Hence my original question: what does this function actually have to be able to do? What do you expect as a user?
And:
Is this kind of banner definition too complex?
Oliver
-
I don't think it's too complex at all.
-
Hi!
I have now put the first instructions for creating banners on the server: Creation of banners and stickers (from v0.10) (https://foshkplugin.phantasoft.de/generic#banner).
I am curious to see if it is understandable so far.
If you are interested, please contact me for a beta test of this new function.
What is possible with it can best be seen here (https://foshkplugin.phantasoft.de/banner).
Anyone with ideas for banners or stickers is welcome to share them. I'll see if it's feasible right now.
Oliver
-
I'll definitely beta test this for you.
-
Hi!
To the beta testers:
You can update FOSHKplugin to the current developer build in the usual way I described in the last PM. The file name is still unchanged.
The biggest difference to the last internal beta is the support of banners and stickers - described here (https://foshkplugin.phantasoft.de/generic#banner).
I would be happy if people would test again - especially the banner feature is still so new for me that I can't judge yet whether the documentation and the code are suitable for the general public.
Updated examples of banners and stickers can be found here (https://foshkplugin.phantasoft.de/banner/).
Happy testing!
Oliver
-
Hi Oli,
To the beta testers:
You can update FOSHKplugin to the current developer build in the usual way I described in the last PM. The file name is still unchanged.
Just getting the opportunity to update and test the banners.
The biggest difference to the last internal beta is the support of banners and stickers - described here (https://foshkplugin.phantasoft.de/generic#banner).
I would be happy if people would test again - especially the banner feature is still so new for me that I can't judge yet whether the documentation and the code are suitable for the general public.
Updated examples of banners and stickers can be found here (https://foshkplugin.phantasoft.de/banner/).
Will provide feedback after getting things set up.
Thanks,
Arthur
-
Banner is working perfectly!
-
Hi!
Thanks for the feedback!
Oh yes, for your attention. Today I added a new feature that can integrate logos into the banner based on the data. Depending on the input data, you can now display a "sun" or a "rain" logo. Or, if a value is exceeded, a red logo can be used instead of the normal green one. Or use logos with arrows.
I have illustrated this in the documentation (https://foshkplugin.phantasoft.de/generic#banner) with an example (https://foshkplugin.phantasoft.de/banner/#img/banner-logo.png).
Oliver
-
The new banner feature is working great! My creation is now on my profile!
-
Hi!
I have now added two last (?) enhancements to the banner & sticker creation:
- It is now possible to create an output image with round corners without graphics processing. It is irrelevant whether a real background image or "only" a colour is used. The radius of the rounding can also be configured.
- Now existing timestamps (such as last lightning or all min/max times) can be displayed as formatted time in the banner. The output format can be defined for each font definition - it is therefore also possible to output date and time in different lines.
In addition, a frame of any thickness and colour can now be generated for all banners and stickers.
Examples:
(https://foshkplugin.phantasoft.de/banner/img/banner-lightning-en.png)
(https://foshkplugin.phantasoft.de/banner/img/banner-grey.png)
The version for internal beta testers is available on the server.
The public beta test will start soon.
Regards, Oliver
-
Hi!
Does anyone have a need for custom output formats or embedding weather station values into their own documents (text files, web pages)?
FOSHKplugin can replace tags like [[@tempf]] in files with the corresponding value (tempf in this case) and upload these files to a server via FTP, for example.
The TAGFILE function is almost finished and may be included in the next release. The documentation (https://foshkplugin.phantasoft.de/generic#tagfile) is still in an early stage - but should already give information about the possibilities and the configuration.
A demo (https://foshkplugin.phantasoft.de/tagfile) page also exists to show the possibilities.
Anyone who would like to test it in advance: please PM.
Oliver
-
Wow, Oli, you're really making FOSHKplugin more and more advanced. [tup]
I'll take a look at the new TAGFILE functionality over the next week!
-
Oliver I was wondering if there was a setting in the plugin like there is in both Weather Display and CMX (and perhaps others) to limit wind gust values. My WS80 today sent a max gust value of 85.9mph which I think is unlikely yes it is windy here but I've never had a gust in excess of 65mph since I started recording in 2005. Obviously WD and CMX both will ignore this value as I've now set the limit to 65mph. Is this something you would consider adding in the plugin as it would then not send this bad data to my Android display or anywhere else for that matter.
Stuart
-
Hi Stuart!
Interesting approach. I wasn't aware that CMX and WD handled it that way.
No, so far there is no comparable possibility with FOSHKplugin - it stubbornly sends the values it has received from the weather station.
I also have a certain stomachache about reacting to the reported values in this way - after all, it is not impossible that there really are gusts of wind with this speed. Even without announcing them in advance.
But I am thinking about an optional cut-off function. However, this can only be value-related and does not consider the historical development (FOSHKplugin is event- and not database-based and has hardly any knowledge about the past - although: for wind speed, direction and gusts there is a 10-minute history).
If necessary, one could define the value from which onwards transmission does not take place:
cut_off = windgustmph=65
This would mean that the windgustmph key would not be processed further if the value is greater than or equal to the specified value (here: 65).
Would this be an acceptable approach?
Or should the history and/or the wind be taken into account? But in which way? After all, gusts can indeed occur suddenly and without notice.
Can anyone think of other sensor values that should also be protected in this way? Or does this only apply to wind gusts?
Oliver
-
Oliver the issue today was 85.9 mph was so far above any other wind speed recorded today that it must have been an aberration. I have never seen anything near that recorded locally. As I said my highest ever gust recorded since 2005 was around 65mph. I'd suggest perhaps either capping it or I believe what CMX does is to ignore it and just not send it, I thinnk I'd prefer the latter so no value gets recorded for that interval. I believe this is a WS80 issue and possibly WS90.
Certainly wind gust is the only one I have had an issue.
Stuart
-
No chance someone aimed a leaf blower at it? :) . I am kidding
-
No chance someone aimed a leaf blower at it? :) . I am kidding
8-) #-o :roll: =D>
Stuart
-
Hi!
if there was a setting in the plugin like there is in both Weather Display and CMX (and perhaps others) to limit wind gust values
With FOSHKplugin v0.10 there will be such an option:
Export\LIMIT_WINDGUST = value # ignore windgustmph if >= value (key will be renamed to _windgustmph) and use last "good" maxdailygust
I'll test this now ...
add:
testing done - works as expected
Oliver
-
Stuart,
85.9 mph was so far above any other wind speed recorded today
doesn't maxdailygust then also show the wrong value?
And just to be sure:
We are talking about windgustmph and not windspeedmph?
Oliver
-
Yes it does.....
Stuart
-
Thinking about this some more I'm not sure if either CMX or WD actually ignore that max reading and just use the wind gust supplied value and use the max received from that. The max gust sent by the gateway is also in my case that 85.9mph which I believe to be invalid. So to be sure I think if either wind gust of max gust are in excess of the limit value both should be ignored. I noticed that CMX has a default value for max gust in settings of 999 so effectively allows anything, WD does something similar. I have no idea what other software does.
Stuart
-
Hi!
I think if either wind gust of max gust are in excess of the limit value both should be ignored.
With the wind gust value, a wrong value can indeed be ignored - it comes again with the next interval - hopefully correct again.
However, maxdailygust is sent again and again by the console until 24:00 - so it does not make sense to completely dispense with this value for the rest of the day. Because this would mean that a real maximum wind gust would no longer be recorded and forwarded.
So in future FOSHKplugin will cache the last valid maxdailygust and output it as maxdailygust instead of the value >= IGNORE_WINDGUST.
Actually, I would expect this behaviour already in the firmware of the console ...
Oliver
-
Hi!
I think if either wind gust of max gust are in excess of the limit value both should be ignored.
With the wind gust value, a wrong value can indeed be ignored - it comes again with the next interval - hopefully correct again.
However, maxdailygust is sent again and again by the console until 24:00 - so it does not make sense to completely dispense with this value for the rest of the day. Because this would mean that a real maximum wind gust would no longer be recorded and forwarded.
So in future FOSHKplugin will cache the last valid maxdailygust and output it as maxdailygust instead of the value >= IGNORE_WINDGUST.
Actually, I would expect this behaviour already in the firmware of the console ...
Oliver
I think your suggestion is a good one. I'm not sure there is anything in f/w to alter the max gust value, certainly I have found no options to allow capping of wind speeds max or otherwise on either GW1000 or GW1100 and I suspect it is unlikely to happen on anything other than a WS80 or WS90.
Stuart
-
Hi!
In case anyone missed it.
I have started a poll here (https://www.wxforum.net/index.php?topic=45360.0) for future support of another database server.
The current results confirm my personal ideas. However, only very few users have participated so far.
However, I am always open to other improvements or requests.
Thanks, Oliver
-
Hi!
The public beta test for FOSHKplugin v0.10 has begun.
There are - as usual - several bug fixes and tons of new features in this version.
Major new features are:
- greater compatibility with other distributions (Suse, Fedora, Synology, Arch Linux)
- support of InfluxDB2
- statistics page for forwards and warn on unsuccessfull forwards (https://foshkplugin.phantasoft.de/generic#fwdwarning)
- scan weather station page (https://foshkplugin.phantasoft.de/generic#wsscan)
- queue and resend missed data transfers for several forward types (https://foshkplugin.phantasoft.de/generic#queue)
- custom push notifications via Pushover (https://foshkplugin.phantasoft.de/generic#pocustom)
- automatic generation of banners and stickers with current weather data (https://foshkplugin.phantasoft.de/generic#banner) - demo (https://foshkplugin.phantasoft.de/banner/) available
- user-defined output format based on tags and templates - even for complete web pages (https://foshkplugin.phantasoft.de/generic#tagfile) - demo (https://foshkplugin.phantasoft.de/tagfile/) available (and another demo (https://foshkplugin.phantasoft.de/tagfile/index-pool.html))
and much more ...
If you are interested - the complete changelog is available by clicking on Version History (https://foshkplugin.phantasoft.de/generic#changelog).
Users who do not urgently need the new functions can stay with the stable version v0.09 for the time being.
The public beta test is intended to find out any errors in use cases that are difficult to recreate by me and the internal test team. In addition, I recognise through enquiries where the documentation should still be completed or adapted.
This version has been running stable for a handful of people for a few weeks, so I don't expect any major problems.
To upgrade:
Change via ssh to the directory in which FOSHKplugin is running - according to my recommendations, it could be /opt/FOSHKplugin.
If you run FOSHKplugin as root, you can do the following commands without sudo - if you run FOSHKplugin in a certain user context, the specification of that user would be important so that the permissions are correct:
sudo -u username ./generic-FOSHKplugin-install.sh -upgrade generic-FOSHKplugin-0.0.10Beta.zip
sudo -u username ./generic-FOSHKplugin-install.sh -repair
The "repair" is important this time, because FOSHKplugin has to install a new package via apt/pip to get InfluxDB v2 support.
Let me know if there're any problems or you need some explanations of the new functions. Most things should already be described on the website (https://foshkplugin.phantasoft.de/generic/).
For first time (or parallel) installation just use this link (https://foshkplugin.phantasoft.de/files/generic-FOSHKplugin-0.0.10Beta.zip) and the common installation procedure.
LoxBerry users should download and install this (https://foshkplugin.phantasoft.de/files/loxberry-FOSHKplugin-0.0.10Beta.zip) version the usual LoxBerry-installation-way instead.
Have fun!
Regards, Oliver
-
Updated with no issues.
-
Still running well, and continuing to test the new features.
-
Hi!
The public beta test for FOSHKplugin v0.10 has begun.
Do any other users have the v0.10Beta running? Are there any problems, uncertainties, wishes or requests?
Feedback is welcome - only then I can estimate if the version is stable enough for a release or if I still have to work on the code or the documentation.
Thanks a lot!
Oliver
-
v0.10Beta still running with no issues.
-
All working here Oliver with no problems noted, for ages here [tup]
-
All continuing to work well on my install of v0.10Beta.
-
Although I don't use it, I just read some of the documentation for the plug in, from a link on another post in here. The documentation alone is outstanding and I know how much effort that takes.
Oliver, really awesome job on this whole project, I really should play with it rather than just buying another GW1X or GW2X when I need another custom server ;).
who knows, might get me into nix...
Rover
-
Hi!
For a comparison of my stations regarding the air pressure, I wrote a small script today that once again shows how useful the getvalue (https://foshkplugin.phantasoft.de/generic#getvalue) function of FOSHKplugin can be used.
The script queries a list of consoles and outputs the absolute and relative air pressure as CSV:
addr;model;abs;rel
192.168.15.236:8081;HP2551C;1007,72;1012,83
192.168.15.100:8084;HP3501C;1007,72;1012,83
192.168.15.100:8083;GW2000;1006,4;1011,51
192.168.15.100:8089;GW1100;1006,2;1011,31
192.168.15.236:8080;GW1000-1;1007,01;1012,09
192.168.15.237:8080;GW1000-2;1006,6;1011,72
192.168.15.100:8080;WN1900C;1007,11;1012,19
192.168.15.100:8082;WN1980C;1007,42;1012,5
I also included a function in FOSHKplugin to convert the decimal point into a comma, as this is necessary for the import into a German Excel version. The sed command could therefore be omitted if an additional &comma were specified in the URL (this internal beta is not yet published).
The script:
#!/bin/bash
# write CSV header
echo "addr;model;abs;rel"
# list of weather stations model,ipaddress:port
array="HP2551C,192.168.15.236:8081 HP3501C,192.168.15.100:8084 GW2000,192.168.15.100:8083 GW1100,192.168.15.100:8089 GW1000-1,192.168.15.236:8080 GW1000-2,192.168.15.237:8080 WN1900C,192.168.15.100:8080 WN1980C,192.168.15.100:8082"
for device in $array; do
model=`echo ${device%%","*}`
addr=`echo ${device##*,}`
abs=`curl -s http://${addr}/getvalue?key=baromabshpa|sed 's/\./\,/g'`
rel=`curl -s http://${addr}/getvalue?key=baromrelhpa|sed 's/\./\,/g'`
echo "$addr;$model;$abs;$rel"
done
In this way, one could of course also write other values together in an Excel file for comparison purposes.
Perhaps one or the other idea for your own problem solutions will result from this ...
Oliver
-
Has anyone tried installing the plugin on a Synology NAS? I'm new to this and am asking for help.
-
there are several options - probably the simplest would be to install an Ubuntu VM (Virtual Machine) and run FOSHKplugin inside than VM.
It depends on the capabilities of your Synology NAS - not all come with the same features.
But if yours has the VMM (virual machine manager) or it can be optionally installed, that would be a way to go.
A Docker container could be another option, even though there is probably not a ready-made FOSHKplugin Docker "VM".
It also depends on your knowledge of Linux (derivates) etc.
I installed an Ubuntu VM (your choice if it's a VM with a desktop or a console only install) for someone on a Synology NAS to run CumulusMX in it. And then FOSHKplugin can of course also be run inside that VM. The creation of a (Linux, here Ubuntu) VM is a rather uncomplicated process and you can find lots of setup examples/instructions in the web.
-
I need to allow my PWTablet to be sent data having replaced the non-existent temp/hum from my WS80 (the sensor has failed again!) with the values from my WH31, however the export function specifically says it does not affect RAWEW which is what PWT uses. How can I achieve this with the plugin?
Stuart
-
Hi!
Try FWD_TYPE = EW please.
Oliver
-
Thanks I'll try that.
Stuart
-
Is it possible to feed a v10 beta from a v9 stable and run both in parallel for test?
-
Hi!
Yes, that's absolutely no problem. I also like to do that here for testing purposes. Simply install v0.10 in a separate directory and declare a different name for the service (if you want to run this instance also as a service) and create a forward of type EW or RAWEW with target to FOSHKplugin v0.10.
BTW:
I have updated the downloadable beta versions to the current working status today. Minor bugs have been fixed and the option of temporarily deactivating the sending of battery warnings via the web interface has been added.
Oliver
-
I have moved my FOSHKplugin install from a local server in my house to an AWS instance. I can access the /FOSHKplugin/help page and data is being received from my weather station, however none of my forwards are working to external services.
[Forward-17]
FWD_CMT = forward in Awekas API format
FWD_TYPE = AWEKAS
FWD_ URL = http://data.awekas.at/eingabe_pruefung.php?
FWD_SID = USERNAME-REMOVED
FWD_PWD = PASSWORD-REMOVED
FWD_INTERVAL = 60
FWD_ENABLE = True
[Forward-25]
FWD_CMT = Windy
FWD_TYPE = WU
FWD_ URL = https://stations.windy.com/pws/update/[KEY-REMOVED]?
FWD_INTERVAL = 300
FWD_ENABLE = True
[Forward-26]
FWD_CMT = PWSWeather
FWD_TYPE = WU
FWD_ URL = https://www.pwsweather.com/pwsupdate/pwsupdate.php?ID=ROYALOAKYYC&PASSWORD=[PASSWORD-REMOVED]&dateutc=now
FWD_INTERVAL = 60
FWD_ENABLE = True
What am I missing? I had this running locally without any issues.
Cheers,
Jeff
-
Hi Jeff,
none of my forwards are working to external services
you should check the log files and/or the URL http://foshkpluginsite:port/FOSHKplugin/fwdstat (from FOSHKplugin v0.10Beta on).
Is it possible that FOSHKplugin does not receive any data from the weather station? Have you changed the settings for the custom server on your weather station to the new host (at AWS)?
What does http://foshkpluginsite:port/ display? A blank page? Or does the data from your weather station appear there?
Which version of FOSHKplugin are you using?
BTW:
When operating on the Internet, you should bear in mind that anyone can access the FOSHKplugin instance from anywhere and therefore interfere with it. FOSHKplugin is not designed for operation outside the private local network and is therefore not well secured against possible attacks.
I advise against using it on publicly accessible hosts.
To have at least some security, you should definitely use Config\AUTH_PWD (if set, only incoming & outgoing http-requests containing this passphrase will be accepted).
Regards, Oliver
-
Hi Oliver I’m trying to migrate my very stable Weewx/foshkplugin off my Pi 4 buster onto my shiny new Pi5 running Bookworm. I tried the standard install steps as documented on your loxberry site. But I got these errors from the install script. See below - paho? Any ideas? I can send you pm/email the full install output log if you want.
+++ FOSHKplugin +++ attempt auto configuration
import failed: No module named paho
createConfig: import failed: No module named paho
setWSConfig: import failed: No module named paho
Paul
-
Hi Paul!
import failed: No module named paho
Actually, the install script should do this automatically. However, I have not yet tested FOSHKplugin under Bookworm. So it may well be that there are still a few problems.
Please open a shell on the host (not) running FOSHKplugin under Bookworm and start
sudo pip3 install --upgrade requests paho-mqtt influxdb urllib3 influxdb-client Pillow
Do you get any error messages?
Which Python version is currently installed under Bookworm?
Please let us continue via PM. We will then post the resolution here.
Oliver
-
you should check the log files and/or the URL http://foshkpluginsite:port/FOSHKplugin/fwdstat (from FOSHKplugin v0.10Beta on).
Is it possible that FOSHKplugin does not receive any data from the weather station? Have you changed the settings for the custom server on your weather station to the new host (at AWS)?
Yes, as I mentioned, I can see data from the weather station. Including the link above. It just does not seem to send the data externally.
What does http://foshkpluginsite:port/ display? A blank page? Or does the data from your weather station appear there?
Which version of FOSHKplugin are you using?
I see the same data at http://foshkpluginsite:port/ as I do at http://foshkpluginsite:port/FOSHKplugin/fwdstat. Both live data from the weatherstation
BTW:
When operating on the Internet, you should bear in mind that anyone can access the FOSHKplugin instance from anywhere and therefore interfere with it.
Understood. Once I get it running properly, I can lock it down to only allow external traffic from my IP.
-
Hi Jeff,
which version of FOSHKplugin are you using?
But you wrote
I can access the /FOSHKplugin/help
so the version number should be displayed there. And there should also be a link to /FOSHKplugin/fwdstat ...
Oliver
-
which version of FOSHKplugin are you using?
FOSHKplugin v0.09
-
Hi Jeff,
unfortunately, the forward status page /FOSHKplugin/fwdstat is only supported with/from FOSHKplugin v0.10Beta.
You must therefore check the send log file to see what is going wrong. In the standard installation, this is the file snd-foshkplugin.log.
For each unsuccessful transmission attempt, an error number or an error text is output in addition to the line that should be transmitted.
Perhaps a cause can be recognised there?
Oliver
-
Hi Jeff,
unfortunately, the forward status page /FOSHKplugin/fwdstat is only supported with/from FOSHKplugin v0.10Beta.
You must therefore check the send log file to see what is going wrong. In the standard installation, this is the file snd-foshkplugin.log.
For each unsuccessful transmission attempt, an error number or an error text is output in addition to the line that should be transmitted.
Perhaps a cause can be recognised there?
Oliver
There is nothing in that log except a number of service start and stop messages:
19.11.2023 21:40:36.717 <OK> FOSHKplugin v0.09 stopped
19.11.2023 21:40:52.205 <OK> FOSHKplugin v0.09 started
-
Hi Jeff,
this sounds a bit strange ...
Please enable the full logging via /FOSHKplugin/loglevel=ALL (clickable from the help page) and check the log file again.
Oliver
(now off for some sleeping hours)
-
Hi Jeff,
this sounds a bit strange ...
Please enable the full logging via /FOSHKplugin/loglevel=ALL (clickable from the help page) and check the log file again.
Oliver
(now off for some sleeping hours)
The other log files are being updated, but there is still nothing new in the SND log file. Despite the internal periods having been surpassed.
-
Hi Jeff,
in the event of such strange behaviour (data from the weather station arrives but is not forwarded), it is advisable to stop the FOSHKplugin service and start the program manually instead. This allows you to see any error messages directly on the screen.
To do this, please enter the following commands in the console:
service foshkplugin stop # if the service has this name
cd /opt/FOSHKplugin # if the programme was installed there
./foshkplugin.py # starts FOSHKplugin in the current user context - if necessary, specify a different user with sudo -u username foshkplugin.py
Please send me this output (after a minute runtime or so) as well as the FOSHKplugin log files and the config file (after changing the passwords contained therein) as a ZIP file via PM. Here, too, we should continue via PM as the readership is unlikely to be interested in a single-case solution.
Thank you and good luck!
Oliver
-
Hello,
I am using FOSHKplugin to feed data to Weewx and it otherwise works great but every time I reboot RPi OS and the config file looks like this:
[Status]
last_lightning_time = 1700959855
last_lightning = 10
StopTime = 1702205509
I then restore config from backup and restart service and it works fine until next reboot when all this happens again. Any idea why ?
-
Hi!
Is that all the file contains?
That's strange.
I know the problem that the contents of the config file are occasionally lost. But this really only happens occasionally. I start the various FOSHKplugin services here very often. Only very rarely is the file destroyed.
I have therefore only given this problem a low priority so far.
If you don't have an external backup of the file (or want to speed up the recovery), you can also use the foshkplugin.conf.foshkbackup created by FOSHKplugin - this file contains the status of the last successful start of FOSHKplugin.
Oliver
-
Hi,
Yes, that's all. But it doesn't actually happen every time. I just rebooted it few times in a row and no problem.
I forgot to mention, I am running it from NAS. Perhaps that's why it is doing it. :roll:
Anyway, I reboot very rarely so not really a problem. I was just curious to know.
Thanx for replying.
-
Hi!
Does anyone here already use the new TAGFILE function (https://foshkplugin.phantasoft.de/generic#tagfile) of FOSHKplugin v0.10?
This allows values from the weather station to be "implanted" in any text files at definable locations.
The trick here is that so-called tags are defined, which are replaced by FOSHKplugin with the actual value each time data from the weather station is received.
These files can also be dynamically generated web pages - such as this one (https://foshkplugin.phantasoft.de/tagfile/tag-mod.html) .
I am currently working on significantly increasing the flexibility of these tags. So that the output format of each individual value can be changed before it is saved to the file.
I would be interested in your wishes and ideas in this regard - the functions substr, round, replace, fillleft, fillright, addleft, addright, strip, concat, dtime (for outputting time/date in a definable format) and onempty (e.g. use n.a. if no value received) have been implemented so far.
Interesting?
Oliver
-
That is a lot of work Oliver.
And awesome.
As you know I do something similar and just provide a file , with a bunch of variables for each, and then use JS of the page of the page to pull in as an include .
What are you using for a transport mechanism , to say , a remote site. FTP, or something that requires PHP on an http ?
I mean, to keep it simple I just use FTP
.
-
Hi!
First and foremost, the files are created locally in the file system - so they can be sent to their destination in any way - for example via Samba, directly to the local Apache or remotely via NFS.
In addition, FOSHKplugin itself supports sending to a remote server via FTP, SFTP and http/POST.
Oliver
-
Hi Oli,
Does anyone here already use the new TAGFILE function (https://foshkplugin.phantasoft.de/generic#tagfile) of FOSHKplugin v0.10?
I've not yet fully explored implementing a page with this; but have tinkered with it. It really is extremely handy. I'm amazed at the functionality that you keep adding to FOSHKplugin.
Thank you!
-
I am unable to install foshkplugin on a raspberry pi running the latest (bookworm based) OS. I believe this is because of the change in installing python3 packages in Debian Bookworm. The following error is thrown when I try to install it
+++ FOSHKplugin +++ now we have to install the python-libs
error: externally-managed-environment
× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
python3-xyz, where xyz is the package you are trying to
install.
If you wish to install a non-Debian-packaged Python package,
create a virtual environment using python3 -m venv path/to/venv.
Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
sure you have python3-full installed.
For more information visit http://rptl.io/venv
note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.
And at the very end:
createConfig: import failed: No module named paho
setWSConfig: import failed: No module named paho
How can I solve this?
-
Hi!
Just install the current beta v0.10 (https://foshkplugin.phantasoft.de/files/generic-FOSHKplugin-0.0.10Beta.zip) instead of the last stable v0.9.
I' be modified the install script to be compatible with Bookworm.
... or wait some minutes to get the brand new and latest version ...
Oliver
-
Hi!
I have just updated the public beta of FOSHKplugin v0.10 (https://foshkplugin.phantasoft.de/files/generic-FOSHKplugin-0.0.10Beta.zip) on the server.
New features include an optional calculation of the dew point for all (!) T/H sensors and the (optional) calculation of the spread (T-Td), which also collects daily minmax values.
The TAGFILE functionality (https://foshkplugin.phantasoft.de/generic#tagfile) has been revised, which now also allows more complex function blocks for modifying the values to be output.
The sending of user-defined push notifications (https://foshkplugin.phantasoft.de/generic#pocustom) has also been updated, making comparisons between different keys possible.
The first (?) Prometheus support (https://foshkplugin.phantasoft.de/generic#prometheus) has been implemented.
Finally all times (timestamps) can now also be output as text for getvalue (https://foshkplugin.phantasoft.de/generic#getvalue) queries.
BTW:
The TAGFILE function is particularly important to me - it provides the basis for customised websites (https://foshkplugin.phantasoft.de/tagfile/tag-mod.html) or apps (!). I'm really excited about what's possible on Android - this page can be installed (https://foshkplugin.phantasoft.de/temp/webApp.mp4) as a Android app!
Perhaps an Iphone user can check whether this page can be installed as a web app?
To upgrade:
I strongly recommend making a copy of the FOSHKplugin directory before upgrading. This way you have a fallback in case of unexpected problems.
Change via ssh to the directory in which FOSHKplugin is running - according to my recommendations, it could be /opt/FOSHKplugin.
If you run FOSHKplugin as root, you can do the following commands without sudo - if you run FOSHKplugin in a certain user context, the specification of that user would be important so that the permissions are correct:
sudo -u username ./generic-FOSHKplugin-install.sh -upgrade generic-FOSHKplugin-0.0.10Beta.zip
sudo -u username ./generic-FOSHKplugin-install.sh -repair
The "repair" is important this time, because FOSHKplugin has to install some packages via apt/pip.
If you just want to install as a separate installation you may download the file here (https://foshkplugin.phantasoft.de/files/generic-FOSHKplugin-0.0.10Beta.zip) and follow the usual installation process (https://foshkplugin.phantasoft.de/generic#install).
Please let me know if there're any problems or you need some explanations of the new functions. Most things should already be described on the website (https://foshkplugin.phantasoft.de/generic#changelog) in topic "Version history".
Have fun!
Oliver
-
Hi!
Now that I have learnt in the course of the investigations into Backup and Restore (https://www.wxforum.net/index.php?topic=46424) that Ecowitt distributes the sensor information on 2 separate pages due to the size, FOSHKplugin (https://foshkplugin.phantasoft.de/generic#signalquality) uses the http/JSON API for compatible consoles to provide the reception quality data.
These values can be collected in an InfluxDB, for example, and analysed graphically with Grafana. But this may also be helpful for BANNER and TAGFILE forwards.
Oliver
-
Attention!
If you have activated the the processing signal quality data (https://foshkplugin.phantasoft.de/generic#signalquality) via Export\ADD_SIGNAL = True, please note this:
I have experienced twice here that the GW1100 does not respond correctly to an http query and FOSHKplugin then waits indefinitely for a response and stops any further work.
Of course, this is not the way it was intended!
I have already implemented a fix (timeout) - I just have to test it.
Until the release of the next beta (probably tomorrow), it is recommended to switch off this feature with an Export\ADD_SIGNAL = False in the config file.
Sorry!
Oliver
-
Hi!
Although I cannot say with certainty that the bug with addSignalQuality has been fixed (it only happens sporadically that the GW1100 does not respond as expected and in my test run so far this has not happened afain), I have placed a new beta version of FOSHKplugin (https://foshkplugin.phantasoft.de/files/generic-FOSHKplugin-0.0.10Beta.zip) on the server.
If you urgently need ADD_SIGNAL, you should install this version. Otherwise you can wait for the next beta (or finally the release).
Update as usual:
sudo -u username ./generic-FOSHKplugin-install.sh -upgrade generic-FOSHKplugin-0.0.10Beta.zip
sudo -u username ./generic-FOSHKplugin-install.sh -repair
Have fun!
Oliver
-
Hi!
Is this (https://foshkplugin.phantasoft.de/generic#script) perhaps something you've been waiting for?
It's not in the public beta yet. But I can provide a test version if needed.
But most importantly:
Is the content of the function sufficiently explained and comprehensible?
Oliver
Provide additional data from third-party devices globally for weather services (script) (https://foshkplugin.phantasoft.de/generic#script)
-
Hi!
Is this text understandable and can it be used as a template for a recipe?
Additional spread calculation (dew point) for outdoor and indoor sensors
Ecowitt consoles only calculate the dew point for the outdoor temperature/humidity; the dew point is not calculated for any internal T/H sensors.
If you also want to set up dew point monitoring indoors - for example due to possible mould development - you can do this with FOSHKplugin.
For comparative analyses, however, the temperature valid at the respective time is required in addition to the dew point, which is a hindrance for subsequent analyses.
For this reason, FOSHKplugin calculates the so-called spread (https://en.wikipedia.org/wiki/Dew_point_depression) - the difference between the air temperature and the dew point temperature - instead of the dew point. The greater the spread, the lower the relative humidity and the lower the spread, the more humid the air.
If the spread is 0, the air temperature and dew point temperature are identical - the air is saturated and therefore cannot absorb any more moisture - the moisture is deposited on surfaces.
The spread value is therefore already the result of the comparison of temperature and dew point.
With the configuration option (this optional calculation is deactivated by default)
Export\ADD_SPREAD = True
in foshkplugin.conf, the additional calculation of the spread can be activated for the outdoor sensor as well as for all WH31 and WH45/46.
FOSHKplugin uses the following keys for the respective dew point difference:
outdoor: spread
indoor: spreadin
WH31: spreadN (where N = 1..8)
WH45: spread_co2
These keys are part of the (daily) CSV and are transmitted via UDP and in banner, tag file (example (https://foshkplugin.phantasoft.de/tagfile/tag-dewpoint.html)), MQTT and InfluxDB forwards when ADD_SPREAD is activated. The values can also be retrieved via http and used as triggers for user-defined push notifications via pushover.
For all other forward types, these keys are in a blacklist and are NOT transmitted automatically.
If you want to switch off this blacklist for a specific forward in Ecowitt format, you can do this by setting the line
FWD_OPTION = blacklist=False
within this forward section in the configuration file foshkplugin.conf. A separate block could be used to display these values in the PWS dashboard, for example.
This function is available with FOSHKplugin v0.10 from beta 240308 (https://foshkplugin.phantasoft.de/files/generic-FOSHKplugin-0.0.10Beta.zip).
Is this function interesting for you?
Regards, Oliver
-
Hi!
There are various ways of integrating data from an Ecowitt weather station into Home Assistant.
The easiest way to do this is via the Ecowitt integration contained in the core of HA. This provides most of the keys of the current Ecowitt weather stations.
However, the additional keys generated by FOSHKplugin are of course not processed and therefore do not end up in HA.
With the current beta (https://foshkplugin.phantasoft.de/files/generic-FOSHKplugin-0.0.10Beta.zip) version v0.10 of FOSHKplugin there is a much better support of Home Assistant based on the MQTT protocol. See also the corresponding recipe (https://foshkplugin.phantasoft.de/generic#hass).
Update as usual:
sudo -u username ./generic-FOSHKplugin-install.sh -upgrade generic-FOSHKplugin-0.0.10Beta.zip
sudo -u username ./generic-FOSHKplugin-install.sh -repair
I look forward to feedback and suggestions for improvement.
Have fun!
Oliver
-
I have an Ambient Weather 2902C console and an Ecowitt GW1000 on my network. I have configured foshkplugin to get the weather data and I store it in an influxdb database using a nodered flow. I get the values through http://<ip address>:8081/JSON link in the nodered flow. Looking at the data returned from the link, I see the following 2 formats:
{"stationtype":"AMBWeatherV4.3.4", .....}and
{"PASSKEY":"xxxxx","stationtype":"GW1000B_V1.7.5", .....}The ambient data does not include values for rainratemm and yearlyrainmm; the ecowitt data includes both. Mostly the data is in the 1st format but randomly switches to the 2nd format. I would like it to get the 2nd format data. I have changed the ip address in the conf file to the GW1000 but it makes no difference. How can I force foshkplugin to get its data from the GW1000? I am using version 0.0.10Beta.
Thanks.
-
Hi!
I'm not quite sure what you're actually doing.
It looks like both consoles (i.e. the WS2902C and the GW1000) are sending to FOSHKplugin in parallel.
Is that your goal?
If not, you would have to deactivate the custom server setting on the 2902.
With the JSON query, you always receive the last data set sent in - regardless of which console.
I cannot say why you are missing the two rain values from the 2902. In which format does the 2902 send? WU or Ambient Weather? Please send me the two JSON outputs by PM. Please also send me the corresponding part of the snd-foshkplugin.log.
BTW:
Why do you supply the InfluxDB via Nodered and not directly via FOSHKplugin?
Oliver
-
I'm not quite sure what you're actually doing.
It looks like both consoles (i.e. the WS2902C and the GW1000) are sending to FOSHKplugin in parallel.
Is that your goal?
If not, you would have to deactivate the custom server setting on the 2902.
Oh, that might be the problem. Unfortunately, I am not at the location so I cannot change the 2902C settings. I will do so when I visit the site in the next few weeks.
BTW:
Why do you supply the InfluxDB via Nodered and not directly via FOSHKplugin?
I have been using the nodered flow much before I started using FOSHKplugin. I didn't change the flow other than the initial http node when I started using the FOSHKplugin :)
Thanks