I do get occasional lightning_distance records, but 0 strikes = n/a distance for the vast majority of the time. I haven’t gone back in to debug log to see when/why they’re slipping through. Maybe the json method would be better, but I’d have to refactor all of my observations. Add to that, there’s 2 or 3 different message types, with significant overlap between them (i.e. one has temp-rain-lightning, one has temp-wind-lightning, another has temp-uv-lightning). Not quite sure how I’d handle that.
On Fri, Apr 11, 2025 at 11:43 AM [email protected] <[email protected]> wrote: > Well, that is good news! I did not recommend those configuration options > for a few reasons. First, I felt that I never got a confirmation that it > worked. Second, those options are 'experimental', which primarily means > that I am not fully comfortable with the implementation and for various > reasons might not be able to fully support the functionality in the future. > Knowing that it works for at least one person 'in the real world' is a good > data point as I decide whether to move it out of 'experimental' to > 'production'. > > Thanks for letting us know that things are working. > rich > > On Wednesday, 2 April 2025 at 18:34:01 UTC-4 Andrew McGinnis wrote: > >> But as far as the corrections not working, I think you are probably >>> running into the fact that MQTTSubscribe creates a packet for each topic. >>> For 'individual' topics this works fine if observations are not dependent >>> on another. The correction you are writing introduces a dependency between >>> count and distance. Some additional information is in this thread, >>> https://groups.google.com/g/weewx-user/c/NQIQ6KhG7To/m/Ke_SWuQxCwAJ >>> Is there an event topic? This is json message and therefore will get >>> around the dependency limitation of 'individual' topics. >>> rich >> >> >> This is what was happening. I followed the links and read through that >> thread. Maybe I took away the wrong solution, but I added the >> collect_observations >> = True and single_queue = True options. Wipe errant db records, >> rebuild affected daily reports, restart weewx, and boom- everything is >> working as intended. Lightning strikes are recording as 0, and strike >> distance is registering as N/A. We'll see what happens during the next >> expected storm this coming Monday, but this seems to be what I needed. >> >> On Tue, Apr 1, 2025 at 8:23 PM [email protected] <[email protected]> >> wrote: >> >>> >>> I'm not quite following either. But as far as the corrections not >>> working, I think you are probably running into the fact that MQTTSubscribe >>> creates a packet for each topic. For 'individual' topics this works fine if >>> observations are not dependent on another. The correction you are writing >>> introduces a dependency between count and distance. Some additional >>> information is in this thread, >>> https://groups.google.com/g/weewx-user/c/NQIQ6KhG7To/m/Ke_SWuQxCwAJ >>> Is there an event topic? This is json message and therefore will get >>> around the dependency limitation of 'individual' topics. >>> rich >>> On Tuesday, 1 April 2025 at 18:14:40 UTC-4 vince wrote: >>> >>>> Andrew - I think you need to more clearly state your setup and which >>>> problem(s) you are asking for help with because I certainly got very lost >>>> in your posts….. >>>> >>>> What is emitting mqtt ? >>>> Are there actual duplicate mqtt messages with the same timestamps ? >>>> How is your mqtt subscribe configured ? >>>> Which mqtt subscribe variant and version are you using ? >>>> >>>> What do a few received mqtt messages look like ? >>>> What do a few weewx loop messages with debug=1 look like ? >>>> What do you see ? >>>> What do you expect/hope to see ? >>>> >>>> On Tuesday, April 1, 2025 at 1:43:56 PM UTC-7 gjr80 wrote: >>>> >>>>> A few comments. >>>>> >>>>> I don't see multiple copies of a loop packet arriving causing a >>>>> problem. Archive record obs that are averaged (eg outTemp) will be >>>>> the same irrespective of how many time the loop packet is 'accumulated'. >>>>> Per-period obs such as rain and, in this case, lightning_strike_count >>>>> will similarly be unaffected as the difference for each such obs between >>>>> successive duplicate loop packets will be zero. Of course cumulative obs >>>>> will be nonsense, but as WeeWX does not use cumulative obs that should not >>>>> be a problem. >>>>> >>>>> Also, keep in mind how the [StdCalibrate] [[Corrections]] operate. >>>>> Each [StdCalibrate] [[Corrections]] option value is used as the >>>>> argument to a python eval() statement; if the eval() statement >>>>> causes a python exception to be raised the correction is silently ignored >>>>> (and if it exists the destination obs is left unchanged, if it does not >>>>> exist it is not created). I would suggest your main issue is your >>>>> lightning_distance correction not working as intended (are you sure >>>>> lightning_strike_count is indeed 0 or is it None?). Also, the 2nd of >>>>> your three lightning_distance corrections is the one you use; WeeWX >>>>> does not use 'nan' and use of Null will raise a python exception. >>>>> >>>>> I would suggest you set some appropriate debug settings (I am not >>>>> familiar with the MQTTSubscribe driver to know what debug settings >>>>> are required) in place such that loop packets emitted by the >>>>> MQTTSubscribe driver are logged. Then you will know exactly what is >>>>> being fed to WeeWX and how to ensure it is processed/recorded correctly. >>>>> >>>>> Gary >>>>> On Wednesday, 2 April 2025 at 04:52:32 UTC+10 Andrew McGinnis wrote: >>>>> >>>>>> ETA- 5000+ strike count/min comes from the sensor broadcasting >>>>>> packets in triplicate, and every 10 seconds for lightning. So up to 18 >>>>>> messages in each 1-min interval, with what was the true cumulative count >>>>>> of >>>>>> 303, resulted in 5454 strikes "recorded". >>>>>> >>>>>> If anyone has a way to suppress duplicate MQTT messages, I'm all >>>>>> ears. I get why sensors will send a packet multiple times to maximize >>>>>> the >>>>>> chances of reception at a station, but weewx (or, at least >>>>>> MQTTSubscribeDriver) sees each one and records it as a separate datapoint >>>>>> to aggregate in the archive period. Mostly harmless, but not entirely >>>>>> accurate. >>>>>> On Tuesday, April 1, 2025 at 2:28:50 PM UTC-4 Andrew McGinnis wrote: >>>>>> >>>>>>> I just set up an Acurite Atlas with the lightning detector sensor >>>>>>> add-on. The strike_count that it outputs is cumulative (after I found I >>>>>>> had 5000+ lightning strikes per 1min archive interval). I have it, and >>>>>>> the >>>>>>> strike_distance outputs mapped to weewx as below. rtl_433 is converting >>>>>>> strike_distance from the imperial 'miles' that is natively output, to >>>>>>> metric 'km', hence the additional units switch: >>>>>>> >>>>>>> [[[rtl_433/pi4b8/devices/Acurite-Atlas/A/571/strike_count]]] >>>>>>> name = lightning_strike_count >>>>>>> contains_total = true >>>>>>> >>>>>>> [[[rtl_433/pi4b8/devices/Acurite-Atlas/A/571/strike_distance]]] >>>>>>> name = lightning_distance >>>>>>> units = km >>>>>>> >>>>>>> The sensor output always has a strike count and distance, but since >>>>>>> the strike count is cumulative, there should be no recorded distance if >>>>>>> the >>>>>>> delta is 0. >>>>>>> >>>>>>> In StdCalibrate/Corrections, I have these: >>>>>>> radiation = luminosity / 126.7 if luminosity is not None else None >>>>>>> (<----this is working as expected) >>>>>>> lightning_distance = lightning_distance if lightning_strike_count > >>>>>>> 0 else float('nan') (<----does not work) >>>>>>> lightning_distance = lightning_distance if lightning_strike_count > >>>>>>> 0 else None (<----does not work) >>>>>>> lightning_distance = lightning_distance if lightning_strike_count > >>>>>>> 0 else Null (<----does not work) >>>>>>> >>>>>>> The *radiation *observation is being recorded as 0 when *luminosity >>>>>>> *is recorded as 0. But, since 0 is a valid possible output, if 0 != >>>>>>> None, then 0/126.7 = 0. Fair enough. >>>>>>> The *lightning_distance* should be evaluating as 0 or None, but >>>>>>> instead is being recorded as the sensor's output value, while >>>>>>> *lightning_strike_count* is recorded as 0. I went into the db and >>>>>>> ran the following, then rebuilt the affected dailies: >>>>>>> >>>>>>> - update archive set lightning_strike_count = 0 where >>>>>>> lightning_strike_count > 5; >>>>>>> - update archive set lightning_distance = 0 where >>>>>>> lightning_strike_count = 0; >>>>>>> >>>>>>> strike_count > 5 was because I caught my contains_total omission mid >>>>>>> day yesterday, and there was thunder last night. Strikes before the >>>>>>> storm >>>>>>> were largely invalid, but distance wasn't necessarily. >>>>>>> >>>>>>> [image: Screenshot 2025-04-01 141609.png] >>>>>>> Straight away, *lightning_distance* is being recorded as the >>>>>>> sensor's value, instead of 0, or ideally None/null. >>>>>>> 0 is a valid possible distance, assuming I get a direct strike. >>>>>>> Without a strike, it's not 0 distance- there *isn't* a distance. >>>>>>> >>>>>>> Rather than continue trying random changes to the Corrections logic, >>>>>>> can anyone point to where the issue or mistake may lie? Is it something >>>>>>> to >>>>>>> do with the referenced *lightning_strike_count* being a cumulative >>>>>>> number? Do I just need to yield and make the logic evaluate to 0? >>>>>>> >>>>>> -- >>> >> You received this message because you are subscribed to a topic in the >>> Google Groups "weewx-user" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/weewx-user/b3O1IzVjiCc/unsubscribe. >>> >> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> >> To view this discussion visit >>> https://groups.google.com/d/msgid/weewx-user/1e68532d-4cca-487f-aefa-bcb429c9462fn%40googlegroups.com >>> <https://groups.google.com/d/msgid/weewx-user/1e68532d-4cca-487f-aefa-bcb429c9462fn%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "weewx-user" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/weewx-user/b3O1IzVjiCc/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/weewx-user/fdcc73f3-44dc-4cb0-84ea-ea14d27d4735n%40googlegroups.com > <https://groups.google.com/d/msgid/weewx-user/fdcc73f3-44dc-4cb0-84ea-ea14d27d4735n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 visit https://groups.google.com/d/msgid/weewx-user/CAH3iRs2LtXKTNsBMXadhH%2BLaWTe1tET%2B1tk6ex%2BK1cszeFN3%2BA%40mail.gmail.com.
