Sign inRegisterCheck connection

The Cumulus-Host RSS Endpoint: What Consumers Should Require

Consumers of cumulus.tnetweather.com/rss.php should require observation time, units, and station coordinates. This is not tnetweather.com/index.rss.

Back to Cumulus weather software guides

/rss.php on cumulus.tnetweather.com is a feed URL: the document a program actually fetches. This article is the consumer-side contract for that Cumulus-host endpoint. It states what must be present before the XML is treated as a personal-weather-station observation, and how that requirement set differs from a generic blog feed.

It is not the generator. How a project should build RSS from realtime.txt, web tags, or Cumulus XML is the Cumulus RSS project. It is not tnetweather.com’s /index.rss (feed-file and HTTP semantics on the main host) and not /RSS/rss-feed.php (station RSS as a general observation contract). Those URLs live on a different host and answer different questions. Do not paste their arguments here under a Cumulus title.

The original PHP that printed the feed is not rehosted. The path stays as documentation of the served object.

Historical context

The Cumulus software family publishes files; community PHP often exposed a stable /rss.php so aggregators did not have to guess feed.xml. On this host the URL sat beside other Cumulus projects: WAP pages, wiki experiments, METAR fetchers. A subscriber who added https://cumulus.tnetweather.com/rss.php expected current conditions from a Cumulus station workflow, not a news magazine and not an official aviation feed.

Cumulus inputs for such a feed are documented by the maintainers: optional realtime.txt, web tags, extra processed files. A consumer cannot see those files from the RSS URL alone. The feed must carry the facts that the files knew.

What this endpoint is

Treat /rss.php as a Cumulus-flavored status document that happens to use RSS 2.0 as the envelope (RSS 2.0). Typical honest behavior:

  • one channel that names the station and the site;
  • one item (or a short stack of snapshots) representing current or recent Cumulus observations;
  • values that originated in Cumulus unit tokens, not in a webmaster’s memory.

If the body is HTML, a domain-expiry notice, or a PHP warning, it is not a feed. If the body is a gadget-sized fragment with no channel, it is the gadget problem, not this one.

Required observation facts

RSS 2.0 makes most item fields optional. Weather cannot. Before you ingest this endpoint into a map, a comparison table, or a research worksheet, require the following. If any item is missing, the document is a brochure.

1. A valid time (pubDate and friends)

Item pubDate must be the observation time, in RSS date language with a zone or numeric offset. Channel lastBuildDate is when /rss.php ran. Those clocks are allowed to differ by seconds; they are not allowed to be interchangeable.

Cumulus file clocks are often local civil time with a locale date order (dd/mm/yy versus mm/dd/yy in realtime.txt field 1). If the endpoint emits Tue, 13 Aug 2026 14:54:00 with no zone, you cannot compare it to a METAR, which is referenced to UTC in the official code (NWS METAR overview; WMO FM-15, below). Reject or flag zone-less dates.

If pubDate is older than the station’s stated upload interval (or older than a documented maximum gap), the item is historical, even though the URL still says “rss.” Do not substitute the HTTP Date header for the observation time.

2. Units in the description or in elements

A Cumulus packet without unit tokens is not complete. realtime.txt carries wind, temperature, pressure, and rain units as explicit fields. A feed that says <description>Wind 12</description> has thrown that information away.

Acceptable patterns:

  • plain-text description that includes the unit next to each number (21.4 C, 1016 hPa, 3.2 mm);
  • namespaced elements or documented extra tags that carry unit attributes;
  • a documented convention published next to the feed (still a contract; still must be fetchable).

Unacceptable: units only on the HTML homepage; units assumed from “the station is in the UK”; converting to SI in the consumer because it “looks like metric.”

3. Station latitude and longitude

Temperature without a point is not a station observation you can place on a map. Classic realtime.txt does not include lat/lon. The endpoint must add them from Cumulus configuration or from a documented station metadata file. Decimal degrees with an explicit sign, and a datum if known (typically WGS 84 for a GPS siting), are the minimum.

If coordinates are absent, you may still display the feed as a named site. You may not treat it as a located observation for spatial comparison with a METAR or with another PWS.

4. Identity and overwrite semantics

Channel title should name the station. Item guid should tell you whether today’s temperature update is the same item overwritten or a new event. Cumulus current-conditions feeds almost always overwrite. A consumer that treats every poll as a new climate sample is manufacturing a time series at the poll interval.

5. Observed versus derived versus official

Cumulus can emit wind chill, humidex, apparent temperature, and a Zambretti-style forecast number (realtime.txt field list). Those are derived by station software. Official aviation observations are METAR/SPECI; official forecasts include TAF. If /rss.php includes a METAR string, demand provenance: was it fetched from an official source or composed locally? A locally composed string is not an NWS/ICAO METAR (projects.metar).

How this host differs from the main-site feeds

| Question | This page (cumulus.tnetweather.com/rss.php) | Main-site RSS articles | |---|---|---| | Input assumption | Cumulus files (realtime.txt, web tags, extra XML) | Generic PWS / WD-era feed practice | | Consumer demand | Units from Cumulus tokens; lat/lon added; Cumulus version if present | General contract and HTTP file semantics | | Neighbor tools | Gadget payload, METAR fetch, Cumulus XML | /index.rss media type and caching |

Use the table as a routing rule, not as a claim that one host’s XML is “better.” Both can be stale, unescaped, or unit-free. The difference is which software family the URL advertised.

Practical consumer checklist

  1. Fetch the URL as XML. If it is not well-formed, stop. Do not regex temperatures out of a broken document.
  2. Read channel identity, item guid, pubDate, and lastBuildDate.
  3. Parse numbers only where units are explicit.
  4. Require lat/lon before any spatial join (including “nearest METAR”).
  5. Record Cumulus version/build if the description includes it; field lists change.
  6. Honor a ttl or cache header if present; do not poll every few seconds. realtime.txt can be small; RSS is not a reason to hammer the host.
  7. Keep a copy of the raw XML with the fetch time. Re-decoding later without the bytes is not reproducible.

Those checks are source quality control. TNET’s public statement of freshness, units, and provenance for weather records used in connection research is data sources, quality controls, and methodology. Conceptual observed-versus-modelled labeling is on how the service works. Neither page is a Cumulus RSS parser.

The Cumulus hub lists the related historical projects. For warnings and official observations, use NWS or the aviation products documented by the Aviation Weather Center.

Sources