Interesting. Thanks for the information. Yeah, at this time I don’t have enough time either. Might be a winter project…. I’m currently displaying the closest strike. I have found I miss that I can’t display the date/time of it. So the first thing I need/want to do is figure out how to capture the time of the closest strike. I am thinking that I will need to write a small service to perform this. But even this will need to wait a bit.
On Tuesday 6 August 2024 at 06:52:01 UTC-4 michael.k...@gmx.at wrote: > Something like this could solve your rtl_433 instance "problem": > https://www.rtl-sdr.com/rtl_433-ported-to-esp32-microcontrollers-with-cc1101-or-sx127x-transceiver-chips/ > > and scan for the WH57's (or other) transmissions. Every single lightning > detected by the WH57 could then be converted to a MQTT message and be > received by mqttsubcribe. I'm thinking about buying something like this > https://www.lilygo.cc/products/lora3?_pos=1&_sid=0081a9887&_ss=r but I > don't see I have enough spare time to play with it. > Letting this little device do the 433/868/915 to MQTT conversion as a > standalone device, could make things a lot easier. > > michael.k...@gmx.at schrieb am Freitag, 2. August 2024 um 21:41:16 UTC+2: > >> 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. >> bell...@gmail.com 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 michael.k...@gmx.at 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. >>>> >>>> bell...@gmail.com 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 michael.k...@gmx.at 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] >>>>>> >>>>>> bell...@gmail.com 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 weewx-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/94c43c02-a392-462e-85b6-a8bcd90b7172n%40googlegroups.com.
