If you look in the weewx-users group you will find dozens of links on how to query your db, but in short you need to query the archive database and look for values where the strike count is greater than zero.
The precise query depends on how you mapped lightning into the weewx schema, and how you installed weewx (setup.py vs. dpkg).
But short answer is the Tempest only records what it sees. The WF app shows you what it calculated based on that ‘and mostly’ surrounding sources of information, so they will never match. There are a few long threads here on lightning in the app vs. what people see from the UDP broadcasts, and why.
Morning - I think this is the right place for the Q, rather than the weewx group - I have WF reporting to Weather Display and Weewx, we had some storms yesterday and the rain full readings are completly different.
WF App - 8.9mm
WD - 9.4mm (assuming dif is due to timings on day recording)
Weewx - 18.9mm (!?) - I cant work out why Weewx is so out, i dont have any calibrations in place for rain fall. So wondering if is anything to do with the UDP readings?
Any thoughts would be great,
my Rain settings btw are
rain = rain_accumulated.SK-00009880.obs_sky
WeatherDisplay is configured with both the station ID that can be used to access the data via the WeatherFlow servers and the sensor names that will work with the UDP interface. For UDP to work, the computer running the WD software needs to be on the same subnet as the WeatherFlow huib ( UDP broadcasts across subnets … Reading Weather Station data from a different subnet than the Hub is connected to ). Otherwise, it will need to get data from the WeatherFlow servers (which it can do if the station ID is configured correctly).
Thanks for the reply @wx3i09 Weather Display did used to have a use UDP tick box, this seems to have gone in the latest versions so it hard to tell if its using the API or UDP (prob a q for the WD forum )
In realtime there should be no difference in readings. If you are living in an area with RainCheck, then Rain Check will modify your received UDP rain sometime during the next morning.
Your weewx looks almost exactly double the WD value, which is curious. Are you running weewx on a wireless ‘and’ wired ethernet box ? I’ve seen behavior under (only) ubuntu where my UDP listener app hears things twice, once on each interface. Weewx ‘should’ handle that situation ok if the packets come in during the same second (you’d ‘duplicate timestamp’ messages in your syslog) but it’s a remote possibility…
Interesting ! its on a wired pi but it also has wireless set up - it is odd that its almost double… I will take a look and monitor it during this weeks rain as the readings i am seeing are realtime (no rain check in the UK)… In terms of the sys log - it seems that traffic is fine - Weather Display seems to be correct so its looking like Weewx is over reading
It only records what it hears…but if there’s an echo…
You’d have to basically compare the REST api historical data to your weewx db in order to figure it out. Remember, however, that you have to make sure both ends didn’t miss any broadcasts during that time period.
I’m pretty sure that WeeWX rejects duplicate LOOP packets. There have also been reports of Hubs emitting two UDP packets for each observation. The station driver has no de-dup code in it, so it may be worth checking with WeeWX to see if their LOOP packet code de-dups when the timestamp in the packet’s data is the same.
This whole conversation has given me a major feature enhancement idea, since some of the raw UDP packets are losing their functionality as WF’s AI matures. Does anyone think that it would be useful if the driver had settings for your API key and called out to the Tempest mothership and generate LOOP packets from the web API that can be mix-n-matched in the sensor_map for things like rain and lightning? No promises at this time of the year, because my work schedule is insane right now for the next month or so…
Yes! I think this would be a nice idea. In fact, I have been quietly working on something similar in the background since I noticed the rain accumulation in the UDP never quite seemed to match up with the web/app. Taking your driver as the starting point, I have a beta-ish version of a driver that uses the websocket rather than listening for the UDP packets. I know this isn’t going to suit everyone because it requires a constant internet connection, but very happy to share everything I have so far.
It might not quite be what you are looking for though if you’d prefer to call the API manually.
I’m pretty sure the core engine de-dups duplicate timestamps but it would be a fair question to ask Tom over there.
Uncertain about a driver that can talk REST API as an alternative to listening for UDP on the LAN. You’re going to likely miss more packets on the REST variant, as we’ve already seen WF have issues trying to keep up with load, but it “would” let you run weewx on a different LAN than the one the Hub is on, which might be advantageous for folks wanting to overlay multiple stations (in multiple locations) on one weewx instance. So maybe.
Thanks - wonder if it was due to the reported bug…
Typically its been dry ever since i noted the discrepancy - the pi is now only running on Wifi and we have rain tomorrow so that should be a good chance to take a look at the data…
Installed and everything is running, BUT, can’t get WeeWX to generate HTML files with the plugin enabled. With raw logging enabled, there’s a bunch of data coming in from the Tempest, but nothing is being generated. Am I missing something here?
WeeWX does generate files when it’s set to Simulator
First and foremost, thank you for that code. I installed it on a Pi 4 and it works flawlessly (to my knowledge!). Reading a few posts on Pi usage and the recommendations to limit the number of read/write to the SD card, I managed to transfer pretty much all the databases and logs related the weewx on a USB drive. For one reason I have only one message left in the syslog file and it reads: « Aug 25 20:35:31 raspberrypi /weewxd: weatherflowudp: MainThread: Listening for UDP broadcasts to IP address on port 50222, with timeout 90 and share_socket False…« . It appears every 5 minutes (my polling and posting time for data). I was wondering if the message was generated by the UDP and if it could be turned off or sent to another file? Thanks.
I am new to most of that (stations, pi and programming) but from what I gathered around for Tempest was that most issues are coming from the wrong sensor map. There is a link Tempest sensor map that provides the right sensor map. Be sure to change the ST-00000025 to your own station ID.
