Changing the schema under [[wx_binding]] doesn't make any difference. Back to the new default setting.
However, after running weectl database reconfigure I get a database with the new schema that updates, i.e. creates weewx.sdb-journal. Unfortunately, when it is done, there are no live updates, and the web page again is stuck at 3:00 AM. Nothing in the log file. I have no idea what else I could try to get at the old database and continue to update it. Perhaps, I'll need to repurpose some of my own code (wx.aamu.edu) to access the old data and just use weewx for the new data. I certainly won't update the Raspberry Pi that is running weewx 4.10.1 at my other house. It didn't have an issue at the start of CDT. On Sunday, March 8, 2026 at 4:10:17 PM UTC-5 Marius Schamschula wrote: > I'm not sure what the log would tell you in this case. In the weewx.conf > file for 4.10.1 had debug = 1 set. I have now also set that for the new > install. I see nothing useful in the log file since I did that, i.e. no > errors other than the ones I always see (e.g. ERROR > weewx.drivers.vantage: LOOP batch try #1; error: Expected to read 99 chars; > got 46 instead). It did show that an old cron job that was used to track > the active tty caused multiple instances of weewx to run (FreeBSD changes > the port from /dev/ttyU0 to /dev/ttyU1 or in reverse at random times). I > commented that out in crontab to make sure only one instance is active. I > tried one more time with the old .sdb file. Monitoring the /var/log/message > file, I see no errors in the log. As before, the database doesn't update > and a web page for 3:00 AM is rendered. > > As the same thing happens with both weewx 4.10.1 and 5.3.1, but a clean > database file works correctly with 5.3.1, so there is no problem with the > basic functionality of both FreeBSD packages and weewx. > > P.S. I'm leaving the root based install in place, as that is no different > than what I was using for 4.10.1. No warnings of the sort: > > Installing collected packages: pyserial, ephem, pyusb, PyMySQL, CT3, weewx > > WARNING: The scripts pyserial-miniterm and pyserial-ports are installed > in '/home/marius/.local/bin' which is not on PATH. > > Consider adding this directory to PATH or, if you prefer to suppress > this warning, use --no-warn-script-location. > > WARNING: The scripts weectl and weewxd are installed in > '/home/marius/.local/bin' which is not on PATH. > > Consider adding this directory to PATH or, if you prefer to suppress > this warning, use --no-warn-script-location. > > when I installed as root. Of course, I've moved everything onto the ZFS > array, rather than leaving it on the boot drive. > > BTW: What happened to $HOME/bin? That's already in the $PATH. > > In my experience some of the python version requirements are out of date > or too strict, i.e. often you can ignore them and everything works > correctly. > > And yes, the venv install installed a newer version of py311-pillow than > the current one provided by FreeBSD ports. So much for the install > instructions for FreeBSD! > > I now have to redo all the customization of the skin for both the private > and public versions of the web site. It's been a while since I first did > that so I have to rediscover what all needs to be edited. > > I still need to get my all old data back! > > I see that 5.3.1 uses an extended schema by default, while 4.10.1 was > still using the old wview schema (yes, I did start out with wview). Could > there be a problem with the database using the old schema? > On Sunday, March 8, 2026 at 2:56:06 PM UTC-5 Vince Skahan wrote: > >> Sure. The other os have python libs they install at the system level >> too. Run 'pip3 list --verbose' to see what's where. >> >> I'm personally ok with things installing as root. I just like not >> 'running' as root whenever it can be avoided. >> >> FWIW - I have run into the problems venv solve quite a lot. Things >> needing certain versions of a library (or minimum versions thereof) and the >> os freezing to something lesser. Any RHEL-like system or LTS debian is a >> good example. They go for many year stability and freeze to old versions. >> The venv thing is a good way to not be limited by the os vendor's choices. >> >> On Sunday, March 8, 2026 at 12:45:33 PM UTC-7 Greg Troxel wrote: >> >>> Vince Skahan <[email protected]> writes: >>> >>> > You generally can't avoid venvs on a modern python on a current os. >>> Nobody >>> > here did that. The python project forced that on everybody. >>> >>> That's not strictly true. pkgsrc has packages for a vast number of >>> py-foo all installed in the system site-packages, and it works fine. I >>> am actually running weewx that way, with the weewx code in >>> /usr/pkg/lib/python3.13/site-packages/weewx and so on. >>> >>> In my case, the weewx progarm files are owned by root and live in the >>> system. I am running it in a data directory (with config file and >>> database) that is owned by a non-root user. Stepping back from weewx >>> and python, this is totally normal, to use installed programs with your >>> own data. >>> >>> <rant> >>> >>> I find that venvs are required because python culture says it is ok to >>> have requirements as foo==x.y.z, rather than foo>=x.y. Thus, there is >>> no way to have everything needed installed, and python packages with >>> unreasonably specific dependencies (Home Assistant) have to be in a venv >>> for isolation. >>> >>> The root cause of pinned deps, besides people thinking it is ok, is API >>> instability within modules. >>> >>> </rant> >>> >> -- 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/799e2a75-2150-43c8-b497-6df8ce1ea24en%40googlegroups.com.
