Sign inRegisterCheck connection

A Project Wiki as Documentation for Cumulus Community Tools

Why a project wiki beat forum-thread documentation for Cumulus community tools, and how the historical TNET wiki differed from the official Cumulus Wiki.

Back to Cumulus weather software guides

A weather-software community that documents its tools only in forum threads is documenting them in a medium that forgets. The useful fact—which file a banner reads, which Cumulus build added a field, which license sat in the PHP header—gets buried under “has anyone tried this on MX?” replies. A project wiki is the opposite instrument: a named page per tool, edited in place, citable by URL, and honest about version. That is why the historical TNET Weather site kept a wiki project at /projects/wiki. It was a documentation layer for community PHP around Cumulus and Weather Display. It was not the official Cumulus Wiki, and this article does not impersonate that wiki.

The official community reference for Cumulus itself remains the Cumulus Wiki (last checked 13 August 2026). Credit it. Link to it. Do not copy it.

Historical context

Personal-weather-station software of the 2000s published observations as files. Cumulus could emit realtime.txt, processed web-tag pages, and dayfiles. Weather Display had ClientRaw and HTML climate reports. Community authors then wrote PHP that turned those files into banners, WAP decks, graphs, and stale-upload checks. Discovery happened on vendor forums. Support happened in the same threads.

A forum thread is a good laboratory notebook and a poor instrument manual. The first post describes version 1.2 against Cumulus 1.8.2. Reply 47 says the field order changed. Reply 112 attaches a different ZIP. A later operator lands on reply 19 and installs the wrong contract. There is no single page whose job is to stay true.

The historical TNET wiki project existed to pull that contract off the thread and onto a durable page. Neighboring URLs in the same family—/projects/wap for the handheld publisher, /projects for packaging and credits—were the tools. The wiki was the layer that said what those tools expected. Editorial rules for writing those pages live on /projects.reference.wiki. This article is about why the layer existed at all.

TNET Weather today does not run that wiki as a live editing community, does not rehost recovered wiki dumps, and does not maintain Cumulus. The URL remains because the idea of a project wiki is still the right way to document a file-shaped weather tool.

Why a forum thread fails as scientific documentation

Station software is an instrument chain. The logger samples. The PC program writes a file. PHP on a host reads the file and publishes a product. Each hop has a version. A scientific record of that chain has to bind four things together in one place:

  1. the input file and its field map, dated;
  2. the output (PNG, WML, status line) and its units;
  3. the software versions that were tested;
  4. the license on the script, in the words the file actually used.

A forum thread can mention all four. It cannot keep them aligned. Chronology fights the map: the newest truth is at the bottom, the citable title is at the top, and search engines index whichever reply a crawler saw. Operators paste screenshots instead of field lists. Someone “fixes” a parser in a code box that is not the released file. Six months later the thread title still says the old interval.

That is not a social failure. It is a medium mismatch. Observation metadata—WMO practice for a measurement includes the quantity, the unit, the time, and the instrument identity—does not belong in a conversation. It belongs in a page that can be corrected without appending.

What a project wiki did that a thread could not

A project wiki, even a small one attached to a single weather site, changed the documentation job in four ways.

Stable names. /projects/wiki plus a child page for a named tool is a citation. Another operator, another site, or a later preservation project can point at that name and mean one contract. A forum URL with a post number is a citation until the board software is upgraded.

In-place correction. When Cumulus MX added fields to realtime.txt, the honest edit is to date the old map and add the new one on the same page. A wiki can do that. A thread can only add a reply that half the readers will never see. The Cumulus Wiki realtime.txt page is the live illustration of that discipline for the vendor file itself: it states which flavour and which version a field list describes. A community-tool wiki should do the same for the PHP that consumes the file.

Separation of code and prose. The wiki holds the field map, the requirements, and the known breaking changes. The script, if it is still distributed, lives under a stated license somewhere else. Pasting binaries or whole PHP dumps into wiki pages destroys both jobs: the page becomes an unlicensed mirror, and the documentation stops being readable. That rule is an editorial standard; the reason for the wiki is that the prose had to live somewhere that was not the ZIP.

A table of contents that is not a search box. Community tools around Cumulus were a family: identity images, WAP, log accumulators, graph packs, server checks. A wiki index makes the family visible as a map of problems. A forum tag cloud does not.

None of this required MediaWiki at Wikipedia scale. It required a writable, named, version-aware page per tool, with a date on every field list.

Distinct from the official Cumulus Wiki

Two wikis in this neighborhood are easy to confuse and must not be fused.

The Cumulus Wiki (cumuluswiki.org) is the community documentation for Cumulus and Cumulus MX: web tags, realtime.txt, extra files, hardware notes, and MX interfaces. It is maintained by the Cumulus community. TNET is not affiliated with Sandaysoft or with the MX maintainers and does not speak for that wiki.

The historical TNET wiki project documented TNET’s own community tools and how those tools used Cumulus and Weather Display files. Its job was the consumer side of the contract: what a banner required, what a WAP deck emitted, what a stale-upload checker treated as “down.” When it needed a vendor fact, the right move was a citation to the Cumulus Wiki, not a fork of the vendor page.

If a recovered TNET wiki page and a Cumulus Wiki page appear to cover the same file, treat the Cumulus Wiki as the authority for how Cumulus writes the file, and treat the TNET page as a historical note about a particular consumer. Do not merge them. Do not restyle this URL as “the Cumulus Wiki.”

What belonged on a community-tool wiki

A useful page for a Cumulus-adjacent PHP tool answered the same questions a later researcher asks of any public weather product.

Identity. Tool name, author credits, and the station-software target (legacy Cumulus 1, Cumulus MX, Weather Display, or generic PHP). “Works with Cumulus” is not a specification.

Input contract. File name, delimiter, field count at a stated software version, unit tokens, and the clock the file uses. For realtime.txt, that means citing the vendor map and dating the citation, because field 59 and later arrived with MX.

Output contract. MIME type or image type, dimensions if the product is a graphic, and whether values are observed, derived (wind chill, heat index), or scenario (Zambretti-style forecast numbers). A wiki that lets those three families share a heading without labels is teaching the next operator to misquote the station.

Freshness. How often the input is expected to be rewritten, and what a consumer should do when the file is older than that. That sentence belongs in documentation even if a separate checkserver tool implements it.

License, in the file’s words. GPL, BSD-style, public domain, or unclear. Unclear is a valid wiki status. It is not a permission to paste the script into the page.

Breaking changes. One dated list: “build n added field k”; “PHP 7 removed mysql_*”; “host disabled GD.” A wiki page that never records a break is a brochure.

Those items are why a wiki beat a thread: they are a checklist that can be kept true. They are not a download catalog. This preservation site does not offer historical ZIPs.

Practical checklist for reading a historical weather-tool wiki

  1. Name the wiki. If the page is TNET’s project wiki, say so. If the fact is about Cumulus behavior, follow the Cumulus Wiki.
  2. Find the date on the field map. An undated realtime.txt column list is a rumor.
  3. Separate observed, derived, and forecast fields in whatever table you inherit. Do not leave heat index in the same unlabeled column as outside temperature.
  4. Look for a license line and believe the file header over the wiki sidebar if they disagree.
  5. Do not treat a wiki code box as a release. If you need to run something, use a maintained project with a stated license, or rewrite from the documented contract.
  6. Record the Cumulus flavour. Legacy 1 and MX share names; they do not share a runtime.
  7. Keep this URL as a citation for the documentation-layer idea, not as a live editor.

Modern relevance

The forum-versus-wiki problem did not end when phones stopped speaking WML. GitHub issues, Discord pins, and screenshot-heavy Facebook groups recreate the same lossy archive. A weather tool that publishes a public file still needs a named page that states inputs, outputs, versions, and license. MX’s HTTP and JSON interfaces changed the transport. They did not remove the need for a dated field map.

A research pipeline that later consumes station-published files has the same requirement in a different vocabulary: provenance, freshness, and source identity. The wiki is the human-readable form of that requirement.

TNET research bridge

TNET’s public explanation of how evidence is grouped—observed measurements, modelled fields, derived summaries—is how the service works. A project wiki that labeled those families on a banner or a WAP deck was doing the same intellectual job at station scale. That page does not publish TNET formulas, and this wiki URL is not a Cumulus manual.

The Cumulus hub indexes the related historical project pages. How to write the reference pages themselves is /projects.reference.wiki. The packaging index is /projects.

Sources