How to Connect an Ecowitt or Davis Weather Station

A weather station on its own answers one question: what is the weather doing at this spot. The decisions that matter on a farm, a golf course or a solar plant need that answer next to other data. Irrigation depends on rain and soil moisture together. Frost alarms only help if they reach the person who can open the sprinklers. And if you install stations for several clients, each one needs to see their own data under their own brand.

That is what connecting a weather station to an IoTITermIoT (Internet of Things)The IoT (Internet of Things) is the network of physical objects with sensors, software and connectivity that collect and exchange data and act autonomously.View profile platform is for. This guide covers the two brands we see most in the field, Ecowitt and Davis Instruments: how their data can leave the vendor app, what to watch for in each, how to turn the raw readings into numbers you can trust, and what the data is good for once it is in one place.

Two ways to get data out of a weather station

There are two routes from a station to a platform.

Local push. The station's console or gateway sends readings over your network to a server you run. Ecowitt gateways have a "customized" upload that posts to any HTTP endpoint, and tools like ecowitt2mqtt translate it to MQTTProtocolMQTTThe standard pub/sub protocol of IoTView profile. Davis has a local API on the WeatherLink Live. The upside is that data never touches the vendor cloud. The downside is that you reconfigure every gateway, keep a server reachable from the site, and start with no history.

Vendor cloud API. The station keeps publishing to the vendor cloud exactly as it does today, and the platform reads it from there with keys the owner creates. Nothing changes on site, and in some cases the history already stored in the cloud can be imported too.

For stations already deployed and reporting, the cloud API is usually the shorter path. It is the route Cloud Studio IoT takes for both brands. Local push still has its place, and it is worth knowing how it works before choosing.

Local push: Ecowitt custom upload and the WeatherLink Live

Ecowitt: the customized upload

In the Ecowitt app (WS View Plus, or the gateway's own web page) there is a "Customized" weather service next to the usual cloud services. You fill in the protocol, the server host or IP, the path and the port, plus an upload interval in seconds. The protocol can be "Ecowitt" or "Wunderground". The Ecowitt format carries more fields, so it is the usual choice.

What arrives is an HTTP POST with form fields named after the measurement and the unit: `tempf`, `humidity`, `baromrelin`, `windspeedmph`, `dailyrainin`, `solarradiation`, and one group of fields per extra sensor (`soilmoisture1`, `temp1f` and so on). Two details matter:

• The units are imperial. Temperature in °F, pressure in inHg, wind in mph, rain in inches. The custom upload does not have the unit selector that the cloud API has.
• The station is identified by a `PASSKEY`, not by its MAC address. The receiver has to keep its own table of which passkey belongs to which station and client.

Davis: the WeatherLink Live local API

The WeatherLink Live answers on your local network. A GET to `/v1/currentconditions` on port 80 returns the latest readings, and Davis documents that it supports requests as often as every 10 seconds. For faster data there is a real-time mode: a call to `/v1/realtime` starts a UDP broadcast on port 22222 with wind and rain every 2.5 seconds, for 20 minutes by default and up to 24 hours. Requests have to come from the same local network as the device.

Units are US customary here too, and rain comes as a count of tips of the collector. The `rain_size` field says what one tip is worth (0.01 in, 0.2 mm, 0.1 mm or 0.001 in), so the conversion depends on how the gauge was configured.

When local push is worth it

Local push makes sense when data must not pass through a third-party cloud, when you need readings every few seconds (wind for a crane or a spray boom, for example), or when the site already has a server. It costs more to run: one gateway to configure at a time, an endpoint that must stay up, and no history from before the day you switched it on. For a fleet of stations spread across clients, that cost adds up fast.

Reading the vendor clouds: Ecowitt API v3 and WeatherLink v2

Ecowitt: the cloud API v3

Ecowitt gateways and consoles publish to ecowitt.net. The API v3 reads that data with two keys created in the user profile on ecowitt.net: an Application Key and an API Key. Each station is identified by its MAC address.

What helps:

• You choose the units. The API takes a unit selector per measurement, so you can ask for °C, hPa, m/s, mm and W/m² directly. One exception: vapour pressure deficit (VPD) comes back in inHg whatever you ask.
• History is there. Ecowitt keeps 5-minute detail for recent data and 30-minute detail for older ranges. A station that has been reporting for months can bring that history along instead of starting with an empty chart.
• "No data" is not an error. For a station that has not reported, the API answers successfully with an empty data block. Treat that as silence, not as a failure, or your logs fill with false alarms.

What to watch: no two stations report the same set of sensors, and channel numbers do not say what they measure. On one station `soilch1` can be the 60 cm probe and `soilch4` the 15 cm one.

Davis Instruments: the WeatherLink v2 API

Davis stations report to the WeatherLink cloud. The v2 API uses an API Key and an API Secret, generated on the Account page of weatherlink.com with Generate v2 Key. Each station has a numeric station ID, which the `/stations` endpoint returns.

What helps:

• The secret stays out of URLs. Davis takes the secret in the `X-Api-Secret` header, so it does not end up in server or proxy logs.
• One API for all the hardware. A WeatherLink Live, a Vantage Pro2 or Vantage Vue with a data logger and an EnviroMonitor node are all read the same way.

What to watch:

• Units are fixed. The v2 API always answers in US customary units: °F, inHg, inches and mph. Conversion is your job.
• The response depends on the hardware. Data comes in sensor blocks, each with its own `sensor_type`, and the field names change from one block type to another.
• Rate limits. Davis allows two calls per second and 300 per hour per key. Polling every 5 minutes is 12 calls per hour per station, so one key covers about 25 stations.
• History needs a Pro plan. The `/historic` endpoint only works for stations with a WeatherLink Pro subscription, and returns 24 hours per call.

Ecowitt and Davis side by side

• Authentication: Ecowitt uses an Application Key and an API Key in the request. Davis uses an API Key plus a secret in a header.
• Station identifier: MAC address for Ecowitt, numeric station ID for Davis.
• Units: selectable on Ecowitt; always US customary on Davis.
• History: available from the Ecowitt cloud at 5 or 30-minute resolution; on Davis, only with a Pro plan.
• Response shape: both depend on the sensors behind the station, so both need a mapping per station type.

Units, timestamps and a map for each station

Getting the readings is half the work. The other half is making sure a number means the same thing whatever station it came from.

Convert once, at the entrance

Whatever route you use, at least part of the data will arrive in US customary units. Convert it once, when it comes in, and store everything in one system. The factors are exact and short:

• Temperature: °C = (°F − 32) × 5/9
• Pressure: 1 inHg = 33.8639 hPa
• Rain: 1 in = 25.4 mm
• Wind: 1 mph = 0.44704 m/s = 1.609344 km/h

Pressure needs one more decision. Stations report both absolute pressure, measured at the station, and relative pressure, corrected to sea level. Weather maps use relative pressure; evapotranspiration formulas use the absolute one. Pick the field that matches the use and label it, because the two can differ by more than 100 hPa at altitude.

Rain is a counter, not a reading

Rain arrives as running totals: rain since midnight, since the start of the event, in the last hour. Those counters reset, and they reset on the station's own clock. If you store the daily total every five minutes and add the values up, you count the same rain many times. Store the increments instead: the difference between one reading and the next, ignoring the drop at the reset. That turns rain into something you can add up over any period.

Timestamps in UTC

Store every reading with its time in UTC and convert to local time only on screen. Daily figures (rain per day, minimum temperature, evapotranspiration) should be cut at local midnight in the station's time zone, not in the server's. Otherwise a station in Mexico and one in Spain read by the same server end up with their days shifted by hours.

A map for each station

Write down, at installation time, what each channel is: sensor, height or depth, and location. Then turn that list into the mapping the platform uses. For example, `soilch1` → soil moisture, 60 cm, north sector; `soilch4` → soil moisture, 15 cm, north sector. Without that sheet, nobody will know in six months which probe is which, and swapping two depths on a chart gives exactly the wrong irrigation advice.

Good weather station data starts at the mast

An API cannot fix a sensor in the wrong place. A few siting rules, from the WMO guide to instruments and methods of observation, make the difference between a weather station that helps and one that misleads:

• Temperature and humidity between 1.25 and 2 m above the ground, inside a ventilated radiation shield, over short grass and away from walls, paving and machinery. A sensor on a sunny wall reads too high in the afternoon.
• Rain gauge level, with its rim clear of obstacles. A common rule is to keep it at least twice the height of the nearest tree or building away from it.
• Wind in an open spot. The meteorological standard is 10 m, but agricultural stations are usually mounted at 2 m. That matters for evapotranspiration, which expects wind at 2 m. FAO-56 gives a correction for other heights: u₂ = u_z × 4.87 / ln(67.8 z − 5.42), where z is the height in metres.
• Solar radiation with the sensor level and clean. Dust and bird droppings lower the reading, and so does shade from the mast itself.

Then maintenance. Leaves and insects block rain gauge funnels; a gauge that reads zero through a storm is usually blocked, not broken. Check the level of the radiation sensor and clean it on every visit. The platform can help by watching for signs of trouble: radiation above zero at night, temperature that does not move for hours, humidity stuck at 100 % for days, or rain that stays flat while the station next door records a storm.

What the weather data is for

Most agricultural uses come down to a few variables, and the most valuable figure is not measured directly.

Evapotranspiration and irrigation

The FAO-56 Penman-Monteith method for reference evapotranspiration (ET₀), the standard way to estimate how much water a crop loses, uses air temperature, relative humidity, wind speed at 2 m and solar radiation, plus atmospheric pressure, which can be estimated from the altitude. A station that reports those four can feed an irrigation decision.

The crop's own water use is ET₀ multiplied by a crop coefficient (Kc) that changes with the crop and its stage. Subtract effective rain and you have the water the soil has to make up. Daily ET₀ is the usual unit for irrigation. It needs a full day of readings, so a station with gaps gives a weaker figure, and it is better to mark those days than to hide them.

Frost

Frost alarms work on air temperature at crop height, which on clear, still nights can be colder than at 2 m. Dew point helps too: when the air is dry, temperature falls faster after sunset and frost comes earlier. The alarm has to wake someone in time to act, so the threshold goes a couple of degrees above zero, and it needs a hysteresis so it does not fire and clear every few minutes around the threshold.

Spray windows

Spraying needs low wind, no rain soon after, and air that is not too dry. Wind speed and rain come straight from the station. For drying of the droplets, a widely used measure is Delta T, the difference between the dry-bulb and wet-bulb temperatures, which can be calculated from temperature and humidity. Values between 2 and 8 °C are commonly cited as good spraying conditions.

Other common uses

• Growing degree days, to follow crop development and pest cycles: each day adds the mean temperature minus a base temperature that depends on the crop.
• Rain totals next to soil moisture, to see how much actually infiltrated.
• Solar radiation next to the output of a PV plant, to tell a cloudy day from a fault.
• Wind speed and direction for dust, odour or crane work.

None of these needs a new weather station. They need the station's readings in the same place as the rest of the data, and alarms that reach the person who can do something about them.

How it works in Cloud Studio IoT

Cloud Studio IoT reads both brands through their cloud APIs, so the stations stay as they are. You add the keys in the client's Integrations tab, create one device per station (MAC for Ecowitt, station ID for Davis) and the device model's script maps the vendor fields to endpoints. From there the readings sit on the same dashboards, alarms and reports as any other device, for example next to LoRaWAN soil moisture sensors. Wind has its own wind rose widget, with 4, 8 or 16 direction sectors. Alarms go out by email, SMS, WhatsApp, voice call or push. For Ecowitt, the history in the Ecowitt cloud is imported too.

Because the IoT platform is multi-tenant and white-label, an integrator can connect stations for several clients and each client sees only their own, under the integrator's brand.

Step-by-step guides: Ecowitt integration and Davis WeatherLink integration. For the wider picture of sensors in the field, see our smart farming guide.

Before you connect: a short checklist

1. Keys from the account owner. The keys belong to whoever owns the Ecowitt or WeatherLink account. If that is your client, ask them to create the keys, so they can revoke them later.
2. A list of stations. MAC address or station ID, location and client for each one.
3. A map of each station. What every channel measures, at what height or depth.
4. Units and polling. Decide the units you store and how often you read. On Davis, check the number of stations per key against the limit of 300 calls per hour.
5. Who receives what. One recipient per alarm, the person who can act on it, and an alarm for a station that stops reporting.

Frequently asked questions

Do I need to change anything on my weather station?

Not with the cloud API route. The station keeps publishing to ecowitt.net or WeatherLink as it does today, and the platform reads from there.

Should I use local push or the cloud API?

For stations already working and spread across several sites, the cloud API: nothing to touch on site and, with Ecowitt, history included. Local push is for cases where data must not go through a third-party cloud or you need readings every few seconds.

Can I mix Ecowitt and Davis stations in one dashboard?

Yes. Once each station's fields are mapped and converted to the same units, the readings are ordinary device variables, whatever brand they come from.

Is the data from my Ecowitt station before the connection lost?

No. The Ecowitt cloud keeps history, at 5-minute detail for recent data and 30-minute detail for older ranges, and it can be imported.

How many Davis stations can one WeatherLink key handle?

At one call per station every 5 minutes, about 25 stations stay under Davis's limit of 300 calls per hour. With more stations, poll less often or use more than one key.

How often should a weather station be read?

Every 5 to 15 minutes is enough for irrigation, frost and reports. Faster reading only pays off for wind-sensitive work, and then local push is the better route.