Announcing weewx-skyfield (a modern almanac), weewx-loopdata (live report tags), and weewx-celestial (a live sky display)

[John Kline]

Hi all,

I'd like to (belatedly, in one case) introduce three extensions that work alone or together: weewx-skyfield, a drop-in Skyfield replacement for WeeWX's built-in almanac; weewx-loopdata, which updates report tags on every loop packet; and weewx-celestial, a live celestial page that shows what the two can do together. Everything below is running right now at paloaltoweather.com, so you can click through and see it live.

weewx-skyfield — a drop-in replacement for the built-in almanac

https://github.com/chaunceygardiner/weewx-skyfield

WeeWX's almanac tags are computed by PyEphem, a library its own author has deprecated in favor of his successor library, Skyfield. weewx-skyfield registers a Skyfield almanac ahead of the built-in one, so on WeeWX 5.2 or later every almanac tag your reports already use — $almanac.sunrise, $almanac.moon.transit, $almanac(horizon=-6).sun(use_center=1).rise, $almanac.next_full_moon, $almanac.rigel.mag — is computed with Skyfield and JPL's DE421 ephemeris. It really is drop-in: no skin changes, no configuration. Install it, restart WeeWX, and the Seasons skin's Celestial page (and everything else) is computed by Skyfield.

Installation is three steps:

1. pip install 'skyfield>=1.47' into your WeeWX virtual environment (or sudo apt install python3-skyfield on a package install — Debian 13 or later; bookworm's 1.45 is too old).
2. weectl extension install weewx-skyfield.zip (download from the release page).
3. Restart WeeWX.

Compatibility was a first-class goal. The extension natively computes everything the built-in almanac serves plus a lot it doesn't (constellations, eclipses visible from your station, all 412 IAU-named stars — or all 118,218 Hipparcos stars if you drop in the full catalog). The test suite includes two permanent audits: one proves that with PyEphem installed, every tag the built-in almanac could evaluate still evaluates (anything weewx-skyfield doesn't compute falls through to PyEphem); the other proves that on a system with no PyEphem at all, every tag used by WeeWX's standard skins — and much more — works with Skyfield alone.

So was performance. The DE421 ephemeris ships in the extension zip and is read fully into memory at startup — nothing is downloaded at runtime, and the page keeps working offline. Results are cached aggressively, so the expensive rise/set searches are paid once, not every report cycle; it runs comfortably on a Raspberry Pi.

Why DE421 and not the newer, bigger DE440? Because the extra accuracy disappears the moment the light hits the atmosphere. DE440's corrections amount to well under an arcsecond as seen from Earth for every body this almanac serves — an arcsecond moves a rise or set time by about a fifteenth of a second — while atmospheric refraction at the horizon, which no ephemeris can predict, makes every real rise and set uncertain by tens of seconds. At the precision reports display, the two are indistinguishable, and DE421 is half the size.

Why are there two Skyfield almanacs for WeeWX? You may know weewx-skyfield-almanac, Johanna Roedenbeck's independent extension that also replaces the built-in almanac with Skyfield. The two grew up independently with different design philosophies, and I think the choice is genuinely useful. weewx-skyfield-almanac is configurable and self-updating: you choose the ephemerides and catalogs, and it downloads and refreshes them at runtime. weewx-skyfield is self-contained: everything it needs is in the zip, nothing is ever fetched at runtime, and the emphasis is on strict compatibility with the built-in almanac (audited by the test suite) and on report-cycle speed. If you want to pick your own ephemeris, use weewx-skyfield-almanac; if you want batteries included and PyEphem-parity guarantees, use weewx-skyfield. Install one or the other, not both.

The Sky page. Installing weewx-skyfield also installs a one-page, planetarium-style report, computed for your station's location:

A sky dome of everything above your horizon right now, rise & set ribbons over twilight bands, today's sun path, the solar year, the current lunation, an orrery, an analemma, eclipse and equinox countdowns, and a full almanac table. It's self-contained HTML and inline SVG — no JavaScript libraries, no web fonts, nothing fetched at run time.

And if you like any single panel, you can have it: every panel is rendered by a standard search-list extension ($sky_page.*) and can be dropped into your own skin's template — add one line to skin.conf, copy the CSS classes you need, done. The bundled template shows every panel in use. A few examples:

weewx-loopdata — make the almanac (and everything else) come alive

https://github.com/chaunceygardiner/weewx-loopdata

A WeeWX report is a snapshot: it shows the values from the last archive interval until the next page reload. LoopData changes that. LoopData itself isn't new — it has been quietly keeping pages alive for years — but recent releases dramatically enhanced it: it now supports nearly any tag you would use in a report, including almanac tags, which is what makes everything below possible. You list the tags you care about — current observations, trends, day/week/month/year aggregates, rolling windows from one minute to 24 hours (10m.windGust.max, 24h.rain.sum), almanac tags — in weewx.conf, and on every loop packet (every 2 seconds with a Vantage) LoopData writes them to a small JSON file, loop-data.txt, every value already unit-converted and formatted exactly as your report would render it. A few lines of JavaScript in your template fetch that file and the page comes alive: $current.outTemp, $day.outTemp.max, $almanac.sun.alt — all ticking in real time. And if you rsync your reports to a public web server, LoopData will rsync loop-data.txt to that same server on every loop, so remotely hosted pages are just as alive as local ones (paloaltoweather.com works exactly this way).

The sample report included with the extension is a NOAA-style windrose and eleven gauges, drawn by a few hundred lines of dependency-free canvas JavaScript — every needle, petal and readout redraws on every loop packet:

weewx-celestial — the two together

https://github.com/chaunceygardiner/weewx-celestial

weewx-celestial is a sample report that ties weewx-skyfield and weewx-loopdata together: the almanac computes the sky, LoopData publishes it on every loop packet, and the page moves.  See it live: https://www.paloaltoweather.com/celestial/

Earth sits at the center; the sun, moon, eight planets and Proxima Centauri are placed by compass bearing and log distance, the moon at its true phase, bodies below the horizon dimmed and dashed, an hour of motion trail behind every dot. Beside the dial, each body gets an odometer distance readout that ticks between loop refreshes at the body's true radial rate — watch Mercury recede ~28 km every second while Saturn approaches at the same pace. One computation engine (the registered almanac) serves both the report tags and the live page, so they always agree.

What you can build with this

The pages above are the bundled samples. For what these extensions look like worked into a full skin, paloaltoweather.com is the demo site:

• Celestial pages — https://www.paloaltoweather.com/celestial.html — Today, Sun, Moon, Planets and Stars pages, all live-updating, built on weewx-skyfield tags published through weewx-loopdata.
• Gauges — https://www.paloaltoweather.com/gauges.html — live wind, temperature and rain gauges redrawing on every loop packet.
• The home page itself — https://www.paloaltoweather.com/ — every current condition on it is live.

Requirements in brief: weewx-skyfield needs WeeWX 5.2+, Python 3.9+, and Skyfield 1.47+ (PyEphem not required); weewx-loopdata needs WeeWX 4 or 5 and Python 3.7+; weewx-celestial needs weewx-loopdata 5.0+ and (strongly recommended) weewx-skyfield. Each README has full installation instructions.

Take these extensions for a spin and let me know what you think. Questions, bug reports and suggestions welcome — here or on the GitHub issue trackers.

Cheers,
John Kline

[Karen K]

One remark: I did not include the ephemerides into the package, because I guess it is not allowed to do so.

[John Kline]

Hi Karen,

I believe I traded some emails about this previously.  At that time, I stated the ephemeris does not change and should be included.  It is legal to do so.  For the ESA data, they require a Credit: ESA, which you will find on https://github.com/chaunceygardiner/weewx-skyfield and https://www.paloaltoweather.com/.

John   

On Jul 23, 2026, at 10:52 PM, Karen K <kk44...@gmail.com> wrote:

One remark: I did not include the ephemerides into the package, because I guess it is not allowed to do so.

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/e4452499-63ba-4482-b6d7-557cb5f1c665n%40googlegroups.com.

[Christian Peters]

Dear users,

I installed all three extensions and I'm very happy to implement them on my weewx site. 

Now getting live data without using MQTT which makes always trouble with my reverse proxy setup. Smart solved now. :-)  

I even installed the skiefield and celestial extension and with the help of John now all runs smootly! 

Did a quick check of the skyfield dark sky against my AllSky camera (RP4 with PoE hat, running https://github.com/AllskyTeam/allsky ).

The night was not very dark but as you can see it fits nicely...! 

Thank for providing this great extensions!

Regards,

Christian 

[Jo Hunter]

Thank you so much for this Skyfield extension! It’s awesome.

And while I’m at it, thank you to those responsible for the New Belchertown skin, too.

I put both of them on my site: http://wxmonitor.net

It’s a great upgrade :-)

Jo

[John Kline]

Hi Jo,

Thank you for the kind words and for sharing your site — it looks great!

One small suggestion: you might rename the "Night Sky" tab to something like "Sky" or "Sky Now".  The page is actually a current view of the whole sky, day and night.

Either way, thanks for putting it up — it's fun to see it.

Best,

John

On Jul 27, 2026, at 5:49 PM, Jo Hunter <futu...@gmail.com> wrote:

Thank you so much for this Skyfield extension! It’s awesome.

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/12cc23e2-c9f7-4627-8517-f071e2ba4ec3n%40googlegroups.com.

[jterr...@gmail.com]

Hi John,

Thanks for this Skyfield extension.  I installed it today (release V1.13).

Using your skin, I have a problem with data fields showing the visible time of various bodies : they all show 0h 00m

The live page of the skin on my site  is here : http://meteo-sciez.fr/weewx/skyfield/index.html

 

I have also added this message in the "Issue" section of the extension's Github.

Any ideas of a possible cause for this problem ?

Best,

Jacques

[Jacques Terrettaz]

John,

I don't know if it is related to my problems with the skin, , but I have a failed comparison when running your test scripts :

====================================================================================================== test session starts =======================================================================================================

platform linux -- Python 3.11.2, pytest-9.1.1, pluggy-1.6.0

rootdir: /home/meteo/weewx-skyfield-main

collected 428 items                                                                                                                                                                                                              

tests/test_almanac.py .........................................................F.......................................................................................................................................... [ 45%]

...........................................................................................................................................................................................                                [ 89%]

tests/test_sky_page.py .............................................                                                                                                                                                       [100%]

============================================================================================================ FAILURES ============================================================================================================

___________________________________________________________________________________ TestPhysicalAttributes.test_magnitudes_agree_with_pyephem ____________________________________________________________________________________

self = <test_almanac.TestPhysicalAttributes object at 0x7fff290fb0d0>, almanac = <weewx.almanac.Almanac object at 0x7fff28c7cd10>

    def test_magnitudes_agree_with_pyephem(self, almanac):

        ephem = pytest.importorskip('ephem')

        observer = pyephem_observer()

        for planet in ('mercury', 'venus', 'mars', 'jupiter', 'saturn', 'uranus', 'neptune',

                       'sun', 'moon', 'pluto'):

            body = getattr(ephem, planet.title())()

            body.compute(observer)

            # PyEphem uses older magnitude models, so agreement is loose.

>           assert getattr(almanac, planet).mag == pytest.approx(body.mag, abs=0.6), planet

E           AssertionError: moon

E           assert np.float64(-8.420329067365575) == -10.9 ± 0.6

E             

E             comparison failed

E             Obtained: -8.420329067365575

E             Expected: -10.9 ± 0.6

tests/test_almanac.py:656: AssertionError

======================================================================================================== warnings summary ========================================================================================================

[John Kline]

Good news on that test failure: it's not related to your skin problem, and

it's not your machine computing anything wrong.  That test compares my moon

magnitude against the locally installed PyEphem, and PyEphem's lunar

magnitude model was quite crude before version 4.2 — yours (likely Debian's

python3-ephem 4.1.x) says -10.9, modern PyEphem 4.2 says -8.4, agreeing with

my value.  I'll make that test tolerant of older PyEphem versions.

  

The 427 tests that *passed* are actually the interesting part: they show the

Python environment you ran them in computes these durations correctly.  That

makes the answers to the questions in my previous comment — especially

`weectl extension list` and which Python environment weewxd itself runs in — 

the most likely place the answer is hiding.

I answered your first post here on the github issue you filed, but repeating here so others can follow.  The leading hypothesis is that you also have weewx-skyfield-almanac installed; but I’m awaiting your answers to these questions.

Thanks for the report — and for the link to your live page, which helped a lot.

Here is what I can see from your page: everything is being computed correctly
except the durations. Rise, set and transit times, altitudes, azimuths, the
constellations, even the widths of the bars in the day-timeline panel (which
are drawn from the same rise/set times) are all right. Only the durations
derived from the almanac's visible tag — the Daylight line, the "Up for"
column, and the timeline tooltips — show 0h 00m.

I have not been able to reproduce it. I ran the v1.13 code at your
coordinates for July 28/29 under every Skyfield release the extension supports
(1.47 through 1.54, including Debian trixie's Skyfield 1.53 + NumPy 2.2
combination), and visible comes out correct in every case (about 14h56m for
the sun). So the difference must be something about your system, and I'd like
to ask for a few details:

1. WeeWX version and Python version, and how WeeWX and Skyfield were
   installed (Debian apt packages, or pip into a virtual environment)?
2. The output of
   python3 -c "import skyfield, numpy; print(skyfield.VERSION, numpy.__version__)"
   using the same Python that runs WeeWX (if pip-installed, activate the venv
   first).
3. The output of weectl extension list — in particular, is
   weewx-skyfield-almanac or weewx-celestial also installed? Another
   extension that registers its own almanac could be the one actually
   answering these tags.
4. The weewxd startup log lines that mention Skyfield, e.g.
   sudo journalctl -u weewx | grep -i skyfield
   (the extension logs its own version and the Skyfield version at startup).
5. Which files you changed or added for your French translation — did you add
   a lang/fr.conf, or edit the template or wxskyfield_sky.py directly?

If you're up for one more test, temporarily add this line anywhere in
skins/Skyfield/index.html.tmpl and report what it prints:

  <p>$almanac.sun.visible.raw</p>

That is the raw number of seconds behind the Daylight line; today it should
print about 53800.

One request in return: the next release will ship a French translation of the
Sky page and of the almanac's body and constellation names (marked Beta —
the words await native-speaker review). Since you know the material and have
already translated the page for yourself, would you be willing to look it
over? I've attached the proposed lang/fr.conf (you will need to unzip it); corrections from a native
speaker would be very welcome, and it should also spare you maintaining your
own translation going forward.

Thanks,
John

On Jul 29, 2026, at 9:40 AM, Jacques Terrettaz <jterr...@gmail.com> wrote:

John,

--
You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/C72B29DD-F726-4F21-87C8-7E55EF6A63B2%40gmail.com.

[John Kline]

Jacques replied on the issue. Repeating my follow-up here since he “filed” the issue here and on GitHub:

Hi Jacques,

You do have roe-dl's "Skyfield almanac 0.6" and "Skymap almanac 0.3" co-installed alongside wxskyfield 1.13.  You should pick one; but that is not what is causing this error.

I did find the problem — your WeeWX unit settings include group_deltatime = hour (check grep -r group_deltatime  /home/meteo/weewx-data/ to see where). That's a perfectly valid preference, but the Sky page assumed seconds when reading the almanac's visible value, so every duration collapsed to 0h 00m. This is fixed in the next release (1.14); which is imminent and will include a Beta of French translations (which I already had queued up).

Cheers,

John

On Jul 29, 2026, at 9:59 AM, John Kline <jo...@johnkline.com> wrote:



[Jacques Terrettaz]

Hi John,

Concerning "Skyfield almanac 0.6" and "Skymap almanac 0.3", I removed everything concerning these extensions in my weewx.conf, so they are not active.  They were listed as extension since they still appears in  /weewx_data/bin/user/installer folder.

Concerning group_deltatime, yes, I have group_deltatime = hour  in my weewx.conf file. I use this format for the sunshine time.

Thanks for the fix, and I come back to you tomorrow for the /lang/fr.conf file

Best,

Jacques

You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/q2B2QNqJIc8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/weewx-user/B6A87C8B-1635-4138-AA07-1AB80071EFBA%40johnkline.com.

[John Kline]

French support for weewx-skyfield, weewx-celestial and weewx-loopdata is now released (beta, pending native speaker review).

I believe Jacques issue is fixed.  Reply repeated here from the github issue.

Hi Jacques,

The root cause: your WeeWX unit settings include group_deltatime = hour
(a perfectly valid preference), and the Sky page assumed seconds when
reading the almanac's raw duration values, so every duration collapsed
to 0h 00m. weewx-skyfield 1.14 fixes this — the page now renders
identically whatever unit preferences your reports set. You can keep
your configuration exactly as it is.

To upgrade, download weewx-skyfield.zip from
weewx-skyfield v1.14
and install it right over 1.13:

  weectl extension install weewx-skyfield.zip

then restart WeeWX. 1.14 also ships the complete French translation we
discussed (lang = fr in the [[SkyfieldReport]] stanza — one note:
installing replaces the skin's lang/ files, so save a copy of your own
fr.conf first if you want to compare). And the test suite now passes
on your system's older PyEphem — that magnitude failure you found is
guarded.

French also shipped today in the two companion extensions, in case they
interest you:

• weewx-celestial 7.4 — a live, self-updating celestial page:
  weewx-celestial v7.4
• weewx-loopdata 6.5 — the realtime loop-data engine behind it:
  weewx-loopdata v6.5

All three French translations are marked Beta pending a native
speaker's review — so your offer to look over fr.conf stands very
much appreciated, and corrections will land in the next release.

Cheers,
John

On Jul 29, 2026, at 11:09 AM, Jacques Terrettaz <jac...@terrettaz.net> wrote:

Hi John,

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/938A2586-E08F-458B-9FF2-3BD2D31E90AC%40terrettaz.net.

[Ian]

John,

This is really tremendous stuff. I wondered is there any chance that you could add a tag for moon's parallactic angle.
Crongratulations and thank you

Ian

[John Kline]

Hi Ian,

Thanks for the kind words!

Good news: it's already there.

$almanac.moon.parallactic_angle works today (since 1.0), returning radians as PyEphem did.

For degrees:

#import math
$("%.1f°" % math.degrees($almanac.moon.parallactic_angle))

Example:

#import math
...
<p>Moon parallactic angle: $("%.1f°" % math.degrees($almanac.moon.parallactic_angle))</p>

It works for any body, not just the moon.

Note: I could make $almanac.moon.parallactic_angle.degrees work (rather than having to concrete it). I return radians for PyEphem compatability; but I could keep that and still support the .degrees. I’ll probably do that in the next release.

Cheers,
John

[Ian]

Hi John,

I don't no how many times I read through that and I missed it!

Thanks
Ian

[Ian]

Hi again John,

Just one more thing

All these values are resolving except for earth

$rad($almanac.mercury.hlongitude.raw)
$rad($almanac.venus.hlongitude.raw)
$rad($almanac.earth.hlongitude.raw)
$rad($almanac.mars.hlongitude.raw)
$rad($almanac.jupiter.hlongitude.raw)
$rad($almanac.saturn.hlongitude.raw)
$rad($almanac.uranus.hlongitude.raw)
$rad($almanac.neptune.hlongitude.raw)
$rad($almanac.pluto.hlongitude.raw)

Thanks
Ian

[John Kline]

Hi Ian,

  

That one is expected: the earth is the observer in the almanac, not one of the bodies it serves, so there's no $almanac.earth — same as PyEphem, which has Sun, Moon, and Mercury through Pluto, but no Earth body.

Earth's heliocentric longitude is still available, though, just under a different name. Since the sun's own heliocentric coordinates are undefined (it sits at the origin), $almanac.sun.hlongitude reports the Earth's heliocentric ecliptic longitude — a convention inherited from XEphem/PyEphem. So:

$rad($almanac.sun.hlongitude.raw)

completes your set of nine, computed in the same frame as the others. 

  

This is deliberate, and it's a policy: weewx-skyfield aims to be a drop-in replacement for WeeWX's built-in PyEphem almanac. Every tag that worked before keeps working and means the same thing — the test suite carries a permanent parity audit that evaluates everything the built-in almanac could do against both engines. Where we  knowingly deviate (only where PyEphem is measurably wrong, e.g. Jupiter's central meridian longitudes), each case is documented in the README under "Differences from PyEphem". So when a tag like $almanac.earth doesn't resolve, that's fidelity to the original almanac rather than a gap.

Regards,

John

On Jul 29, 2026, at 11:54 PM, Ian <weathe...@gmail.com> wrote:

Hi again John,

--

You received this message because you are subscribed to the Google Groups "weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to weewx-user+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/96983ce1-6398-447d-9f19-1aeeae74faf3n%40googlegroups.com.

[jo...@johnkline.com]

Hi Ian,

Following up: weewx-skyfield 1.15 is out, and the .degrees I mentioned is in it.

$almanac.moon.parallactic_angle still returns radians, as before, for PyEphem compatibility — but you can now override the unit by appending .degrees:

<p>Moon parallactic angle: $("%.1f°" % $almanac.moon.parallactic_angle.degrees)</p>

No #import math needed anymore (though the math.degrees(...) way keeps working — the value is unchanged, still a radians float).  There's also an explicit .radians if you want to spell it out.

The same trick works on every tag that returns radians: the moon's libration_lat/libration_long and colong, Jupiter's cmlI/cmlII, Saturn's earth_tilt/sun_tilt, and $almanac.separation().

Release notes: https://github.com/chaunceygardiner/weewx-skyfield/releases/tag/v1.15

Cheers,
John

[Ian Millard]

Hi John,

This great and very much appreciated.

Cheers,

Ian

https://steepleclaydonweather.uk

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/4c9254cf-005f-4895-97ea-c009f2da6130n%40googlegroups.com.

[gert.a...@gmail.com]

Hi

I have translated all 3 extensions into danish. I have an issue with LoopData and "Rising Slowly" translation, which is still in english. Please see screenshot. I have attached screenshot and da.conf

Rgds

Gert

[John Kline]

Hi Gert,

Thank you for this — a complete Danish translation would be a wonderful contribution.  I'd like to include it in the next release, with credit to you, if you'll give me permission.  Could you send the other two files?

  

On the barometer showing "Rising Slowly": your translation is not the problem — I ran your file through loopdata's own test suite and every string checks out, including all nine tendency descriptions.  The tendency text is just produced differently from the rest of the page: the page's labels are translated each time the report is generated, but trend.barometer.desc is a live value that loopdata translates using the [Texts] of its target report, read once when weewxd starts.  So please check three things:

  

1. In weewx.conf, look at [LoopData] → target_report. It should say LoopDataReport (or be absent — that's the default).  Older loopdata installs often carry target_report = SeasonsReport from earlier setup instructions; the Seasons skin has no "Rising Slowly" text in any language, so the tendency falls back to English while everything else on the page is Danish — exactly the symptom you describe.

2. Restart weewxd after installing da.conf and setting lang = da — the tendency strings are captured at startup, so they stay English until a restart even though the page itself retranslates on the next report cycle.

3. Make sure you're on loopdata 6.4 or later (the startup log line loopdata: Service version is ... tells you).  Translatable tendency descriptions were introduced in 6.4.

  

A quick way to confirm: open your loop-data.txt — if the English "Rising Slowly" is in there, the cause is one of the three above.

  

One tiny thing I spotted in the file: the [Almanac] section is missing a line for Pluto — pluto = Pluto (if that's the Danish name too).  I can add it, or include it when you send the other files.

  

Cheers,  

John

On Aug 1, 2026, at 4:50 AM, gert.a...@gmail.com <gert.a...@gmail.com> wrote:



To view this discussion visit https://groups.google.com/d/msgid/weewx-user/08be1cfd-62ad-4c22-8491-37ec8ffa0a03n%40googlegroups.com.

<Slowly.jpg>

<da.txt>

[John Kline]

Hi Gert,

I should explain LoopData's target report setting.  You should think of LoopData as providing values for report tags every time your WeeWX driver emits a loop record.  These report tags can pretty much be any tag you can write in a report.  So, if you add the field day.outTemp.avg, and your driver writes loop records every 2 seconds, loop-data.txt will contain day.outTemp.avg = X where X is the average outside temperature today and will be updated every 2 seconds.

Conversions are decided by the report, not by the units stored in the database.  As such, if the database is metric, but your report specifies US units, day.outTemp.avg will be displayed in degrees F (e.g., 68.2°F, if the tag was day.outTemp.avg.formatted, it would be 68.2–without the label).  This is the reason LoopData needs a target report.  When LoopData processes each loop record, it looks up the proper converters/formatters as specified in the target report and uses them for unit conversions, formatting, etc. such that the json file (loop-data.txt) shows the value exactly as the WeeWX reporting cycle would have produced it.

Now, before I added i18n, the target report specified often didn't matter because it is likely all your reports used the same converters/formatters.  With i18n, the target report also supplies the language: while $trend.barometer is a standard WeeWX report tag, the .desc wordy description ("Rising Slowly" and friends) is LoopData's own addition, and its translations come from the target report's [Texts].  The same goes for everything else LoopData localizes — moon phases, compass ordinals, almanac body and constellation names, and hemisphere letters all follow the target report's language, so this isn't a barometer-only quirk.

So: make sure [LoopData] target_report points at the LoopDataReport — the report whose skin carries your da.conf with the barometer phrases — and that its stanza sets lang = da (LoopDataReport is the default if target_report is absent).  Then restart weewxd — the descriptions are read once at startup.

In particular, if you pointed target_report at the CelestialReport, that explains what you're seeing: the Celestial dictionary has no barometer phrases in any language, so those fall back to English.  Targeting the LoopDataReport instead fixes it and costs the Celestial page nothing — every value it takes from loop-data.txt is a number; all of its text is translated when the page is generated, from its own da.conf.

I hope this explains why the target report is needed and why the barometer tendency phrase isn't translated.

John

On Aug 1, 2026, at 5:39 AM, John Kline <jo...@johnkline.com> wrote: