Some harder to get data

Every morning, our local ham repeater has a weather net. Local hams take weather observations and they are passed up to NWS. Most people don’t have weather stations as fancy as my tempest.

There are a few things to report that cover time from 7 AM local yesterday to 7 AM local today.

  1. Low and high temp
  2. accumulated rain

For low temp, I really need to get the low from yesterday and the low from today, since the temp could dip either before or after midnight.

For accumulated rain, most people go out and read and empty the rain gauge right before net time.

Any ideas of the best way to get this data each morning?

Thanks,
Ed Greenberg
AE2Z
Queensbury NY
https://tempestwx.com/station/20031/

Hi @edg, welcome to the community.

There are a couple of different options that might suit your needs. Firstly, in the WF Tempest app there is a history tab. This gives the high/low temperature and accumulated rain for each 24 hour period, but admittedly it is not between 7 am and 7 am.

Secondly, there is a rich collection of third party applications, some of which will almost certainly suit your needs. Ones that immediately come to mind are WeeWX UDP driver for WeatherFlow station, ArchiveSW - Display & Data Archive Storage, and WeatherFlow UDP listener and MQTT/InfluxDB publisher utility.

Finally, you can always use the open API provided by WF to roll your own solution (https://weatherflow.github.io/SmartWeather/api/). If you are familiar with Python or another programming language you could readily write a script to download all the data from the past 24 hours, calculate the max/min and total accumulation, and run it just after 7 am each day.

Hope this helps!

1 Like

Thanks, Peter. The station showed up yesterday. We did our first report
to the weather net this morning. I’ll check out your links, but I run
linux. They may not be compatible.

That said, I’m an experienced python programmer, and this morning, while
I should have been working, I got Rest retrieval working and am watching
UDP packets in Wireshark.

Since I have code that monitors UDP already, I should be able to run a
monitor as a daemon and keep a data set of some sort active.

Thanks,

Ed

Remember that many of us run a Raspberry Pi. Linux is at its heart for most.

FWIW, this question comes up in the weewx-users group occasionally from users who have a desire to report based on a different ‘clock day’ than midnight-to-midnight. All the data is there in the database, you just need to query it appropriately to have it use the right start/stop times.

The weewx NOAA reports do this from midnight-to-midnight, so the sqlite3 query for these is easy to tweak. Weewx is pure python, so the code should be understandable if you’re a python dev.

The weewx driver lets you leverage that piece of code and it’s thousands of users and decade+ of use worldwide. Very stable capable software and driver.

My UDP listener takes a little different tact, basically listening similarly but being able to publish to MQTT and (thanks to a nice PR from a user) also directly publish to influxdb if desired. I run it here to let me use grafana to do a custom dashboard, but I have to think a custom query of influxdb based on a start/stop time per day is something that could readily be done.

I would suggest that you don’t want your software to keep running counts, as a system reboot would zero things out. I’d suggest the db approach and then you’re just doing a db query.

I might add, that while you should expect your hi/lo temperature to be accurate, you can ‘not’ expect that your accumulated rain is remotely accurate if you just sniff the UDP packets. WF applies their proprietary RainCheck the ‘next’ calendar day to adjust your data based on some secret sauce. I don’t know if it’s possible to get a RainCheck(ed) total for a day that is offset from midnight-to-midnight…

Since the REST data publishes RC data per reporting period… you can get RC data based on different times instead of midnight… you’l have to calculate the totals for yourself, but it is doable…