What's New in Pro Weather: Closing the Self-Hosted Feature Gap
By Lennart · Hands-on guides from the people building the platform
Pro Weather has just shipped fourteen features in one go, and every one of them came from the same exercise: working out what a station owner still gives up by choosing a hosted site over running weewx or CumulusMX themselves. Sensor calibration, an editor for readings already in your history, NOAA-style climate reports, all-time records four deep going to twenty-eight, alarms going from nine conditions to forty-two, and a public API. Everything below is live on every site right now, with nothing to install and nothing to migrate.
Where the list came from
The honest version: we worked through the documented feature set of the two programs serious station owners actually run, CumulusMX and weewx, and compared them against Pro Weather capability by capability. Some of it we were already ahead on: severe-weather warnings, a real forecast, eleven languages, multi-tenant hosting. The rest was a list of things a self-hoster gets and a Pro Weather owner did not, and that list became this release.
A few items on that list we deliberately left off. That section is at the bottom, because a changelog that only lists wins is not much use to anyone deciding between two tools.
Getting your numbers right
Two different problems, two different fixes, and confusing them is how people end up with a wrong archive.
Sensor calibration
Every station drifts. A barometer sits 2 hPa low, a thermometer catches an hour of afternoon sun, a tipping bucket under-catches in heavy rain. Quality control was already discarding impossible readings, but a reading that is merely wrong looks perfectly plausible and gets stored like any other.
Calibration is the fix. Ten sensor families take a correction, and which knob they take is the whole distinction:
| Knob | Sensors | Use it when |
|---|---|---|
| Offset | Temperature, humidity, sea-level and station pressure, the indoor pair, wind direction (in degrees) | The sensor mis-reads by a fixed amount |
| Multiplier | Wind speed and gust, rainfall, solar radiation, UV index | The sensor mis-scales |
A rain gauge catching 4% too little needs a multiplier of 1.04, not a fixed amount added on. A vane mounted a few degrees off north needs the offset.
Derived values are recalculated from the corrected inputs rather than left behind, so your dew point, heat index, wind chill, humidex, apparent temperature and cloud base all follow the temperature you fixed. Nothing on your site ends up disagreeing with itself.
Alongside that sit spike limits: the largest change you accept between two consecutive readings. Radio interference, a dying battery or a loose connector produce single readings that jump further than the weather can. A reading that fails its limit is dropped rather than clamped, and two readings more than an hour apart are never compared, so a gateway coming back online after a quiet night is not mistaken for a spike.
One deliberate limit, stated plainly in the docs: a correction applies to new readings, not to months of stored history. Silently rewriting an archive behind your back is not something we will do, so your chart shows a small step at the moment you saved the correction.
Editing stored history
Calibration cannot reach backwards, and sometimes a single wrong number is already in there. The data editor is a Data tab in your dashboard: pick a station and a day, narrow to an hour if the day is busy, and correct any of nine fields in your own units. Clear a single field to drop just that value when one sensor misbehaved and the rest of the row is fine. Or remove the reading entirely, or a whole range of them if an import brought in garbage.
The interesting part is what makes it stick. Pro Weather re-reads the last hour of your station's archive on every refresh, and separately re-checks the last year for days that look short of readings. A row that was simply deleted would be re-imported within the hour, bad value and all. So a removal leaves the timestamp behind as an empty slot, which is what marks the reading as meant to be gone.
An edit takes the rest of the row with it too: the interval's stored high and low are cleared, because those describe the reading you just replaced and your records read them first. Every single-row change is snapshotted before it is overwritten, so it doubles as a change log and can be undone.
If you spotted a spike on a chart but do not know which day it was on, the editor has jump links straight to the days holding your highest and lowest temperature, strongest gust and wettest day. That is where a bad reading almost always turns out to be.
A deeper archive
Records went from 4 to 28
Four all-time records is a novelty. Twenty-eight is a station history. Here is the full set the almanac now keeps:
| Group | Records kept |
|---|---|
| Temperature (12) | Hottest day, coldest night, warmest night, coldest day, warmest and coldest daily mean, largest and smallest daily range, highest heat index, lowest wind chill, highest and lowest dew point |
| Rain (7) | Wettest day, wettest hour, heaviest rain rate, wettest month, wettest year, longest dry spell, longest wet spell |
| Wind (3) | Strongest gust, strongest sustained wind, longest wind run |
| Humidity (2) | Highest and lowest humidity |
| Pressure (2) | Highest and lowest pressure |
| Sun (2) | Highest solar radiation, highest UV index |
Nothing new is captured at your station to make this work: every one of these comes out of columns the archive already had. The same set is computed for the running calendar year and month, and per calendar month once you have two years of data, which is what makes "warmest June ever" a question your own site can answer.
NOAA-style climate reports
The Reports tab prints the climatological summary that every serious install produces, in the layout weewx and CumulusMX have generated for decades. A month is one row per day: mean temperature, high and low each with the time it happened, heating and cooling degree days, rain, average wind, peak gust with its time, and the speed-weighted dominant wind direction. A year is one row per month across three tables, closing with a year row that is by construction the sum of the months above it.
Every report also downloads as the classic fixed-width NOAA-YYYY-MM.txt, deliberately untranslated, because in that format the column positions are the format. The on-screen tables are the localized surface.
Soil, leaf, lightning and leak sensors are archived
Accessory channels used to be live gauges: you could see soil moisture right now and nothing else. They are stored now, which means seven-day trends under every probe, CSV export, and alarms. Water-leak detectors came along in the same pass, and they behave unlike everything else on the list: a leak sensor reports a state, not a measurement, so there is nothing to average. The archive answers exactly one question about it, which is when the channel last went wet.
Knowing sooner
Alarms went from 9 conditions to 42, in three kinds:
| Kind | How many | What you can alert on |
|---|---|---|
| Threshold | 33 | Temperature (7), accessory sensors (9), humidity (3), air quality (3), station health (3), pressure, wind, rain and sun (2 each) |
| Rate of change | 4 | Pressure falling or rising over 3 hours, temperature falling or rising over 1 hour |
| Event | 5 | It started raining, an all-time record was broken, a reading was rejected as a spike, an upload is failing, a leak detector went wet |
The thresholds are where most of the growth is, and the accessory group is the biggest single block: soil moisture and soil tension as separate alarms, soil temperature, leaf wetness, extra room temperature and humidity, lightning distance and strikes today. Each multi-channel alarm watches all of its channels and names the worst one, so eight soil probes are one rule rather than eight.
Rate-of-change alarms are the ones a threshold genuinely cannot express, and they are the actual storm signals. A 3 hPa fall in 3 hours is the classic gale signal at sea, and no fixed pressure number will ever tell you that.
Delivery is email, a signed HTTPS webhook, or both, per rule. The webhook posts JSON with an HMAC-SHA256 signature so your receiver can prove the request came from us, and the docs carry a verification snippet. There is also a latch setting that will look familiar if you are arriving from CumulusMX: re-notify every 1, 3, 6, 12 or 24 hours while a condition persists, instead of once per episode.
New numbers on your site
Eight air-quality standards instead of two. With an AirLink or a WH45/WH46 module you can now show the European EAQI, the US EPA index, the UK DAQI, the EU CAQI, Canada's AQHI, Australia's NEPM scale, the Dutch LKI or the Belgian BelAQI. They agree on almost nothing, which is the whole reason this took work. The European index runs six bands from Good to Extremely poor; the UK's DAQI is "numbered 1-10 and divided into four bands"; the US EPA index runs 0-500. Canada's AQHI is the awkward one, because its published formula has no PM10 term at all, so a PM10-only sensor now shows no index under that standard rather than an invented one.
Grower numbers you configure. Growing degree days, chill hours, vapour pressure deficit and heat stress (WBGT) are on the site, and the settings behind them are yours: GDD base and optional cap, chill band, chill season start month. These apply when the page is read, not when a reading arrives, so moving your GDD base from 10 °C to 8 °C re-scores your entire archive instead of only what arrives next.
Sunshine hours with no sunshine sensor. Every archived solar reading is compared against the clear-sky maximum for that exact instant, computed from your coordinates, altitude and the sun's position. Beat 75% of it and that reading counts as sunshine. Because it is derived from the archive rather than counted minute by minute, imported weewx and CumulusMX history counts toward it too.
A snow diary. No consumer station measures lying snow: a rain gauge reports a trickle when it eventually melts and nothing at all while it sits there. The diary is where you write down snow depth, 24-hour snowfall, thunder, hail, fog and gales, and a note. Once there is an entry, a Diary tab appears on your public site with the last twelve months. It reports the deepest snow and the day it was on the ground, not the most recent depth, which is usually the day the last of it melted.
Deeper astronomy. The Astronomy tab gained the next new, first quarter, full and last quarter moon, the next equinox and solstice, live azimuth and altitude for both bodies, moon transit and distance, and how much longer today is than yesterday. Equinoxes print a time because the calculation is good to a few minutes; moon phases print a date only, because the lunar model behind them is good to a couple of hours and a clock time next to that would be false precision.
Getting data in and out
Import from any CSV. Alongside the weewx and CumulusMX importers there is now a generic one for Weather Display, WeatherCat, a Weather Underground download, a logger export or a spreadsheet you kept by hand. The mapping step is the feature: you declare which column is which and what units they are in. Three things no CSV ever states are asked rather than guessed, because guessing them wrong fails quietly instead of loudly. 03/08/2026 is 3 August or 8 March. 12,5 is a decimal comma or a thousands separator. A rain column is per reading or a running daily total, and summing the wrong one reports a month of rain as several metres.
Three new upload targets, taking publishing to sixteen: Windguru, Custom HTTP (post the whole observation as JSON, or fill a {{field}} URL template for the many small networks whose API is a query string), and Bluesky. Bluesky is the one that is not a per-refresh upload, because a station posting every five minutes is a spammer. It carries its own interval, from hourly to weekly, and defaults to daily.
A public API and an RSS feed. Every site now serves GET /api/v1/<subdomain>/current as JSON with both unit systems in every reading, plus RSS at /feed.xml on your own domain. Both are documented, CORS-open, and serve exactly what your public page already shows to any visitor. Feed items are keyed per period rather than per reading, so subscribing to your station does not put 288 unread items in someone's reader every day.
What we deliberately did not build
Some of what the self-hosted programs offer is a consequence of self-hosting, not a gap a hosted service should close. FTP and SFTP upload, template systems, custom log files, MySQL export, per-driver serial station support, add-on installers and a local desktop interface all exist because you own the server. Here, we do. Adding them would be re-creating the maintenance a hosted platform is supposed to remove.
Inside what we did build there are honest limits too. All of them are stated in the docs rather than buried:
- Calibration does not rewrite stored history. It corrects new readings, so your chart shows a step at the moment you saved.
- A range removal in the data editor cannot be undone. Single readings can.
- Snow stays out of the almanac records and climate reports. Those are built from the sensor archive, and mixing a human record in would quietly change what "record" means.
- WBGT is the shade approximation. The full index weights a black-globe thermometer, and no consumer station has one.
Nothing to turn on
All of it is live on every site. New tabs hide themselves until they have something to show, so Reports appears once your archive holds about a week of complete days and Diary appears once you write an entry. Nothing needs migrating, and no existing setting changed meaning.
If you are weighing a hosted site against running CumulusMX or weewx yourself, the list of things you would be giving up got considerably shorter this week. Start a free trial and point it at your station, or read the full docs first.