Sign inRegisterCheck connection

The Compact Station-Info Card on a Cumulus Host

A Cumulus /info page is a compact station card: ID, location, software, and units. It is not a full siting-and-metadata configuration essay.

Back to Personal weather station guides

A Cumulus site needs a station-info card: a short, stable block that names the station, says where it is, names the software that wrote the files, and states the unit system. That card is /info on this host. It is not a siting treatise, not a sensor-by-sensor calibration log, and not a network-gear inventory. Those belong on a configuration pillar. The card exists so every other page—mobile root, webcam hub, template slot—can point at four fields instead of repeating a biography.

The historical URL /info on cumulus.tnetweather.com is treated here as that card. The original layout is not restored. No live equipment list is claimed. The full metadata-and-siting essay on the main host remains station configuration as scientific metadata. Use that page when the question is exposure class, obstacle distances, or logger architecture. Use this page when the question is “what four lines should the Cumulus host show before a number.”

Historical context

Personal weather websites grew a dedicated “station info” link because the front page was busy. Visitors who arrived from a mesomap or a forum wanted identity without scrolling past gauges. Mobile decks and WAP cards had even less room: they needed a single URL that answered who, where, which program, and which units. Cumulus templates already had tags for location and version; operators still put a static HTML or PHP page at /info so the text would survive a theme change.

The historical TNET Cumulus host was a software citation hostname as well as a publisher of station-shaped pages. An info card on this host therefore has a double duty: it identifies the station the templates were bound to, and it identifies the software stack the hostname was known for. Mixing those duties into a long equipment narrative is how /info accidentally clones /configuration.php. This rewrite keeps the card compact on purpose.

The four fields

A complete card is four fields, each in ordinary HTML text. Graphics are optional and never a substitute.

1. Station ID

A stable token used in filenames, CWOP or other network IDs if the station reports there, and page titles. The ID is not a marketing slogan. It should not change when the template is redesigned. If the station reports to a public network, cite that identifier as the network cites it; do not invent a parallel code.

If no public network ID was documented for the historical site, the honest card says the local name and “no public network ID recorded.” Inventing a MADIS or CWOP number would be a false observation.

2. Location

Place name and region at a resolution you actually know: city and administrative area, or a named site. Coordinates help machines and later maps; they are optional on a compact card and required on a configuration page. The card must not imply official-station status. A backyard in a named city is a backyard in a named city.

Timezone belongs next to location. Temperature time stamps are meaningless if the card never says whether the clock is local civil time or UTC. State the zone by IANA name when you can (America/Phoenix), not by a colloquial “Mountain Time” that may include daylight-saving rules the site does not use.

3. Software

Name, flavour, and version. “Cumulus” is incomplete when classic Cumulus 1 and Cumulus MX diverge on files and tags. Record the version the operator last documented, as historical software citation, not as a claim that TNET still runs that build. If Weather Display or a helper also read the logger, say so in one line; do not turn the card into a software history.

The Cumulus Wiki software page is the authority for current vendor behaviour (last checked 13 August 2026). TNET is not affiliated with Sandaysoft or the MX maintainers. The card cites; it does not support.

4. Units

The unit system the published files use: temperature, wind, pressure, rain. Cumulus realtime.txt carries unit tokens in the classic map so a consumer does not guess. The info card should match those tokens. A card that says “metric” while the template prints Fahrenheit is a data-quality defect, not a style choice.

If the operator switched units during the archive, the card must say so and date the change. A single unlabeled series that mixes °C and °F is two experiments glued together.

What the card must not absorb

Siting class and obstacle notes. WMO exposure guidance and ISO 19289-style siting classification are how you interpret whether a thermometer represents a neighbourhood or a roof. That interpretation is the configuration pillar. Putting a full obstacle survey on /info makes the card unreadable on a phone and duplicates configuration.php.

Sensor model laundry lists. “Davis-class integrated station” as an architecture note can live on the configuration page. The compact card does not need SKUs. Brand names are not observations.

Hosting and ISP furniture. Server OS, firewall, and upstream provider are not station metadata in the climate sense. They rot quickly and they are not what a visitor needs to read a temperature.

Forecast products. NWS zone text, model output, and software forecast tokens are not station identity. Link them, labeled, from the template or from /m/forecast. The info card stays identity.

Live values. /info is the wrong place for “now 21.4°.” Current conditions belong in the main template slot or on /m. An info page that reprints a packet without a time becomes a second, poorly labeled dashboard.

How other pages should use the card

Treat /info as the canonical short identity. The mobile root should link it rather than truncating the station name into a logo. The webcam hub should reuse the same location line so a camera caption cannot drift to a different city. Graph image pages should inherit units from the card unless a specific figure documents a conversion.

If a processed include needs a machine-readable form, use a small definition list or labeled fields that match the four headings. Do not invent a private XML dialect on the info page when Cumulus already has tags for location and units; bind those tags in the web-tag vocabulary and keep /info human-readable.

A visitor who cannot see images still needs the four fields. That is an accessibility requirement and a scientific one: the identity of the series must survive CSS and CDN failure.

Practical checklist

  • Station ID is text, stable, and not a slogan.
  • Location includes region and timezone; coordinates if you publish them.
  • Software names flavour and version, dated if historical.
  • Units match the published files; a unit change is dated.
  • No live packet, no forecast block, no siting essay.
  • Mobile and webcam pages link here instead of forking the identity.
  • Missing historical facts stay “not recorded,” not guessed.

Modern relevance

APIs and JSON status endpoints still need the same four fields. A browser gauge that fetches MX JSON without a unit key, or a coverage map pin without a timezone, is an info-card failure in a new skin. TNET’s public research pages treat source identity, units, and freshness as quality control for a reason: a number without those fields is not reusable.

This URL does not assert that a particular backyard station still reports. It teaches the minimum identity block a Cumulus host owed its readers.

TNET research bridge

Source identity, native units, and freshness are the modern counterpart of this card for records used in connection research. That public note is data sources, quality controls, and methodology. It does not replace a PWS siting survey.

How observed values are distinguished from modelled and derived displays is how the service works. The weather-station hub groups this card with other instrument pages. Full exposure and sensor-suite metadata remain on configuration.php.

Sources