Sign inRegisterCheck connection

Station Software as Metadata for Interpreting Published Files

A weather site's software name is metadata: Cumulus, Weather Display, or another program changes how published files and numbers should be read.

Back to Cumulus weather software guides

A personal weather site publishes numbers that look like weather. The program that wrote those numbers is part of the record. An About page that names Cumulus, Weather Display, or another station package is not a product pitch. It is a declaration of the file contract a later reader must assume before treating a temperature, a rain total, or a “live” banner as an observation.

The historical TNET URL /aboutus.wxsoftware sat in that About cluster. Its job was to say what this site ran, so visitors, forum posters, and later archivists could interpret the files the site uploaded. Choosing which program to install is a different question; that checklist lives at /aboutus/wxsoftware.

Historical context

Hobby weather websites of the 2000s commonly listed the console, the logger, and the PC program on an About or credits page. The names were social—operators compared notes on forums—but they were also scientific. Cumulus and Weather Display occupied the same architectural slot (read the station, keep local logs, publish a site) and used incompatible public vocabularies. Mixing those vocabularies without a declaration is a provenance error.

The historical TNET Weather site on the Cumulus host was a Cumulus-side publisher. Neighboring About URLs named projects, website generator information, and web tags. Software identity belonged with that cluster because a reader who only sees 72.4 on a gauge cannot tell whether the number came from a processed Cumulus template, a Weather Display ClientRaw parser, or a typed caption. Modern TNET Weather does not run that CMS, does not maintain third-party station software, and does not restore an editor for this page.

Why the program name is metadata

An observation that will be reused needs identity, units, time, and source. Station software is source identity for everything the site generated after the logger.

File layout is not shared. Cumulus can emit an optional one-line realtime.txt of space-separated fields, processed HTML from web tags of the form <#temp>, monthly logs, and a dayfile.txt daily appendix. Weather Display’s public compact file is clientraw.txt (and related extra clientraw files), with HTML templates using %temp%-style custom tags. A parser written for one layout will assign the other layout’s columns to the wrong quantities. The Cumulus Wiki realtime.txt page (last checked 13 August 2026) is explicit that the file is optional, frequently rebuilt, and not a substitute for logs. Declaring “this site runs Cumulus” tells a later script which field table to open.

Tag languages are not interchangeable. <#wgust> and %gust% may both mean a gust in English, but they are tokens in different processors. Treating a Weather Display template as a Cumulus extra web file, or the reverse, produces error strings, blanks, or worse: plausible numbers in the wrong slots.

Derived indices travel with the program. Wind chill, heat index, humidex, apparent temperature, and later “feels like” values are software-derived from other observations (and from that program’s implementation). They are legitimate to publish if labeled. They are not extra thermometers, and they are not interchangeable across packages. A Zambretti-style forecast number from a station program is a scenario, not a National Weather Service product.

Version and flavour change the contract. Legacy Cumulus 1 and Cumulus MX share ideas and some file names; they do not share a runtime. Field counts in realtime.txt grew across MX builds. A declaration that stops at “Cumulus” is better than silence and worse than “Cumulus MX, build N, realtime fields as of that build.”

Without the software name, an archived folder of text files is an unlabeled instrument.

What a useful declaration contains

A one-line credit (“Powered by Cumulus”) is a start. A declaration that later readers can use is a short instrument note.

| Item | Why it matters | |---|---| | Program and flavour | Cumulus 1 versus MX versus Weather Display versus another package selects the file map | | Version or build | Field lists and tag names change; MX can emit WebTags.txt for the running instance | | Logger or console family | Davis-class, Fine Offset / EasyWeather-class, La Crosse, and others have different native intervals | | Native units | The packet’s unit tokens (<#tempunitnodeg>, <#rainunit>, and their WD analogues) are part of the number | | Published files and intervals | Processed HTML, optional realtime file, extra includes, dayfile—each is a different object | | Rollover time | “Rain today” is defined by the station clock, not by the visitor’s midnight | | What is derived | Indices and software forecasts labeled as derived or scenario |

That note belongs next to siting remarks (height of the anemometer, radiation shield, nearby pavement). Software does not fix a thermometer over asphalt. It does tell you which file you are holding.

How the declaration changes a reading

Suppose an archive contains a one-line text file and a PNG banner.

If the About page declared Cumulus, the line is a candidate realtime.txt. Units may appear as sibling fields. Decimal points are documented as script-friendly even when the PC locale uses commas. Version and build historically occupied late fields in the classic layout. A homemade append-log of that line is a derived series the operator chose to keep; it is not the Cumulus monthly log.

If the About page declared Weather Display, the compact file is a candidate ClientRaw. Field order, unit conventions, and extra files (clientrawextra.txt and relatives) follow that stack. HTML that still contains %temp% was not processed. HTML that contains a number where a tag used to be is a snapshot at processing time, the same scientific status as a processed Cumulus page.

If the About page named something else, or named nothing, do not guess. WeeWX, Meteobridge, console-native uploads, and hand-built PHP all existed in the same era. Guessing Cumulus because the hostname contains the word is not a method. Until a forum post, packet version field, or generator tag supplies the program, the files are unidentified. The website-info sibling holds stack strings; this page is station-program identity.

Incomplete and misleading declarations

Several failure modes appear in old About pages.

Theme named instead of program. “SteelSeries gauges” or a skin name is a display. The gauges still consume a packet. Name the packet’s writer.

Network named instead of program. Weather Underground, CWOP, AWEKAS, and similar networks are destinations. Many programs can upload to several of them. A network copy is not a substitute for naming the local program that wrote the site files.

“Real-time” as a brand. Both Cumulus and Weather Display can upload often. Cadence is a configuration choice. EasyWeather-class hardware that updates on the order of tens of seconds cannot honestly support a one-second “live” claim. The software name plus the logger family makes that limit visible.

Copied credits. Templates circulated with leftover “powered by” lines from the author’s station. A declaration that does not match the files on the host is false metadata. Prefer evidence in the files (version tags, field counts, leftover unprocessed tokens) over a decorative footer.

Practical checklist for readers of a historical site

  1. Read the About or credits page for the program name, flavour, and version.
  2. List the public files and do not parse a Cumulus realtime line with a ClientRaw map, or the reverse.
  3. Treat processed pages as snapshots at generation time, not as live objects.
  4. Label software indices and forecast tokens as derived or scenario.
  5. Record native units from the packet, not from the visitor’s preference cookie.
  6. If the software name is absent, stop and look for version fields, generator metadata, or unprocessed tags before assuming a stack.
  7. For current behavior of software you still run, use the vendor docs: Cumulus Wiki Software and Weather Display custom tags (last checked 13 August 2026).

Modern relevance

Source identity did not become optional when sites moved from FTP of realtime.txt to JSON extra files or local HTTP APIs. A later reader still needs to know which program serialized the fields. TNET’s public discussion of source identity, units, and freshness for weather records used in connection research is data sources, quality controls, and methodology. That brief does not list historical PHP names, and this page does not describe TNET internals.

How observed, modelled, and derived information are distinguished in TNET’s public vocabulary is conceptual on how the service works. The Cumulus hub indexes the related historical pages. If you need to choose a station program rather than read a declaration, use the software-choice article.

Sources