Sign inRegisterCheck connection

The TNET Web-Tags Project: Extra Tokens in Cumulus Templates

TNET's web-tags project added extra tokens to Cumulus templates via extra web files and PHP includes: an extension pattern, not the tag language.

Back to Cumulus weather software guides

Cumulus already ships a tag language: in a processed file, <#temp> becomes a number. Station sites still needed more layout than the default website and more values than one HTML template could upload every interval. The historical TNET project at /projects/tnetwebtags was an extension pattern for that gap: extra template files, extra tokens bound to PHP (or to a compact include), and a split between what Cumulus processes on the PC and what the web host interpolates on request.

This page is the project. The vocabulary—how a tag maps to an observation, extra sensors, timestamps, and name changes across versions—lives on /tnetwebtags.php. Do not treat the two URLs as duplicates. One is a historical engineering pattern. The other is the data-binding language.

Historical context

Steve Loft’s Cumulus processed templates and could upload a default site. Operators who wanted custom PHP pages faced a bandwidth and architecture problem: uploading a full HTML page on every realtime tick wastes a link; leaving the page static leaves the numbers stale. The community pattern, later documented on the Cumulus Wiki as PHP webtags (last checked 13 August 2026), was:

  1. Write a template that looks like PHP assignments, with Cumulus tags on the right-hand side.
  2. List that file as an extra web file, with processing on.
  3. Let Cumulus substitute tags and upload a small script of variables.
  4. require that script from pages that never need to be re-uploaded when the weather changes.

The historical TNET project sat in that family. It is documented here as a pattern, not as a restored package. TNET does not rehost a ZIP of extra tokens, a webtags.php drop-in from the old site, or anyone else’s ready-made template. Current tag lists come from the running Cumulus build and from the Cumulus Wiki webtags page.

What TNET can say without inventing a token catalog: the project was about adding bindings—more files, more intervals, sometimes more names in the include—so banners, WAP decks, and custom pages could share one processed packet instead of each scraping HTML.

Why extra tokens existed

Stock Cumulus tags already cover temperature, humidity, wind, rain, pressure, many extremes, and unit strings. Extra tokens appeared for reasons that are still valid:

Cadence splitting. Tags that change every few seconds (now-temperature, latest wind) do not belong in the same uploaded file as tags that change at rollover (yesterday’s rain, month-to-date). The wiki’s PHP-webtags note says you can process more than one template at more than one interval. That is an extension of the publication contract, even when every name is a stock Cumulus tag. “Extra” here means extra files, not necessarily extra physics.

Host-side layout. A PHP page on the server can branch on a variable (if ($tempunit == 'C')) without asking Cumulus to rebuild the HTML. The extra file is then a data include. The TNET project’s job was to make that include exist and stay in sync with the station program.

Values the default website did not show. Extra sensors, soil, leaf, air quality, and similar families have tags in later Cumulus builds when the hardware exists. A default template will not mention them. An extra processed file can. That is hardware-true extension: new tokens because new observations exist, not because a theme needed another keyword.

Script-friendly formatting. Locale, decimal commas, and date formats break parsers. MX output modifiers such as rc=y (decimal point) exist so an include can be machine-readable. A project that “adds tokens” is often adding formatted variants of the same observation for PHP, JSON, or WML consumers.

None of these require TNET to have invented a private meteorology. They require a second processed file and a documented naming map.

The extension pattern

Treat the TNET web-tags project as a pipeline with four contracts.

Template (local, unprocessed). Contains literals plus Cumulus tags in the documented form <#tag_name [parameters]>. For a PHP include, a typical line is an assignment, not a web page. The file can use any extension; Cumulus cares that it is listed for processing.

Processed include (uploaded). After substitution, tags are gone. What remains must be valid for the consumer: PHP, a delimiter-separated line, XML, or JSON. Unknown tags in MX become error strings, not silent blanks—so an extra token that is misspelled is a failed contract, not a missing sensor.

Host consumer. Banner GD, WAP project, gauges, or a custom page requires the include or reads the packet. The consumer must not invent fields the include does not define.

Version pin. The set of legal names depends on Cumulus 1 versus MX and on the build. MX can emit WebTags.txt listing names the instance currently implements (from version 3.12.0, via a program setting; last checked 13 August 2026). An extra-token project that does not record the Cumulus version is not reproducible.

That is the whole pattern. Adding a token means: pick a Cumulus tag (or a value derived after substitution, clearly labeled as derived), give it a stable name in the include, document units and interval, and bump a version when the name or meaning changes.

What not to add

Extension projects fail in stereotyped ways:

  • Alias collision. Re-binding <#temp> to $temperature in one file and $temp in another guarantees a banner and a WAP deck will disagree after a refactor.
  • Derived values disguised as tags. A PHP wind-chill computed on the host is not a Cumulus web tag. If the include adds it, the name must not look like a stock tag, and the formula belongs to the operator, not to Cumulus and not to TNET internals.
  • Forecast text as observation. <#forecastnumber> is a station-program scenario index. Extra tokens that expand it into English phrases are still scenarios.
  • Secrets in templates. Credentials, paths, and mail settings do not belong in a processed public include.
  • Redistributing someone else’s token file as “the TNET tags.” Ready-made PHP webtag templates in the wild have authors, versions, and licenses. This URL is not their mirror.

Distinct from the language page

/tnetwebtags.php answers: what is a web tag, which observation families exist, how timestamps work, what happens when names change. This project page answers: how a station site grew extra processed files so multiple consumers shared one binding, and what rules keep that binding honest.

If you are looking up <#wgust> versus <#wspeed>, use the language page. If you are deciding whether to process a second extra file at end-of-day for yesterday’s totals, you are in this project’s problem space.

The same split appears in Weather Display culture as tags versus ClientRaw. Cumulus culture is tags versus optional realtime.txt versus extra processed files. The TNET project lived in the third branch.

Practical checklist for an extra-file include

  1. List every name the host consumers need. Do not dump hundreds of unused tags on a realtime interval.
  2. Split files by cadence: realtime, standard interval, end-of-day.
  3. Pin Cumulus flavour and build next to the include (the classic realtime layout even carried version and build as fields 39–40).
  4. Keep units as separate tokens, not implied by the station’s country.
  5. Treat MX error strings as faults. Do not ship them into GD or WML as temperatures.
  6. When a tag is renamed or added upstream, version the include and keep a compatibility alias only with a documented expiry.
  7. Do not host the include as a world-writable debug dump.

Modern relevance

MX still processes extra web files and still substitutes tags. JSON and HTTP APIs are additional bindings, not a reason to scrape HTML. The extra-file pattern remains the right way to feed a custom page without uploading the page. Old PHP 5 includes, and any historical TNET ZIP, stay unrestored.

Schema extension—adding fields, splitting files by freshness, recording which build produced the names—is a data-source problem. TNET’s public discussion of source identity, units, and quality control is data sources and methodology. How those fields group as atmospheric evidence is evidence families. The Cumulus hub lists neighboring historical projects, including the banner and WAP consumers this include was meant to feed.

Sources