For what it's worth, it's also doing it to the battery and solar voltage values coming from the anemometer - so it's not isolated to just the wind values, but rather all values. I'm sure this is expected but wanted to call it out.
On Monday, February 15, 2021 at 10:35:07 AM UTC-5 Pat O'Brien wrote: > Sorry - you're right. When I said aggregated I meant averaged. And I think > that's what it's doing after staring at it for the last 20 minutes :-) It > appears that any MQTT packet in between the Vantage loop is being averaged > and presented at the NEXT loop. > > This probably isn't a big deal for everyone. My use case may be special > since I want to display this 2nd anemometer on my Belchertown website in > real time. > > The problem with 2 weewx instances is I'd like to have 1 database to > archive the data and eventually show the charts of that data. I think that > gets squirrely with 2 instances. > > On Monday, February 15, 2021 at 10:31:24 AM UTC-5 [email protected] wrote: > >> Well, if you are receiving multiple MQTT messages for a given a loop, I’d >> expect the wind speed to be the average. MQTTSubscribe is going to put the >> wind data into an accumulator and then extract the data to update the loop. >> I reasoned that this would be the same as two loop packets and WeeWX >> accumulating and then extracting them at archive creation. But I have to >> admit, wind data in WeeWX makes my head spin. >> At 2.5 second loop packets, I’d be surprised if the MQTT data made it >> into the ‘same timed’ packet... I guess you might get 2 loop from MQTT if >> the previous one just missed the loop window. >> You could set debug = 1 and we could see what is being received, managed, >> and ultimately updating the loop. You’d probably want to capture what is >> being published too. >> Maybe running two instances of WeeWX is the way to go? >> -rich >> >> On Monday, 15 February 2021 at 10:07:31 UTC-5 [email protected] wrote: >> >>> Yeah I think so. On my 2nd console, I can see the windspeed is 4.48mph >>> for example, but in the packet it's not 5.22, it's 3.7. Which looks to be a >>> rounded value of the last 2 mqtt packets within the driver's LOOP...? >>> Another example is the console shows 2.24 mph, but the MQTT packet shows >>> 2.6. Another is 3.73 on console and 4.5 in MQTT. >>> >>> So I can't tell if it's an aggregation of the MQTT packets in between >>> driver LOOPS or if the driver LOOP is behind from the MQTT payload (so the >>> next LOOP would show the next MQTT payload in chronological order)? >>> >>> My 2nd console has an update period of 2.5 seconds, and the Vantage is >>> 2.5ish seconds too, right? However they don't seem to be 100% aligned when >>> comparing them against the console. >>> >>> On Monday, February 15, 2021 at 9:57:27 AM UTC-5 Tom Keffer wrote: >>> >>>> I assume the problem happens if more than one MQTT message comes in >>>> between Vantage LOOP packets? >>>> >>>> On Mon, Feb 15, 2021 at 6:55 AM Pat O'Brien <[email protected]> wrote: >>>> >>>>> Bummer. The StdService aggregation isn't a big deal if you're not >>>>> running a live updated website :-) I wonder if it makes sense to fork the >>>>> vantage driver and try to stuff some MQTT stuff within it, which would >>>>> submit it's own additional LOOPs that way? >>>>> >>>>> On Monday, February 15, 2021 at 9:52:13 AM UTC-5 Tom Keffer wrote: >>>>> >>>>>> Not possible. genLoopPackets() is a generator function. While you can >>>>>> pipeline generator functions together (have one feed into another), you >>>>>> can't have them running in parallel. >>>>>> >>>>>> The general problem is that WeeWX allows only one driver, and, for >>>>>> better or worse, the trend over the last few years has been for people >>>>>> to >>>>>> use more than one device feeding the WeeWX engine. I've been >>>>>> experimenting >>>>>> with designs that would use a select() function, or Python async >>>>>> functions, >>>>>> to allow multiple devices. Unfortunately, it gets complicated real fast, >>>>>> plus the necessary underlying libraries are not always there. It would >>>>>> also, almost surely, break backwards compatibility. >>>>>> >>>>>> It's a problem better done in JavaScript. >>>>>> >>>>>> >>>>>> On Mon, Feb 15, 2021 at 6:34 AM Pat O'Brien <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Is it possible for a StdService to submit it's own loop packet? I >>>>>>> don't see genLoopPackets within the function but wanted to ask. It >>>>>>> would be >>>>>>> nice to be able to submit this MQTT packet as it's own loop in addition >>>>>>> to >>>>>>> the driver's loop. Right now I'm seeing a bit of a mis-timing problem >>>>>>> with >>>>>>> the StdService waiting for the driver's loop, and the MQTT data is >>>>>>> being >>>>>>> aggregated instead of added as it comes in. >>>>>>> >>>>>>> On Tuesday, February 2, 2021 at 1:09:42 PM UTC-5 Pat O'Brien wrote: >>>>>>> >>>>>>>> Thanks. Been so disconnected that it feels like I need to re-learn >>>>>>>> extensions again (ingest from mqtt, submit to loop). >>>>>>>> >>>>>>>> On Tuesday, February 2, 2021 at 1:07:48 PM UTC-5 Tom Keffer wrote: >>>>>>>> >>>>>>>>> On Tue, Feb 2, 2021 at 9:20 AM Pat <[email protected]> wrote: >>>>>>>>> >>>>>>>>>> Guess I need to dust off my memory on all this stuff :) I was >>>>>>>>>> thinking of a driver, but I think I need an extension which hooks to >>>>>>>>>> the >>>>>>>>>> loop, then I can track the max wind speed for the archive period and >>>>>>>>>> submit >>>>>>>>>> it to the record. Then reset it. >>>>>>>>> >>>>>>>>> >>>>>>>>> That's basically the way the Vantage driver does it. See class >>>>>>>>> VantageService in drivers/vantage.py. >>>>>>>>> >>>>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "weewx-development" 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-development/248cb3f4-1dc1-4d61-8eb0-cc3bbede3952n%40googlegroups.com >>>>>>> >>>>>>> <https://groups.google.com/d/msgid/weewx-development/248cb3f4-1dc1-4d61-8eb0-cc3bbede3952n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "weewx-development" 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-development/285f8283-1093-4fc9-bca0-7e6fd4149484n%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/weewx-development/285f8283-1093-4fc9-bca0-7e6fd4149484n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- You received this message because you are subscribed to the Google Groups "weewx-development" 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-development/1c5a42d0-580b-4eb0-ba58-1d5c4fca43b8n%40googlegroups.com.
