What a day, what a coincidence. One Thunderstorm after another: Vanilla (left) vs. the above config adaptions (right): [image: lightnings.png] The more lightnings in an archive_interval, the more difference (obviously!) A storm with some 300+ lightnings detected in one hour would be interesting. Thunderstorm season seems coming to an end at my place, anyway, I'm still convinced it's as close as you can get for the given hardware. [email protected] schrieb am Freitag, 2. August 2024 um 18:40:30 UTC+2:
> Thanks for the real world experience on a 10 second polling interval. I’ll > probably give that a go. > Also, thanks for the URL. Looks like an interesting place to explore. > rich > > On Thursday 1 August 2024 at 08:53:34 UTC-4 [email protected] wrote: > >> I've set my polling rate to 10s, because the WH90 provides data in about >> that frequency. Works without any hiccups in my setup, but I use GW2000 >> hardware. >> I could again rant about the fact, that the ecowitt don't emit events for >> such data as lightning strikes, like weatherflow devices do. But summing >> everything up, it wouldn't make that big of a difference, because of the >> already mentioned data quality on the sensor's side in the first place. >> If one really cares about lightning events in a given radius around the >> station, participating >> https://www.blitzortung.org/de/live_lightning_maps.php would be the way >> to go and then write an extension that extracts the relevant data for the >> individual site in realtime. >> >> [email protected] schrieb am Donnerstag, 1. August 2024 um 14:39:45 >> UTC+2: >> >>> I thought about increasing the polling frequency. But I’d want to do >>> some performance benchmarking first. Things like how long does it take to >>> send the request and process it - to give me an idea of a reasonable >>> minimum value. I’d also want to check on the load on the system. And >>> ultimately this would just decrease the possibility of multiple strikes in >>> a loop packet or the first strike “belonging” to the previous archive >>> record. >>> I also have played around with SDR. I think I could use rtl_433 and >>> MQTTSubscribe to get the data. But my other sensors are frequency 433 and >>> my ecowitt is 915, so I’d have to run another rtl_433 instance. I may still >>> do it, it could be a good MTTSubscribe wiki page. >>> At this time neither idea is worth the effort to me and I’ve already got >>> too many “irons in the fire”….. >>> Looking forward to what you learn. >>> rich >>> >>> On Thursday 1 August 2024 at 01:24:04 UTC-4 [email protected] wrote: >>> >>>> Hi Rich, >>>> >>>> that sounds to me as if your approach is as close as you can get, given >>>> that the Ecowitt devices only let you poll data in a given Interval. Also, >>>> the WH57 is more a "toy" than a sensor, missing out the vast majority of >>>> lightning strikes, and mine is set to the maximum sensitivity (but not >>>> indoor), and it often misses lightnings that are within less than 3km. >>>> Anyway, as I am running a couple of Ecowitt stations in parallel, I'll >>>> configure one of them the way you described here and compare the one to >>>> the >>>> other. Last night would have delivered good data: >>>> [image: The weather in AT, Salzburg, Hallein, Rif.png] >>>> >>>> [email protected] schrieb am Donnerstag, 1. August 2024 um 01:52:27 >>>> UTC+2: >>>> >>>>> I finally had some time to experiment with my WH57. Here is what I >>>>> ended up doing. >>>>> I have the driver polling the 1100 every 20 seconds and my archive >>>>> interval is 5 minutes. >>>>> >>>>> ‘Out of the box’ the number of strikes in an archive interval is >>>>> persisted and the distance from the last strike, even if no strikes >>>>> occurred in the interval. Like many others, I only wanted the distance if >>>>> a >>>>> strike occurred. In the [StdCalibrate][[Corrections]] I added the >>>>> following. >>>>> lightning_distance = lightning_distance if lightning_strike_count and >>>>> lightning_strike_count > 0 else None >>>>> This checks that the loop packet field lightning_strike_count has a >>>>> value and it is greater than 0. Checking that the field has a value is >>>>> important because the first loop packet after starting WeeWX sets it to >>>>> None. >>>>> >>>>> Persisting the last strike in an archive interval is nice, but I also >>>>> wanted to persist the closest. I also figured if I was capturing the last >>>>> strike, I might as well capture the first strike. I also decided to >>>>> capture >>>>> the time of the first and last strike. (Note, without writing some code I >>>>> could not figure out a way to capture the time of the min (closest) >>>>> strike. >>>>> >>>>> I also decided that the lightning_distance field would persist the >>>>> average distance to the strikes in the archive period. I did this for a >>>>> couple of reasons. First, for more consistent naming conventions. Second, >>>>> it would easily work with the Seasons skin. Note, I have no intention of >>>>> using the additional first, last, and min values in the Seasons skin. I >>>>> will use my WeeWX-JAS skin to display these. >>>>> >>>>> The first thing to do is get the data into these additional fields. I >>>>> used the [StdCalibrate][[Corrections]] section. I ended up with the >>>>> following. >>>>> lightning_last_distance = lightning_distance if lightning_strike_count >>>>> and lightning_strike_count > 0 else None >>>>> lightning_last_det_time = lightning_last_det_time if >>>>> lightning_strike_count and lightning_strike_count > 0 else None >>>>> >>>>> lightning_first_distance = lightning_distance if >>>>> lightning_strike_count and lightning_strike_count > 0 else None >>>>> lightning_first_det_time = lightning_last_det_time if >>>>> lightning_strike_count and lightning_strike_count > 0 else None >>>>> >>>>> lightning_min_distance = lightning_distance if lightning_strike_count >>>>> and lightning_strike_count > 0 else None >>>>> >>>>> lightning_distance = lightning_distance if lightning_strike_count and >>>>> lightning_strike_count > 0 else None >>>>> >>>>> With these ‘corrections’, WeeWX now accumulates the lightning data >>>>> into multiple fields. In the loop packet, all of the distance fields have >>>>> the same value. Same with the time fields. Using the accumulator >>>>> function, >>>>> the first, last, and min values can be extracted and put into the archive >>>>> record. >>>>> >>>>> My [Accumulator] section looks like the following. >>>>> # Additional lightning data, note lightning_last_det_time is below >>>>> in the GW1000 section >>>>> [[lightning_last_distance]] >>>>> extractor = last >>>>> [[lightning_first_distance]] >>>>> extractor = first >>>>> [[lightning_first_det_time]] >>>>> extractor = first >>>>> [[lightning_min_distance]] >>>>> extractor = min >>>>> # 'override' the setting that GW1000 driver has (I decided to set >>>>> it here and delete from the GW1000 section) >>>>> [[lightning_distance]] >>>>> extractor = avg >>>>> >>>>> Next, I used weectl database to add the new fields to the database. >>>>> >>>>> Finally I updated the bin/user/extensions.py with the units for the >>>>> new fields. >>>>> import weewx.units >>>>> weewx.units.obs_group_dict['lightning_last_distance'] = >>>>> 'group_distance' >>>>> weewx.units.obs_group_dict['lightning_last_det_time'] = 'group_time' >>>>> weewx.units.obs_group_dict['lightning_first_distance'] = >>>>> 'group_distance' >>>>> weewx.units.obs_group_dict['lightning_first_det_time'] = 'group_time' >>>>> weewx.units.obs_group_dict['lightning_min_distance'] = 'group_distance' >>>>> >>>>> Known limitations. >>>>> If there is more than one strike is in a loop packet interval (20 >>>>> seconds), the loop packet will have the number of strikes and the packet >>>>> will have the distance to and time of the last strike. >>>>> >>>>> Now to get some real data to experiment with displaying the data… >>>>> rich >>>>> >>>> -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/a963d666-cae0-4386-a350-69202681a1fdn%40googlegroups.com.
