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/724e4aad-9f06-459c-81c1-3cacc47cadd8n%40googlegroups.com.
