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.

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.

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.

"—" 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.

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 — 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.

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.

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.