Multiple anemometers?

[Pat]

I'm working on adding a 2nd anemometer and I've extended my schema to include windSpeed1 and windGust1. My sensor does not report gust speed, so I'm relying on weewx for that. 

What's the best method to have weewx calculate windGust1 from the windSpeed1 loop packets?

[Pat]

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. 

Let me know if there's an easier way. 

[Tom Keffer]

On Tue, Feb 2, 2021 at 9:20 AM Pat <pobri...@gmail.com> 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.

[Pat]

Thanks. Been so disconnected that it feels like I need to re-learn extensions again (ingest from mqtt, submit to loop). 

[Pat O'Brien]

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. 

[Tom Keffer]

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.

--
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 weewx-developm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/248cb3f4-1dc1-4d61-8eb0-cc3bbede3952n%40googlegroups.com.

[Pat O'Brien]

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?

[bell...@gmail.com]

What do you mean by ‘aggregated instead of added’?

-rich

[Tom Keffer]

I assume the problem happens if more than one MQTT message comes in between Vantage LOOP packets?

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/285f8283-1093-4fc9-bca0-7e6fd4149484n%40googlegroups.com.

[Pat O'Brien]

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. 

[bell...@gmail.com]

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

[Pat O'Brien]

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. 

[Pat O'Brien]

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. 

[bell...@gmail.com]

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

[Graham Eddy]

i favour the collection of sensors approach as compared to the centralised weather station approach

suppose the weewx driver was just a heartbeat - creates an empty LOOP packet with a timestamp. then all data sources would be a service that insert their data since last heartbeat. but, compared to present ‘dataful driver’, it would lose the coherency of data inside each packet

by coherency, i mean that in the present design we expect every LOOP packet to carry a meaningful ‘snapshot’ of the world, to the point where we can even fill in gaps by deriving values from combinations of values present in the packet (e.g. ET). loss of LOOP coherency means it might take several packets to gather enough info to make such a derivation. that derivation would have to be made by a stateful engine monitoring LOOP packets - a bit of an expansion of StdWXCalculate from today

off the top of my head, a derivation service could have a set of inputs, each described as (obs_type, last value, expiry time), mapped into a set of outputs, each described as (obs_type, calculation). whenever an output has all non-expired inputs satisfied, it fires and injects a derived value

all this presumes that on a regular basis - the archive interval - we have collected enough data to provide a coherent set to present to the world as ‘reports’

as i think about pat’s situation, which is a need to add packets on demand, the heartbeat driver could take requests to fire a packet immediately. or to hurry up or slow down. pushing the analogy perhaps too far, if *everyone* fires packets whenever they want (probably a system config mistake) then do we risk arrhythmia..?