I've set up the new test service after 20:00 CEST(18:00 UTC), so comparing only makes sense for data after the change. But more thunderstorms are predicted for the coming hours. :)
[email protected] schrieb am Donnerstag, 1. August 2024 um 20:21:55 UTC+2: > I've set up my test installation with the settings above: > https://kainzbauer.net/weather/Test/Rif/en/index.html > > You can compare the lightning chart with the "vanilla" installation here: > https://kainzbauer.net/weather/Rif/en/index.html > > [email protected] schrieb am Donnerstag, 1. August 2024 um 14:53:34 > UTC+2: > >> 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/50dff00e-76e5-4bda-8c35-299b9cd29ab8n%40googlegroups.com.
