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.
[email protected] 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. > [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/bbbfc9bc-3d65-4ca5-a6d6-ec7979842aadn%40googlegroups.com.
