Almanac extension

[Karen K]

I guess I did not announce the almanac extensions here, which are available from WeeWX 5.2 on.

There was a discussion some months ago about PyEphem becoming outdated and replaced by Skyfield. It resulted in making the WeeWX almanac extensible and providing an installable WeeWX extension based on Skyfield. This was done because Skyfield has more dependencies than PyEphem, and we did not want to add new dependencies to core WeeWX. The extension not only replaces the PyEphem based almanac, but also provides some additional attributes and events like:

• solar date and time
• apsides (the events when they take place)
• Venus and Mercury phases
• which constellation a star or planet is in
• additional attributes for heavenly bodies

For a list of differences see PyEphem vs. Skyfield.

Additionally there is a second extension based on the first one which provides an actual sky map for the location of the weather station with Sun, Moon, the planets, stars, and -configurable - Earth satellites, as well as a symbol of the moon with realistic phase and tilt, and an analemma.

Here you find those extensions:

• weewx-skyfield-almanac
  
• weewx-skymap-almanac
  

[Pablo Sanchez]

Thank you and everyone else who participated in the discussion. it is like an iceberg: all I see are two new extensions but behind the scenes, I can see (and appreciate!) the mental cycles behind the decision. Quite cool.

---
pablo

On 2025-11-25 09:44, Karen K wrote:

I guess I did not announce the almanac extensions here, which are available from WeeWX 5.2 on.

[ trimmed ]

[Tom Hogland]

Love this and installed it per directions, except for using "--config=vp2.conf" and "--config=tempest.conf" in the weectl install line as I have two weather stations running. Tempest picked it up without error and is working, but the VP2 is giving an error - "ERROR user.skyfieldalmanac: live almanac error: unsupported operand type(s) for *: 'float' and 'NoneType'". This is the line where Tempest is showing pressure... 

Any thoughts? I've attached both .conf files and a run of logs from start through a complete second report cycle.

[Tom Hogland]

Love this and installed it per directions, except for using "--config=vp2.conf" and "--config=tempest.conf" in the weectl install line as I have two weather stations running. Tempest picked it up without error and is working, but the VP2 is giving an error - "ERROR user.skyfieldalmanac: live almanac error: unsupported operand type(s) for *: 'float' and 'NoneType'". This is the line where Tempest is showing pressure... 

Any thoughts? I've attached both .conf files and a run of logs from start through a complete second report cycle.

On Tuesday, November 25, 2025 at 6:15:20 AM UTC-9 Pablo Sanchez wrote:

[vince]

You might want to check your VP2 db to see if you have readings for pressure.

At first read I leapt to thinking it was the difference between barometer and pressure but I see you're using prefer_hardware for both in your VP2 .conf file so that looks ok I think. My VP2 database does have both elements FWIW.

$ echo "select datetime(dateTime,'unixepoch','localtime'),datetime,barometer,pressure from archive ORDER BY rowid DESC LIMIT 5;" | sqlite3 vp2.sdb
2025-11-25 09:35:00|1764092100|30.242|29.8328369985047
2025-11-25 09:30:00|1764091800|30.238|29.8296893509559
2025-11-25 09:25:00|1764091500|30.239|29.8306616771881
2025-11-25 09:20:00|1764091200|30.24|29.8316434818231
2025-11-25 09:15:00|1764090900|30.241|29.8326253020723

Also - your logs are throwing all kinds of errors related to not being able to find schemas, which I'm guessing is due to the 5.2 change in where things moved under the hood. Things like...

DEBUG weewx.manager: Could not load schema 'schemas.wview_extended.schema'

 See the Upgrade Guide (link) for that one, but I don't know if it's related or not.

[Tom Hogland]

Running that sqlite command I get the same results you did - both values.

I did fix that schema error - changed 'schemas.' to 'weewx.schemas.' as it suggested and all is cleaned up. This has been running essentially unchanged since the early 4.x releases, maybe earlier, so that error could be years old :D Haven't addressed the localization file error in sftp but that's not high on the list at the moment.

I took out the debug=1 and restarted after that log extract, and still running along the same - Tempest is clean, VP2 shows that error every 5 minutes. 

Anything else I can gather to try to track this down?

[Karen K]

Tom Hogland schrieb am Dienstag, 25. November 2025 um 18:12:29 UTC+1:

"ERROR user.skyfieldalmanac: live almanac error: unsupported operand type(s) for *: 'float' and 'NoneType'". This is the line where Tempest is showing pressure... 

There was a bug that caused an error if the pressure is missing. Please try the fix I provided some minutes ago.

[John Smith]

I am trying to figure out how to use the new extension to give the next moon rise and set, however there isn't anything about that in the documentation or even the extension code, and I'm not sure how to do a dump of all information in the $almanac variable.

Also this log line is now misleading:

weewxd[12249]: INFO weewx.engine: 'pyephem' not detected, extended almanac data is not available

--
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/10824a8d-3c33-49d1-9008-e0cd1e08a6aan%40googlegroups.com.

[Karen K]

John Smith schrieb am Mittwoch, 26. November 2025 um 10:00:17 UTC+1:

I am trying to figure out how to use the new extension to give the next moon rise and set, however there isn't anything about that in the documentation or even the extension code, and I'm not sure how to do a dump of all information in the $almanac variable.

 There is no difference to the old almanac for that. 

$almanac.moon.next_rising

$almanac.moon.next_setting

[John Smith]

Thanks, after looking closer at your code and a little trial and error I came up with the same solution...

--
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/84ef31b0-2e79-4fe3-8363-bc9567ed5826n%40googlegroups.com.

[Karen K]

John Smith schrieb am Mittwoch, 26. November 2025 um 15:14:43 UTC+1:

Thanks, after looking closer at your code and a little trial and error I came up with the same solution...

There is documentation available: Customization of WeeWX using the weewx-skyfield-almanac extension. It reads at the beginning:

$almanac(almanac_time=time,            ## Unix epoch time
         lat=latitude, lon=longitude,  ## degrees
         altitude=altitude,            ## meters
         pressure=pressure,            ## mbars
         horizon=horizon,              ## degrees
         temperature=temperature_C     ## degrees C
       ).heavenly_body(use_center=[01]).attribute

So replace heavenly_body by the name of the body you want (like moon), and attribute by the appropriate attribute (like next_rising). Which bodies and attributes are avaiable, you find there, too.

[John Smith]

I saw that example, but I was only after timestamps using details in the current archive record.

--
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/7008b50c-cac8-406d-9960-fe3614f010bdn%40googlegroups.com.

[Tom Hogland]

I didn't see anything from you about a bug prior to this, and nothing off-list. It also appears that pressure is there. Can you point me at what you're referring to?

[Karen K]

Tom Hogland schrieb am Mittwoch, 26. November 2025 um 17:14:05 UTC+1:

I didn't see anything from you about a bug prior to this, and nothing off-list. It also appears that pressure is there. Can you point me at what you're referring to?

 Please, download the updated version of the extension and install it, and then report, whether the problem is still there or gone. I did some changes that may address the problem.

[John Smith]

Someone emailed me just then saying that they had an exception while using pyephem:

weewxd[1356]: ERROR weewx.cheetahgenerator: **** Reason: cannot find 'next_rise'

The template contains the following that caused the exception:

#if $almanac.hasExtras
$almanac.moon.next_rise.format("%H:%M %d")|$almanac.moon.next_set.format("%H:%M %d")|#slurp
#else
||#slurp
#end if

On Thu, 27 Nov 2025 at 00:58, Karen K <kk44...@gmail.com> wrote:

--
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/84ef31b0-2e79-4fe3-8363-bc9567ed5826n%40googlegroups.com.

[michael.k...@gmx.at]

Thanks for the extension. Will Skyfield interfere with an existing pyephem?

And why does the extension installer merge other skins lang files? This alters existing translations, imho not for the better. And if the other extension is updated, the merged files are overwritten anyway.

[John Smith]

On Thu, 27 Nov 2025 at 15:19, 'michael.k...@gmx.at' via weewx-user <weewx...@googlegroups.com> wrote:

Thanks for the extension. Will Skyfield interfere with an existing pyephem?

A page comparing the 2 libraries mentions if both are installed Skyfield takes precedence... 

[Karen K]

michael.k...@gmx.at schrieb am Donnerstag, 27. November 2025 um 05:19:43 UTC+1:

Thanks for the extension. Will Skyfield interfere with an existing pyephem?

No.

 

And why does the extension installer merge other skins lang files? This alters existing translations, imho not for the better. And if the other extension is updated, the merged files are overwritten anyway.

 

It does not alter existing translations. It adds words, that are not there so far.

There is one system of internationalization in WeeWX only, the $gettext tag. It receives the translations from the language files of the skin. If an extension adds things that include text, it has to look for the localized words in the skin's language files. The Sykfield almanac extension adds texts only that are specific to astronomy like planet names and constellation names and some labels. They are all not included in skins so far, so there is nothing to interfere with. Please, consider the altervative: then is would be necessary to have a long installation instruction involving the user to edit all those language files by hand and a lot of support issues from users who do not read instructions.

[michael.k...@gmx.at]

It does in fact alter existing translations.

The skin I use has a lang/de.conf file, the contents of

[Almanac]

    # The labels to be used for the phases of the moon:
    moon_phases = Neumond, Zunehmender Sichelmond, Zunehmender Halbmond, Zunehmender Mond, Vollmond, Abnehmender Mond, Abnehmender Halbmond, Abnehmender Sichelmond

were overwritten during the merge when installing weewx-skyfield-almanac. Maybe there is an option to let the merge prefer existing keys, but this won't solve the issue that the merged configs will be overwritten by installing an updated version of the skin.

Since it is the users decision to install whatever extension, I'll let it up to the user to have translations for any skyfield related stuff. I'd never expect any extension to mess with the configs of another extension, it's asking for issues by design. As an extension author dealing with almanac stuff and celestial bodies, I'd prepare the translations in the extensions lang file, just as I did with pyephem before, for as long no other way providing augmenting translations exists. This would require an additional layer in the processing order under weewx/defaults.py and above skin.conf

[Karen K]

michael.k...@gmx.at schrieb am Donnerstag, 27. November 2025 um 09:17:29 UTC+1: 

Since it is the users decision to install whatever extension, I'll let it up to the user to have translations for any skyfield related stuff. I'd never expect any extension to mess with the configs of another extension, it's asking for issues by design. As an extension author dealing with almanac stuff and celestial bodies, I'd prepare the translations in the extensions lang file, just as I did with pyephem before, for as long no other way providing augmenting translations exists. This would require an additional layer in the processing order under weewx/defaults.py and above skin.conf

Could you move those thoughts to an issue within the Skyfield almanac extension? That would be a better location to discuss the issue, I guess. 

[Tom Hogland]

I checked and the version #'s hadn't changed - still 0.3 - but it appears something was updated. I re-downloaded and installed, restarted both instances and no more errors. Just as a thought, I might suggest bumping the version to 0.3.1 or similar, to make it obvious an update happened.

Thanks - working great!

[Tom Hogland]

I checked and the version #'s hadn't changed - still 0.3 - but it appears something was updated. I re-downloaded and installed, restarted both instances and no more errors. Just as a thought, I might suggest bumping the version to 0.3.1 or similar, to make it obvious an update happened.

Thanks - working great!

[Karen K]

Tom Hogland schrieb am Donnerstag, 27. November 2025 um 16:43:30 UTC+1:

I checked and the version #'s hadn't changed - still 0.3 - but it appears something was updated. I re-downloaded and installed, restarted both instances and no more errors. Just as a thought, I might suggest bumping the version to 0.3.1 or similar, to make it obvious an update happened.

It was a test for you to check only. So I did not change the version number, as this was no official version.

 

[michael.k...@gmx.at]

Done. And I'm curious what other think about this, maybe my limited knowledge of things is the real problem :)

[michael.k...@gmx.at]

For the record: Issue #9

[michael.k...@gmx.at]

I've been wondering if it is really a good idea to put the ephemeris in WEEWX_ROOT/SQLITE_ROOT  

Since a "skyfield" subdirectory is created anyway, why not put it in  WEEWX_ROOT/skyfield

[Karen K]

michael.k...@gmx.at schrieb am Sonntag, 30. November 2025 um 14:42:02 UTC+1:

I've been wondering if it is really a good idea to put the ephemeris in WEEWX_ROOT/SQLITE_ROOT  

Since a "skyfield" subdirectory is created anyway, why not put it in  WEEWX_ROOT/skyfield

Skyfield data is dynamic data, and SQLITE_ROOT is dynamic data. WEEWX_ROOT may be a read-only directory. So I guess putting the Skyfield directory into WEEWX_ROOT would violate the directory structure of WeeWX.

[Tom Keffer]

Exactly right. SQLITE_ROOT is the right place.

--
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/3c6fad87-9858-42c3-a6a3-6cd6450fdf01n%40googlegroups.com.

[michael.k...@gmx.at]

The naming got my wondering because  SQLITE_ROOT sounds sqlite exclusive to me.

[Tom Keffer]

We could rename it DATABASE_ROOT. 😀

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/b0f8e91c-f05a-423e-86f4-b0dd4d46f50fn%40googlegroups.com.

[vince]

Given a weewx-5.3 coming out eventually this might be a good time to talk through whether doing something would be helpful.  Adding an item to 'where to find things' costs little other than a few lines in the markdown docs.

To me - this one is an edge case.  It's not WEEWX_ROOT (core code) or USER_ROOT (user skins/extensions added to core) or HTML_ROOT (generated web pages) or SQLITE_ROOT (databases).

There's not really a canonical place in the tree hierarchy for data a skin/extension needs to download and process and/or save across restarts.

Does USER_DATA or USER_TMP or USER_VAR or WEEWX_TMP or the like make any sense ?  

I'm sure there are other unix fossils here with similar war stories to mine who'd have thoughts.....

[Karen K]

vince schrieb am Sonntag, 30. November 2025 um 22:14:27 UTC+1:

Does USER_DATA or USER_TMP or USER_VAR or WEEWX_TMP or the like make any sense ?  

If you ask me, then I would connect names including TMP to places, where data is saved a very short time, for example during installation or during one single report creation cycle. The data Skyfield saves is used for days and months and updated on a regular basis. It is a kind of database. So out of the examples USER_DATA or USER_VAR seem to me a better choice for such kind of data.

 

[vince]

Agree. Historically /var is for writable data and /tmp is temporary data, and /var/tmp is persistent temporary data.

So for one extension perhaps….

config={
                'Almanac': {
                    'Skymap': {
                        'enable':'true',

                         ‘user_data’:  ‘/var/tmp/Skymap’,
                    }
                }

or anywhere the weewxd user can write to..,

[Karen K]

vince schrieb am Montag, 1. Dezember 2025 um 07:04:54 UTC+1:

config={
                'Almanac': {
                    'Skymap': {
                        'enable':'true',

                         ‘user_data’:  ‘/var/tmp/Skymap’,
                    }
                }

 That would not work for pip based installations.

[michael.k...@gmx.at]

Skyfield epehmeris data files don't receive updates. If there is an update, there will be new files. So you download the file once and never update it, and you may use it for decades.
https://rhodesmill.org/skyfield/planets.html

[John Smith]

SystemD will now remove files from tmp directories so not sure that storing long term data there is a good idea any more.

--

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/cc3dfdaa-d011-4647-b5aa-685f39c97865n%40googlegroups.com.

[Karen K]

michael.k...@gmx.at schrieb am Montag, 1. Dezember 2025 um 08:12:16 UTC+1:

Skyfield epehmeris data files don't receive updates. If there is an update, there will be new files. So you download the file once and never update it, and you may use it for decades.
https://rhodesmill.org/skyfield/planets.html

Not true. Celestrak files are updated very often. Timescales are updated as well. And even the ephemerides of the planets are updated sometimes.

It depends on the configuration what the WeeWX Skyfield almanac extension does. If the user set up to use Earth satellite data, they get updated daily. And it is no use to do it less often. Time scales and ephemerides files get downloaded as configured (where it is possible to switch off updates).

[michael.k...@gmx.at]

So why does the docs say:
Note that ephemeris files never receive updates, so once you have a file like de421.bsp on disk you never need to download it again.

The configured bsp-file will be downloaded and the file, according to the docs, never changes. 

[vince]

Please explain 'why' it would not work.   My experience is that the extension installer doesn't know/care which type of installation it is running within.

[vince]

Sigh - yes I remember seeing mention of that. The systemd borg continues to break things that have been around just fine for 45 years now.

[John Smith]

It's a shame it's so useful for speeding up boot times with all the detrimental stuft that does too.

To view this discussion visit https://groups.google.com/d/msgid/weewx-user/943c1b18-a21a-49fd-8aa3-7a9d829b8659n%40googlegroups.com.