Fix links and formatting in Troubleshooting section

This commit is contained in:
Tom Keffer
2023-07-21 14:39:34 -07:00
parent a99b578ed4
commit 4a5ca4fdc0
6 changed files with 252 additions and 102 deletions

View File

@@ -22,6 +22,11 @@ go with type `SQLite` are defined in section
The path to the SQLite file. If the path is relative, it is relative to
[`SQLITE_ROOT`](../database-types#sqlite_root). Default is `weewx.sdb`.
#### timeout
How many seconds to wait before raising an error when a table is locked.
Default is `5`.
## [[archive_mysql]]
This definition uses the MySQL database engine to store data. It is free,

View File

@@ -1,13 +1,31 @@
# Hardware problems
## Tips on making a system reliable
If you are having problems keeping your weather station up for long periods of time, here are some tips, in decreasing order of importance:
* Run on dedicated hardware. If you are using the server for other tasks, particularly as your desktop machine, you will have reliability problems. If you are using it as a print or network server, you will probably be OK.
* Run headless. Modern graphical systems are extremely complex. As new features are added, test suites do not always catch up. Your system will be much more reliable if you run it without a windowing system.
* Use an Uninterruptible Power Supply (UPS). The vast majority of power glitches are very short-lived — just a second or two — so you do not need a big one. The 425VA unit I use to protect my fit-PC cost $55 at Best Buy.
* If you buy a Davis VantagePro and your computer has an old-fashioned serial port, get the VantagePro with a serial connection, not a USB connection. See the Wiki article on [Davis cp2101 converter problems](https://github.com/weewx/weewx/wiki/Troubleshooting-the-Davis-Vantage-station#davis-cp2101-converter-problems) for details.
* If you do use a USB connection, put a ferrite coil on each end of the cable to your console. If you have enough length and the ferrite coil is big enough, make a loop so it goes through the coil twice. See the picture below:
If you are having problems keeping your weather station up for long periods of
time, here are some tips, in decreasing order of importance:
* Run on dedicated hardware. If you are using the server for other tasks,
particularly as your desktop machine, you will have reliability problems. If
you are using it as a print or network server, you will probably be OK.
* Run headless. Modern graphical systems are extremely complex. As new features
are added, test suites do not always catch up. Your system will be much more
reliable if you run it without a windowing system.
* Use an Uninterruptible Power Supply (UPS). The vast majority of power glitches
are very short-lived — just a second or two — so you do not need a
big one. The 425VA unit I use to protect my fit-PC cost $55 at Best Buy.
* If you buy a Davis VantagePro and your computer has an old-fashioned serial
port, get the VantagePro with a serial connection, not a USB connection. See
the Wiki article on [Davis cp2101 converter
problems](https://github.com/weewx/weewx/wiki/Troubleshooting-the-Davis-Vantage-station#davis-cp2101-converter-problems)
for details.
* If you do use a USB connection, put a ferrite coil on each end of the cable to
your console. If you have enough length and the ferrite coil is big enough,
make a loop so it goes through the coil twice. See the picture below:
<figure markdown>
![Ferrite Coils](../../images/ferrites.jpg){ width="300" }
@@ -18,13 +36,25 @@ Ferrite coils on a Davis Envoy. There are two coils, one on the USB connection (
## Archive interval
Most hardware with data-logging includes a parameter to specify the archive interval used by the logger. If the hardware and driver support it, WeeWX will use this interval as the archive interval. If not, WeeWX will fall back to using option `archive_interval` specified in [[StdArchive]](../../weewx-config-file/stdarchive). The default fallback value is 300 seconds (5 minutes).
Most hardware with data-logging includes a parameter to specify the archive
interval used by the logger. If the hardware and driver support it, WeeWX will
use this interval as the archive interval. If not, WeeWX will fall back to using
option `archive_interval` specified in
[[StdArchive]](/reference/weewx-options/stdarchive/). The default fallback value
is 300 seconds (5 minutes).
If the hardware archive interval is large, it will take a long time before anything shows up in the WeeWX reports. For example, WS23xx stations ship with an archive interval of 60 minutes, and Fine Offset stations ship with an archive interval of 30 minutes. If you run WeeWX with a WS23xx station in its factory default configuration, it will take 60 minutes before the first data point shows up, then another 60 minutes until the next one, and so on.
If the hardware archive interval is large, it will take a long time before
anything shows up in the WeeWX reports. For example, WS23xx stations ship with
an archive interval of 60 minutes, and Fine Offset stations ship with an archive
interval of 30 minutes. If you run WeeWX with a WS23xx station in its factory
default configuration, it will take 60 minutes before the first data point shows
up, then another 60 minutes until the next one, and so on.
Since reports are generated when a new archive record arrives, a large archive interval means that reports will be generated infrequently.
Since reports are generated when a new archive record arrives, a large archive
interval means that reports will be generated infrequently.
If you want data and reports closer to real-time, use the [wee_device](../../../utilities/wee_device) utility to change the interval.
If you want data and reports closer to real-time, use the
[wee_device](../../../utilities/wee_device) utility to change the interval.
## Raspberry Pi

View File

@@ -1,34 +1,80 @@
# Meteorological problems
## The pressure reported by WeeWX does not match the pressure on the console
Be sure that you are comparing the right values. There are three different types of pressure:
* **Station Pressure**: The _Station Pressure_ (SP), which is the raw, absolute pressure measured by the station. This is `pressure` in WeeWX packets and archive records.
* **Sea Level Pressure**: The _Sea Level Pressure_ (SLP) is obtained by correcting the Station Pressure for altitude and local temperature. This is `barometer` in WeeWX packets and archive records.
* **Altimeter**: The _Altimeter Setting_ (AS) is obtained by correcting the Station Pressure for altitude. This is `altimeter` in WeeWX packets and archive records.
Any station might require calibration. For some hardware, this can be done at the weather station console. Alternatively, use the `StdCalibrate` section to apply an offset.
Be sure that you are comparing the right values. There are three different types
of pressure:
If your station is significantly above (or below) sea level, be sure that the station altitude is specified properly. Also, be sure that any calibration results in a station pressure and/or barometric pressure that matches those reported by other stations in your area.
* **Station Pressure**: The _Station Pressure_ (SP), which is the raw, absolute
pressure measured by the station. This is `pressure` in WeeWX packets and
archive records.
* **Sea Level Pressure**: The _Sea Level Pressure_ (SLP) is obtained by
correcting the Station Pressure for altitude and local temperature. This is
`barometer` in WeeWX packets and archive records.
* **Altimeter**: The _Altimeter Setting_ (AS) is obtained by correcting the
Station Pressure for altitude. This is `altimeter` in WeeWX packets and archive
records. Any station might require calibration. For some hardware, this can be
done at the weather station console. Alternatively, use the `StdCalibrate`
section to apply an offset.
If your station is significantly above (or below) sea level, be sure that the
station altitude is specified properly. Also, be sure that any calibration
results in a station pressure and/or barometric pressure that matches those
reported by other stations in your area.
## Calibrating barometer does not change the pressure displayed by WeeWX
Be sure that the calibration is applied to the correct quantity.
The corrections in the `StdCalibrate` section apply only to raw values from the hardware; corrections are not applied to derived quantities.
The corrections in the `StdCalibrate` section apply only to raw values from the
hardware; corrections are not applied to derived quantities.
The station hardware matters. Some stations report gauge pressure (`pressure`) while other stations report sea-level pressure (`barometer`). For example, if the hardware is a Vantage station, the correction must be applied to `barometer` since the Vantage station reports `barometer` and WeeWX calculates `pressure`. However, if the hardware is a FineOffset station, the correction must be applied to `pressure` since the FineOffset stations report `pressure` and WeeWX calculates `barometer`.
The station hardware matters. Some stations report gauge pressure (`pressure`)
while other stations report sea-level pressure (`barometer`). For example, if
the hardware is a Vantage station, the correction must be applied to `barometer`
since the Vantage station reports `barometer` and WeeWX calculates `pressure`.
However, if the hardware is a FineOffset station, the correction must be applied
to `pressure` since the FineOffset stations report `pressure` and WeeWX
calculates `barometer`.
## The rainfall and/or rain rate reported by WeeWX do not match the console
First of all, be sure that you are comparing the right quantities. The value `rain` is the amount of rainfall observed in a period of time. The period of time might be a LOOP interval, in which case the `rain` is the amount of rain since the last LOOP packet. Because LOOP packets arrive quite frequently, this value is likely to be very small. Or the period of time might be an archive interval, in which case `rain` is the total amount of rain reported since the last archive record.
Some consoles report the amount of rain in the past hour, or the amount of rain since midnight.
First of all, be sure that you are comparing the right quantities. The value
`rain` is the amount of rainfall observed in a period of time. The period of
time might be a LOOP interval, in which case the `rain` is the amount of rain
since the last LOOP packet. Because LOOP packets arrive quite frequently, this
value is likely to be very small. Or the period of time might be an archive
interval, in which case `rain` is the total amount of rain reported since the
last archive record.
The rain rate is a derived quantity. Some stations report a rain rate, but for those that do not, WeeWX will calculate the rain rate.
Some consoles report the amount of rain in the past hour, or the amount of rain
since midnight.
Finally, beware of calibration factors specific to the hardware. For example, the bucket type on a Vantage station must be specified when you set up the weather station. If you modify the rain bucket with a larger collection area, then you will have to add a multiplier in the `StdCalibrate` section.
The rain rate is a derived quantity. Some stations report a rain rate, but for
those that do not, WeeWX will calculate the rain rate.
To diagnose rain issues, run WeeWX directly so that you can see each LOOP packet and REC archive record. Tip the bucket to verify that each bucket tip is detected and reported by WeeWX. Verify that each bucket tip is converted to the correct rainfall amount. Then check the database to verify that the values are properly added and recorded.
Finally, beware of calibration factors specific to the hardware. For example,
the bucket type on a Vantage station must be specified when you set up the
weather station. If you modify the rain bucket with a larger collection area,
then you will have to add a multiplier in the `StdCalibrate` section.
To diagnose rain issues, run WeeWX directly so that you can see each LOOP packet
and REC archive record. Tip the bucket to verify that each bucket tip is
detected and reported by WeeWX. Verify that each bucket tip is converted to the
correct rainfall amount. Then check the database to verify that the values are
properly added and recorded.
## There is no wind direction when wind speed is zero
This is by design &mdash; if there is no wind, then the wind direction is undefined, represented by NULL in the database or `None` in Python. This policy is enforced by the `StdWXCalculate` service. If necessary, it can be overridden. See option [force_null](../../weewx-config-file/stdwxcalculate-config#winddir) in the [[StdWXCalculate]](../../weewx-config-file/stdwxcalculate-config) section.
WeeWX distinguishes between a value of zero and no value (NULL or None). However, some services do not make this distinction and replace a NULL or None with a clearly invalid value such as -999.
This is by design &mdash; if there is no wind, then the wind direction is
undefined, represented by NULL in the database or `None` in Python. This policy
is enforced by the `StdWXCalculate` service. If necessary, it can be overridden.
See option [force_null](/reference/weewx-options/stdwxcalculate/#force_null)
in the [[StdWXCalculate]](http://localhost:8000/reference/weewx-options/stdwxcalculate/)
section.
WeeWX distinguishes between a value of zero and no value (NULL or None).
However, some services do not make this distinction and replace a NULL or None
with a clearly invalid value such as -999.

View File

@@ -1,7 +1,10 @@
# Software problems
## Nothing in the log file
As it is running, WeeWX periodically sends status information, failures, and other things to your system's logging facility. They typically look something like this (the first line is not actually part of the log):
As it is running, WeeWX periodically sends status information, failures, and
other things to your system's logging facility. They typically look something
like this (the first line is not actually part of the log):
``` log
DATE TIME HOST weewx[PID] LEVL MESSAGE
@@ -13,18 +16,25 @@ Feb 8 04:25:17 hummingbird weewx[6932] INFO weewx.restx: Windy: Published recor
Feb 8 04:25:17 hummingbird weewx[6932] ERROR weewx.restx: WOW: Failed to publish record 2020-02-08 04:25:00 PST (1581164700): Failed upload after 3 tries
```
The location of this logging file varies from system to system, but it is typically in `/var/log/syslog` or `/var/log/messages`.
The location of this logging file varies from system to system, but it is
typically in `/var/log/syslog` or `/var/log/messages`.
However, some systems default to saving only warning or critical information, so **INFO** messages from WeeWX may not appear. If this happens to you, check your system logging configuration. On Debian systems, look in `/etc/rsyslog.conf`. On Redhat systems, look in `/etc/syslog.conf`.
However, some systems default to saving only warning or critical information, so
**INFO** messages from WeeWX may not appear. If this happens to you, check your
system logging configuration. On Debian systems, look in `/etc/rsyslog.conf`. On
Redhat systems, look in `/etc/syslog.conf`.
## ConfigObj errors
These are errors in the configuration file. Two are very common. Incidentally, these errors are far easier to diagnose when WeeWX is run directly from the command line than when it is run as a daemon.
These are errors in the configuration file. Two are very common. Incidentally,
these errors are far easier to diagnose when WeeWX is run directly from the
command line than when it is run as a daemon.
### `configobj.DuplicateError` exception
### Exception `configobj.DuplicateError`
This error is caused by using an identifier more than once in the configuration file. For example, you may have inadvertently listed your FTP server twice:
This error is caused by using an identifier more than once in the configuration
file. For example, you may have inadvertently listed your FTP server twice:
```ini
[Reports]
@@ -38,7 +48,8 @@ This error is caused by using an identifier more than once in the configuration
...
```
Generally, if you encounter this error, the log file will give you the line number it happened in:
Generally, if you encounter this error, the log file will give you the line
number it happened in:
``` log
Apr 24 12:09:15 raven weewx[11480]: wxengine: Error while parsing configuration file /home/weewx/weewx.conf
@@ -47,9 +58,10 @@ Apr 24 12:09:15 raven weewx[11480]: **** Duplicate keyword name at line 254.
Apr 24 12:09:15 raven weewx[11480]: **** Exiting.
```
### `configobj.NestingError` exception
### Exception `configobj.NestingError`
This is a very similar error, and is caused by a misformed section nesting. For example:
This is a very similar error, and is caused by a misformed section nesting. For
example:
```ini
[Reports]
@@ -62,7 +74,9 @@ Note the extra closing bracket on the subsection `FTP`.
## No barometer data
If everything appears normal except that you have no barometer data, the problem may be a mismatch between the unit system used for service `StdConvert` and the unit system used by service `StdQC`. For example:
If everything appears normal except that you have no barometer data, the problem
may be a mismatch between the unit system used for service `StdConvert` and the
unit system used by service `StdQC`. For example:
```ini
[StdConvert]
@@ -74,9 +88,12 @@ If everything appears normal except that you have no barometer data, the problem
barometer = 28, 32.5
```
The problem is that you are requiring the barometer data to be between 28 and 32.5, but with the unit system set to `METRIC`, the data will be in the range 990 to 1050 or so!
The problem is that you are requiring the barometer data to be between 28 and
32.5, but with the unit system set to `METRIC`, the data will be in the range
990 to 1050 or so!
The solution is to change the values to match the units in `StdConvert`, or specify the units in `MinMax`, regardless of the units in `StdConvert`. For example:
The solution is to change the values to match the units in `StdConvert`, or,
better yet, specify the units in `MinMax`. For example:
```ini hl_lines="7"
[StdConvert]
@@ -88,7 +105,8 @@ The solution is to change the values to match the units in `StdConvert`, or spec
barometer = 950, 1100, mbar
```
## `Cheetah.NameMapper.NotFound` errors
## Exception `Cheetah.NameMapper.NotFound`
If you get errors of the sort:
``` log
@@ -97,18 +115,27 @@ Apr 12 05:12:32 raven reportengine[3074]: **** Message: "cannot find 'fubar' in
Apr 12 05:12:32 raven reportengine[3074]: **** Ignoring template and continuing.
```
you have a tag in your template that WeeWX does not recognize. In this example, it is the tag `$fubar` in the template `/home/weewx/skins/Standard/index.html.tmpl`.
you have a tag in your template that WeeWX does not recognize. In this example,
it is the tag `$fubar` in the template
`/home/weewx/skins/Standard/index.html.tmpl`.
## Dots in the plots
If you see dots instead of lines in the daily plots, you might want to change the graphing options or adjust the station's archive interval.
If you see dots instead of lines in the daily plots, you might want to change
the graphing options or adjust the station's archive interval.
In a default configuration, a time period greater than 1% of the displayed timespan is considered to be a gap in data. So when the interval between data points is greater than about 10 minutes, the daily plots show dots instead of connected points.
In a default configuration, a time period greater than 1% of the displayed
timespan is considered to be a gap in data. So when the interval between data
points is greater than about 10 minutes, the daily plots show dots instead of
connected points.
Change the [line_gap_fraction](../../../custom/image-generator#line_gaps) option in `skin.conf` to control how much time is considered a break in data.
Change the option
[`line_gap_fraction`](/reference/skin-options/imagegenerator/#line_gap_fraction)
in `skin.conf` to control how much time is considered a break in data.
As for the archive interval, check the log file for an entry like this soon after WeeWX starts up:
As for the archive interval, check the log file for an entry like this soon
after WeeWX starts up:
```
Dec 30 10:54:17 saga weewx[10035]: wxengine: The archive interval in the configuration file
@@ -116,47 +143,36 @@ Dec 30 10:54:17 saga weewx[10035]: wxengine: The archive interval in the configu
Dec 30 10:54:17 saga weewx[10035]: wxengine: Using archive interval of 1800
```
In this example, interval in `weewx.conf` is 5 minutes, but the station interval is 30 minutes. When the interval in `weewx.conf` does not match the station's hardware interval, WeeWX defers to the station's interval.
In this example, the interval specified in `weewx.conf` is 5 minutes, but the
interval specified in the station hardware is 30 minutes. When the interval in
`weewx.conf` does not match the station's hardware interval, WeeWX defers to the
station's interval.
Use the [`wee_device`](../../../utilities/wee_device) utility to change the station's interval.
Use the [`wee_device`](/utilities/wee_device) utility to change the
station's interval.
## Spikes in the graphs
Occasionally you may see anomalous readings, typically manifested as spikes in the graphs. The source could be a flaky serial/USB connection, radio or other interference, a cheap USB-Serial adapter, low-quality sensors, or simply an anomalous reading.
Occasionally you may see anomalous readings, typically manifested as spikes in
the graphs. The source could be a flaky serial/USB connection, radio or other
interference, a cheap USB-Serial adapter, low-quality sensors, or simply an
anomalous reading.
Sensor quality matters. It is not unusual for some low-end hardware to report odd sensor readings occasionally (once every few days). Some sensors, such as solar radiation/UV, have a limited lifespan of about 5 years. The (analog) humidity sensors on older Vantage stations are known to deteriorate after a few years in wet environments.
Sensor quality matters. It is not unusual for some low-end hardware to report
odd sensor readings occasionally (once every few days). Some sensors, such as
solar radiation/UV, have a limited lifespan of about 5 years. The (analog)
humidity sensors on older Vantage stations are known to deteriorate after a few
years in wet environments.
If you frequently see anomalous data, first check the hardware.
To keep bad data from the database, add a quality control (QC) rule such as Min/Max bounds. See the [QC](../../weewx-config-file/stdqc-config) section for details.
To keep bad data from the database, add a quality control (QC) rule such as
Min/Max bounds. See the section [`[StdQC]`](/reference/weewx-options/stdqc/) for
details.
To remove bad data from the database, you will have to do some basic SQL commands. For example, let's say the station emitted some very high temperatures and wind speeds for one or two readings. This is how to remove them:
1. Stop WeeWX
2. Make a copy of the archive database
``` bash
cp weewx.sdb weewx-YYMMDD.sdb
```
3. Verify the bad data exist where you think they exist
``` bash
sqlite3 weewx.sdb
sqlite> select dateTime,outTemp from archive where outTemp > 1000;
```
4. See whether the bad temperature and wind data happened at the same time
``` sql
sqlite> select dateTime,outTemp,windSpeed from archive where outTemp > 1000;
```
5. Remove the bad data by setting to NULL
``` sql
sqlite> update archive set windSpeed=NULL where outTemp > 1000;
sqlite> update archive set outTemp=NULL where outTemp > 1000;
```
6. Delete the aggregate statistics so that WeeWX can regenerate them without the anomalies
``` bash
weectl database drop-daily
```
7. Start WeeWX
To remove bad data from the database, see the Wiki article [_Cleaning up old
"bad" data_](https://github.com/weewx/weewx/wiki/Cleaning-up-old-'bad'-data).
## 'Database is locked' error
@@ -175,45 +191,68 @@ Feb 12 07:11:06 rpi weewx[20930]: **** raise weedb.OperationalError(e)
Feb 12 07:11:06 rpi weewx[20930]: **** OperationalError: database is locked
```
We are still trying to decipher exactly what the problem is, but it seems that (many? most? all?) implementations of the SQLite 'C' access libraries on the RPi sleep for a full second if they find the database locked. This gives them only five chances within the 5 second timeout period before an exception is raised.
We are still trying to decipher exactly what the problem is, but it seems that
(many? most? all?) implementations of the SQLite 'C' access libraries on the RPi
sleep for a full second if they find the database locked. This gives them only
five chances within the 5 second timeout period before an exception is raised.
Not all Raspberry Pis have this problem. It seems to be most acute when running big templates with lots of queries, such as the forecast extension.
Not all Raspberry Pis have this problem. It seems to be most acute when running
big templates with lots of queries, such as the forecast extension.
There are a few possible fixes:
* Increase the [timeout option](../../weewx-config-file/databases.md#sqlite).
* Use a high quality SD card in your RPi. There seems to be some evidence that faster SD cards are more immune to this problem.
* Increase the option [`timeout`](/reference/weewx-options/databases/#timeout).
* Use a high quality SD card in your RPi. There seems to be some evidence that
faster SD cards are more immune to this problem.
* Trim the size of your templates to minimize the number of queries necessary.
None of these 'fixes' are very satisfying and we're trying to come up with a more robust solution.
None of these 'fixes' are very satisfying, and we're trying to come up with a
more robust solution.
## Funky symbols in plots
If your plots have strange looking symbols for units, such as degrees Fahrenheit (°F), that look something like this:
If your plots have strange looking symbols for units, such as degrees Fahrenheit
(°F), that look something like this:
![funky degree sign](../../images/funky_degree.png)
Then the problem may be that you are missing the fonts specified for the option `unit_label_font_path` in your `skin.conf` file and, instead, WeeWX is substituting a default font, which does not support the Unicode character necessary to make a degree sign. Look in section `[ImageGenerator]` for a line that looks like:
```
unit_label_font_path = /usr/share/fonts/truetype/freefont/FreeMonoBold.ttf
```
Make sure that the specified path (`/usr/share/fonts/truetype/freefont/FreeMonoBold.ttf` in this case) actually exists. If it does not, on Debian operating systems (such as Ubuntu), you may be able to install the necessary fonts:
unit_label_font_path = /usr/share/fonts/truetype/freefont/FreeMonoBold.ttf
Make sure that the specified path
(`/usr/share/fonts/truetype/freefont/FreeMonoBold.ttf` in this case) actually
exists. If it does not, on Debian operating systems (such as Ubuntu), you may be
able to install the necessary fonts:
``` bash
sudo apt-get install fonts-freefont-ttf
sudo fc-cache -f -v
```
(On older systems, the package `fonts-freefont-ttf` may be called `ttf-freefont`). The first command installs the "Truetype" fonts, the second rebuilds the font cache. If your system does not have fc-cache command, then install it from the `fontconfig` package:
(On older systems, the package `fonts-freefont-ttf` may be called
`ttf-freefont`). The first command installs the "Truetype" fonts, the second
rebuilds the font cache. If your system does not have the `fc-cache` command,
then install it from the `fontconfig` package:
``` bash
sudo apt-get install fontconfig
```
If none of this works, or if you are on a different operating system, then you will have to change the option `unit_label_font_path` to point to something on your system which does support the Unicode characters you plan to use.
If none of this works, or if you are on a different operating system, then you
will have to change the option `unit_label_font_path` to point to something on
your system which does support the Unicode characters you plan to use.
## UnicodeEncodeError
This problem is closely related to the ["Funky symbols"](#funky-symbols-in-plots) problem above. In this case, you may see errors in your log that look like:
## Exception `UnicodeEncodeError`
This problem is closely related to the ["Funky
symbols"](#funky-symbols-in-plots) problem above. In this case, you may see
errors in your log that look like:
``` log
May 14 13:35:23 web weewx[5633]: cheetahgenerator: Generated 14 files for report StandardReport in 1.27 seconds
May 14 13:35:23 web weewx[5633]: reportengine: Caught unrecoverable exception in generator weewx.imagegenerator.ImageGenerator
@@ -236,21 +275,51 @@ May 14 13:35:23 web weewx[5633]: **** return font.getsize(text)
May 14 13:35:23 web weewx[5633]: **** UnicodeEncodeError: 'ascii' codec can't encode character u'\xe8' in position 5: ordinal not in range(128)
May 14 13:35:23 web weewx[5633]: **** Generator terminated...
```
This is frequently caused by the necessary Truetype fonts not being installed on your computer and, instead, a default font is being substituted, which only knows how to plot ASCII characters. The cure is as before: install the font.
This is frequently caused by the necessary Truetype fonts not being installed on
your computer and, instead, a default font is being substituted, which only
knows how to plot ASCII characters. The cure is as before: install the font.
## Data is archived but some/all reports do not run
If WeeWX appears to be running normally but some or all reports are not being run, either all the time or periodically, the problem could be the inadvertant use or incorrect setting of the `report_timing` option in `weewx.conf`. The `report_timing` option allows the user to specify when some or all reports are run (see [*Scheduling report generation*](../../../custom/report_scheduling)). By default, the [_`report_timing`_](../../weewx-config-file/stdreport-config/#report_timing) option is disabled and all reports are run each archive period.
If WeeWX appears to be running normally but some or all reports are not being
run, either all the time or periodically, the problem could be the inadvertant
use or incorrect setting of the `report_timing` option in `weewx.conf`. The
`report_timing` option allows the user to specify when some or all reports are
run (see [_Scheduling report generation_](/custom/report-scheduling/)).
By default, the option
[_`report_timing`_](/reference/weewx-options/stdreport/#report_timing)
is disabled and all reports are run each archive period.
To see if the `report_timing` option is causing reports to be skipped, inspect
the log file. Any reports that are skipped due to the `report_timing` option
will be logged as follows:
To see if the `report_timing` option is causing reports to be skipped inspect the [log file](../../running-weewx#monitoring-weewx). Any reports that are skipped due to the `report_timing` option will be logged as follows:
``` log
Apr 29 09:30:17 rosella weewx[3319]: reportengine: Report StandardReport skipped due to report_timing setting
```
If reports are being incorrectly skipped due to `report_timing`, then edit `weewx.conf` and check for a `report_timing` option in `[StdReport]`. Either remove all occurrences of `report_timing` to run all reports each archive period, or confirm the correct use and setting of the `report_timing` option.
If reports are being incorrectly skipped due to `report_timing`, then edit
`weewx.conf` and check for a `report_timing` option in `[StdReport]`. Either
remove all occurrences of `report_timing` to run all reports each archive
period, or confirm the correct use and setting of the `report_timing` option.
## The wrong reports are being skipped by report_timing
If the [_`report_timing`_](../../weewx-config-file/stdreport-config/#report_timing) option is being used, and the results are not as expected, there may be an error in the `report_timing` option. If there are errors in the `report_timing` parameter, the report will be run on each archive interval. First check the `report_timing` option parameters to ensure they are valid and there are no additonal spaces or other unwanted characters. Then check that the parameters are correctly set for the desired report generation times. For example, is the correct day of the week number being used if limiting the day of the week parameter. Refer to [*Scheduling report generation*](../../../custom/report_scheduling).
Check the [log file](../../usersguide/running-weewx#monitoring-weewx) for any entries relating to the reports concerned. Errors in the `report_timing` parameter and skipped reports are logged only when `debug=1` in `weewx.conf`.
If the option
[_`report_timing`_](/reference/weewx-options/stdreport/#report_timing) is being
used, and the results are not as expected, there may be an error in the
`report_timing` option. If there are errors in the `report_timing` parameter,
the report will be run on each archive interval. First check the `report_timing`
option parameters to ensure they are valid and there are no additonal spaces or
other unwanted characters. Then check that the parameters are correctly set for
the desired report generation times. For example, is the correct day of the week
number being used if limiting the day of the week parameter. Refer to the
section [_Scheduling report generation_](/custom/report-scheduling/).
Check the log file for any entries relating to the reports concerned. Errors in
the `report_timing` parameter and skipped reports are logged only when `debug=1`
in `weewx.conf`.

View File

@@ -4,9 +4,9 @@ If you are having problems, first look at the hardware, software, and
meteorological problems pages. You might be experiencing a problem that
someone else has already solved.
[Hardware Problems](../hardware)<br/>
[Software Problems](../software)<br/>
[Meteorological Problems](../meteo)
[Hardware problems](../hardware)<br/>
[Software problems](../software)<br/>
[Meteorological problems](../meteo)
Be sure to search the
[weewx-user group](https://groups.google.com/g/weewx-user), especially
@@ -14,7 +14,7 @@ if you are using a driver or skin that is not part of the WeeWX core.
If you still have problems, here are a few things to try on your system:
1. Look at the [log file](../../usersguide/running-weewx#monitoring-weewx). We
1. Look at the [log file](/usersguide/running/#monitoring-weewx). We
are always happy to take questions, but the first thing someone will ask is,
"What did you find in the log file?"

View File

@@ -65,9 +65,9 @@ nav:
- "MySQL/MariaDB": usersguide/mysql-mariadb.md
- "Troubleshooting":
- "What to do": usersguide/troubleshooting/what-to-do.md
- "Hardware Problems": usersguide/troubleshooting/hardware.md
- "Software Problems": usersguide/troubleshooting/software.md
- "Meteorological Problems": usersguide/troubleshooting/meteo.md
- "Hardware problems": usersguide/troubleshooting/hardware.md
- "Software problems": usersguide/troubleshooting/software.md
- "Meteorological problems": usersguide/troubleshooting/meteo.md
- Customization guide:
- "Introduction to customization": custom/introduction.md