Hi Dale, A follow-up on your “which engine is doing the calculations” question, since it has a simpler answer now…
As of 1.16 (released yesterday), everything astronomical the built-in almanac ever answered is computed natively in Skyfield — including the moon.subsolar_lat example I gave you. The only attributes that still fall through to PyEphem are a_epoch (an epoch stamp, not astronomy) and PyEphem's own deprecated rise_time/set_time/transit_time family, and that's deliberate — rise/set/transit are the supported native vocabulary. Of course, it is still the case that, if you disable stars in weewx-skyfield, it will fall through to PyEphem; and, if you pick dates earlier then July 29, 1899 or later than October 9, 2053, it will fall through to PyEphem. Cheers, John > On Jul 25, 2026, at 1:34 PM, John Kline <[email protected]> wrote: > > > > >>> On Jul 25, 2026, at 12:46 PM, DR <[email protected]> wrote: >>> >> There was a github info on the skyfield replacement for pyephem. >> >> I can't find the answers to a few questions: >> >> a) when skyfield is added, does it sniff through all the *.conf files in the >> root of the weewx-data and insert the line that enables it to be run ahead >> of pyephem, or only the weewx.conf file in the weewx-data directory; of >> concern if there are several weewx configs for those of us running a couple >> of types of stations. > There is no “sniffing” involved. WeeWX added a feature that allows an > extension to insert itself ahead of pyephem (if pyephem is installed) and > ahead of the built-in almanac. As such, at report time, the extension’s > almanac is queried first to resolve the almanac tag. If it doesn’t, the > pyephem/built-in almanac(s) will be queried. >> >> b) If those config files are modified, there is the implication at least in >> the FAQ that the whole installation of Skyfield needs to be run again, >> which seems a bit odd but lends credence to the idea that the installation >> of it does look through and modify the files. > I’m not sure if you are referring to my almanac extension > (https://github.com/chaunceygardiner/weewx-skyfield) or > https://github.com/roe-dl/weewx-skyfield-almanac; but, whichever one makes > you think you have to continuously reinstall, you should let us know so we > can clarify the documentation. If new versions of the extensions are > released, you do need to reinstall to use that new version; but changing > other skins, adding almanac tags, etc. do not require you to reinstall the > skyfield almanac. >> >> >> c) Is there any way of seeing if skyfield is doing the calculations, or if >> pyephem is? The notes indicate that if installed, skyfield will be tried >> first, then fall back to pyephem. > I can answer this for my extension: > > Yes, there's a test for the no-PyEphem case. The test suite has a fixture > that simulates a machine without PyEphem installed (it removes the ephem > module and leaves only the Skyfield almanac registered), and an audit test > (TestSkyfieldOnlyAudit) that requires every supported tag to evaluate > correctly in that configuration. So the Skyfield engine is proven to answer > everything it claims to on its own, not silently via PyEphem. > > On which engine is doing the calculations — it's actually a bit stronger than > "try Skyfield first, then fall back." Once the extension is registered, > Skyfield computes everything it knows how to compute. PyEphem is consulted > only in three narrow, by-design cases: > > 1. Attributes Skyfield doesn't compute at all (direct PyEphem extras like > moon.subsolar_lat). > 2. Named-star tags when the star catalog is disabled (but you would have to > go out of your way to disable it). > 3. Dates far enough outside the bundled DE421 ephemeris span (1899–2053) > that a search window can't complete. > > Ways to see it for yourself: > > - Check the startup log. If the extension registered, syslog shows: > Skyfield almanac registered; reports will use Skyfield for almanac > computations. > If that line is present, your report tags are coming from Skyfield except > for the three cases above. > - The definitive experiment — the same thing the test suite does: pip > uninstall ephem in your WeeWX virtual environment and restart. Anything that > still evaluates is pure Skyfield. (The handful of PyEphem-only attributes > become per-tag errors, not aborted reports, so it's safe to try.) > - Look at the values. The README's "Differences from PyEphem" section lists > tags where the two engines measurably disagree (e.g., Jupiter's central > meridian longitude differs by ~0.8°, and twilight with a custom horizon is > geometric per USNO rather than refracted). If your output matches the > documented Skyfield/USNO value, Skyfield computed it. >> >> d) If at this point skyfield is the preferred option going forward and will >> have not only more accuracy (I really don't need it but seems like a good >> thing) along with an ephemeris which will be updated, maybe it is a >> worthwhile thing to get a new install of my whole RaspPi system and try to >> remove pyephem? Maybe this isn't even possible, and my RaspOS skills are >> rudimentary for knowing if this is a worthwhile thing. > I’m not sure who would bestow the “preferred” label. Probably Tom could make > that pronouncement; but I *think* he is in the camp that PyEphem is good > enough. I think it is a reasonable position to regard PyEphem as good > enough. As fore starting over, you don’t need to start over to remove > PyEphem (depending on how you installed WeeWX, that might be a pipe uninstall > or an apt remove). >> >> >> e) while I'm asking, there were implications that Trixie broke a few things >> by imposing a higher level of security, so I was happy to have my install >> just working and never upgraded to that version. Is there still some parts >> of the whole WeeWx ensemble which isn't happy with Trixie, or have those >> problems (if they existed for ordinary users) been taken care of in WeeWx >> 5.4? > I’ll pass on answering this question as there are others more familiar with > the issues. >> >> >> thx. Dale >> >> >> >> >> -- >> 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 [email protected]. >> To view this discussion visit >> https://groups.google.com/d/msgid/weewx-user/cee66acf-04c9-4669-b6d4-835b0725c157%40gmail.com. -- 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 [email protected]. To view this discussion visit https://groups.google.com/d/msgid/weewx-user/9E7143E1-2520-4FBC-8A83-C89FD1286CDC%40johnkline.com.
