I wish the lightning alerts could have a custom alert radius. Currently, I receive alerts for lightning up to 30 or 40 miles away. I rarely ever drive that far away from my home. I’d change my settings to only alerts for strikes less than 5 miles away.
Last week, we had a storm and my alerts we’re positively blown up from the dozens and dozens of strikes that happened within the default radius, but nowhere I even knew there was lightning happening.
I also have disabled lightning alerts. I don’t mind seeing the lightning strikes that are 30 or 40 miles away, but there are too many alerts. There needs to be some way to limit the number of alerts. I don’t really need to know every time there is a lightning strike. Does it currently group the lightning strikes? If so then maybe the time frame could be adjustable, so that you would get fewer alerts.
it reports a new strike whenever it is closer than the previously reported strike, or half a hour has past after the last reported strike.
Because the lightning reporting got more precise (in 15 distance ranges, instead of 4 or 5 as it used to be) you possibly get more strikes reported. I don’t mind if it reports a few (say 3) to tell you the storm is getting closer but the current implementation isn’t very practical.
They should divide them into ranges like 0-10km, 10-20 km and 20+ km and report the first strike and report the next ones only if it is a more nearby distance range. This will give at most 3 reports per storm. The half hour rule should change that a strike is reported not half an hour after the last reported strike but half an hour after the last detected strike.
Note that the graphs still should show the detailed 15 distance intervals, only the alerts should be binned together.
I agree completely on setting a lower limit trigger level for the lightning alerts. I had 26 strikes yesterday from my new unit. It’s out in the field several hundred feet away from any electrical that might be generating false data. But thats too many. I was outside and only heard one rumble…
Completely agree, but maybe break out the closer rings a little more. 0-2 miles, 2-5 miles, 5-10 miles, 10-15 miles, 15-20 miles, 20-30 miles, greater than 30 miles with a 30 min snooze. That way, you can quickly tell if the storm is approaching you and how quickly.
Hey everyone! Thanks for taking the time to share more information on how lightning alerts can be improved.
We have been discussing the alerts feature and would like to share one of our proposals to get your feedback. Below are screenshots of a prototype of the modified alert options. Please disregard the style and coloring and focus more on the options presented.
Users can disable lightning notifications (just like now)
Users can set a distance threshold to limit the lightning strike notifications to a range
Users can set a frequency setting. With the default frequency, selected users will receive an alert if it has been more than 30 minutes since your station last received a strike OR if the most recent strike is closer than the previous one. Selecting a different frequency ensures that you will only receive one lightning alert during that time, even if a closer strike happens during the same time window. Further, to trigger another lightning alert after your frequency time has expired, the lightning strike must be closer than the previous strike that triggered the alert.
We feel these options will satisfy the user that wants to get a notification for each closer strike, but will also allow other users to limit the number of lightning notifications in ways that work best for them.
I think it would be a lot better if the time setting was used for the time after the last detected strike, not the last reported strike. If the time is set to for example 15 minutes, and you are in the middle of a big storm, it is no use to send a notification again after 15 minutes. If you start these 15 minutes after the last detected strike, there will be no notifications unless the new strike is closer than the last notified one.
Also because you now fill in strikes from other sources, I get the strong feeling that distances have a pretty high resolution. Let’s assume it is 1 km. That means that for a single storm you can get up to 40 alarms (one for each kilometer). And with your current definition of frequency, you would possible get that again 30 minutes later. That is a flood of notifications nobody is waiting for.
So yes your first two bullet points are nice, but the third one could be a lot better as it basically the same as it currently is, but with a different timeout.
I propose to define a few distance ranges, like 0-5 km, 5-10, 10-20, 20-40+ km. You send a notification if the new strike is in one of the closer ranges compared to the previously reported strike, or the given time (frequency) has past since the last detected strike (not the last notified strike)
That way you get at most 4 notifications per storm.
Wouldn’t that be a lot better??
Admittedly reducing range (bullet point 2) and frequency limit the amount of notifications somewhat, but only at the expense of loosing otherwise useful input. (if you set frequency to 3 hours and range to 10 km, you still might get 10 notifications, but you won’t get a warning if a new storm is approaching in the next 3 hours, nor will you get long distance warnings… all just because you don’t want to be flooded with notifications (and 10 notifications is still a lot))
I might be missing something here, but how long does this effect last? For example, say a storm passes over head and the last alert received is for a strike 10 km out. If a week later a storm passes close by (but not overhead), would you get an alert for a 20 km strike (assuming the distance threshold is set sufficiently far out)? By my reading you wouldn’t, because although the frequency time has expired, the next strike is not closer than the last.
no, it is basically just the same rules that currently are in place, you will get your warning. Corrine wrote in caps a big OR, so after 30 minutes you will get a warning (and possibly many more that are reported closer than the previous one)
changing the frequency as Corrine called it, doesn’t effect the mechanism much. The mechanisme described is the current implemented mechanism (just with a customizable timeout and max range) The idea is that you get a warning for a storm in range, so you can prepare yourself and get a few (currently possibly a lot) of extra warnings if the storm keeps approaching. Once you have a nearby strike, there is no need for notification for other strikes, is there? Anyway the timelimit you want is the timelimit that Corrine is talking about. After the time is passed, you will get a warning for the next strike (independently of the distance) and you will get all the notifications for strikes that are closer.
Problem with that is that it might be exactly the same storm you are still experiencing, these extra notifications also don’t signal an approaching storm. In fact the storm might be going away from you, but still produce some strikes that are closer than the previous reported strike.
In my opinion that time-out shouldn’t start after the last reported strike, but after the last detected strike, so this flood of notification doesn’t happen twice for the same storm.
Thanks for taking the time to review our initial proposal and provide feedback. Sorry for any confusion, @peter - describing how it works in words is tricky, which is probably a sign that it’s too complicated! To be clear, this flow chart describes the current Lightning Alert algorithm:
So, as you can see, the current algorithm is pretty simple. It worked great with the lightning reporting of AIR, but as @sunny points out, with the Tempest’s improved lightning reporting, there are lots more strikes and we can estimate the distance to your station with much more confidence. The result: way too many lightning alerts for most people!
@sunny, we really like the idea of ranges/zones and we’re going to implement that ASAP.
We also want to continue the discussion here and work toward a more refined approach, including user-level control. Meanwhile, some discussion and questions:
I like how they get “tighter” as they get closer. I wonder if it would be even better to define the innermost range a bit tighter? For example, 0-3, 3-10, 10-20, 20-40+ km? Or maybe we should add an additional range that’s really close, say 0-1, 1-4, 4-10, 10-20, 20-40+?
Curious to hear everyone’s thoughts on the zone/range definition…
That’s a good point, but what if there’s a big lightning storm that’s lingering around, wouldn’t you like to know that even if it’s not “approaching”. Or, what about days where multiple storms move through in bands? If we used the strike time vs. the alert time, no alerts would be sent on the second and third bands on a day like this one:
That said, we do think it makes sense to have this timeout/reset time be user-configurable, rather than fixed at 30 minutes (and rather than adding an additional “frequency” time as proposed above). That way the user has more control.
We’ve heard from a few users (including staff at WeatherFlow) who appreciate getting all the alerts, but it seems safe to say the majority probably agree we’re sending too many now.
Thanks again to everyone here. If you have any further thoughts, please share them here! We’ll work on implementing the “ranges” ASAP, and more elegant solution soon after.
Yeah I thought about that, and initially thought it would need complex algorithms to solve, but there is a practical solution for it (come to that in a moment). But you mention that there are people that want to have all the alerts. That seems a bit crazy, that could generate hundreds or thousands of alerts. To those people I would say, as soon as the first alert comes in, open you app and just watch all the strikes come in, no need for further alerts. But for sure we love watching the strikes getting closer in the app.
In my opinion the purpose of the alerts is to alert people of incoming lightning so they can take appropriate action (go inside and enjoy the storm on your app ). It would also be good if the app warns for lightning storm coming towards you, and not just passing by very far away.
So the idea in general is to give you a warning as soon as the app is confident that there is a strike (((a long time ago I already offered a solution to suppress the false strikes, but that might have been solved in a different way, or not, I don’t know))). Then if the storm gets closer and closer, send at most a handful of extra notifications and that’s it. No more notifications, you are in a storm, and better sit it out. It will pass over. if it is a big storm, the current implementation just starts sending new alerts half an hour after it send out the last notification. It wrongly assumes it must be a new storm. And you will get a series of notifications of strikes getting closer (but in reality it is the same storm not getting closer at all). Having a timeout after the last detected strike instead of the last reported strikes prevents that.
Now getting back to the situation that another storm enters the detection range without the previous one being gone. The fix to the problem mention above was to have a timeout after the last detected strike. That would assume that this is still the same storm and not notify you again. The solution to that is to have a time-out per range (the 4 or 5 ranges you mentioned earlier). So that is 4 or 5 timers. A timer restarts when it detects any strike in its range or in a range closer to you. You won’t get notifications for a range when its timer is still running. So if a strike is detected at 12 km, the timers for the range 10-20 km and 20-40+km would both restart.
@dsj if that isn’t a clear enough description we could discus in private.
Ok, this is in place as of about 30 minutes ago. There are now four “zones” (aka “@sunny zones”) defined by the distance away from an individual station, as follows:
Zone 1: 0-5 km or 0-3 mi Zone 2: 5-10 km or 3-6 mi Zone 3: 10-20 km or 6-12 mi Zone 4: 20+ km or 12+ mi
The zones are slightly different depending on whether a station is set for SI vs imperial units, just to make sure they have integer boundaries.
And now, rather than just checking whether the latest strike is “closer than previous strike” in absolute distance, we are checking whether the latest strike is in a “closer zone than previous strike”. So the new simple algorithm looks like this:
While this quick fix doesn’t address everyone’s concerns, it should dramatically reduce the number of lightning alerts sent!
Yes, all very clear and will go into our thinking as we design improvements over this simple “closer zone rather than closer absolute distance” change. Thanks!