Zasder Zasder

Zasder Weather / Connect an Ecowitt gateway

Connect an Ecowitt gateway

Every Ecowitt gateway and console can post its readings straight to a server you own. No vendor cloud in the middle, and when the server is on your own network there is no extra hardware and nothing to install. You change five settings on the gateway and your weather starts arriving. Needs a Zasder Weather server on version 1.9.0 or later.

Which gateways this works with

Ecowitt gateways and consoles have a built in feature called Customized upload. It was designed so you could send your weather to your own software, and that is exactly what we use.

It works on the whole family: the GW1000, GW1100, GW1200, GW2000 and GW3000 gateways, and the HP2551 class display consoles. If your device offers a Customized option in its settings, it will work here.

Your sensors keep working exactly as they do today. This adds a second destination for the same readings, so you can keep using the Ecowitt app alongside if you want to.

Readings arrive with their units intact. A metric console is fine, the server converts the metric fields as they come in. Per sensor battery flags come along too, and feed the station health watchdogs in the app.

Read this first: no HTTPS on the gateway

This is the one thing that decides how the rest of your setup looks, so it comes before the steps rather than after them.

Ecowitt gateways speak plain HTTP only. Their firmware cannot do TLS. That is a limit of the hardware, not something a setting can turn on. It has two consequences worth being blunt about.

If you have no always-on machine at home and your server is on Fly.io, this path is not for you. The good news is that the same sensors are usually reachable another way: a LilyGO radio board hears Fine Offset and Ecowitt sensors off the air directly, and the setup planner will tell you which board yours needs.

What you need in front of you

Consider minting a separate ingest token just for this gateway in the app, under Settings, Data. Then if you ever want to cut the gateway off, you revoke one token and everything else keeps sending.

The settings to change

In WSView Plus, select your gateway, open its settings, and find Customized. Turn it on, then fill in these fields.

FieldWhat to put in it
Protocol Type Ecowitt. Not Wunderground. The two send different data in a different shape, and only Ecowitt is understood here.
Server IP / Hostname Your server's address on its own, for example 192.168.1.40. No http://, no port, no trailing slash.
Path The line below, with your own token in place of the placeholder.
Port 8080 for a Docker server at home, which is the default it ships with. If you are using a forwarder, use the forwarder's port instead.
Upload Interval 16 seconds, or anything higher. Sixteen seconds matches how often most Ecowitt sensor arrays actually transmit.

The path is one line. Copy it whole, then replace YOUR_INGEST_TOKEN with your own token:

/ingest/ecowitt?token=YOUR_INGEST_TOKEN

Save. The gateway starts posting on its next interval.

That path contains a credential. The token has to ride in the address because Ecowitt firmware cannot send the HTTP header a token would normally travel in. So treat the whole path like a password: do not paste it into a forum post or a screenshot. If you think it has leaked, revoke it in the app, issue a new one, and update the gateway.

It also means the hop from your gateway to your server is unencrypted. On your own home network that is a reasonable trade. On a network you do not control, it is not.

Check it worked

Open the Zasder Weather app. Within a minute or two the gateway shows up as a new station with live tiles. If you already have the same sensors arriving another way, give the new station a name that tells them apart.

Nothing after five minutes? Two quick checks before you start changing settings:

Cloud server? Add a small forwarder

Only needed if your Zasder Weather server is on Fly.io, or anywhere else that answers on HTTPS only.

A forwarder is a tiny program on your home network that accepts the gateway's plain HTTP upload and passes it on to your server over HTTPS. It has to run on a machine that is always on, on the same network as the gateway: a Raspberry Pi, a NAS, a Mac that never sleeps.

Caddy does it in four lines. Save this as a file named Caddyfile, with your own server address in both places:

:8081
reverse_proxy https://your-app.fly.dev {
    header_up Host your-app.fly.dev
}

Then start it from the folder holding that file:

caddy run

Now go back to the gateway settings and use the forwarder instead of the server:

Set Caddy to start on boot so a power cut does not quietly end your weather history. On a Raspberry Pi or Linux box that is what Caddy's own service install does for you.

Any TLS-terminating proxy works, not just Caddy. If you already run nginx, Traefik or Home Assistant's proxy add-on, point the gateway at that instead. The only requirement is that it forwards the path unchanged and sets the Host header to your server's hostname.

Two rain sensors on one station

Some Ecowitt setups report rain twice. A WS90 measures rain haptically, by feeling drops hit the sensor, and many owners run a WH40 tipping bucket alongside it.

When both report, the tipping bucket wins. That is deliberate and it is not configurable. Haptic sensors register phantom rain when the mast gets bumped, by wind, a bird landing, a gate slamming against the fence they are mounted on, and phantom rain corrupts a rain record permanently. The tipping gauge counts actual water.

If a field is missing from the tipping gauge, the haptic reading fills in for that field only. You do not lose data by having both, you just get the more trustworthy of the two.

When it does not work

In order of how often each one is the answer.

Still nothing? The Help and FAQ page covers the broader questions, and the backend is open source, so issues and questions are welcome on GitHub. There is also a support page.