Sign inRegisterCheck connection

Choosing Station Software: Logger Support, Templates, and File Formats

A checklist for choosing station software: logger support, template model, and file formats, distinct from declaring what a historical site actually ran.

Back to Cumulus weather software guides

Station software is the program that sits between a logger or console and a published website. The decision is not which logo looks best on an About page. It is whether the program speaks your hardware, writes files you can parse later, and processes templates you can maintain. The historical TNET URL /aboutus/wxsoftware is the place to work that decision as a checklist.

Declaring what a site already ran is a different job. That interpretation metadata lives at /aboutus.wxsoftware. Do not treat the dotted and slash URLs as duplicates. One is a reading guide for existing files. This page is a selection guide before those files exist.

Modern TNET Weather does not sell, rank, or maintain Cumulus, Weather Display, or other station packages, and it does not restore a software-credits editor. Current behavior belongs to the vendors’ documentation.

Historical context

Personal weather operators in the Cumulus era typically chose among a small set of PC programs that could poll a console, keep local climate files, and FTP a site. Cumulus (Steve Loft / Sandaysoft, later Cumulus MX) and Weather Display were the two names that dominated English-language hobby forums. Other packages existed. The About cluster on this host listed software next to projects and tags because operators arriving from a forum needed a place that said how this station published, not only what the sky did this hour.

The slash path /aboutus/wxsoftware reads as a section page: software as a topic under About, including the practical question of what to run. A login alias at /aboutus/wxsoftware&action=login gated edits to license and attribution lines. This article is the selection problem, not the gate.

Three constraints that actually decide

Marketing feature lists are long. Three engineering constraints decide whether a package will still make sense a year later.

Logger and console support

The program can publish only what the hardware sampled and what the PC received. Davis-class integrated stations, Fine Offset / EasyWeather-class loggers, La Crosse families, and Oregon / WMR-class consoles have different native intervals and extra-sensor maps. The Cumulus Wiki About page (last checked 13 August 2026) documents logger support, Fine Offset without EasyWeather, La Crosse, and Davis WMII among Cumulus’s historical capabilities. MX later connected to a wider set of automatic weather stations than Cumulus 1. Weather Display’s reputation in the same era was breadth of hardware drivers.

Match the driver to the device you own, not to a screenshot of a gauge. A program that “supports Davis” may still speak only a subset of VP2 versus Vue versus WeatherLink Live paths. Confirm the exact console or logger on the current vendor list before you commit climate memory to that program’s file format.

Native interval matters scientifically. If the logger updates on the order of tens of seconds, configuring a one-second website refresh does not create a faster instrument. It creates a busier upload of the same sample.

Template model

Templates are how a number becomes a page.

Cumulus processes files that contain web tags of the form <#tag_name …>. Extra web files can be processed at the realtime interval, a standard interval, or (in MX) end of day. The output is a snapshot. MX also documents local HTTP GET/POST bindings and JSON for later site designs (Cumulus Wiki: Webtags, last checked 13 August 2026). Unknown tags become visible error strings, not silent blanks.

Weather Display processes custom tags of the form %temp% in HTML and can emit compact ClientRaw files for scripts that never see a tag (Weather Display Wiki: Using Custom Tags, last checked 13 August 2026). ClientRaw is not a tag file. You cannot drop %temp% into clientraw.txt.

Choose the model you can operate. If you want PHP on the host to branch on units without rebuilding every HTML page, you need a processed include (Cumulus extra files, WD custom text, or an equivalent). If you want a theme that a community already maintains, prefer the stack that theme actually consumes. A Saratoga-style Weather Display template will not process Cumulus tags without an adapter, and the reverse is also true.

File formats you will still have to read

Climate memory is the logs, not the pretty gauges.

Cumulus stores monthly standard logs and a dayfile.txt daily appendix; MX adds databases and interfaces on top of that file tradition. The optional realtime.txt is a current packet, off by default, not a historic series (Cumulus Wiki: realtime.txt). Weather Display keeps its own monthly logs and ClientRaw family. Switching later is a conversion project. MX documents ImportWD for Weather Display monthly logs, with CreateMissing required afterward to build dayfile rows from the new monthly files (Cumulus Wiki: Software; ImportWD, last checked 13 August 2026). That utility exists because the formats are not the same object with a different extension.

Ask, before you start: which file will a later graph, a later researcher, or a later you open? If the answer is “whatever the theme caches,” you do not yet have an archive.

Decision checklist

Work the list in order. Stop when a candidate fails a row you cannot change (hardware, operating system, or an archive you refuse to convert).

  1. Hardware driver. Named console or logger, extra sensors, and native interval, on the current vendor list.
  2. Operating system. Cumulus 1 was a Windows program. MX is documented as a cross-platform continuation (Cumulus MX on GitHub, last checked 13 August 2026). Weather Display’s supported OS is a vendor fact; verify it at purchase or install time.
  3. Template processor. Tags you can type, extra files you can schedule, or JSON/HTTP you can consume. Match the theme you intend to run.
  4. Public compact file. Optional Cumulus realtime.txt versus WD ClientRaw versus neither. Parsers are stack-specific.
  5. Climate files. Monthly logs and daily appendix you can export, back up, and, if needed, convert.
  6. Units and locale. Decimal commas, unit tokens, and rollover time must be first-class settings, not afterthoughts in PHP.
  7. Upload cadence versus link. Frequent realtime uploads on a capped connection produce gaps that look like calm weather.
  8. Network destinations. Weather Underground, CWOP, AWEKAS, WOW, and similar uploads are optional outputs. They do not replace local logs.
  9. Exit path. Is there a documented converter out of this format, not only into it?
  10. License and credits. Donationware, commercial, or open-source changes what you may redistribute in a template. The login-gated credits article covers why those lines were protected. Record the license in the station notebook when you install.

A Zambretti-style or software forecast widget is not a reason to choose a package. That output is a scenario from the station program. For warnings, use NWS or the national service with authority at the site.

What this checklist is not

It is not a score table. TNET does not rank Cumulus against Weather Display. Hardware you already own, the template community you can get help from, and the files you are willing to keep usually dominate any abstract “features” comparison.

It is not a declaration of what the historical TNET Cumulus site ran. If you are reading archived files from this hostname, start on the declaration page and the Cumulus overview.

It is not permission to rehost old PHP packs from this domain. Named historical projects remain on their own URLs as explainers.

Modern relevance

The same three constraints apply when the “website” is a JSON endpoint on the LAN. Logger support, a binding model (tags, SQL, HTTP), and a file or database you can still read in five years are still the decision. Raspberry Pi hosts and always-on mini PCs changed the operating-system row; they did not remove it.

Source identity after you choose is a data-quality problem: which program wrote the series, in which units, at which interval. TNET’s public note on those questions for records used in connection research is data sources, quality controls, and methodology. Observed versus derived labeling is conceptual on how the service works. The Cumulus hub lists neighboring historical pages, including the template-author tag glossary.

Sources