Sign inRegisterCheck connection

Weather Display Web Tags as a Data-Binding Language

How Weather Display custom tags bind observation fields into HTML chrome, and why those template tokens go stale when software versions change.

Back to Weather Display software guides

Weather Display's custom web tags are a data-binding language. You write HTML chrome—headings, tables, units, language—and you leave tokens such as %temp%, %baro%, and %time% where the current observation belongs. The application replaces those tokens, writes a finished page, and uploads it. The recovered /wdmml.php page was a station homepage, not a tag manual. This article does not clone that Mesa front page. It explains the markup contract that made such pages possible, and why the contract ages.

Call the token language what the URL preserved: Weather Display markup, or MML in this cluster. Official Weather Display documentation calls the same mechanism custom tags or customised web pages. The scientific object is the binding: observation fields on one side, HTML chrome on the other.

Chrome versus fields

A published weather page mixes two kinds of text.

Chrome is everything that would still make sense if the station were offline: the site title, navigation, unit labels you chose, explanatory sentences, CSS classes, and static maps. Chrome is authored by the operator.

Fields are values that must come from the current observation, from today's running extremes, or from a clearly dated historical summary. Temperature, humidity, pressure, wind, rain, and the observation time are fields. So are derived quantities Weather Display computes from those readings, such as dew point or heat index, when you insert the corresponding tag.

The point of a tag language is to stop operators from typing the temperature into the HTML by hand. The risk is the opposite mistake: putting chrome in a field, or putting a field in chrome. If the word "Fahrenheit" is hardcoded beside %temp% while Weather Display is emitting Celsius, the page is wrong even when the number is right. If the observation time is only in a footer image, parsers and archives will lose it.

Weather Display's own help describes the workflow: create a template (commonly wxlocal.html in the web files folder) that contains the tags; Weather Display replaces the tags with values in the units you configured, writes an output file such as wx.html, and can upload it, leaving the template intact. That is compile-and-publish, not a live query from the browser. The finished page is as fresh as the last successful processing and FTP cycle.

Tokens are names, not sensors

A tag such as %temp% is a name in Weather Display's vocabulary. It is not a guarantee of a particular sensor model, height, or averaging period. The same token can represent a Davis-class outside temperature or another logger's channel, depending on how the station is configured. %weathercond% is a Weather Display interpretation of the station data. %weatherreport% is documented as current conditions from a selected METAR—an official or third-party observation, not the backyard instrument. %metar/report=% inserts a downloaded METAR or warning file. Those last two are not the station's observed packet, even though they appear inside the same HTML table.

Forecast-like strings belong in a forecast panel. Historical month-to-date tags, which Weather Display documents as coming from the daily averages/extremes page when that report is enabled, belong in a historical panel. Mixing them in one "current conditions" cell without labels is how a homepage becomes scientifically unreadable.

The ClientRaw parser describes the numeric files WDLive and AJAX dashboards often read instead of HTML. Tags and ClientRaw are two bindings to overlapping fields. A page can use both: tags for the first paint, clientraw.txt for later updates. They still need the same unit and time discipline.

Why tokens go stale when WD versions change

Data-binding languages fail in versioned software for ordinary reasons.

New tokens appear. A later Weather Display build adds soil, lightning, or extra temperature tags. Old templates ignore them, which is safe.

Old tokens change meaning. A tag that once emitted inHg may follow a new default, or a wind tag may switch from mean to gust in a rebuilt template copied from a forum. The HTML still compiles. The comparison to last year's saved pages does not.

Tokens disappear or are renamed. A template that still contains a retired tag may print the token literally, print a blank, or print a neighboring field if the replacement engine becomes less strict. Any of those outcomes is a silent schema change.

Units live outside the token. Custom tags emit "the units you have chosen." The template's chrome must match that choice. A bilingual page that hardcodes "mph" next to a metric wind tag is a unit error, not a translation error.

Language and HTML reports drift. Tags that pull from English daily-report phrases will not match a German or Spanish Weather Display output. That is the same class of failure as HTML scrapers that search for "Average temperature."

The operator's defense is the same as in any binding language: version the template with the Weather Display build, keep a list of tokens actually used, and treat a WD upgrade as a schema migration. Weather Display ships tag lists with the product (community documentation points to tagslist.txt and the long custom-tag list). Diff the list when you upgrade. Do not assume a homepage that "still looks fine" still maps fields correctly.

Include files, fragments, and repeated chrome

Personal weather sites often split chrome into included headers and footers so the tag template only owns the observation table. That is good hygiene: one place to change navigation, many pages to receive new observations. It is also how a stale include can stamp yesterday's menu, or a visitor counter, onto an otherwise current table.

The historical TNET notebooks treated included-file websites as a maintenance pattern. The included-file notebook is the neighboring artifact for that chrome problem. Keep observation tokens out of the include that is cached as a static site-wide banner, or the banner will freeze a temperature for every page.

For a near-real-time console, the binding is the ClientRaw file, not the HTML tag. For a compact map module, the binding is a labeled fragment. Those are WDLive consoles and station boxes. Markup does not replace either. It is the chrome around them.

Observed, forecast, and historical in the template

A homepage template is where the three evidence types collide.

  • Observed: %temp%, %avgspd%, %dayrn%, %time% and their relatives, with units and a visible observation time.
  • Derived: heat index, humidex, apparent temperature, "weather condition" strings computed from station data. Label them.
  • Forecast: METAR-based remarks, downloaded warnings, or WD forecast text. These are not backyard observations. Official warnings belong to the issuing service, not to the template.
  • Historical: month-to-date averages and extremes, all-time records, yesterday's summaries. Date them.

Do not use a template to imply that TNET or Weather Display is an official warning channel. For hazards, the page should point at the relevant national service.

Practical rules for a maintainable template

  1. Put every observation in a tag; put every unit in chrome that you can grep.
  2. Print observation time next to the values, not only in the browser tab.
  3. Separate observed, derived, forecast, and historical blocks in the HTML.
  4. Record the Weather Display version in a comment or a %wdversion% tag so a later reader knows which token dictionary applied.
  5. After a WD upgrade, render the template to a file and diff it against a known-good snapshot; look for leftover %...% tokens and unit mismatches.
  6. Do not scrape your own HTML if ClientRaw or a tag-to-PHP export can carry the same fields with less fragility.
  7. Keep the Mesa-style narrative—if you still want a station story—in chrome that does not pretend to be a live feed.

The Weather Display category hub is the index for this publishing family. Custom tags are the HTML binding. ClientRaw is the numeric binding. Neither is a live Mesa homepage.

Sources