Help & FAQ

Two things: a personal weather station (or vendor cloud credentials for one), and a small backend server you host — a ~$2/month Fly.io machine or any always-on computer with Docker. The setup planner asks what hardware you have and generates the exact steps. Then install the app and connect it to your backend.

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.

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:

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

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.

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.

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 → Integrations and the Tempest appears as its own station within a minute of polling.

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 — Data → 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; 1.7 adds a 24-hour temperature sparkline to it.

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

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.