Sign inRegisterCheck connection

Cumulus Station Software and the Historical TNET Project Family

Cumulus as station software and the historical TNET project family of graphs, realtime logs, banners, WAP, and web tags: a research overview, not a download catalog.

Back to Cumulus weather software guides

Cumulus is station software: it reads a personal weather station, keeps local logs, and can publish a website from templates and small text files. Around that core, community authors built banners, log accumulators, WAP pages, and graph packs that treated Cumulus files as a public data contract. This article is a research overview of that system. It is not a download catalog, and it does not imply that modern TNET Weather writes, supports, or ships Cumulus software.

The historical TNET page at /cumulus.php listed named packages, ZIP and click-tracker links, version tables, and PayPal lines. Those distribution mechanisms are not restored. Child URLs for individual projects remain as historical addresses; their deep implementation notes belong on those pages, not here.

Historical context

Steve Loft developed Cumulus and distributed it through Sandaysoft as donationware for Windows personal weather stations. The software sat in the same architectural slot as Weather Display: logger on one side, files and FTP on the other. Its public vocabulary was different. Where Weather Display operators talked about ClientRaw and %temp% tags, Cumulus operators talked about web tags of the form <#temp>, optional realtime.txt, dayfile.txt, monthly logs, and a default website the program could upload.

The historical TNET Cumulus project family grew in that file-shaped gap. PHP on the web host could read realtime.txt and draw a banner, append a line to a homemade archive, or emit a WAP deck for phones that could not render the full site. The index page also pointed at official Sandaysoft forum, product, wiki, and map links. That pointer remains the right instinct: current behavior of the software is defined by its maintainers, not by a preserved community index.

Cumulus later split in practice into the legacy Cumulus 1 line and Cumulus MX, a cross-platform continuation. MX is documented on the Cumulus Wiki and developed in public on GitHub (last checked 13 August 2026). TNET is not affiliated with Sandaysoft or with the MX maintainers and does not endorse either product.

Cumulus as a station-to-file system

A scientifically usable Cumulus site is a chain of contracts.

Hardware and logger

Cumulus, like other station programs, can only publish what the hardware sampled and what the PC received. Davis-class integrated stations, Fine Offset / EasyWeather-class loggers, and other supported families have different native intervals. The Cumulus Wiki notes, for example, that EasyWeather-class stations update on the order of tens of seconds, so a "real-time" file interval faster than the hardware is mostly cosmetic. That is an instrument fact, not a theme-park refresh rate.

Local records

Cumulus stores dayfiles, monthly logs, and configuration in local files (and, in MX, additional databases and interfaces). Those records are the climate memory of the station. They are historical observations (plus software-derived daily extremes). They are not the same object as the tiny file uploaded every few seconds for a live banner.

Web tags

Web tags are Cumulus's template language. In a file marked for processing, <#temp> becomes a number when Cumulus generates the output file. MX documents the tag list, modifiers, and the fact that unknown tags become error strings rather than silent blanks (Cumulus Wiki: Webtags, last checked 13 August 2026). A processed template is therefore a snapshot of values at processing time. It is an excellent way to publish a daily climate page. It is a clumsy way to animate a gauge every second, which is why a separate realtime file exists.

Optional realtime.txt

realtime.txt is an optional, frequently rebuilt, single-line, space-separated packet of current values plus unit tokens and some today's extremes. The Cumulus Wiki realtime.txt page states the properties that matter scientifically:

  • generation is off by default;
  • the file is meant to be re-created often and uploaded for near-current readings;
  • it is not a substitute for logs: it does not hold long historic series in the Cumulus-1 field list, and it is not the dayfile;
  • decimal points are produced in a script-friendly way even when the PC locale uses commas;
  • field counts grew over versions, so a parser is version-sensitive.

A PHP banner that reads this file is reading a current observed (and software-derived) packet. A graph pack that reads a homemade log of those lines is reading a derived archive the operator chose to keep, not an official Cumulus climate product.

Default website versus extra files

Cumulus can upload its own site, extra processed files, and optional realtime files on different timers. Bandwidth notes in the wiki exist because cadence is a data-quality choice: too fast on a capped link produces gaps; too slow makes a "live" banner a lie. MX also offers JSON and HTTP interfaces that later templates use instead of scraping realtime.txt. Those are current-vendor facts; community PHP from 2008 does not automatically speak them.

The historical TNET project family as engineering problems

The old index mixed several jobs. Grouping them as problems keeps this pillar from duplicating later deep-dives.

Identity images (PHP-GD banner, avatar, thermometer). Given a current packet, draw a small PNG that a forum or sidebar can hot-link. The engineering issues are GD/TrueType availability, unit labels taken from the packet, and cache headers so that a banner is not glued to yesterday afternoon. The named banner project keeps its own URL.

Realtime log accumulation. realtime.txt is overwritten. If an operator wants a high-frequency series for graphs, something must append a timestamped copy on a schedule (historically PHP plus cron). That homemade log is a new dataset. It needs a clock policy, a rotation policy, and an honest statement that it is not the Cumulus monthly log. Rotation scripts existed because unbounded append is a disk-failure mode.

Graphs from the homemade log. Once a log exists, a graphing library can draw 24-hour traces. That is visualization of the operator's derived archive. It is not Cumulus's built-in graph engine, and it is not a place to paste JpGraph configuration. Compatibility with PHP, fonts, and the log's column order is the whole game.

WAP pages. Phones of that period often handled WML better than a full HTML weather site. A script that emitted a tiny deck from realtime.txt was a constrained-viewport publisher. It is historically interesting as an accessibility and bandwidth design, not as a current app store.

Server capability checks. A small script that tested PHP and GD before the operator installed a banner pack was release engineering: fail on missing libraries rather than on a blank image at 02:00.

Web-tag and XML includes. Some projects tried to expose extra processed files or XML so the host could include values without asking Cumulus to rebuild every page. That is the same split Weather Display operators made with tags versus ClientRaw: process on the PC when the layout is stable; publish a small data file when the layout is a PHP template.

METAR, moon, mail, wiki, and cookie experiments. These sat at the edge of station software: pulling an aviation METAR, formatting almanac data, mailing on triggers, or wrapping European cookie notices. They are integrations, not Cumulus internals. A METAR is an official aerodrome observation code; a PWS banner is not. Combining them on one page requires labels.

This overview deliberately stops at the problem names. Checkserver, JpGraph packs, and other children should keep their own articles. Collapsing them here would make those URLs duplicates.

What Cumulus is not

Cumulus is not an official forecast office. Zambretti-style or software forecast fields that appear in realtime.txt are scenario or rule-of-thumb outputs from the station program, not National Weather Service products. For warnings, use NWS or the national service that has authority at the site.

Cumulus is not a siting standard. A perfect realtime.txt can still be a thermometer over asphalt. Configuration metadata belongs with the station, not with the banner script.

Cumulus MX is not "TNET Cumulus." Modern TNET Weather does not maintain forks, issue builds, or provide ZIP downloads of these community projects.

Practical checklist for reading a historical Cumulus site

  1. Identify the flavour. Legacy Cumulus 1 and MX share ideas and some file names; they do not share a runtime. Wiki pages often mark which flavour they describe.
  2. List the published files and their intervals: processed HTML, realtime.txt, extra templates, images.
  3. Do not parse realtime.txt with a Weather Display ClientRaw map. Different order, different fields, different unit tokens.
  4. If a PHP graph depends on a homemade realtime log, find the cron that wrote it. Missing cron looks like a flat calm.
  5. Record the Cumulus version and build from the packet or the interface. Field 39–40 in the classic realtime.txt layout carried version and build; MX added later fields.
  6. Check licenses on any leftover PHP before publishing a modified banner. The historical index mixed GPL and other labels; file headers win.
  7. Follow current official docs for anything you still run. The wiki and MX GitHub are the live references (last checked 13 August 2026).
  8. Keep child TNET URLs as citations, not as software mirrors.

Modern relevance

The Cumulus file contract—web tags for processed pages, optional compact realtime file for live consumers, logs for climate—is still a clean design. MX's HTTP and JSON interfaces are a continuation of the same idea with less FTP. Operators migrating from Cumulus 1 to MX are migrating a data contract, not a theme.

Community PHP that assumed PHP 5, GD, and a one-line realtime.txt from 2008 may still illustrate the contract and still be a poor thing to execute. For maintained template ecosystems on the Weather Display side, Saratoga remains the living collection; for Cumulus, the wiki's extra-files and web-tag documentation is the first stop. TNET's preservation job is to keep the historical map of the project family readable.

TNET research bridge

Cumulus sites published frequent, compact, unit-labeled observations. Whether those observations are usable in later work depends on provenance: which software wrote them, how often they were uploaded, and whether a homemade log was substituted for the vendor dayfile. TNET's data sources, quality controls, and methodology note is the modern discussion of those questions for the public records used in connection research.

The Cumulus hub lists related historical pages. Packaging and licensing across both Cumulus and Weather Display are covered in weather-software project packaging. The PHP tooling layer that hosted many of these scripts is covered in the scripts article.

Sources