Help & FAQ

Two things: a personal weather station (or vendor cloud credentials for one), and a small backend server you host, either a ~$2/month Fly.io machine or any always-on computer with Docker. Since app 1.9 the phone can create that server for you in about ten minutes, so most people never open a terminal. The setup guide covers all three ways to do it, and the setup planner tells you what your particular hardware needs.

Yes, on both the iPhone (app 1.9 and later) and the Mac. Guided Setup deploys the backend to Fly.io for you: sign up at fly.io, create an org token in their dashboard, paste it into the app, and it creates the server, its storage volume, and its secrets, waits until it reports healthy, and connects itself. Then it walks you through adding your first weather source.

Signing up at Fly.io is free but does require a payment card, and one small server costs about $2 a month. The token you paste is used on that device only and is not stored in the app; setup does save a deploy credential on the new server so one-tap updates work later, and you can revoke either one from the Fly.io dashboard at any time. Full walkthrough in the setup guide.

Local Docker installs are still script-only by nature, since there is nothing for the app to deploy to.

A one-line code starting with ZW1. that packs your backend's URL and access token together. In the app (iPhone or Mac), open Settings → Quick setup and paste it — one paste instead of two fields. The script also prints a separate read-only share code that is safe to send to family. Local Docker installs configure with the URL and token directly; both are in the install summary the script writes.

No. The apps talk only to the backend you deploy; there's no account with us, no analytics, no telemetry. If you enable background push, the notification's title and body (never readings, location, or your backend address) pass through Zasder's App-Attest-gated relay so alerts arrive while the app is closed. Never enable push and the relay is never contacted. Details in the privacy policy.

Yes — that's the normal shape. The owner's devices use the full-access token; everyone else gets a read-only share link (see Sharing). One server, one $2 bill, the whole household.

They can, but since 1.7 they don't have to. Settings → Data & Integrations → Device tokens (on the Mac, the Data tab) mints a token per device — one for the 915 MHz board, one for the poller, one for your custom script. Revoking a token cuts off only that device; the original shared token keeps working alongside, so nothing breaks when you start. Boards running 1.7 firmware even upgrade themselves: on their next post the backend hands them a personal token, and the row's "last used" stamp then tells you at a glance which token belongs to which device.

Yes. Your backend is a read-only MCP server, which is the protocol both assistants use for custom connectors. In the assistant, add a custom connector with your server's address followed by /mcp. It registers itself and asks to sign in; the sign-in page tells you to approve it in the app. Open Settings → Sharing & Public Page → Connected apps, approve the pending app, or mint a connect code there and type it on the sign-in page. The assistant can then read your stations, history, records, insights, reports and storms, and nothing else.

It uses your own Claude or ChatGPT subscription; the server never stores a provider key. Every connected app is listed with a remove button that cuts it off at once. If you never want the endpoint, set MCP_ENABLED=0 on the server and it disappears, along with the sign-in pages.

On the sign-in page, never in the assistant's own settings. Add your server as a remote or URL type connector, the address ending in /mcp, and leave any command, token or header fields empty. The assistant then opens a sign-in page in your browser. If the app is not approved yet, that page asks for the connect code from Settings → Sharing & Public Page → Connected apps. Type it there and the app is approved.

The command type of server (a "command to launch") is for programs that run on your own computer, which this is not. A code works once and expires after ten minutes, so mint a fresh one if the first attempt went astray. The proof it worked is a row under Connected apps that says Approved with a login count and a last-read time.

As a beta. Guided Setup has a smaller Sign in with Fly button under the token field. It opens Fly's own login in your browser and hands the app a short-lived credential, which it uses to build the server and then discards. It is marked use at your own risk because it relies on the same handshake Fly's command-line tool uses, which Fly has not published as a public interface. Pasting a token remains the main path.

If your backend address ends in fly.dev, it is a small machine at Fly.io, and that is where your data lives. The Mac app is not the server. When it forwards a WeatherLink Live or acts as a relay, it is the messenger that reads the station on your network and sends the readings up. The rest of the Mac app is the same app as the iPhone one, pointed at the same server.

So the Fly items in the release notes, Sign in with Fly and the server recommendations card, need nothing from you. Sign in with Fly is for creating a brand-new server, and the recommendations card only appears when your machine could use more memory or disk. Docker installs at home are the other shape, and the setup summary tells you which one you have.

Two different things can go wrong, and they look different. A connection error means the app could not reach the server at all. A station that goes quiet while the rest of the app works means the server is fine and the station or its bridge stopped sending. For the first, open your server address with /status on the end in a browser; it is an open page that shows the version and uptime. If it loads, check the address and token in Settings. If it does not, the server is restarting or down.

A backend update restarts the server for about a minute, and a guest server is updated by whoever runs it. Nothing is lost during a short outage. Stations keep counting rain in their own hardware, the dashboard keeps showing the last readings with their time, and readings resume on their own.

The iPhone, Mac and Watch apps are free, with no subscription. What you pay for is your own server, about $2 a month for a small Fly.io machine, or nothing if it runs on a computer you already keep on. The tip jar in Settings is optional and only says thank you; it unlocks a supporter badge and nothing else.

There is no hosted option yet. Everyone runs their own server, which is also why nothing about your weather passes through Zasder. A managed option is on the roadmap.

Settings → Units & Appearance. Temperature, wind, pressure and rain each have their own unit, so a metric temperature with inches of rain is fine. The server stores everything in one set of units and converts for display, so switching never changes your history.

Everything on the server: the readings, and also the settings stored on the server, the integration credentials it holds, sharing links, and connected-app sessions. Deployment secrets such as the API token and the Fly.io credential live outside the database and are not touched. The app says exactly this before you confirm, and it tells you when the server could not count what it currently holds rather than calling it empty.

The server checks the uploaded file against the full schema before anything moves, closes the database for the few seconds of the swap, keeps the previous database as a safety copy, and puts it back automatically if the restored one cannot start. Afterwards it picks up the restored settings on its own, so cloud pollers and reports come back without a restart. Restore lives under Settings → Server & Backups on the iPhone, and in Guided Setup as Restore from a backup on a fresh install.

On the Mac, Settings → Server can also back the database up to a folder you pick on a schedule, with rotation. That backup needs the Mac app to be running at the scheduled time.

The test button proves the notification channel, not the alert pipeline — it posts directly on your device. When tests work but alerts don't, check in Settings → Alerts & Notifications (on the Mac, the Alerts tab):

• Is the rule enabled, and has its condition actually crossed? (Rules fire on the crossing, not continuously.)
• What is your email scope? With "device offline only", threshold and storm emails are deliberately withheld — push still delivers them. Set scope to all events if you want them by email too.
• Since 1.7 the Alerts tab lists recent deliveries, so you can see whether an alert fired at all (and was swiped away) or never fired. Rules there are editable in place too.

Usually the opposite. If your email scope is "device offline only" and your station has simply stayed online, silence is the system working. Check the dashboard: if readings are fresh, there was nothing to send.

A reading hovering right at your threshold — wind gusting across a 30 mph rule, say — crosses it over and over, and each crossing used to be a fresh alert. Since 1.7 a rule re-arms only after its condition has stayed clear for a full 15 minutes, so a flapping value produces one alert per real episode instead of one per gust. If you still see true duplicates on 1.7+, that's a bug we want to hear about.

The rain-start Live Activity, new in 1.7. When the forecast sees rain about to begin at your station, your backend starts a Live Activity on your iPhone: a countdown to the predicted onset in the Dynamic Island and on the Lock Screen, with the expected two-hour total. At onset it switches to "rain any moment now", and it clears itself — your station's storm summary later confirms what actually fell.

It needs iOS 17.2 or later and background push enabled, and the phone must register for it once: open the app once after updating to 1.7 (or after re-enabling push). No readings are involved — the start push carries only the onset time and forecast total, through the same relay as other push alerts.

Any mailbox provider's SMTP submission service works. The setting that bites: use port 465 with SSL (or 587 with STARTTLS — the app's SSL toggle pairs the port correctly for you). Implicit SSL on port 587 fails with a TLS version error. If mail sends but bounces at Gmail, the fix is usually your domain's SPF/DKIM records, not the app.

That's macOS policy: once a Mac app is installed, macOS stops mirroring that app's iPhone notifications. The Mac app therefore raises its own — since 1.5 for device-offline, and since 1.6 for all four alert kinds. Enable them in the Mac app's Settings and in System Settings → Notifications.

One notification after rain ends — total, duration, peak rate, wind — instead of a stream of pings during it. The quiet period defaults to 30 minutes (configurable 5 min–6 h). Under a device-offline email scope it arrives by push only. Since 1.7 storm summaries have their own settings screen under Settings → Alerts & Notifications, and delivered summaries land in the Alerts tab's recent list.

If you set quiet hours, pushes below the urgent tier hold their tongue at night — they still land in the Alerts tab's recent list, and minor ones ride the morning digest. Urgent alerts (lightning nearby, pipe-freeze cold, NWS warnings, and any rule you mark urgent) always break through. Email is unaffected; an inbox is inherently quiet.

Yes. Not reporting means the server saw no readings from that station for longer than its offline threshold, fifteen minutes by default and adjustable per station under Settings → Alerts & Notifications. Reporting again closes it. The usual causes are a server restart during an update (about a minute), the station's hub or bridge losing power or Wi-Fi, a home network blip, or a vendor cloud that repeats the same reading for minutes at a time. Since 2.1 the server re-posts an unchanged cloud reading every two minutes, so a Govee no longer trips a five-minute threshold. If a source is slow by nature, raise its threshold rather than living with the pair.

Yes. Settings → Alerts & Notifications → Email has a scope pull-down: all alerts, or device offline only. With the second, only a station going quiet or coming back sends mail; everything else still arrives as a push and lands in the Alerts tab. That is the setting most people want, since an inbox is for the things you would otherwise miss.

Expected, once. The first boot after a backend update looks for a day that has no report stamp and sends that day's report right away, at whatever hour the restart happened. From the next morning it is back on schedule. The stamp is what prevents a repeat.

Since 1.8, yes — three watchdogs run server-side: low battery flags on any sensor the station reports, a sensor gone quiet (the station keeps posting but a field that used to carry readings has been empty for hours), and flatlines (humidity pegged at exactly 100%, or a full day without a single wind gust — calm nights happen, a windless day usually means seized cups). Each fires once, and you get a recovery notice when it clears.

Yes. Every Ecowitt gateway and console, GW1000 through GW3000 and the HP2551-class displays, has a Customized upload setting. Point it at your own server and readings arrive directly, no vendor cloud and nothing extra to buy. Set the protocol to Ecowitt, the server to your backend's address, the path to /ingest/ecowitt?token=YOUR_INGEST_TOKEN, and the port to 8080.

The honest catch: Ecowitt gateways cannot do TLS. That means this works directly against a backend running on your own network, but a Fly.io backend answers on HTTPS only, so you need a small forwarder on an always-on LAN machine in between. Full instructions, including the forwarder recipe, are on the Ecowitt page. Needs backend 1.9.0 or later.

Yes, and you should. A small bridge extension forwards every WeeWX archive record to your backend, so your station shows up in the app with charts, records and alerts while WeeWX carries on doing everything it does today. Because WeeWX speaks to more than seventy station families, this is often the answer for hardware that has no direct path here.

Two things to expect: the data is as fresh as your archive interval, typically five minutes rather than seconds, and the backend address must be https:// unless it is on your own network. Needs backend 1.9.0 or later.

The tipping bucket. On a station with both sensors, say a WS90's haptic rain plus a WH40 tipping gauge, the tipping gauge wins wherever both report, and the haptic reading only fills in fields the gauge doesn't provide. Haptic sensors feel drops as vibrations, so a bumped mast, a bird landing, or a gate slamming the fence can register as rain that never fell. This isn't configurable, and it's deliberate: phantom rain corrupts a rain record permanently.

Almost always a wrong station ID. It's the number in your station's URL at tempestwx.com — not the device serial number. Fix the ID in Settings → Data & Integrations and the Tempest appears as its own station within a minute of polling. Since 1.7 the keys are checked live when you save, so a wrong ID fails at save time instead of silently.

The Tempest's rain sensor is haptic — it feels drops as vibrations. A hard knock on the pole (a bird landing, a gate slamming the fence it's mounted on) can register as phantom rain. A rigid, isolated mount is the cure.

Check it against the official reports first. After a big storm the National Weather Service publishes a Public Information Statement listing rain totals by town from CoCoRaHS observers and spotters, and your county's list is the fairest benchmark you can get. A tipping-bucket station that lands inside the spread of nearby reports is doing its job.

Two things make a backyard gauge disagree. A funnel gauge that is not a proper 4-inch gauge can read high or low in a downpour, and it only tells you what fell since it was last emptied. And a haptic sensor such as the Tempest's feels drops as vibrations, so it undercounts heavy rain; on a day when it lost power with its hub, it simply missed the hours it was off.

Your daily total survives an outage on your side. The rain counter lives in the station itself, so when the bridge (a Mac app, a relay board, a poller) is offline the counter keeps counting, and the total is right once readings resume. The minutes in between show up as a flat stretch, or as coarser data if you filled the gap with a Weather Underground import.

"—" means no reading, and that's deliberate: a station without a solar sensor doesn't have zero sunlight, it has no data. Sources that post partial packets (some radio relays send temperature and wind in separate transmissions) merge into a complete view within a cycle or two.

Settings → Stations. On the iPhone, press and hold a row and drag it; there is no Edit button on purpose, because edit mode greys out every link on the page. On the Mac, each row has up and down buttons. The top station is the primary one: the main station on the public page, the default for widgets and complications, and the station each sharing network sends unless you pick another. Air monitors such as a Govee or an AirGradient are never primary, wherever you put them.

Two senders posted under different station IDs — commonly a script relay and an app integration running side by side. Give both the same station ID (Settings lets you edit it) and they merge; the backend keeps history under the ID you keep.

Yes, through Govee's cloud. Settings → Data & Integrations → Integrations takes your Govee API key and the monitor's device ID. Govee's app shows a short form of the ID; the server accepts that and resolves it to the full one. The monitor appears as an air monitor beside your weather stations, and since 2.1 it sits wherever you place it in the station order rather than always at the bottom.

Govee's cloud repeats the same reading for minutes at a time. The server re-posts an unchanged reading every two minutes so the monitor never looks silent against a five-minute offline threshold.

Open-Meteo by default, which needs no key and gives seven days. If you have a Weather Underground API key, Settings offers The Weather Company's forecast instead, which is today plus five days, so six rows, not a bug. The rain-start countdown and its Live Activity always use Open-Meteo's 15-minute model whichever source you pick; the setting governs only the daily forecast.

Yes — Settings → Data & Integrations → Import History pulls your WU station's archive into your own database (users have imported a decade, hundreds of thousands of rows). WU's API has a daily quota; the importer stops cleanly at the limit and resumes where it left off the next day.

That's an anemometer dropout marker (0xFF), not a measurement — some sources emit it and historical imports can carry it in as fact. Backend 1.5.1+ rejects implausible readings at ingest and includes a maintenance cleanup that repairs history already affected. If a bogus record persists, update your backend and re-run the records view.

Update your backend — 1.6 computes records from daily rollups ("instant records") instead of scanning millions of rows, which took a million-row database from nearly two minutes to instant.

Yes. Open History, choose Explore, and tap any day's card. That day's 24-hour charts open, with the day's rain, high and low, bounded by its own midnights. The chip used to be called History; it is Explore now.

Partly, today. A past day's page has share buttons at the bottom, and they make chart cards: the chart you are looking at, the last storm, and the comparison across stations. The storm card is the one that carries totals, rain, peak rate and duration, so if the day was the last storm, that is the card to post. The tiles at the top of the day do not have a card of their own yet; a day card, and a daily version of the NOAA-style report, are on the list.

The comparison chart under the day is a rate chart in inches per hour, not a running total, so it will not match the tiles by eye.

History → Reports lists every morning report and storm summary the server has kept, newest first, plus the NOAA-style monthly and yearly climate reports you run per station. Tap a notification and it opens the report it is about. Older reports load with a Load older reports row at the bottom. How many the server keeps is under Settings → Server & Backups, for reports and for the storm ledger separately.

If the station also uploads to Weather Underground, yes. Settings → Data & Integrations → Import History pulls whatever your WU station has for the missing days, and the importer skips rows you already have, so running it after an outage only fills the hole. Imported rows are five minutes apart rather than seconds, so charts look smoother across that stretch. Rain totals are right either way, because the counter lives in the station. A vendor cloud such as WeatherLink is not an import path; Weather Underground is.

It is printed only when it matters. The morning report shows the feels-like high when it ran at least 3°F above the actual high, so a dry 100° day says nothing and a humid one shows the number people actually felt. Silence there means the two were close.

A LilyGO or SDR receiver posts one rain number: the sensor's total since it was powered. Until 2.1 the app showed that as this year's rain. Now the year bucket is that counter measured against January 1, or against the first reading on file for a station younger than that, and the raw counter is kept beside it as totalrainin for anyone reading the API. A replaced or reset gauge restarts the totals instead of pinning them at zero.

Widgets refresh on iOS's schedule (roughly every 15+ minutes, budgeted by the system), and each face shows its data age. Opening the app always shows live data. If a widget seems stuck for hours, tap through to the app once — that resets the timeline.

Yes — long-press the widget → Edit Widget to pick the station and the readings, including the Lock Screen circle. The 2x2 face shows six configurable readings, plus (since 1.7) a 24-hour temperature sparkline.

Before 1.6 there was no native Mac widget — macOS mirrored the iPhone's widget, and mirrored widgets can only hand off to the phone. 1.6 ships real Mac desktop widgets: add them from the Mac widget gallery (they're listed under the Mac app).

A full watch app with your live tiles plus complications, including a combined wind + gust ring (sustained wind fills the ring, the current gust rides it as a tick). Complications refresh on watchOS's budget, so treat them as a glance and the app as the live view.

Settings → Sharing & Public Page (on the Mac, the Sharing tab) creates a read-only link — under the hood, a share token minted on your server. Recipients tap the link and their app connects with view-only access; they can't change anything, and you can revoke each share individually without touching the others. Requires app 1.6+ on the receiving end; on 1.7, guest installs trim Settings down — the iPhone hides the owner-only sections entirely, and the Mac shows them with a note explaining they're owner-managed.

Yes. Turn on the read-only public dashboard and your backend's front page shows live conditions, charts, and records to anyone with the URL — no tokens exposed. Backend 1.6.1+ also serves /embed, just the dashboard sized for an iframe:

<iframe src="https://your-app.fly.dev/embed" width="100%" height="1300" style="border:0"></iframe>

1.6.2+ accepts ?theme=light|dark|auto so the embed matches your site. Live example — the developer's station in Chandler, AZ.

The first request after a server restart builds the page from scratch, which takes about fifteen seconds; every request after that is served at once and refreshed in the background, so a page that was slow once is not slow twice. The embed posts its height to the parent page, so a few lines of script can size the frame to fit; otherwise give it a fixed height of about 1300 pixels. On WordPress with Divi, put the snippet in a Code module; Divi rewrites URLs placed in ordinary fields and breaks the follow buttons.

Your primary station by default. The backend's PUBLIC_DASHBOARD_MACS setting (or the owner API on 1.6.2+) selects all stations or a specific list.

Windy replaced its station upload API in January 2026 and the old one refuses keys made since, which is the error people see. The new one wants the station's own ID and station password, both shown on the station's page under My Stations at stations.windy.com. Keys from api.windy.com, the point forecast and map products, are a different thing and are refused. Since 2.1 the Windy page asks for the ID and password, and a refused report shows Windy's own reason next to it.

Each network page has a Send every picker and a Station picker. The intervals go down to each network's own limit: one minute for PWSWeather, five for Windy and CWOP, ten for WeatherCloud's free plan, and up to an hour. The station defaults to the top of your list and can be changed per network. A station that stops reporting is never replaced by another one under its network ID; the row says why nothing was sent. Save and verify sends one report on the spot and shows what the network answered.

On purpose. The full setup, with the station ID shared with history import and the upload key, lives under Settings → Data & Integrations → Forward to Weather Underground. The networks list under Sharing shows a Weather Underground row beside the other four so you can see that it is on and when the last upload was accepted, and the row opens the same page. Weather Underground receives every reading your station posts, one a minute at most.

Your own server is the default site. When someone shares their server with you, they send a site link; opening it on a phone that already has a server adds that server as a site under Settings, Server & Sites, without touching your own. When you have more than one site, a switcher appears under the Dashboard header. Tap a site and the whole app looks at it until you quit; the next launch opens your own server again. Push, widgets and the Watch always stay on your own server.

Since 2.2. In the Shortcuts app, Zasder Weather offers Get Current Conditions, which returns the temperature, feels like, humidity, wind and gust, rain today and rate, pressure, UV, CO2 and PM2.5 as values a Shortcut can compare, in your units, and Open a Chart, which opens the app on a station's chart. After opening the app once on 2.2, Siri answers "current conditions in Zasder Weather" or "what is the temperature in Zasder Weather". Both talk to your own server, never a shared site.

A forecast delivered at the time you choose, under Alerts, Quiet hours. Before noon it describes today; from noon on, tomorrow. It comes from Open-Meteo, or from The Weather Company through your Weather Underground key if you pick that, and it says so when it had to fall back. It arrives as a push and an email and is kept in Reports. It needs the 2.2 server.

A note before sunset with tonight's moon and a verdict for the telescope: good, fair or poor, scored from tonight's cloud forecast, your station's humidity, dew point and wind, and how much of the moon is up and lit. Every reason that cost points is named. Turn it on under Alerts, Quiet hours, and choose Only on good nights if you want to hear only about the clear ones. It needs the 2.2 server.

Since 2.2 the app says which side failed. No internet connection means this device is offline and your server may be fine; the last readings stay on screen. Your connection is having trouble means the device has a network but nothing on the internet answers, usually a captive portal or a dropped link. Your server isn't reachable means the internet answers but your box, its tunnel or its host does not. Server address not found, Your server returned an error and Your server refused the token each say what they mean. The Dashboard, the header and Settings, Stations all show the same verdict.

Since 2.2 a station fed by a cloud service (AirGradient, Tempest, Ecowitt cloud, Govee, WeatherLink, Ambient Weather) shows one orange line while its poller is failing, in the server's words: the vendor's service is not answering, your saved credentials were rejected, the vendor is rate limiting you, or the server failed to store the readings. Nothing shows while the poller is healthy or for stations on your own network. After an hour of failures the server also sends one alert naming the vendor and the reason, and one notice when it recovers.