Back to blog

Put Any Weather Station Online: The Complete 2026 Guide

By · Hands-on guides from the people building the platform

Put Any Weather Station Online: The Complete 2026 Guide - Pro Weather guide

Almost every weather station sold in the last decade can be put online, and there are only three ways it happens: the firmware posts to an address you type in, a small piece of software sits in between and does the posting, or a cloud API is read on your behalf. Identify which of those three applies to your hardware and the rest of the decision is about where you want the data to land, not whether it can get there at all.

That distinction is what makes this confusing when you first look into it. Most guides answer a narrower question, usually "how do I get my station onto Weather Underground". The wider question has two independent halves: how the data leaves your station, and what receives it. You can change either one without touching the other, and you can send to several destinations at once.

Looking for your exact model rather than the general picture? The supported weather stations list names them brand by brand and model by model.

What does "putting a weather station online" actually mean?

It means three separate jobs that most people think of as one: getting readings out of the station, storing them somewhere durable, and presenting them to a reader. Different products do different subsets, which is why comparing them directly tends to go wrong.

A station console on its own does none of the three. It reads the outdoor sensors over a short-range radio link and shows the numbers on a screen in your hallway. To get anything onto the internet, a device on your network has to take those readings and send them somewhere.

A gateway is that device: the piece of hardware that holds your WiFi credentials and performs the uploading. On Fine Offset hardware it is a GW1000, GW1100, GW1200, GW2000 or GW3000, or a console with a screen. On a Davis setup it is a WeatherLink Live or a WeatherLink Console. On older kit there is no gateway at all, and a computer running station software takes the role. If your sensors are reaching a console but that console is not on WiFi, nothing leaves the house.

Where the readings go determines what you end up with:

DestinationWhat you getWhose page is it
Manufacturer cloud (ecowitt.net, WeatherLink.com, ProWeatherLive)A working dashboard, free, zero configurationTheirs
Public network (Weather Underground, PWSweather, CWOP, Weathercloud)A map pin and a contribution to a shared datasetTheirs
Self-hosted software (weewx, CumulusMX)Total control of layout and dataYours, and yours to maintain
Hosted site on your own domainA branded public website with a permanent archiveYours

None of these is the right answer for everyone. A dashboard you check on your phone twice a day has no need to be a website. A station representing a village, a school, a sailing club or a farm usually does. The point of separating the two halves is that the destination question stays open: you are never choosing it at the same time as choosing hardware, and you can change your mind later without rewiring anything.

For the wider comparison of hosted and self-built approaches, the best weather station software for a personal website covers the software decision, and best weather website hosting platforms covers where a self-built site should live.

Which of the three connection routes does your station use?

Work this out first, because it determines how much effort everything downstream takes. The three routes, in ascending order of setup difficulty:

  1. Direct upload URL. The firmware has a field where you type a server address, a path and a port. You paste in a destination and you are done. No computer involved, nothing to keep running.
  2. Relay. The firmware only offers a fixed list of services with no free-text field. You run a small program (weewx, Meteobridge or CumulusMX) that reads your station and forwards the data to wherever you want.
  3. Native API. The station uploads to the manufacturer cloud as normal, and your destination reads it back out through a documented API using a key you issue. Nothing is configured on the station at all.

Here is how that maps onto the brands people actually own:

BrandFirmwareRouteWhat you do
EcowittEasyWeatherPro / WS ViewDirect URLPaste server, path and port into Customized
FroggitEasyWeatherPro / WS ViewDirect URLIdentical to Ecowitt
SainlogicEasyWeatherProDirect URLVia WS View or the station web interface
EurochronEasyWeatherProDirect URLNeeds firmware v1.5.3 or later
Ambient WeatherawnetDirect URLSame field names as Ecowitt
Davis Instrumentsn/aNative APIIssue a WeatherLink v2 API key
Bressern/aRelayweewx, Meteobridge or CumulusMX in between
Vevorn/aRelaySame limitation as Bresser
Oregon Scientific, LaCrosse, AcuRite, Hideki, PeetBros, RainWisen/aRelayAnything on the weewx hardware list

The reason one row covers five brands is that most consumer WiFi stations are not designed by the company whose name is on the box. Shenzhen Fine Offset Electronics, founded in 2008, builds the hardware and licenses it widely (Ecowitt company page, retrieved 2026-07-26). Ecowitt, Froggit, Sainlogic, Eurochron and Ambient Weather all run variants of the same EasyWeatherPro firmware and are configured through the same WS View app, which is why a single set of instructions works across all of them.

If your brand is not in the table, check the compatibility reference. The practical rule is that if weewx can read your station, the relay route is open to you regardless of age or brand.

Route 1: The Customized upload (Ecowitt, Froggit, Sainlogic, Eurochron, Ambient Weather)

The Customized upload is a field in Fine Offset firmware that accepts any server address, path and port you type into it. That one field is what stops these stations being locked to the manufacturer's own cloud, and it is why a single brand of hardware can publish to a service the manufacturer never listed.

Using it takes about five minutes. In WS View Plus (or awnet on Ambient Weather hardware), open your device, go to Weather Services, and scroll to Customized. Enable it, choose the Ecowitt protocol, and fill in the server, path and port your destination gave you.

Protocol:  Ecowitt
Server:    i.pro-weather.com
Path:      /i/<your token>
Port:      80
Interval:  60 seconds

The Customized entry is additive. Whatever you already had enabled (ecowitt.net, Weather Underground, Weathercloud) keeps working untouched, which is what makes this cheap to try: point the Customized upload at a new destination, leave everything else alone, and compare the two for a fortnight. If you prefer the old arrangement, delete the entry and you are exactly where you started.

Three firmware limits that catch people out

Ecowitt's Customized upload has quirks that are not documented on the vendor side, and every one of them presents as "the destination is broken" rather than as a configuration error. These are worth knowing before you spend an evening debugging:

  • It posts plain HTTP only. No firmware release as of 2026 sends TLS from the Customized upload. Any destination has to answer unencrypted requests on port 80 for that path, which is why services hand gateways a dedicated hostname rather than their main domain.
  • It does not follow redirects. A host that answers port 80 with a 301 or 308 to HTTPS, which is the default on most modern hosting platforms, silently loses every upload. The gateway does not retry and does not report an error.
  • Server plus path plus port cannot exceed 64 characters. Longer values are truncated or rejected outright, so a destination that issues long tokens on a long hostname will not fit.

Pro Weather handles the first two on a dedicated hostname, i.pro-weather.com. It accepts the plain-HTTP post on port 80 and forwards it over an encrypted connection from there, so the unencrypted hop only ever exists between your gateway and the edge. The short /i/ path keeps the whole string to 54 characters, inside the firmware limit.

For the screen-by-screen version, see the Ecowitt Customized upload walkthrough, or how to put an Ecowitt weather station online for the four routes specific to that brand.

Route 2: The relay (Bresser, Vevor, and anything older)

A relay is a small program that reads your station locally and re-uploads the data to a destination of your choosing. It exists to solve one problem: firmware that offers a fixed service list with no free-text address field.

Bresser consoles are the common example: the manual lists ProWeatherLive, Weather Underground, Weathercloud and AWEKAS as the available targets (Bresser 7003500 instruction manual, retrieved 2026-07-26), and there is nowhere to type your own address.

In practice it re-sends the data using the Weather Underground upload protocol, pointed at your destination instead of at Weather Underground. Three programs do this well:

  • weewx. Python, runs on a Raspberry Pi, Linux, macOS or BSD, and stores observations in a SQLite database by default. It has the broadest hardware support of any weather station software (weewx.com), which is why it is the fallback for anything unusual.
  • CumulusMX. A .NET application, native on Windows and workable on Linux or macOS through Mono. The setup wizard is the friendliest of the three, though the admin interface still shows the occasional rendering glitch off Windows.
  • Meteobridge. Commercial firmware for small routers and dedicated hardware. Costs money, needs the least babysitting.

The honest trade: you gain a full local archive as a side effect, and you take on a machine that has to stay powered and patched. That machine is now the single point of failure for your entire online presence. Our own view on that trade is in five reasons self-hosted weather software is a pain, and the money side is in the hidden costs of running a weather server. If you are picking between the two open-source options, CumulusMX vs weewx goes through it properly.

One clarification, because the naming causes real confusion: running weewx as a relay is not the same as self-hosting your website on weewx. The relay is a forwarder. You can use weewx purely as a translator between an awkward station and a hosted destination, and never touch its report generation at all.

Route 3: The native API (Davis Instruments)

Davis stations do not push to arbitrary addresses, and they do not need to. A Vantage Pro2, Vantage Vue or AirLink uploads to WeatherLink.com through a WeatherLink Live or a WeatherLink Console, and any outside service reads that data back out through the documented WeatherLink v2 API. Nothing is configured on the station itself.

The API is available to station owners and covers "weather station metadata and weather observation data for WeatherLink.com connected weather stations that you have access to" (WeatherLink v2 API documentation, retrieved 2026-07-26). Requests authenticate with an API key passed as a URL parameter plus an API secret sent in an x-api-secret header, both generated from your weatherlink.com account.

The catch is the plan tier. On the free Basic plan the API serves current conditions but not historical records; retrieving archive data, or getting a shorter archive interval, requires a WeatherLink Pro subscription (Davis Weather Stations Knowledgebase, retrieved 2026-07-26). This matters more than it sounds: a destination reading your Basic-plan account can only build history forward from the day you connect it, because the backfill is not available to fetch.

That is a good argument for connecting sooner rather than later even if you are still evaluating, since the archive starts accumulating on the destination side from day one regardless of plan.

Practical next steps for Davis owners:

Where should the data actually go?

Now the interesting half. Four categories of destination, and they answer genuinely different needs.

The manufacturer cloud

Free, reliable, and already running. ecowitt.net, WeatherLink.com and ProWeatherLive all give you live readings, charts and a shareable page with no configuration beyond registering the device. If all you want is to check your own conditions from your phone, stop here. You do not need anything else and you should not pay for anything else.

The limits are the layout and the address. The page lives on their domain, on a design you cannot change, with the branding and the feature set they chose. Free tiers also tend to cap history: this is the point where owners who assumed their data was being kept forever discover otherwise.

The public networks

Weather Underground is the largest, advertising "250,000+ Weather Stations" in its network (Weather Underground PWS overview, retrieved 2026-07-26). Contributing puts a pin on their map and improves forecasting for your area.

Be careful about treating it as a way to get your data back out programmatically, though. Weather Underground stopped offering its public weather API on 31 December 2018, several years after IBM completed its acquisition of The Weather Company's web properties in January 2016 (Wikipedia: Weather Underground, retrieved 2026-07-26). Arrangements for station owners have changed more than once since, so check the current terms before you build anything that depends on reading your own readings back.

CWOP deserves a specific mention because it is the one destination with a public-interest argument. The Citizen Weather Observer Program forwards volunteer station data to the National Weather Service, emergency managers and researchers through NOAA's MADIS system. It is free and non-commercial, it needs your latitude, longitude and site elevation, and your data appears on NOAA's site roughly two weeks after registration completes (wxqa.com and NOAA MADIS CWOP signup, retrieved 2026-07-26). If your station is well sited, this is the highest-value thing you can do with it at zero cost.

What the networks do not give you is a website. You get a station page in their house style, indexed under their domain, competing with a quarter of a million others. Weather Underground alternatives covers the field, and sharing station data with Weather Underground and CWOP is the setup guide for both.

Self-hosted

weewx and CumulusMX both generate a full website from your data, and you can theme it however you like. This is the maximum-control option and the maximum-work option. You are running the server, the software updates, the TLS certificates, the backups and the uptime. Automatic weather station data backup exists because this is the part people skip.

A hosted site on your own domain

The middle path: your domain, your branding, a permanent archive, and no server to maintain. This is what Pro Weather does, reading a Davis account through the v2 API or accepting the Customized upload directly from Fine Offset hardware. Creating a weather website with no coding covers the approach generally, and the alternatives comparison puts it next to every other option honestly.

Manufacturer cloudPublic networkSelf-hostedHosted, own domain
Your own domainNoNoYesYes
Your own layoutNoNoYesYes
Archive lengthCapped on free tiersVariesUnlimited, your diskPermanent
Server to maintainNoneNoneYesNone
CostFreeFreeHardware, power, your timeSubscription

You do not have to choose just one

This is the most useful thing to understand and the most commonly missed. Uploading is not exclusive. A single Ecowitt gateway can post to ecowitt.net, Weather Underground, Weathercloud and a Customized destination at the same time, and a Davis account can be read by several services concurrently without conflict.

So the realistic configuration for a well-run station is not one destination but three: the manufacturer cloud as a fallback you never touch, CWOP because the data is genuinely useful to someone, and a site on your own domain as the thing you actually point people at. Setting up the second and third does not put the first at risk.

What owners get wrong

Four mistakes account for most of the disappointment, and only one of them is technical.

Siting invalidates everything upstream. A station in the wrong place produces bad data, and no destination can fix that. A temperature sensor over a patio or too close to a wall will read high on sunny afternoons no matter how good your website is. Sort this out before you invest effort in publishing: the weather station siting guide covers placement, and why your station reads too high covers the specific and very common case.

Confusing an app with a website. ProWeatherLive, the WeatherLink app and the ecowitt.net dashboard are apps and dashboards. They are good at what they do. None of them produces a page you can put on a business card, hand to a local newspaper, or link from a school site. If that is what you wanted, no amount of configuring the app will get you there. The ProWeatherLive alternative is written specifically for people who hit this wall.

Assuming free history is permanent. Free tiers cap retention, and the cap is usually discovered retroactively. If your records matter to you, find out today what your current destination keeps and for how long.

Waiting for a decision before connecting anything. Archives only accumulate forward. Every month spent evaluating is a month of history that does not exist anywhere, and on a Davis Basic plan it cannot be backfilled later.

Before you commit to a destination, check these four things

If you are past the basics and choosing between services, these are the questions that separate them, and none of them is usually on the pricing page.

Does it keep your accessory sensors? Base packages handle temperature, humidity, wind, rain and pressure. The interesting sensors are the ones that get dropped: lightning strike counts, CO2, soil moisture probes, leaf wetness, and the extra indoor channels. Many destinations silently discard fields they do not recognise, and you will not notice until you go looking for the data a year later.

What resolution is stored, and for how long? "We keep your history" can mean five-minute records kept forever or hourly averages kept for a year. For anything you intend to analyse later, the resolution matters as much as the retention.

Can you get your data back out? An export or an API is the difference between a destination and a lock-in. Ask before you have three years in there.

Which protocols does it accept? A service that only speaks the Ecowitt protocol cannot serve a Davis owner, and one that only reads the WeatherLink API cannot serve a Froggit owner. If you might change hardware, protocol coverage is what stops that becoming a migration.

Getting started in three steps

Step 1: Identify your route. Open the app that configures your station. If there is a Customized or custom-server screen with a free-text address field, you are on route 1 and this is a five-minute job. If the service list is fixed, you are on route 2. If you own a Davis, you are on route 3. The supported hardware list confirms it by model.

Step 2: Register with CWOP. Do this regardless of what else you decide, because it is free, it takes fifteen minutes, and your readings become useful to the National Weather Service and to researchers. You need your coordinates and site elevation to hand.

Step 3: Pick one destination and connect it now. Not the perfect one, just one, because the archive starts the day you connect and every week of deliberation is a permanent gap. Adding a second destination later costs nothing, and removing the first costs nothing either.

If a site on your own domain is where this is going, the Ecowitt and Davis starting points are set up for exactly these two routes, and clubs and schools covers the shared-station case.

Frequently asked questions

Can any weather station be put online?

Almost any, but not quite all. If the station has a WiFi gateway with a Customized upload field, or if weewx can read it over USB, serial or radio, it can be published. The genuine exceptions are fully sealed display-only consoles with no data output of any kind, and a handful of proprietary systems with no documented interface. If you can find your model in the weewx hardware list or in our supported hardware page, you are fine.

Do I need to leave a computer running?

Only on the relay route. Fine Offset gateways and Davis WeatherLink Live units upload by themselves with no computer involved, so nothing in your house has to stay switched on beyond the gateway. Bresser, Vevor and older non-WiFi stations need a machine running weewx, Meteobridge or CumulusMX, and that machine becomes a dependency for your whole online presence.

Will adding a new destination break my existing uploads?

No. The Customized upload on Fine Offset hardware is an additional entry alongside the services you already have enabled, and the WeatherLink v2 API is read-only, so nothing you connect to a Davis account changes what the account does. In both cases you can remove the new destination and be exactly where you started.

Why does my Ecowitt gateway need a plain HTTP address when everything else uses HTTPS?

Because the firmware has never implemented TLS on the Customized upload. As of 2026 it posts unencrypted on port 80 and it does not follow redirects, so a destination that upgrades port 80 to HTTPS loses every upload without reporting an error. Services that accept gateway uploads therefore publish a dedicated plain-HTTP hostname and encrypt from their edge onwards. It is a firmware limitation, not a security decision by the destination.

Is CWOP worth the effort if I already upload to Weather Underground?

Yes, and they serve different purposes. Weather Underground is a commercial network with a consumer-facing map. CWOP feeds NOAA's MADIS system, which puts your observations in front of National Weather Service forecasters, emergency managers and researchers. Registration is free and the two uploads coexist. The main requirement is that your station is reasonably sited, since the data is genuinely used.

How much history will I lose by switching destinations?

None from the station's point of view, because the station has no long-term memory to lose. The risk is at your old destination: whatever it holds usually stays there. Export before you leave if an export exists. Note that a new destination reading a Davis Basic account cannot backfill your archive because the API does not serve historical data on that tier, so history there begins on connection day.

What is the difference between hosting a weather website and just embedding my data somewhere?

Embedding puts a live widget on a page you already have, which is the right answer if you run a business or club site and want current conditions on it. Hosting means the weather data is the site, with its own domain, archive, records and forecast pages. Embedding live weather data on a website or blog covers the widget route.

The short version

Establish your connection route before you shop for a destination, because the route is fixed by hardware you already own and the destination is not. Fine Offset stations paste in a URL, Bresser and older stations need a relay, and Davis stations are read through the WeatherLink v2 API.

Then connect something today rather than the perfect thing next month. Archives only build forward, free tiers cap retention more often than owners realise, and a Davis Basic plan cannot backfill what you did not capture. Registering with CWOP costs nothing and makes your readings useful beyond your own household, which is a reasonable thing to do on day one regardless of where the rest of your data ends up.

Continue reading

By brand:

Setup walkthroughs:

Choosing an approach:

Getting the data right first: