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 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/fdcc73f3-44dc-4cb0-84ea-ea14d27d4735n%40googlegroups.com.
