Sign inRegisterCheck connection

Turning On a Cumulus Realtime Snapshot Logger

Enable a Cumulus realtime logger: which fields to append from realtime.txt, how to size the disk budget, and how this differs from log rotation.

Back to Cumulus weather software guides

realtime.txt is overwritten. A logger that keeps history has to be switched on: enable the realtime file in Cumulus, choose an append interval, choose which fields to copy, and budget the disk before the first week fills a Pi. This dotted URL, /projects.realtimelog, is that enablement note. It is not the science of high-frequency accumulation.

Why a homemade log is a derived series, and how sample interval trades against file growth in the abstract, is the slash twin, accumulating realtime.txt snapshots. Closing and naming files so extrema survive is a third URL, already written: rotating realtime weather logs. Do not mix the three jobs in one config screen. Modern TNET Weather does not ship the accumulator and does not maintain Cumulus.

Historical context

The realtime.txt wiki page states the properties that force an extra file into existence: optional, off by default, one line, rebuilt often, not a historic series (last checked 13 August 2026). The TNET scripts catalog lists “Cumulus RealTimeLog Script.” This hostname does not rehost it.

Two enablement places were common. On the web host, PHP plus cron appended each newly uploaded packet. On the logger PC, the Cumulus Wiki Toolbox realtime tab copied the local file on its own interval and could upload the growing realtimelog.txt. Toolbox’s wording is the operational hint: Cumulus may produce the file every 15 seconds; the log may keep every minute. Configure both intervals. They are independent.

JPGraph packs consumed that log. If you are enabling the logger in order to draw graphs, install the series first; JPGraph setup is a later step.

Enable the source file in Cumulus

The logger has nothing to copy until realtime generation is on.

Cumulus 1. Configuration → Internet → Sites/Options: set Realtime interval in seconds; tick Enable Realtime, Enable Realtime FTP, and Realtime.txt FTP. Default is not to create the file. The upload interval equals the creation interval.

Cumulus MX. Enable the realtime timer, set its period in seconds, enable file transfer or local copy, and enable generation of this specific file. Interface labels move between MX releases; the four facts do not: timer on, period set, transfer on, this file on.

Then confirm a file appears where the appender will read it: the Cumulus data/web folder on the logger, or the remote path after FTP. A checker that watches freshness is the stale-file install article, not this page. If the file is missing, stop. You cannot log an absent packet.

Hardware caps the useful interval. The wiki’s Fine Offset / EasyWeather note: many of those loggers update on the order of 48 seconds (solar ~60). A 1-second realtime setting does not create 1-second observations. Set the Cumulus interval to something the station can fill; set the append interval equal or slower, never faster, unless you accept duplicate lines on purpose.

Where to turn the appender on

Toolbox (Windows logger). Setup already needs Cumulus.ini location and, if you use Rules, a processed PHP webtags file. The realtime.txt tab is a separate enable: choose how often to keep a line, independent of Cumulus’s rebuild period. Output is realtimelog.txt in the Cumulus folder. Upload that file with the Upload Files tab if the graph script lives on the host. Toolbox also has prune controls; pruning is rotation. Leave prune off until you have read log rotation and chosen a dated-file policy. Auto-prune inside a single growing file is convenient and easy to mis-set.

PHP on the host. Requires the packet to arrive first. Cron (or Toolbox HTTP Requests, if cron is missing) runs a script that reads the uploaded realtime.txt and appends a line. If FTP lags, you will log late copies of the same packet clock. Collapse duplicates later; do not “fix” it by appending faster.

Do not append from inside the public dashboard PHP on every visitor hit. That couples log growth to traffic and duplicates lines whenever two people load the page.

Do not point the appender at dayfile.txt or at a monthly standard log. Those are vendor files with vendor rotation. The homemade series is a new path. Name it realtimelog.txt or realtimelog-current.txt and leave the vendor files alone.

Which realtime fields to append

You do not need every token. The classic 1.9.4 / early MX layout has 58 fields; MX 3.7.0 added feels-like as field 59; MX 4.3.0 added weekly rain as field 60. Appending the whole line is the honest default: one space-separated copy of whatever Cumulus wrote, plus a server timestamp if you want an independent clock. That preserves columns you did not know you would plot.

If disk is tight, append a subset, but write a header or sidecar that lists the columns in order. A naked stream of numbers is not recoverable when you later forget whether column 4 was humidity or dewpoint.

Minimum useful set for temperature, pressure, and rain plots:

| Keep | Classic field | Why | |---|---|---| | Date, time | 1, 2 | Clock; do not trust file order after a crash | | Outside temperature | 3 | Primary observed scalar | | Humidity, dewpoint | 4, 5 | Often plotted with temperature | | Wind average, gust | 6, 41 | Name which wind if you keep only one | | Rain rate, rain today | 9, 10 | Rate versus total; do not drop the pair | | Pressure | 11 | Independent scalar | | Unit tokens | 14–17 | Without these, the log is not self-describing | | Version, build | 39, 40 | Schema drift detector | | Sensor-contact flag | 51 | Fine Offset lost-contact; quality, not weather |

Optional, only if you will plot them: solar and UV (44–46), apparent / feels-like (55, 59), daylight flag (50).

Usually skip on a tight disk: indoor temperature and humidity, today’s high/low times (already in the dayfile), Beaufort number, and Zambretti forecast number (a scenario token).

If you subset, do not convert units in the appender. Store what Cumulus wrote. Conversion belongs in the graph, labeled as derived. Always append the packet clock. Timezone of both clocks belongs in the sidecar with the column map, Cumulus flavour, and start date.

Disk budget before the first month

Measure, do not guess. Take the byte length of one appended line (source line plus your extra timestamp plus newline). Multiply by appends per day, then by the number of days you will keep in the current file.

Example arithmetic, not a TNET statistic: a 400-byte line at one-minute interval is about 576 KB per day, about 17 MB per month. A one-second append is sixty times that. Measure your own line.

Budget three numbers: append interval, bytes per line, and days in the current file before rotation. If the product exceeds the free space you will give this series, slow the append or shorten the current-file window. Logging locally and uploading a growing log every minute is a different bandwidth bill from uploading a 1 KB realtime.txt.

This page stops at choosing an interval and a budget. When the current file should close, what to name the closed file, and how not to delete the afternoon that held the year’s gust, go to rotation. Enable rotation before the first full month.

Practical checklist

  1. Enable realtime generation and upload; confirm realtime.txt appears.
  2. Set Cumulus interval to the hardware period; set append interval equal or slower.
  3. Turn on Toolbox’s realtime tab or host cron—not both writing the same path, and not the public page view.
  4. Append the full line, or a documented subset that always includes clocks and unit tokens.
  5. Write a sidecar: columns, units, timezone, Cumulus version, start date.
  6. Measure bytes per line and compute a monthly size; leave headroom on the disk.
  7. Configure dated rotation as a separate job before month-end.
  8. Keep live realtime.txt as the current packet. Banners and heartbeats should not read the growing log.

Modern relevance

MX JSON and HTTP interfaces can reduce the need to scrape a one-line text file, but any overwritten current-conditions document still needs an explicit enable, a field list, and a disk budget if you want a series the vendor logs do not provide.

Building a series from overwritten snapshots is a data-source problem: cadence, completeness, and identity of the derived file. TNET’s data sources, quality controls, and methodology note is the modern discussion of those questions for records used in connection research. This page does not describe TNET internals.

Related pages: the slash accumulation article, log rotation, the projects map, and the Cumulus legacy hub.

Sources