Topic: looking for a weather station that can be directly polled

[CW2274]

There is no "new" ISS. Other than some upgrades, the VP2 ISS hasn't changed since it's inception in 2006. That said, if update times have changed without public knowledge...(I truly doubt it, that's a selling point).

There have been at least two updates to the ISS.

For instance 2016+ ISS and pre-2016 ISS support different Temp/Humidity sensors. 

I was the person on this forum that broke the news on the SHT31 upgrade over the 11 and have had many (testing) in my ISS since March 2016. I don't need to call Davis for anything.

[CW2274]

I'd like to get back the OP topic......mmmmkay?

What's the problem??

[waterside]

I was the person on this forum that broke the news on the SHT31 upgrade over the 11 and have had many (testing) in my ISS since March 2016. I don't need to call Davis for anything.

Then you are already aware there have been updates to the ISS with actual behavioral changes, yet you still chose to claim the opposite?

Can we drop this now?  Please?

[galfert]

I'd like to get back the OP topic......mmmmkay?

What's the problem??

The problem is not the message. The problem is the delivery. And I can already tell things are headed the wrong way.

[waterside]

For the OP:

For wireless stations, such as from Davis, there are also independent options to receive the radio signal which in turn can allow you to build your own solution to meet your specific needs.  That can help reduce cost potentially, depending on your needs/wants.

Reviewing the specific vendor sections in this forum can be helpful if you are so inclined.  You can even look to building your own station with any combination of home-build and vendor-built components.  Some even over time end up with a solution based on components from multiple vendors (IE: rain gauge from vendor X, anemometer from vendor Y, ...).

Ultimately if your goal is to retrieve data from the station directly (IE: not via some "cloud" portal) you're likely looking at a layered solution comprised of a weather station and a third-party (free or paid) software solution.  Or if you are so inclined completely developing your own solution but there is so much good work out there already that it would make sense to leverage what has already been done.  When considering third-party software there are quite a few solutions that can work with a variety of hardware.

[galfert]

so, what I'm looking for would be a weather station that uses MQTT protocol and run a MQTT server to pull data. What would be really nice would be if it had a tipping gauge that would allow me to know whenever it tips and all data would be stored internally on my computer - not a server somewhere else that depends on the internet to get updated.

I am personally not aware of any weather station solution itself that would publish to MQ, but there are additional solutions such as Weather Display that will retrieve data from many different weather stations and in turn can publish to your MQ service.  That's just one option.

I did not know that Weather-Display could also do MQTT. Thanks! I've not used MQTT so I wonder if there are any differences between Weather-Display, WeeWX and Cumulus MX within regards to this respect?

[waterside]

I did not know that Weather-Display could also do MQTT. Thanks! I've not used MQTT so I wonder if there are any differences between Weather-Display, WeeWX and Cumulus MX within regards to this respect?

I had actually posted a request to Brian in his forums years ago for this.  I think it was within the past year that he added it and it took off - there are a bunch of discussions from those that jumped on it immediately and posted about their usage.

Sadly I haven't had the chance to get back to it, but it opens up a pretty wide number of uses without him needing to add solution-specific support (IE: it is pretty straightforward to build an MQTT consumer to publish to a time-series DB such as TSDB, Influx, or similar).

MQ adds an independent standard for publishing and consumption.  And a solution such as WD supports a wide variety of hardware.

I don't want to take away from any of the other great solutions - I only noted WD supporting MQ since the OP mentioned the use of MQ.

[Edit]:  I hadn't noticed that Cumulus now supports MQ as well.  It has been a while since I had looked at that but this demonstrates that the OP likely has multiple options from which to choose.

Weather data is a prime candidate for MQ.  The third party solutions are what add the value here, so the OP should keep that in mind too.

[TraderGary]

I believe this would still be pertinent to the OP...

FWIW
The VP2 update interval specs from the current Davis site:
Rainfall = 10 to 12 seconds
Rate of rainfall = 10 to 12 seconds

[johnd]

WiFi Logger is another hardware option that supports MQTT and is probably the closest one comes to a console+logger with MQTT as one of its supported interfaces and no local computer needed.

But any such arrangement is not explicitly going to support notification of when the spoon tips - I think you would need to design your own station around eg an Arduino and various sensors - perfectly doable with the right skills, but not available off the shelf AFAIK. But you can approximate this just by comparing one 10s rain reading with the next - if zero then the spoon obviously has not tipped. And rain rates >1 tip/10sec are going to be rare, so most of the time it would work fine. (Of course you would still need some code running on an upstream computer somewhere to monitor rain tips.)

Overall, I suspect that what the OP is looking for doesn't exist, short of designing and building your own station. There are no stations I know of that literally pass through raw data as and when changes occur. Rather they all do a small amount of preprocessing of the raw data and then pass that along. So I think the choice is between designing your own station or working within the constraints of what is available.

[Bushman]

There are realtime, analog/digital rain buckets based on strain gauges that do this, like from FTS.  But they are mil spec and cost a small fortune.  Frankly, I do not see the benefit in knowing to this level of granularity.

[waterside]

Davis stations (the actual Integrated Sensor Suite/ISS) transmit both rain accumulation and rain rate.  From the work that has been done deciphering the RF signal rain rate appears to be time between tips (in seconds) and rain accumulation appears to be a running total tip count that will wrap around to 0.  The console (or other receiver) would track both.

There would be no need to calculate rain rate separately, as the station itself measures that and reports it.  So capturing notification at each tip would not be needed, nor would it be possible with a Davis station.  I can't comment on other commercial units.

If the primary (or only) reason for MQ is for a near-real-time notification of a bucket tip to calculate rate then there may be better options.  If a station calculates and reports rain rate then that work is already done and all that would be left is to figure out how to collect the data and present it.  For that (collect and present) there are many options, some of which have been mentioned in this thread already.

[johnd]

Davis stations (the actual Integrated Sensor Suite/ISS) transmit both rain accumulation and rain rate.  From the work that has been done deciphering the RF signal rain rate appears to be time between tips (in seconds) and rain accumulation appears to be a running total tip count that will wrap around to 0.  The console (or other receiver) would track both.

Certainly, Davis unit calculate rain rate of course. But not everyone is happy with the algorithm used. Given that the OP seems so focused on rain rate then my guess is that they would rather use their own algorithm. (But obviously difficult to know in the absence of further feedback.)

MQTT isn't really needed for local real-time updates. But where it comes into its own is for remote real-time updates (eg across the web), especially if there might be multiple viewers wanting simultaneous access. It's a good and useful technology but not widely used as yet in weather applications. Hopefully that might change as and when new browser apps for viewing data might appear.

[waterside]

Certainly, Davis unit calculate rain rate of course. But not everyone is happy with the algorithm used.

There doesn't appear to be any algorithm - it is simply the time between tips.  Take the inverse (0.01" / # seconds) for the rate, which is exactly what would be done to obtain rate based on tip events.  This is what the Davis station does and is what the OP stated he does with a standalone tipping gauge:

so I could track rate of rate based on the time frame between tips

There are two methods to calculate a rate:  Time between unit increment or count of units increase over period of time.  Davis stations provide both pieces of data.  An actual tip event is not available from the station itself, but the time between tips is available.  An actual tip event notification would not be needed as the station would be doing exactly the same that would be done separately (as noted by the OP).

It seems that the OP was more concerned with being able to obtain data directly from the station and didn't want to depend upon an internet-based ("cloud") service.  So we're back to the case where there are many third-party solutions available that can provide that from a variety of weather stations.  (this is actually a common want/need from many, and there are a multitude of options as a result).

[johnd]

There doesn't appear to be any algorithm - it is simply the time between tips. 

The algorithm - at least in part -  is about how the rain rate is considered to decay in successive intervals if there are no new tips. See the relevant AN.

[galfert]

Music to my ears. Two statisticians discussing algorithms and maths. I like saying it the British way "maths" too. Not being sarcastic. Good stuff....rates of decay and all....heavy. We'd all be a hit at a Christmas party...right? LOL   

Merry Christmas all.

[davidmc36]

Happy Holidays for sure Gal.