Sign inRegisterCheck connection

AWEKAS as a European PWS Network Upload Path

AWEKAS ingests personal weather stations via identity, timestamp, and units. TNET does not operate AWEKAS; this page explains the Cumulus upload contract.

Back to Cumulus weather software guides

A personal weather station can publish a website and still be invisible to a regional map until it speaks a network’s ingest format. AWEKAS is one such network: a European-origin system that collects PWS observations for a shared map and station pages. The historical path /awekas.php on the Cumulus host was an upload-side helper—producing or documenting the file AWEKAS would fetch. This article is about what a network ingest requires: station identity, a timestamp, and explicit units.

TNET Weather does not operate AWEKAS, does not issue AWEKAS station IDs, and does not rehost an upload script. Current network behavior is defined by AWEKAS, not by this preserved URL.

Historical context

AWEKAS (Automatisches WEtterKArten System—automatic weather map system) began in Austria. The project’s public site describes it as a global network of personal weather stations (AWEKAS, last checked 13 August 2026). The Cumulus Wiki AWEKAS page documents how legacy Cumulus operators produced a small HTML/text file that AWEKAS could retrieve, using web tags and an extra processed file named in the Weather Link–style template family.

On the historical TNET Cumulus host, /awekas.php sat in that workflow: emit or validate a file whose lines matched the ingest template so a registered AWEKAS account could pull the station. Community forum history shows operators wiring Cumulus extra files, Weather Display, and homemade PHP to the same line layout. Those implementations are not restored here.

AWEKAS also documents other transfer modes (including software-specific automatic upload and a “Direct Link” mode without a text file) in its help materials (AWEKAS help: data transfer, last checked 13 August 2026). Operators should follow current AWEKAS instructions for the software they actually run. This page explains the ingest contract, not a live setup wizard.

What a network ingest is

A website is a publication the operator controls. A network ingest is a second publication with a foreign schema. The network must be able to:

  1. know which station produced the values (an ID issued at registration, not a backyard nickname alone);
  2. know when the values were valid;
  3. know the units, because PWS software is not bound to SI;
  4. reject or flag a file that is stale, incomplete, or still full of unprocessed <#tags>.

Those four needs are why AWEKAS-style templates are picky about line order and about unit lines near the end of the file. They are the same needs as Cumulus XML or realtime.txt, expressed as a pull-from-your-website protocol rather than as a named-element dump.

TNET is not AWEKAS. Mapping a station into AWEKAS does not make the observations official METAR, and it does not enroll them in NWS or WMO circuits. It enrolls them in AWEKAS’s map under AWEKAS’s quality rules.

Identity

Registration creates the join between a person, a location, and a pull URL (or a direct-upload credential). The ingest file itself historically did not carry a cryptographic identity; the network trusted the registered URL. That is a location-of-file identity: whoever can write that path can change the observations.

Practical consequences:

  • Put the ingest file in a boring, dedicated path. Do not reuse a general PHP debugger.
  • If the file is generated by Cumulus extra-web processing, the PC that runs Cumulus is the writer. If it is generated by PHP from realtime.txt, the web host is the writer. Those are different trust boundaries.
  • Station coordinates belong in the AWEKAS account metadata. A temperature without a registered point cannot be mapped. Do not assume the network will scrape your HTML for lat/lon.

AWEKAS membership and current account rules are defined on their site. This article does not recreate a signup form.

Timestamp

The documented Cumulus template for the Weather Link–style file includes a time line (HH:MM) and a date line (the wiki example uses day/month/year tags) (Cumulus Wiki: AWEKAS). That is the observation time as Cumulus knows it—typically station local civil time, not UTC.

A network that maps many countries must either require a timezone in the account metadata or interpret the date in a documented local convention. Ambiguous dates (05/09/09 as 5 September versus 9 May) are a real failure mode; the wiki’s preference for a day.month.year style exists for that reason.

If Cumulus stops uploading, the file remains the last successful process. A network that keeps showing that temperature without a freshness check is publishing a stale observation. Operators should confirm that AWEKAS’s current ingest still treats old files as old. On the station side, the honest local check is the same as for any extra file: file mtime versus the web-update interval; leftover web tags mean Process was not ticked.

Units

The documented template does not assume SI. Separate lines carry the unit for temperature, humidity, wind, pressure, rain, solar, rain rate, and UV. Values on earlier lines are meaningless until those unit lines are read. That is the scientifically load-bearing part of the format.

Cumulus web tags such as <#tempunit> and <#windunit> exist so the file can follow the operator’s Cumulus configuration (Webtags). A homemade PHP that always writes C and km/hr while Cumulus is set to Fahrenheit and mph will pass a naive line-count check and still corrupt the map.

Do not convert units in the upload file unless AWEKAS’s current specification says to. Conversion belongs in a tested migrator (convert1) or in the network, not as an undocumented side effect of /awekas.php.

What the Cumulus extra-file path is doing

The wiki’s historical recipe is conceptually:

  • a small template containing AWEKAS’s start token, web tags for the required values, placeholders where the template demands dummies, and a template-version footer;
  • Cumulus extra-file processing (Process, then upload) so tags become numbers;
  • an AWEKAS account that is told the public URL of the processed file.

That is a pull ingest: the network fetches your host. Bandwidth and availability of the website become part of the observation pipeline. If the host is down, the network cannot pull. Direct-upload modes invert that: the station software pushes. Either way, the payload still needs ID (account), time, and units.

This page does not reproduce a full line-by-line template for copy-paste. Templates change; AWEKAS’s forum and help pages are the authority for the current layout (AWEKAS). The Cumulus wiki page should be treated as historical operator documentation, verified against AWEKAS before use (last checked 13 August 2026).

What AWEKAS is not

  • Not a METAR source. Official aviation observations remain NWS/ICAO products (projects.metar).
  • Not a TNET service. Modern TNET Weather does not ingest AWEKAS on behalf of operators and does not claim their station counts, uptime, or map as TNET data.
  • Not a siting certificate. A mapped station can still be a poor exposure.
  • Not a warning authority. For hazards, use the national service with authority at the site (NWS in the United States).

Practical checklist

  1. Read current AWEKAS ingest instructions for your station software, not only a 2000s wiki snapshot.
  2. Confirm the processed file shows numbers, not <#temp>.
  3. Confirm date, time, and unit lines match the Cumulus configuration you actually run.
  4. Register coordinates and timezone in the network account as AWEKAS requires.
  5. After a clock change or a unit change in Cumulus, re-check the first mapped values against the station HTML.
  6. If you leave the network, remove or stop generating the ingest file so a stale path is not pulled forever.

Network ingest is a provenance problem: who identified the station, when the sample was valid, and in which units. TNET’s public discussion of source identity and freshness for weather records used in connection research is data sources, quality controls, and methodology. Observed-versus-derived labeling in that research is conceptual on how the service works. Historical Cumulus projects remain listed on the Cumulus hub.

Sources