I can see that I am going to have to add a “derived value” of strike_count = 1 to the next version, since WeeWX finally supports lightning strike counts natively and all of these workarounds to make a “1” in WeeWX are way too kludgy for most users…
2 Likes
I had a thunderstorm last night unexpected. Weatherflow had 9 lightning strikes and the Weewx database recorded 5.
I didn’t have the log enabled. But my server is hardwired.
Yeah, I plan to if I can’t figure it out on my own. I’d rather struggle a bit for now and learn more about how WeeWX works. This is a fun distraction from work. 
We may have some storms roll through later today. I’m logging the evt_strike packets with the listener and I’ll compare the log with what ends up in the WeeWX database.
1 Like
We’re having some pretty significant T-Storms here in NJ this evening, and my Tempest has recorded 119 strikes in the last 3 hrs, however WeeWX hasn’t recorded any.
Here’s my sensor_map:
[[sensor_map]]
...
lightningXXX = lightning_strike_count.ST-00002310.obs_st
lightningYYY = lightning_strike_avg_distance.ST-00002310.obs_st
...
lightning_distance = distance.ST-00002310.evt_strike
lightning_strike_count = energy.ST-00002310.evt_strike
… and my StdCalibrate
[StdCalibrate]
[[Corrections]]
lightning_strike_count = lightning_strike_count + 1
I’m stumped…
Also in NJ and I hadn’t logged anything in WeeWX with the storms in the area this evening, but the Tempest app does show plenty of lightning.
I’ve been watching the decoded data in weatherflow-udp-listener and there were no evt_strike packets and the lightning counter in the obs_st packets never reflected anything other than 0. In my frustration, I just fired up tcpdump and I’m not seeing anything come off the Tempest that isn’t reflected in weatherflow-udp-listener when the app shows lightning. I’m puzzled.
Edit: So we’ve got a storm moving through now and it seems I finally got a few evt_strike packets and the counts in obs_st matches (as well as WeeWX). The app shows 168 strikes in the last 3 hours. I wonder if someone from WeatherFlow can shed some light on this?
Mine finally registered some too, using the config 
, but it’s way off:
There’s no way we had 30 million strikes of lightning last night. 
20 mile average distance seems about right, though.
1 Like
Here’s your sensor_map:
[[sensor_map]]
...
lightningXXX = lightning_strike_count.ST-00002310.obs_st
lightningYYY = lightning_strike_avg_distance.ST-00002310.obs_st
...
lightning_distance = distance.ST-00002310.evt_strike
lightning_strike_count = energy.ST-00002310.evt_strike
The XXX and YYY were placeholders in a commented-out (not executed) config line, as an example of using the per-minute obs_air data back before WeeWX supported lightning data natively. Put a # back in front of these two lines, unless you only want to use the per-minute summary in WeeWX. Then, change the variable names on the left of the equals signs to lightning_distance and lightning_strike_count.
… and your StdCalibrate:
[StdCalibrate]
[[Corrections]]
lightning_strike_count = lightning_strike_count + 1
The reason for your 30 million strikes is because we want this kludge above to always come out as 1. We’re mapping energy into count just to have a value in it, and then using the equivalent of count - count (0) + 1 to get the one count that we need.
More details in my next post…
The config I mentioned earlier in the thread worked fine for me. The observed evt_strike packets on the network match what ended up in WeeWx. The only change I made since was to add the following to extensions.py to set the proper groups for these variables (lightning_distance didn’t write to the database with the proper units).
import weewx.units
weewx.units.obs_group_dict['lightning_distance'] = 'group_distance'
weewx.units.obs_group_dict['lightning_strike_count'] = 'group_count'
I’d love to know if anyone is seeing lightning data in the UDP broadcasts (either evt_strike or in obs_st) that better match the numbers in the WeatherFlow app.
1 Like
With the release of WeeWX 4.x a few months ago, the database schema has been expanded to include several new observations…including these lightning-specific ones:
https://github.com/weewx/weewx/blob/schema/bin/schemas/wview_extended.py
('lightning_strike_count', 'REAL'),
('lightning_noise_count', 'REAL'),
('lightning_disturber_count', 'REAL'),
('lightning_distance', 'REAL'),
('lightning_energy', 'REAL'),
Most important thing to note is that they now have an official field for energy!
I have an editor window open now, to add updated sensor_map descriptions in both the driver code and documentation. I am also making one minor change to the driver, to emit a derived value of count = 1 on all evt_strike packets to eliminate the StdCalibrate kludge above. This will be pushed out on GitHub as v1.11, hopefully by the end of the weekend…
4 Likes
I have a different thread where I asked the same question, but got no replies. I’ll post a followup there now and tag WF specifically.
We have ‘very rare’ thunder rumbling here near Seattle/Tacoma and well over a hundred reported events in the WF app, but nothing in my UDP listener either. I’m running it in the foreground to watch as I ‘hear’ the rumbles overhead but see no evt_strike events and the obs_st has nothing in it for lightning.
Just saw a flash so even a close one. Nothing in the UDP data.
So where is WF getting its data ?
2 Likes
Thanks @vreihen, I’m not following this part, though:
Then, change the variable names on the left of the equals signs to lightning_distance and lightning_strike_count.
Change the variable names to the left of what? The obs_st lines, or the evt_strike lines?
I think you need to look into the other thread on Lightning. Short description is you shouldn’t bother integrating lightning strikes if you’re a weewx user. The data simply isn’t all in the UDP emitted broadcasts. They do math-model magic on the WF side that only appears on their servers.
1 Like
I’m curious as to why you’re going through all this work to count the lightning strikes, for two reasons.
- Shouldn’t lightning_strike_count.ST-00007481.obs_st report the number of strikes since the last observation? So just sum the values in the rows to get the total over the time period you want?
- Shouldn’t WeeWx add an row in the DB for every evt_strike, so you could just count the number of rows where a field unique to those (like lightning_energy) > 0 to do the same?
Weewx works just fine. The problem is that the UDP lightning data from the Tempest is a ‘tiny’ part of what WF’s proprietary big-data magic assembles as viewed on their mobile app.
It is not worth your time to even bother saving UDP broadcasted lightning data. It’s going to be wrong by definition. Same for rain (which is even worse, as WF corrects that the ‘next’ calendar day local time).
Please read the other long thread on this referred to a few replies upward. It has all the gory details.
I read that thread, and I looked at the data in the WeeWx database from a storm we had last night, hence my question. (And related, for me, recorded strike count as 0.2, which is weird, I expected an integer, so I’ll have to look into why that happened?). Anyway, since it sends the count of strikes (minus their online AI, I know that’s not there, just strikes recorded by the hardware raw), why can’t you just take that and report out sum the values in the display report to see the total strikes, rather than trying to count events manually?
I think there are multiple ways to get there. One is to count the evt_strike(s) that are individually recorded. One is to use the data in obs_st which is reported less often, but its total should match the number of evt_strike(s) that were seen. You might be also able to use the aggregation (see the Weewx customization guide) to do the totals for you, maybe.
Ok, we’re on the same page then. I only just started this a few days ago so wanted to make sure I wasn’t missing something. Makes sense, thanks!
Can I get some help with the latest “best practices” for lightning strike data collection with weewx and the WFUDP driver? I am using the weewx 4.x database schema with the following tables:
archive_day_lightning_distance
archive_day_lightning_disturber_count
archive_day_lightning_energy
archive_day_lightning_noise_count
archive_day_lightning_strike_count
Here are the relevant parts of my sensor map:
lightning_distance = distance.AR-00005820.evt_strike
lightning_strike_count = energy.AR-00005820.evt_strike
I also have this correction:
[[Corrections]]
lightning_strike_count = lightning_strike_count + 1
However I’m getting this behavior when I have lightning:
How can I get my strike count to be a reasonable number? I’m aware that there are limitations regarding the data presented in the local UDP stream vs the data available in the WF app once their magic cloud algorithms are applied, but I’d still like to capture what I can locally into the weewx database.
Certainly looks incorrect to me. The energy value is some undocumented value that could be almost anything (plus one, given your corrections stanza).