If all you are seeing is log level ERROR and CRITICAL, then the log level is too restrictive. I know nothing about FreeBSD, so you're going to have to figure that out on your own. One thing you could do is have weewx log to a file. See the wiki <https://github.com/weewx/weewx/wiki/WeeWX-v4-and-logging#logging-to-rotating-files> for how to do that.
However you do it, it would be very useful to see the whole log. It might show nothing, but that's a clue in its own way. What kind of logger do you have? Serial, or USB? If the former, are you using a serial-to-USB converter? On Mon, Mar 9, 2026 at 5:00 AM Marius Schamschula <[email protected]> wrote: > Thanks for the insights Tom! > > The thought of corrupted data on the logger has also crossed my mind, but > weewx builds a new database right past the problematic timestamp. > > However, the old database file stops at 1772604000, which is March 4, 2026 > at 12:00:00 AM CST, rather than March 8, 2026 03:00:00 AM CDT. > > The new database goes back to February 27, 2026 at 3:20:00 PM CST. > > As far as the logs are concerned, setting debug = 1, doesn't print any > information on startup. I have restarted 5.3.1 several times w/o any output. > > The only thing in the /var/log/messages file are comm errors: > > Mar 8 23:48:18 mars weewxd[23459]: CRITICAL weewxd: Caught WeeWxIOError: > LOOP max batch errors (3) exceeded. > > Mar 8 23:48:18 mars weewxd[23459]: CRITICAL weewxd: **** Waiting > 60.0 seconds then retrying... > > Mar 9 00:00:04 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP > batch try #1; error: Expected to read 99 chars; got 0 instead > > Mar 9 00:05:03 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP > batch try #1; error: Expected to read 99 chars; got 27 instead > > Mar 9 00:05:23 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP > batch try #1; error: Expected to read 99 chars; got 0 instead > > Mar 9 00:38:47 mars syslogd: last message repeated 1 times > > Mar 9 00:39:05 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP > batch try #2; error: Expected to read 99 chars; got 0 instead > > Mar 9 00:56:51 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP > batch try #1; error: Expected to read 99 chars; got 0 instead > > Mar 9 01:13:05 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP > batch try #1; error: Expected to read 99 chars; got 62 instead > > Mar 9 01:29:04 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP > batch try #1; error: Expected to read 99 chars; got 0 instead > > Mar 9 01:47:53 mars syslogd: last message repeated 1 times > > Mar 9 02:03:13 mars syslogd: last message repeated 1 times > > Mar 9 02:03:59 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP > batch try #2; error: Expected to read 99 chars; got 0 instead > > Mar 9 02:37:24 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP > batch try #1; error: Expected to read 99 chars; got 0 instead > > Mar 9 02:38:00 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP > batch try #2; error: Expected to read 99 chars; got 0 instead > > Mar 9 03:28:44 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP > batch try #1; error: Expected to read 99 chars; got 0 instead > > Mar 9 03:29:38 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP > batch try #2; error: Expected to read 99 chars; got 0 instead > > Mar 9 03:29:48 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP > batch try #3; error: Expected to read 99 chars; got 0 instead > > Mar 9 03:29:48 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP max > batch errors (3) exceeded. > > Mar 9 03:29:48 mars weewxd[23459]: CRITICAL weewxd: Caught WeeWxIOError: > LOOP max batch errors (3) exceeded. > > Mar 9 03:29:48 mars weewxd[23459]: CRITICAL weewxd: **** Waiting > 60.0 seconds then retrying... > > Mar 9 03:45:44 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP > batch try #1; error: Expected to read 99 chars; got 0 instead > > Mar 9 04:02:08 mars syslogd: last message repeated 1 times > > Mar 9 04:03:30 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP > batch try #2; error: Expected to read 99 chars; got 0 instead > > Mar 9 04:19:54 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP > batch try #1; error: Expected to read 99 chars; got 0 instead > > Mar 9 04:37:04 mars syslogd: last message repeated 1 times > > Mar 9 04:54:04 mars syslogd: last message repeated 1 times > > Mar 9 04:54:14 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP > batch try #2; error: Expected to read 99 chars; got 0 instead > > Mar 9 04:54:50 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP > batch try #3; error: Expected to read 99 chars; got 0 instead > > Mar 9 04:54:50 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP max > batch errors (3) exceeded. > > Mar 9 04:54:50 mars weewxd[23459]: CRITICAL weewxd: Caught WeeWxIOError: > LOOP max batch errors (3) exceeded. > > Mar 9 04:54:50 mars weewxd[23459]: CRITICAL weewxd: **** Waiting > 60.0 seconds then retrying... > > Mar 9 05:27:20 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP > batch try #1; error: Expected to read 99 chars; got 0 instead > > Mar 9 05:27:38 mars weewxd[23459]: ERROR weewx.drivers.vantage: LOOP > batch try #2; error: Expected to read 99 chars; got 0 instead > > Mar 9 05:45:06 mars weewxd[55633]: ERROR weewx.drivers.vantage: LOOP > batch try #1; error: Expected to read 99 chars; got 0 instead > > I restarted weewxd toward the end of this timeframe. Nothing here. > On Sunday, March 8, 2026 at 8:38:45 PM UTC-5 Tom Keffer wrote: > >> Your symptoms smell like corrupted data in your logger, but without the >> logs, we cannot be sure. Humor me, set debug=1, restart weewxd, let it run >> through the first reporting cycle, then post the logs. >> >> The database is not your problem. If it's working for you, there is no >> reason to "upgrade" from the old schema to the new schema. It just offers >> more types. >> >> On Sun, Mar 8, 2026 at 2:10 PM Marius Schamschula <[email protected]> >> 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/1e3e0173-f581-45cd-a954-d8ec514b558dn%40googlegroups.com >>> <https://groups.google.com/d/msgid/weewx-user/1e3e0173-f581-45cd-a954-d8ec514b558dn%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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/0e70d3d6-062b-49ed-a8cf-580f9bdd5b64n%40googlegroups.com > <https://groups.google.com/d/msgid/weewx-user/0e70d3d6-062b-49ed-a8cf-580f9bdd5b64n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAPq0zEBXB3XVHDwpG17k2ij0UgF4fag0Xc-okmYFsHQPV8bbMg%40mail.gmail.com.
