The prime purpose of Weatherlink Live is to upload data to the Davis Weatherlink.com platform from where the weather conditions can be viewed and analysed on either the weatherlink.com browser application or via a smartphone app using either a Basic (free) or Pro (subscription) plan. Data can be forwarded to other weather networks such as Weather Underground but this happens only via weatherlink.com and such facilities are limited as yet.
Live WLL data can also be accessed by other local devices (eg programs running on another computer on the same local network) as described in the API documentation for Weatherlink Live at: https://weatherlink.github.io/weatherlink-live-local-api/. Key aspects of the API are summarised below.
It’s worth noting that data uploaded to weatherlink.com by WLL units can – as one might expect – be downloaded from weatherlink.com to other computers. However, these WLL downloads are different in nature than for other older devices uploading to weatherlink.com, as described in the note at the foot of this topic.
There are two important differences of data handling of WLL units from traditional Davis loggers:
Weatherlink Live data handling
There are four main mechanisms for developers to work with data generated by Weatherlink Live units:
- Direct HTTP access to the WLL unit on the local network;
- The UDP data broadcasts from WLL that provide real-time wind and rain data and that are triggered eg when the Weatherlink smartphone app is activated in the local network;
- Programmatic download of current conditions and historic data from a WLL account at weatherlink.com;
- More advanced options for working with real-time data from weatherlink.com (only likely to be of interest to professional developers and nor detailed here);
The first two (HTTP and UDP) mechanisms are covered by the API documentation and summarised briefly below, while the programmatic download of WLL data from weatherlink.com is covered in the section at the foot of this topic.
Both HTTP and UDP methods deliver their data payloads as JSON structures.
The reason for having both HTTP and UDP mechanisms is to accommodate both rapidly and slower changing weather readings in an efficient way. In practice, only wind and rain readings change on a timescale of seconds, while other parameters typically change only on a timescale of minutes. (Arguably, solar/UV can also change quickly, but accounting for solar/UV with a resolution of minutes is usually considered adequate.) So real-time wind and rain readings are handled differently from all of the other weather readings as follows:
The HTTP mechanism is the primary option for accessing weather data and requires an HTTP Request to be sent to the WLL unit. This should return a JSON document containing current conditions data from sensors on all transmitters currently active (remembering that WLL units can potentially receive data from up to eight VP2 ISS units or other transmitters). The data is segmented internally within the overall JSON document in one of four types of data structure, depending on the source of the data:
- Type 1 = ISS-type transmitters, including eg anemometer and supplementary temperature/humidity transmitters;
- Type 2 = 6345 Leaf wetness/Soil Moisture/Temperature transmitters;
- Type 3 = Pressure readings from the WLL unit itself;
- Type 4 = Inside temperature/humidity readings from the WLL unit itself
So there could be multiple listings of the Type 1 and 2 message types if there are multiple transmitters on different wireless ID’s installed, but only one each of Type 3 and 4 is to be expected.
It is not expected that local HTTP requests for current conditions data would be made more often than eg once per minute – typically, there will be no new data available to justify polling more often than that. But the JSON document returned will contain latest readings from ALL of the sensors listed above, ie including comprehensive statistics on wind and rain readings, although the wind & rain data won’t deliver the granularity that the real-time UDP data offers. Davis say that it should be OK for a small number of computers on a LAN to make these HTTP requests independently, though it would be beneficial if the request times from different computers was offset to avoid overloading the WLL unit.
The UDP mechanism for real-time wind and rain data works differently from the HTTP requests in several respects, although the UDP broadcasts, once triggered, deliver a JSON structure for the wind and rain data which is comparable in outline to the HTTP JSON structures.
- UDP broadcasts do not happen unless requested via a specific HTTP request call as described in the WLL API document. A request is made for some specific number (or duration) of UDP packets to be sent, which might be a large number like 480. If continuous broadcasts are required then requests for new UDP broadcasts must be made at regular intervals. (NB If a smartphone or tablet running the Weatherlink app is turned on with WiFi access to the LAN then this will automatically trigger UDP broadcasts).
- UDP broadcasts, once triggered, are automatically emitted by the WLL unit every 2.5 seconds and for the requested number or duration of transmissions. In other words, there is no need to repeat the UDP request until the current sequence of requested transmissions is complete.
- The UDP transmissions are broadcast across the LAN and are therefore available to all devices that might be listening for UDP on the appropriate port. So as long as one device on the LAN is assuming responsibility for managing the UDP transmissions there is no point in other devices wishing to receive the live data to do the same thing (for the wind and rain data) – they only need to listen out for the UDP packets. If more than one device does request UDP transmissions then this shouldn’t cause any problems, but broadcasts will continue until the last packet requested by any device has been sent.
- Wind and rain data for a maximum of three ISS-type transmitters can be sent in a single USP packet (with each transmitter ID’s being listed within its own data structure). If there were ever to be up to eight ISS-type transmitters then the second 3 transmitters’ data would be grouped in a second UDP packet and, if necessary, the final two grouped in a third UDP packet.
Downloads of WLL data from weatherlink.com
It is important to note that downloads of data generated by WLL units from weatherlink.com are limited to those accessible via v2 of the weatherlink.com API. See the WL.com data access by programs topic for more details. So, to underline, certain API methods that were previously available in the v1 API for traditional loggers and cellular upload devices are not supported for WLL uploads.
This means, amongst other things, that WLL data cannot be downloaded into a local copy of the Weatherlink for Windows program using the Web Download mechanism (which is effectively part of the v1 API). In one sense, this is not surprising because WLL can accept data feeds from many more sensors than can be accommodated by the traditional Weatherlink binary data structures. And so WLL data could never be fully compatible with the Web Download approach. (It could be argued that many WLL owners will use a fairly standard VP2 configuration with maybe just one or two extra sensors or transmitters which still fit within the traditional WL data format, in the same way that Enviromonitor stations allow downloads of the gateway ISS data via Web Download. But for whatever reason Davis have chosen not to support this option.)
Post your comment on this topic.