Skip to content

Release v7.2

Choose a tag to compare

View all tags
@chaunceygardiner chaunceygardiner released this 07 Sep 03:33
· 19 commits to master since this release
v7.2
3430188

weewx-loopdata 7.2

A feature release. Drop-in upgrade: install over 7.1, no configuration
changes, nothing to edit by hand. Nothing changes on your station until
you declare one of the new fields.

Every period LoopData serves — hour, day, week, month, year,
rainyear, alltime — is a stretch of time, and WeeWX report tags have
always been able to ask when that stretch begins and ends. LoopData
refused all four of those tags. It no longer does, so a live page can
work out for itself when a period started rather than being told once, at
report time, by an answer that goes stale the moment midnight passes.

What's new

  • A period's own boundaries are now fields. start, end, length
    and dateTime — the same four properties $week.start and its
    siblings give a Cheetah template — can be declared like any other
    field. Declare week.start.raw and every packet carries the instant
    this week began. They take no aggregate, since they are properties of
    the period rather than of an observation, and they accept the usual
    unit override, round(n) and format specs. start, end and
    dateTime are instants and render through the period's time format;
    length is a duration and renders as one, so
    week.length.long_form() reads 7 days, 0 hours, 0 minutes. The
    rolling periods (1m–1440m, 1h–24h) and trend have no fixed
    span and do not carry them.
  • They cost no accumulator. A period's span is a property of the
    calendar, not of anything the period accumulated, so it is computed
    from the packet's own time. A report may declare week.start.raw and
    no other week field and still get it on every packet.
  • The question they exist to answer: did this period begin today? On
    the first day of a week, this week's high is just today's high wearing
    a badge, and a page that says "WEEK HIGH" there is saying nothing.
    Comparing week.start.raw with day.start.raw settles it, and keeps
    settling it correctly across midnight — which a value baked into the
    page when the report ran cannot do. A kiosk page left up for a
    fortnight crosses a great many midnights.
  • alltime spans the archive's first record to the packet in hand,
    which is what the $alltime report tag spans. alltime.end and
    alltime.length therefore advance with every packet, where the
    calendar periods' stay put until the period rolls over. On a
    brand-new station — WeeWX and LoopData installed together — the archive
    is still empty when LoopData starts, so there is no first record to
    read; those four fields then appear with the station's first archive
    record, five minutes in by default, and LoopData takes the value from
    the record itself rather than going back to the database. Everything
    else, alltime aggregates included, works from the first packet.
  • One field form went away. Because a period's dateTime is now its
    start, <period>.dateTime with an aggregate on it — day.dateTime.max
    and its kin — is no longer recognized, and is logged as an unrecognized
    field. That form was never a report tag: $day.dateTime has always
    been the day's start and never the dateTime observation, so a
    declaration is unlikely to name it. current.dateTime.raw, which live
    pages do use for the packet's timestamp, is untouched.

Requirements

  • WeeWX 4.6 or later
  • Python 3.7 or later
  • No third-party Python packages required
  • Satellite almanac fields (almanac.iss.next_pass... and friends) need
    weewx-skyfield
    registered as the almanac; every other almanac field works with
    PyEphem or WeeWX's built-in almanac, as always

Installing/upgrading

Download weewx-loopdata.zip
and install it over your existing copy, then restart weewxd:

weectl extension install weewx-loopdata.zip
Assets 3
Loading