Yup, unfortunately for you, it is as expected. If more than one MQTT message is received for a given loop packet, it will do whatever the accumulator says to do and update the loop packet with the single value. Still a bit confused when publishing and essentially receiving every 2.5 seconds, you get multiple MQTT messages per packet. I guess MQTTSubscribe might ‘too slow’ and the MQTT queue is backing up... Is the MQTT payload json? -rich
On Monday, 15 February 2021 at 10:38:18 UTC-5 [email protected] wrote: > 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/84352f11-cad0-471d-bd70-ef277c77496an%40googlegroups.com.
