A personal weather station changes in public. A humidity sensor is replaced, Weather Display is upgraded, a webcam is marked stale, a monthly NOAA HTML file is added. Those events are not temperatures. They are operations. Station software still tried to publish them automatically, because the same FTP job that uploaded clientraw.txt could upload a short “what’s new” file and the website could print it as Site News.
The historical TNET Weather page at /sitenews.php was that auto-published changelog. Weather Display and the template packs that wrapped it commonly treated a whatsnew-style text file as a first-class web product: timestamped notices the logger PC already knew how to upload. This article is about that product. It is not a live feed, it does not reprint the recovered notice list, and it is not the editorial ops log at /news.
Historical context
Weather Display (WD) ran on the station PC, talked to the logger, and published a bundle of files to a web host. Beside the observation files sat operator-facing text: tags for “last updated,” sometimes a news or whatsnew file, and HTML fragments the template included on a Site News page. Community PHP templates expected that file. The operator typed a line on the WD PC; the next upload made it a web page. No separate CMS was required.
The recovered /sitenews.php page described itself as the place to record website changes, observation-ability changes, and other news that might affect the station. Captured entries were a mix of software version notes, sensor replacements, hosting moves, and gadget work. The scientific remainder of that mix is the type of record: an operational log generated in the same publishing loop as the observations, not a second thermometer.
TNET Weather keeps the URL so old links still resolve. Keeping the URL is not a claim that WD still posts here, and it is not a revival of the original notice file.
What auto-published “whatsnew” actually recorded
A WD-driven news file was only as disciplined as the operator. In practice it held four kinds of line, and only one of them belongs next to the climate series.
Sensor and siting events. Replacing a temperature/humidity probe, noting that an anemometer transmitter failed, or recording that the station was taken offline for repair. These lines are station-history metadata. They explain breaks, spikes, and gaps. They are the amateur form of a national network’s instrument-change record.
Software and publication events. “Updated WDLive,” “parser now matches a new ClientRaw layout,” “added a parsed NOAA month.” These lines are provenance for the website and the files, not for the air. A parser version change can alter which field a downstream notebook reads. That is a data-handling event.
Hosting and power events. Server moves, bandwidth changes, UPS failures. These explain why the website was unreachable or why uploads paused. They are not weather. They are why a gap exists.
Gadget and vanity events. Guestbooks, hit counters, slideshows, forum greeting banners. These belong in a web changelog. They do not belong in a climate diary.
Auto-publish is valuable because it timestamps the first two kinds close to the moment they happened, in the same clock domain as the logger. It is dangerous because it dumps all four kinds into one reverse-chronological pile labeled “news,” which a later reader may quote as if every line were a meteorological event.
Auto-publish is not an observation
An observation is a measurement with time, place, units, and an instrument. A whatsnew line is a historical operations note. Even when the line is “sensor replaced at 17:04,” the news page is not the temperature series. The series lives in the logger files. The news page is the annotation that the series changed meaning at that clock time.
Confusing the two produces specific errors:
- Quoting a “wild readings last month” notice as if it were a climate extreme.
- Treating a WD version note as a calibration.
- Filling a data gap with the story of a UPS failure instead of leaving the gap and citing the log.
- Calling the news page “current conditions” because both were uploaded by the same program.
Quality-control practice in official networks keeps station history beside the observations and does not let the history overwrite the numbers. NOAA’s MADIS documentation for citizen observations is explicit that ingested PWS data are quality-controlled against independent checks; a backyard notice file is not that check. It is the operator’s own diary. Useful, biased, and incomplete.
Data sources, quality controls, and methodology is the modern TNET statement of how public records are treated as evidence: by identity, freshness, and kind. A whatsnew file is source metadata. It is not a weather source.
Distinct from /news
This host also has /news. That path is the editorial operations log: a site-history URL for human-written continuity about the property, not the WD upload slot. The two pages can mention the same outage and still be different documents.
| | /sitenews.php | /news |
|---|---|---|
| Typical source | Station software / whatsnew-style file | Editorial note on the website |
| Cadence | Tied to the upload job | Tied to when someone wrote prose |
| Scientific use | Timestamped station-history hints | Property-level continuity |
| Failure mode | Mixes gadgets with sensor changes | Looks like a press room |
Do not merge them. A crawler that treated both as “TNET news” would flatten a logger diary into a brand blog. The TWS wrapper article is a third object: the PHP that dressed the file in local HTML. That is presentation, not a fourth log.
How to use a station changelog
If you are reading an old PWS news page, or keeping one:
- Split the lines. Sensor/siting; software/files; hosting; gadgets. Only the first two usually belong in a station history that travels with the data.
- Copy the timestamp into the series notes, not into the temperature column.
- Believe outages as gaps, not as interpolated weather. A “SERVER DOWN” line is a missingness flag.
- Do not treat completeness as true. Operators skip days. A quiet news page is not proof that the instruments were stable.
- Cite the file as historical. “The 2007 site-news page recorded a probe replacement” is a legitimate historical claim. “Humidity was X because the news said so” is not.
Practical checklist for operators
- Keep a whatsnew (or equivalent) that the logger PC can upload without a CMS.
- Use a fixed vocabulary on the first line:
SENSOR,SOFTWARE,HOST,SITE. - Put instrument changes in one sentence with clock time and which variable is affected.
- Do not paste live observations into the news file; they already have a page.
- Mirror the sensor lines into the configuration record when the hardware actually changed.
- Never use site news as a warning service. Official alerts stay with NWS or the local meteorological authority.
Modern relevance
Connection and weather research still need to know when a source changed meaning: a file format, a station move, a missing interval. Auto-published station news was the hobby implementation of that requirement. It remains a good idea when it is labeled as operations metadata and a bad idea when it is styled as a headline feed.
TNET does not ingest a WD whatsnew file as a forecast input, and this page does not disclose how TNET assembles estimates. The public account of evidence kinds is how the service works. The public account of source identity and quality control is data sources, quality controls, and methodology, which is the primary next step from this URL.
The site-history hub lists related continuity pages. The legacy hub is the organized entry to the restored footprint.