Sign inRegisterCheck connection

Weather Display ClientRaw Parser

The WD ClientRaw Parser treated a compact observation packet as a diagnostic instrument: named fields, stale uploads, unit confusion, and remote-fetch risks.

Back to Weather Display software guides

A ClientRaw file is a compact, frequently updated observation packet: one line of space-separated fields that Weather Display writes so a website can show current conditions without republishing a full HTML page. The historical TNET Weather ClientRaw Parser existed to make that packet inspectable. It mapped positions to names, showed the values a remote site was actually serving, and thereby told an operator whether the publishing system was alive, stale, or confused about units.

This article keeps that diagnostic purpose. It does not rebuild the live form, does not fetch other people's files, and does not log visitor IP addresses. The recognizable name stays in the title because other sites, including a UCL CASA weather-data note, cited the parser by that name.

Historical context

Weather Display's real-time FTP feature uploads clientraw.txt plus companion files (clientrawextra.txt, clientrawdaily.txt, clientrawhour.txt) into a directory that AJAX templates and Weather Display Live already knew how to read. The files are efficient and unforgiving. There are no column headers. A shifted field, a truncated upload, or a Fahrenheit station read as Celsius all look like weather.

The historical tool at /wd-parser.php accepted a URL to the directory that contained those files, retrieved them, and displayed named fields plus some calculated unit conversions. Construction credits on the old page named Kevin Reed's TNET work, Eric Frisbee's testing and subroutine revisions, and Brian Hamilton as the author of Weather Display who kept the data files evolving. After the original public instance went away, Ken True documented a continuation at Saratoga Weather's WD parser (last checked 13 August 2026). That is the maintained diagnostic to use if you need an interactive decoder today. This URL remains as the historical address and as an explanation of why the instrument mattered.

In 2013, UCL's Centre for Advanced Spatial Analysis described an open London weather feed that published the same four ClientRaw files from a Davis Vantage Pro 2 via Weather Display, and pointed readers at a ClientRaw Parser dump with field labels. That is the backlink this page is careful to remain worthy of: a named decoder for a public observation packet, not a parked form.

ClientRaw as a packet, not a database

Call the file what it is. ClientRaw is a current-state packet. It is observed (and software-derived) weather at the time Weather Display wrote the line. It is not a climate archive, not a forecast, and not a quality-controlled official observation.

Properties that follow from that design:

  • Fixed field order. Consumers index by position. Official structure is documented in Weather Display's clientrawdescription.txt on the PC that runs the software, and community notebooks historically mirrored a dated snapshot of those positions. Positions change when the vendor adds fields; a parser is version-sensitive.
  • High cadence. Intervals of a few seconds to a minute are common. The scientific value is freshness. The operational cost is bandwidth and the chance of reading a file during overwrite.
  • Units inside the software, not always inside the field. Some fields are dimensionless or carry an implied unit from Weather Display's setup. A decoder that prints alternate units is performing a derived conversion. Those conversions are interpretations. They are useful for catching "this station is in °F" mistakes; they are not extra sensors.
  • Four files, four time spans. The main file is the live packet. Extra, daily, and hour files extend the same idea to additional fields and longer windows. A complete diagnostic reads the set, because a site can upload clientraw.txt faithfully while leaving clientrawdaily.txt stale.

Weather Display Live and many AJAX templates consume this packet directly. If the packet is wrong, every live widget is wrong in the same way. That is why a parser that names fields is more than a curiosity. It is a bench test for the publishing system described in the Weather Display station-to-web article.

Why a named-field parser is a diagnostic instrument

Operators did not need a parser to see that "it looks like 72 degrees." They needed a parser to answer questions that a pretty dashboard conceals.

Is the file there? A blank decode, a timeout, or an HTTP error means the upload path failed. The station may still be logging locally. The website is not publishing.

Is the file complete? A truncated line shifts every subsequent field. Named output makes that visible: wind direction becomes a humidity-shaped number, a timestamp becomes a leftover token, a version footer disappears.

Is the file stale? The packet includes time fields. If they stop advancing while the rest of the page still shows last values, the upload cadence has died. Frozen weather is a publishing failure, not a meteorological event.

Are the units the units you think? Printing the same temperature as Celsius and Fahrenheit side by side is a cheap consistency check. If the "°C" column is implausible for the season and the "°F" column looks like a local afternoon, the station is in Fahrenheit and a downstream script assumed SI.

Did the vendor add fields? When Weather Display extends the packet, old parsers either ignore the tail or misalign it. A decoder that also prints field numbers lets the operator compare against the description file for their build.

Are placeholder values leaking? Missing extra sensors often appear as sentinel numbers rather than as "n/a." A named dump is where those sentinels become obvious.

None of these checks requires storing visitor IPs. They require one complete read of files the operator already published.

Conceptual inputs and outputs

The historical web tool can be described as a function without reconstructing it.

Inputs (conceptual):

  • A base URL pointing at a directory, not at a filename, because four files share a location.
  • An expectation that the path uses http:// or https:// and that the files are world-readable.
  • A Weather Display build range the field map was written against. The old page cited version 10.37L build 20 or higher as the documentation target; that is a historical version pin, not a claim about today's WD release.

Process (conceptual):

  • Retrieve each of the four files.
  • Split on spaces.
  • Attach names and types from a field map.
  • Optionally compute alternate units for temperature, wind, rain, and pressure.

Outputs (conceptual):

  • A table of field number, label, type, raw contents, and converted contents.
  • Visible failures: missing file, empty body, timeout, or a line that does not end with a recognizable version token.

Non-outputs:

  • No official quality flag from NOAA or a national meteorological service.
  • No forecast.
  • No claim that the station's siting is adequate.
  • No archive of other people's weather, and no visitor host/IP log on this preserved page.

A local parser that reads files already on the same host is the safer sibling of this design. The notebook that historically showed how to split clientraw.txt in PHP was that sibling: same packet, no remote fetch.

Remote URL-fetch parsers: timeouts and security

The convenience of "paste your site URL" is exactly the risk.

Timeouts. If the target host is slow, firewalled, or serving a hanging FTP-in-progress, a naive fetch blocks a PHP worker. The historical page already warned that a bad URL could pause for a long time and then error or return blanks. That is not a cosmetic UX issue. On shared hosting it is a denial-of-service against the parser's own site.

Server-side request forgery. A public form that fetches arbitrary URLs can be pointed at internal addresses, cloud metadata endpoints, or third-party sites that never agreed to be scraped by your server. OWASP documents this pattern. A diagnostic for PWS operators should restrict targets, impose short timeouts, and refuse to follow arbitrary redirects.

Attribution leakage. The fetch originates from the parser's server, not from the visitor's browser. Target logs show the parser host. Combined with "all connections are logged" copy, the old design collected both sides of a conversation that most operators did not need.

Legal and ethical scraping. Even when a ClientRaw file is intentionally public, repeatedly pulling someone else's live packet from a central form is a different activity from the operator decoding their own files. CASA's London feed was an explicit open publication. Most PWS directories are not an invitation to build a third-party ingest on top of a help form.

This preserved article therefore explains the instrument and sends people who need a working decoder to Saratoga's page, which is operated by that site under its own rules. TNET does not reimplement the remote fetch.

Practical checklist for operators

  1. Confirm the four filenames in the same directory the dashboard uses. Pointing at the site root when files live in /wdisplay/ produces empty diagnostics that look like parser bugs.
  2. Read the version footer in clientraw.txt and compare it to your Weather Display build and to clientrawdescription.txt on the PC.
  3. Watch the time fields for several upload cycles. If widgets move but the packet time does not, you are looking at browser animation, not new observations.
  4. Check units once per season by comparing the packet to the console on the hardware. Derived conversions in a parser will not save a template that hard-coded the wrong unit string.
  5. Prefer atomic rename on upload so the parser never sees a half-written line.
  6. Run a local decode first (files on the same host). Only then consider a remote decoder, and only for your own URL.
  7. Do not paste recovered parser PHP from archives of unknown license onto a public host.
  8. Treat lightning, storm, and advisory fields as station or include data, not as National Weather Service warnings.

Modern relevance

Compact current-conditions files have not disappeared. Cumulus realtime.txt, WeeWX JSON loops, and vendor cloud APIs are the same idea with different field maps. The diagnostic questions transfer: is the packet present, complete, fresh, and in the units the consumer assumes?

What should not transfer is the 2000s implementation: an open URL form, IP capture as a security theater, and an unmaintained field map. Field maps belong next to the software version that produced them. Interactive decoding belongs on a site that still maintains it. Saratoga's parser is the living descendant of this URL's function.

UCL CASA's use of the named parser illustrates the scholarly pattern worth preserving: when a research group publishes a live observation feed, they also need a way for readers to see the schema. A labeled dump of ClientRaw is that schema in operational form. This article keeps the name and the method; it does not keep the unsafe form.

TNET research bridge

A ClientRaw file is a public observation record with a clock, a unit system, and a vendor schema. Deciding whether such a record is usable is a data-source problem: freshness, completeness, and provenance come before any later modeling. TNET's public note on data sources, quality controls, and methodology is the matching modern discussion for weather and network records used in connection research.

See also the Weather Display hub, the publishing-system article, and the historical ClientRaw field notebook for the dated position list that a parser consumes.

Sources