Sign inRegisterCheck connection

A Research Map of Cumulus-Side Engineering Projects

A research map of Cumulus-side projects—graphs, logs, banners, WAP, tags, and checks—as engineering problems, not a packaging catalog or file dump.

Back to Cumulus weather software guides

The /projects path on cumulus.tnetweather.com was an index of Cumulus-side engineering: graphs, logs, banners, WAP decks, web tags, heartbeats, cookie notices, and dayfile parsers. It was a research map of problems that appear once a station program writes public files. It was not a ZIP cabinet, and it was not the packaging-and-credits index that occupies /projects on tnetweather.com.

This article keeps the map. Child URLs keep their own deep explanations. Collapsing those explanations here would make the children duplicates. Modern TNET Weather does not maintain the historical PHP, does not issue Cumulus builds, and does not rehost the packages.

Historical context

Cumulus publishes a website by processing templates and optionally uploading compact data files. The files that mattered to community PHP were small and frequent (realtime.txt), daily and append-only (dayfile.txt), and processed HTML or includes built from web tags. Each file creates a different job for a web host:

  • a current packet that must be read, labeled with units, and not cached as yesterday;
  • a daily appendix that must be parsed as one row per meteorological day;
  • a series that does not exist until someone copies the current packet on a schedule;
  • a picture of that series that must show gaps instead of inventing calm;
  • a tiny viewport for phones that could not render the full site;
  • a liveness check so a silent FTP failure is not mistaken for still air.

The historical TNET Cumulus project page grouped named scripts around those jobs. The Cumulus Wiki catalog of TNET Cumulus Scripts still records the names (last checked 13 August 2026). The Wiki is evidence of how the community cited the index. It is not a license to ship the files from this hostname.

The same path on the main TNET host is a different article: how Weather Display and Cumulus community projects were packaged, versioned, documented, and credited. That page is about release discipline across stacks. This page is about the Cumulus engineering map only. If you arrived here looking for “how a weather-script ZIP should be labeled,” you want the main-host projects article. If you arrived here because the Cumulus Wiki or a forum named a TNET Cumulus helper, you want this map and then the child URL.

How to use the map

Read each row as a problem, a file contract, and a child URL. Do not install across contracts. A banner that reads realtime.txt will not parse a Weather Display ClientRaw line. A dayfile parser will not animate a gauge. A JPGraph pack that expects a homemade log will draw a flat line if the log was never written.

Evidence types stay labeled:

| Problem | Typical input | What the output is | |---|---|---| | Live identity image | Current realtime.txt | Derived PNG from an observed packet | | High-frequency archive | Snapshots of that packet | Derived series, not a vendor log | | Scientific plot | The homemade series or a dayfile | Visualization of observed or derived numbers | | Daily climate table | dayfile.txt | Historical daily appendix | | Heartbeat | File mtime or packet clock | Quality-control flag, not weather | | Preference cookie | Units, language | Browser state, not a measurement | | WAP deck | Current packet | Constrained observed snapshot |

Software forecast tokens that appear in Cumulus packets remain scenario output from the station program. They are not National Weather Service products.

The map

Graphs: a series must exist before a figure can be honest

realtime.txt holds one line. A temperature–pressure–rain trace over 24 hours holds many lines. The missing object is an archive of snapshots. Once that archive exists, a plotting library can draw axes with units, mark missing samples, and refuse to connect a 03:00 gap as if the thermometer had been perfectly steady.

The historical named pack used JpGraph (also written JPGraph / JpGraphs in community pages). The JPGraph graphs article is the scientific-figure discussion: axis units, missing samples, and why a graph pack existed at all. The Cumulus Wiki Toolbox still names JPGraph as a reason to keep a running log of realtime.txt when the web host cannot run cron. That backlink is why this child URL is a pillar, not a caption.

This map stops there. Plot configuration, PHP versions, and font paths belong on the child page—and not as redistributed code.

Logs: accumulation is not rotation

Two different failures hide in the word “log.”

Accumulation copies each new realtime.txt onto the end of a growing file so a later process can plot or analyze a high-frequency series. Sample interval versus file growth is the scientific tradeoff: faster sampling records fronts; it also writes more bytes. That problem lives at realtime log accumulation.

Rotation closes the growing file on a calendar boundary, names the closed file so it can be found, and keeps enough history that a monthly extreme is not deleted because last week’s disk filled. That problem lives at the unique path realtime log rotation. It is not a slash twin of the accumulator, and it is not the Cumulus monthly log documented on the Wiki as standard log files.

A homemade realtime archive is derived. The vendor dayfile and monthly logs are Cumulus climate products. Substituting one for the other in a citation is a provenance error.

Daily appendix: one row per day is not a live packet

dayfile.txt is a CSV-style daily summary: one line per day, with maxima, minima, rain total, and related fields that grew across Cumulus versions. The Cumulus Wiki dayfile page is the field reference. Parsing that file into a monthly HTML table is a different job from splitting realtime.txt. The child dayfile parser article covers that distinction and why a monthly climatological summary needs the dayfile’s provenance, not a gallery of noon snapshots.

Identity images: a packet becomes a PNG

PHP-GD banners, avatars, and thermometer images take the current packet and draw a small graphic a forum can hot-link. The engineering issues are GD availability, unit labels taken from the packet, and cache headers so yesterday afternoon is not glued into a sidebar. Those named projects keep their own URLs (/projects/phpggbanner, /projects/phpgdavatar, and related paths). This map only records the problem class: derived images from an observed line.

Tags and includes: process on the PC, consume on the host

Web tags are Cumulus’s template language. MX documents the tag list and the fact that unknown tags become error strings rather than silent blanks (Cumulus Wiki: Webtags, last checked 13 August 2026). Some historical projects exposed extra processed files or PHP includes so the web host could print values without asking Cumulus to rebuild every page. That is the same split Weather Display operators made with tags versus ClientRaw. The child tag-project URLs keep the implementation notes. The map’s lesson is the contract: processed templates are snapshots at processing time; they are a poor way to animate a one-second gauge.

WAP: a constrained viewport is a publishing design

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 an accessibility and bandwidth design, not a current app. The /projects/wap URL remains the named child. This index records WAP as a viewport problem, not as a product.

Heartbeats: stale data is a quality-control event

If Cumulus stops uploading, the last realtime.txt on the server can sit for hours while the page still looks “live.” A small checker that compares file time or packet clock against the server clock is not a commercial uptime dashboard. It is the difference between observed now and historical last packet. The server-check article is that quality-control note.

Cookie notices: preference state is not a measurement

Personal weather templates often stored units and language in cookies so a visitor could see millimeters instead of inches. European cookie rules of that era asked operators to document storage on the visitor’s machine. The tension is engineering documentation, not a legal clinic. The EU cookie project article stays on that tension. A later Weather Display–oriented pack at a dotted path is a different URL and a different stack.

Distribution: names without binaries

Operators needed a list of what each named package was for. They did not need this hostname to become an unverified file mirror. The downloads catalog is the named-package list plus the reason binaries stay offline. The subdomain homepage explains why those names lived on a Cumulus host at all.

What this index refuses to do

It does not reprint ZIP contents, click-tracker counts, or PayPal lines.

It does not treat the Saratoga legacy scripts page as a TNET download folder. Saratoga currently lists some Cumulus-era TNET scripts (dayfile parser, GD banner, GD avatar, JPGraph graphs) as a living archive with its own notices (last checked 13 August 2026). That is upstream for operators who still need a file. This map is the problem index.

It does not imply that modern TNET wrote, supports, or endorses Cumulus, JpGraph, or any child script.

It does not copy the main-host /projects packaging essay. License identifiers, credit lists, and GPL-versus-unclear reading belong there when the question is release engineering across WD and Cumulus. Here the question is: which Cumulus file problem am I in?

Practical checklist

  1. Start from the file, not the pretty name. If the helper reads realtime.txt, version the field list. If it reads dayfile.txt, version the column count and locale separators.
  2. Mark homemade logs as derived. A graph of an operator’s append file is not a graph of the Cumulus monthly log.
  3. Keep children separate. Use this page to find the problem; open the child URL for the deep note.
  4. Follow current official docs for software you still run: Cumulus Wiki Software and Cumulus MX on GitHub (last checked 13 August 2026).
  5. Do not mix stacks. Weather Display HTML extractors are not on this map.

Modern relevance

The map still matches how people publish station data. MX may push JSON over HTTP instead of a one-line text file, but the jobs remain: a current packet, a daily appendix, a series, a figure, a liveness check, and an honest label for derived files. Raspberry Pi and other always-on hosts still fail in the same ways—cron not firing, disk filling, clocks drifting, uploads stalling—and those failures still look like weather if nobody mapped them as engineering.

TNET’s preservation job on this path is the map, not a support desk.

TNET research bridge

Grouping helpers by the file contract they consume is provenance work: it stops a later reader from treating a homemade graph log as a climate dayfile. TNET’s public note on data sources, quality controls, and methodology is the modern counterpart of that discipline for records used in connection research. It does not list these PHP names.

Related pages on this host: the Cumulus subdomain homepage, the JPGraph figure article, and the named-package catalog. The main-host Cumulus overview remains the station-software pillar. The Cumulus legacy hub collects both hosts.

Sources