WXforum.net
Weather Software => WeatherLink/weatherlink.com by Davis Instruments => Topic started by: johnd on June 29, 2020, 11:59:48 AM
-
Not sure when this happened, but the introduction to the weatherlink.com v2 API now states:
Please Note:
The WeatherLink v2 API now supports Vantage Connect, WeatherLinkIP, and WeatherLink Network Annual Subscription connected stations.
https://weatherlink.github.io/v2-api/
Not sure whether there are any implications that v1 features may start to be turned off before too long? Perhaps not?
-
Not sure when this happened, but the introduction to the weatherlink.com v2 API now states:
Please Note:
The WeatherLink v2 API now supports Vantage Connect, WeatherLinkIP, and WeatherLink Network Annual Subscription connected stations.
https://weatherlink.github.io/v2-api/
Not sure whether there are any implications that v1 features may start to be turned off before too long? Perhaps not?
The text now reads (bold and colours are by me)
Please Note:
The WeatherLink v2 API now supports Vantage Connect, WeatherLinkIP, and WeatherLink Network Annual Subscription connected stations.
The older WeatherLink v1 API will continue to function and support these older device types.
Please be aware that the WeatherLink v2 API is not a one-to-one correlation with the v1 API.
The focus of the v2 API is on the raw data from the weather station as it is reported to the WeatherLink.com service.
The v1 API was more focused on mixing different kinds of data together to form a report.
In the API docs (https://weatherlink.github.io/v2-api/data-structure-types#weatherlinkip--vantage-connect--weatherlink-network-annual-subscription)is stated that daily/ monthly and yearly high-lows will not be available for WiFi-logger type devices / uploads.
They are "High/Low Record (deprecated)"
It took some time to rewrite the data-gathering scripts for the PWS_Dashboard. Still not ready for the Leuven-Template.
The reporting scripts (WL2) can not be converted as almost no data which is currently used is available with the v2API.
Wim
-
The lack of summary and derived data on the v2 API is a bit annoying to say the least. For instance if you want Evapotranspiration like the VP2 console provides, it is only available in the historic data, and then only every 15 minutes.
It also means that in reality you have to maintain a local copy of the all data as well, which for some user applications kind of defeats the purpose of storing it "in the cloud". Without a local copy you are limited to how Davis will allow you to see the data.
The historic data is also raw "interval only" so no summed/max/min values for the day (month, year) except for rainfall. If you want to know the highest windspeed so far this year, you have to download every 1 minute (potentially) interval record for the year so far and find it yourself. You would think it would be kinder on their servers and bandwidth to make summary data available directly.
-
The lack of summary and derived data on the v2 API is a bit annoying to say the least. For instance if you want Evapotranspiration like the VP2 console provides, it is only available in the historic data, and then only every 15 minutes.
It also means that in reality you have to maintain a local copy of the all data as well, which for some user applications kind of defeats the purpose of storing it "in the cloud". Without a local copy you are limited to how Davis will allow you to see the data.
The historic data is also raw "interval only" so no summed/max/min values for the day (month, year) except for rainfall. If you want to know the highest windspeed so far this year, you have to download every 1 minute (potentially) interval record for the year so far and find it yourself. You would think it would be kinder on their servers and bandwidth to make summary data available directly.
+1
-
Does this mean that those running Weatherlink PC software will not be able to download Weatherlink.com data from stations that upload with API v2?
-
Does this mean that those running Weatherlink PC software will not be able to download Weatherlink.com data from stations that upload with API v2?
The upload and download API's are different and not directly connected. We're only talking about the download API here - the upload protocols have never been publicly disclosed AFAIK.
But, that said, there are two groups of upload devices - the 'traditional' ones (WLfW, WLIP and Connect) which effectively upload from a VP2 console and therefore are subject to the VP2 sensor combination rules; and the more recent types (EM and WLL) which, in their different ways, can cope with a much more varied selection of sensors and hence cannot (comprehensively at least) be accessed by software expecting only the VP2 sensor set. I suspect that data from these two groups must be handled rather differently behind the scenes at wl.com.
The newer EM+WLL uploaders never have been properly accessible by the v1 API and needed the v2 API to be created. What's now happened is that the v2 API has also been extended to the traditional upload group, which for now at least can be accessed either by the v1 or v2 routes, according to how your software is written.
Software designed to download data from wl.com like WLfW cannot cope with the v2 API for obvious reasons (ie it's JSON rather than binary and will often have too many sensors) and presumably never will in the case of WLfW. Other programs would likely need a significant rewrite.
But there will only be a problem with older software as and when parts of the v1 API start to be switched off at wl.com. I've absolutely no idea whether this might happen soon or never. Actually, just to pursue this train of thought, my money would probably be on no changes in the foreseeable future - too many people are using the traditional approach with existing software. But perhaps what's really needed is for someone to write a utility that can eg poll a local WLL unit for data and then offer it to client programs via the traditional API - a sort of super VVP perhaps or VVP2, except that it could also generate and buffer archive data?