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/e71fc537-3e44-479e-a55d-b197db44771cn%40googlegroups.com.
