For example, here is a typical set of options for sub-sub-section [[[monthrain]]] :. This will generate an image file with name monthrain.
It will be a bar plot. Option yscale controls the y-axis scaling — if left out, the scale will automatically be chosen. However, in this example we are choosing to exercise some degree of control by specifying values explicitly.
If set to None , the corresponding value will be automatically chosen. So, in this example, the setting. Continuing on with the example above, there will be only one plot "line" it will actually be a series of bars and it will have logical name rain.
Because we have not said otherwise, the database column name to be used for this line will be the same as its logical name, that is, rain , but this can be overridden. The plot line will be titled with the indicated label of 'Rain daily total '. The result of all this is the following plot:. More than one observation can be included in a plot. For example, here is how to generate a plot with the week's outside temperature as well as dewpoint:. This would create an image in file monthtempdew.
Another example. Say you want a plot of the day's temperature, overlaid with hourly averages. Here, you are using the same data type outTemp for both plot lines, the first with averages, the second without.
If you do the obvious it won't work:. The option parser does not allow the same section name outTemp in this case to appear more than once at a given level in the configuration file, so an error will be declared technical reason: formally, the sections are an unordered dictionary. This will override the default action that the logical line name is used for the database column. So, our example would look like this:.
Here, the first plot line has been given the name avgTemp to distinguish it from the second line outTemp. Any name will do — it just has to be different.
We have specified that the first line will use data type outTemp and that it will use averaging over a one hour period. The second also uses outTemp , but will not use averaging.
Here's what a plot looks like without and with this option being specified:. WeeWX can produce progressive vector plots as well as the more conventional x-y plots. To produce these, use plot type vector. You need a vector type to produce this kind of plot. There are two: windvec , and windgustvec. While they do not actually appear in the database, WeeWX understands that they represent special vector-types. The first, windvec , represents the average wind in an archive period, the second, windgustvec the max wind in an archive period.
Here's how to produce a progressive vector for one week that shows the hourly biggest wind gusts, along with hourly averages:. This will produce an image file with name weekgustoverlay. It will consist of two progressive vector plots, both using hourly aggregation 3, seconds. For the first set of vectors, the hourly average will be used.
In the second, the max of the gusts will be used:. By default, the sticks in the progressive wind plots point towards the wind source. That is, the stick for a wind from the west will point left. If you have a chronic wind direction as I do , you may want to rotate the default direction so that all the vectors do not line up over the x-axis, overlaying each other.
If you use this kind of plot the out-of-the-box version of WeeWX includes daily, weekly, monthly, and yearly progressive wind plots , a small compass rose will be put in the lower-left corner of the image to show the orientation of North.
Remember that values at any level can override values specified at a higher level. For example, say you want to generate the standard plots, but for a few key observation types such as barometer, you want to also generate some oversized plots to give you extra detail, perhaps for an HTML popup. The standard weewx. The standard plot of barometric pressure will appear in daybarometer.
We now add our special plot of barometric pressure, but specify a larger image size. It's easy to use more than one database in your reports. Here's an example. Each is running WeeWX. Here's how the bindings and database sections of weewx. The two additions have been highlighted. It also defines some characteristics of the binding, such as which manager is to be used and what its schema looks like. The second addition, [[rpi-mysql]] defines the new database. The new database accepts all of them, except for host , which as been set to the remote host rpi-bug , the name of my Raspberry Pi.
How do we use this new binding? First, let's do a text comparison, using tags. Here's what our template looks like:. How would we produce a graph of the two different temperatures? Here's what the relevant section of the skin. This will produce an image with name daycompare.
The first will be of the temperature from the Vantage. It will be labeled WMR inTemp. The results look like this:. At first, I could not get this example to work. The problem turned out to be that the RPi was processing things just a beat behind the Dell, so the temperature for the "current" time wasn't ready when the Dell needed it.
This section is provides suggestions for localization, including translation to different languages and display of data in formats specific to a locale. What happens when you come accross a report that you like, but it is written in another language, or uses time formats that are foreign to your customs? This section explains how to convert the report to local formats and language.
In every HTML template these typically have a file suffix of. For example, for Spanish use es :. The lang can be language-only, e. Then, go through each template file in the skin, translating any text to your target language. For example, suppose you were localizing the Seasons skin to the French language.
Search all the template files for English phrases that need to be translated. As an example, the file current. Go through the report options that are used by the skin, translating labels and modifying formats to follow local conventions.
The default time formats should use whatever locale is defined on the computer running WeeWX. If you still find those foreign, you can customize using the specific directives.
Finally, you will need to set the environment variable LANG to reflect your locale. For example, assuming you set. The decimal point for numbers will also be modified appropriately. Let's say that you have created a new skin. How do you package that skin for use in other languages and locales? This example shows how to translate the Seasons skin for multiple languages.
Create a directory for each language. Each directory contains template files and a skin configuration file. Any text in each template file should be in the target language. Ensure that each HTML template file has the lang set properly. Translate observation names and other labels, and put them into the skin configuration files. There should be one configuration file for each language. Ensure that any locale-specific formatting is specified properly.
For example, consider the current time, which is parameterized in [Units][[TimeFormats]]. The result is multiple reports, each in a different language and localization, independent of the locale of the computer on which they were generated. This is an advanced topic intended for those who wish to try their hand at extending the internal engine in WeeWX.
Before attempting these examples, you should be reasonably proficient with Python. At a high level, WeeWX consists of an engine that is responsible for managing a set of services. A service consists of a Python class which binds its member functions to various events. The engine arranges to have the bound member function called when a specific event happens, such as a new LOOP packet arriving. The services are specified in lists in the [Engine][[Services]] stanza of the configuration file.
The [[Services]] section lists all the services to be run, broken up into different service lists. These lists are designed to orchestrate the data as it flows through the WeeWX engine. For example, you want to make sure data has been processed by, for example, running it through the quality control service, StdQC , before putting them in the database. Similarly, the reporting system must come after the archiving service. These groups insure that things happen in the proper sequence. See the table Default services for a list of the services that are normally run.
The service weewx. By default, it prints out the entire record, which generally includes a lot of possibly distracting information and can be rather messy. Suppose you do not like this, and want it to print out only the time, barometer reading, and the outside temperature whenever a new LOOP packet arrives.
You then need to specify that your print service class should be loaded instead of the default StdPrint service. Unfortunately, the parser ConfigObj does not allow options to be continued on to following lines. Suppose there is no service that can be easily customized for your needs. In this case, a new one can easily be created by subclassing off the abstract base class StdService , and then adding the functionality you need.
Here is an example that implements an alarm, which sends off an email when an arbitrary expression evaluates True. This service expects all the information it needs to be in the configuration file weewx. So, add the following lines to your configuration file:. There are three important points to be noted in this example, each marked with a NOTE flag in the code. In this case, the alarm is sounded if the outside temperature drops below freezing and the wind speed is greater than Note that units must be the same as whatever is being used in your database.
The new service will wait this long before sending another email out. The recipient s are specified by the comma separated option mailto. Many SMTP hosts require user login.
The last two options, from and subject are optional. If not supplied, WeeWX will supply something sensible. Note, however, that some mailers require a valid "from" email address and the one WeeWX supplies may not satisfy its requirements.
To make this all work, you must first copy the alarm. In addition to this example, the distribution also includes a low-battery alarm lowBattery. A very common problem is wanting to augment the data from your weather station with data from some other device.
Generally, you have two approaches for how to handle this:. Suppose you have installed an electric meter at your house and you wish to correlate electrical usage with the weather. The meter has some sort of connection to your computer, allowing you to download the total power consumed. At the end of every archive interval you want to calculate the amount of power consumed during the interval, then add the results to the record coming off your weather station.
How would you do this? Here is the outline of a service that retrieves the electrical consumption data and adds it to the archive record. This adds a new key electricity to the record dictionary and sets it equal to the difference between the amount of power currently consumed and the amount consumed at the last archive record.
Hence, it will be the amount of power consumed over the archive interval. The unit should be Watt-hours. If it's going to cause a delay of more than a couple seconds you might want to put it in a separate thread and feed the results to AddElectricity through a queue.
To make sure your service gets run, you need to add it to one of the service lists in weewx. When you're done, your section [Engine] will look something like this:.
For most users the database defaults will work just fine. However, there may be occasions when you may want to add a new observation type to your database, or change its unit system.
This section shows you how to do this. Every relational database depends on a schema to specify which types to include in the database. When a WeeWX database is first created, it uses a Python version of the schema to initialize the database. However, once the database has been created, the schema is read directly from the database and the Python version is not used again — any changes to it will have no affect.
This means that the strategy for modifying the schema depends on whether or not the database already exists. WeeWX gives you a choice of three different schemas to choose from when creating a new database:.
For most users, the default database schema, schemas. To specify which schema to use when creating a database, modify option schema in section [DataBindings] in weewx.
For example, suppose you wanted to use the classic and smaller schema schemas. Then the section [DataBindings] would look like:. NOTE: This only works when the database is first created. Thereafter, WeeWX reads the schema directly from the database. Changing this option will have no effect! If none of the three starting schemas that come with WeeWX suits your purposes, you can easily create your own. Just pick one of the three schemas as a starting point, then modify it.
Put the results in the user subdirectory, where it will be safe from upgrades. For example, suppose you like the schemas. The type electricity does not appear in the schema, so you'll have to add it before starting up WeeWX. We will call the resulting new schema user. The only change was the addition highlighted of electricity to the list of observation names. Now change option schema under [DataBindings] in weewx.
Start WeeWX. When the new database is created, it will use your modified schema instead of the default. NOTE: This will only work when the database is first created! Thereafter, WeeWX reads the schema directly from the database and your changes will have no effect!
Suppose the database has already been created and you want to add or remove types? Modifying or changing the Python version of the schema will not work, because it is only used when the database is fist created. Be sure to stop WeeWX before attempting to use it. The tool not only adds electricity to the main archive table, but also to the daily summaries. In a similar manner, the tool can remove any unneeded types from an existing database. For example, suppose you are using the schemas.
You can drop the unnecessary types this way:. Unlike the option --add-column , in the interests of efficiency, the option --drop-columns can take more than one type. Adding new columns is easy and fast with the SQLite database, but dropping columns requires copying the whole database.
By specifying more than one type, you can amortize the cost over a single invocation of the utility. NOTE: Dropping types from a database means you will lose any data associated with them!
The data cannot be recovered. Normally, data are stored in the databases using US Customary units and you shouldn't care; it is an "implementation detail". Data can always be displayed using any set of units you want — the section How to change units explains how to change the reporting units. Nevertheless, there may be special situations where you wish to store the data in Metric units.
For example, you may need to allow direct programmatic access to the database from another piece of software that expects metric units. You should not change the database unit system midstream.
That is, do not start with one unit system then, some time later, switch to another. However, you can reconfigure the database by copying it to a new database, performing the unit conversion along the way. You then use this new database. Modify weewx. If you are switching to metric units, the option will look like:. Check permissions. Make sure you have the necessary permissions to do this. Create and populate the new database. This will create a new database nominally, weewx.
Shuffle the databases. Now arrange things so WeeWX can find the new database. Make a backup of the data before doing any of the next steps! You can either shuffle the databases around so the new database has the same name as the old database, or edit weewx. To do the former:. It's worth noting that there's actually a hidden, last step: rebuilding the daily summaries inside the new database.
This will be done automatically by WeeWX at the next startup. In most cases this will be sufficient; however, if anomalies remain in the daily summaries the daily summary tables may be dropped first before rebuilding:. The summaries will automatically be rebuilt the next time WeeWX starts, or they can be rebuilt with the utility:. This is an area that is rapidly changing in WeeWX. Presently, new units and unit groups are added by manipulating the internal dictionaries in WeeWX as described below.
In the future, they may be specified in weewx. In the examples above, we created a new observation type, electricity , and added it to the database schema.
This is done by extending the dictionary weewx. When our new service gets loaded by the WeeWX engine, these few lines will get run. Once the observation has been associated with a unit group, the unit labels and other tag syntax will work for that observation. So, now a tag like:. But, what if we are measuring something entirely new, like force with time? There is nothing in the existing system of units that covers things like newtons or pounds.
We will have to define these new units, as well as the unit group they can belong to. Now, when the service Rocket gets loaded, these lines of code will get executed, adding the necessary unit extensions to WeeWX. Pretty much like any other units. This will cause the generation of an image monthelectric.
If you wish to use the new type in the templates, it will be available using the same syntax as any other type. Here are some other tags that might be useful:. In the section Adding a second data source , we saw an example of how to create a new type for a new data source.
But, what if you just want to add a type that is a derivation of existing types? The WeeWX type dewpoint is an example of this: it's a function of two observables, outTemp , and outHumidity. WeeWX calculates it automatically for you. It can also allow you to add new aggregatioin types.
Naturally, this is an advanced topic but, nevertheless, I'd like to encourage any Python wizards out there to give it a try. Of course, I have selfish reasons for this: I don't want to have to buy every weather station ever invented, and I don't want my roof to look like a weather station farm!
A driver communicates with hardware. Each driver is a single python file that contains the code that is the interface between a device and WeeWX. Or it may communicate over a network to a physical device or a web service. Create a file in the user directory, say mydriver. This file will contain the driver class as well as any hardware-specific code. Inherit from the abstract base class weewx. Try to implement as many of its methods as you can.
This is a factory function that returns an instance of your driver. It has two arguments: the configuration dictionary, and a reference to the WeeWX engine. This should be a Python generator function that yields loop packets, one after another.
Don't worry about stopping it: the engine will do this when an archive record is due. A "loop packet" is a dictionary. At the very minimum it must contain keys for the observation time and for the units used within the packet. Then include any observation types you have in the dictionary. Every packet need not contain the same set of observation types. Different packets can use different unit systems, but all observations within a packet must use the same unit system. If your hardware is capable of measuing an observation type but, for whatever reason, its value is bad maybe a bad checksum?
If your hardware is incapable of measuring an observation type, then leave it out of the dictionary. A couple of observation types are tricky, in particular, rain. The field rain in a LOOP packet should be the amount of rain that has fallen since the last packet. Because LOOP packets are emitted fairly frequently, this is likely to be a small number. If your hardware does not provide this value, you might have to infer it from changes in whatever value it provides, for example changes in the daily or monthly rainfall.
Wind is another tricky one. It is actually broken up into four different observations: windSpeed , windDir , windGust , and windGustDir. Supply as many as you can.
Be careful when reporting pressure. Many users are running on the Raspberry Pi. The images on this page and throughout this web site are from sample stations running WeeWX. Thousands of stations throughout the world run WeeWX, many of whom have opted-in to be shown on our station map.
I wrote WeeWX over the winter of for two reasons: it was a wet and miserable winter here in Oregon with not much else to do, so there was no good reason not to, and because I wanted a simple, easy-to-understand server to run my Davis VantagePro2 weather station on a Linux box. I had been using wview, which is a high-performance and feature rich system authored by Mark Teel with lots of users. If you want to let weewx install it automatically, please see the Quick Start section of these docs.
It's also possible that some files are missing because they are only copied once or generated at specific times. This page shows how to manually install the NeoWX Material skin. There are no real system requirements. The default value is utfsig. The one character string used to separate fields. Default is , comma. Determines how the time interval WeeWX archive table field interval between successive observations is derived. The interval can be derived by one of three methods:.
The default value is derive. If the CSV source data records are equally spaced in time, but some records are missing, then a better result may be achieved using conf or a fixed interval setting.
Determines whether simple quality control checks are applied to imported data. In such cases you will be alerted through a short message similar to:. As derived observations are calculated after the quality control check is applied, derived observations are not subject to quality control checks. The default is True. Determines whether any missing derived observations will be calculated from the imported data. Determines whether invalid data in a source field is ignored or the import aborted.
To speed up database operations imported records are committed to database in groups of records rather than individually. The size of the group is set by the tranche parameter. Increasing the tranche parameter may result in a slight speed increase but at the expense of increased memory usage. Decreasing the tranche parameter will result in less memory usage but at the expense of more frequent database access and likely increased time to import.
The default is which should suit most users. WeeWX records each record with a unique unix epoch timestamp, whereas many weather station applications or web sources export observational data with a human readable date-time. This option consists of Python strptime format codes and literal characters to represent the date-time data being imported.
CSV data containing separate date and time fields may require further manual processing before they can be imported. The WeeWX rain field records rainfall that was recorded in the preceding archive period, so for a five minute archive period the rain field in each archive record would contain the total rainfall that fell in the previous five minutes. Many weather station applications provide a daily or yearly total. The former may be possible by selecting another rainfall field if available in the source data, otherwise it will require manual manipulation of the source data.
Any value inside the range is normalised to the range 0 to inclusive e. The map consists of one row per field using the format:. A mapping is not required for every WeeWX archive field e. Unused field mapping lines will not be used and may be omitted.
If the source data includes a field that contains a WeeWX unit system code i. Note Any WeeWX archive fields that are derived e. Determines how the time interval WeeWX database field interval between successive observations is determined. This option is identical in operation to the CSV interval option but applies to Weather Underground imports only. The most appropriate setting will depend on the completeness and time accuracy of the Weather Underground data being imported.
This option is identical in operation to the CSV qc option but applies to Weather Underground imports only. As Weather Underground imports at times contain nonsense values, particularly for fields for which no data was uploaded to Weather Underground by the PWS, the use of quality control checks on imported data can prevent these nonsense values from being imported and contaminating the WeeWX database.
The number of records written to the WeeWX database in each transaction. This option is identical in operation to the CSV tranche option but applies to Weather Underground imports only. Determines the range of acceptable wind direction values in degrees.
The default is 0, which should suit most users. The [Cumulus] section contains the options relating to the import of observational data from Cumulus monthly log files. The full path to the directory containing the Cumulus monthly log files to be imported. The Cumulus monthly log file encoding.
The default is utfsig. This option is identical in operation to the CSV interval option but applies to Cumulus monthly log file imports only. The most appropriate setting will depend on the completeness and time accuracy of the Cumulus data being imported. This option is identical in operation to the CSV qc option but applies to Cumulus imports only.
The character used as the date field separator in the Cumulus monthly log file. This parameter must be included in quotation marks. The character used as the field delimiter in the Cumulus monthly log file. A comma is frequently used but it may be another character depending on the settings on the machine that produced the Cumulus monthly log files.
Default is ','. The character used as the decimal point in the Cumulus monthly log files. A full stop is frequently used but it may be another character depending on the settings on the machine that produced the Cumulus monthly log files. Default is '. This option is identical in operation to the CSV tranche option but applies to Cumulus monthly log file imports only. The [[Units]] stanza defines the units used in the Cumulus monthly log files. Units settings are required for temperature , pressure , rain and speed.
The format for each setting is:. As Cumulus supports a different suite of possible units only a subset of the available WeeWX unit names can be used for some settings. The [WD] section contains the options relating to the import of observational data from Weather Display monthly log files.
The full path to the directory containing the Weather Display monthly log files to be imported. The Weather Display monthly log files to be processed. Weather Display uses multiple files to record each month of data. Which monthly log files are produced depends on the Weather Display configuration and the capabilities of the weather station. Either the. The monthly log files selected for processing should be chosen carefully as the selected log files will determine the Weather Display data fields available for import.
Note Whilst the above log files may contain the indicated data the data may only be imported subject to a suitable field map and in-use WeeWX archive table schema refer to the [[FieldMap]] option. The Weather Display monthly log file encoding. This option is identical in operation to the CSV interval option but applies to Weather Display monthly log file imports only.
This option is identical in operation to the CSV qc option but applies to Weather Display imports only. The character used as the field delimiter in Weather Display text format monthly log files.
A space is normally used but another character may be used if necessary. Default is ' '. The character used as the field delimiter in Weather Display csv format monthly log files. A comma is normally used but another character may be used if necessary. The character used as the decimal point in the Weather Display monthly log files. A full stop is frequently used but another character may be used if necessary.
Determines whether missing log files are to be ignored or the import aborted. Weather Display log files are complete in themselves and a missing log file will have no effect other than there will be no imported data for the period covered by the missing log file.
This option is identical in operation to the CSV tranche option but applies to Weather Display monthly log file imports only. Determines whether extreme temperature and humidity values are ignored. Weather Display log files record the value for temperature and humidity fields if no corresponding sensor is present.
The [[Units]] stanza defines the units used in the Weather Display monthly log files. In such cases the units configuration option may be set to Metric or US to select either Metric or US customary units. It is also possible to individually specify the log file units used for temperature , pressure , rain and speed. As Weather Display supports a different suite of possible units only a subset of the available WeeWX unit names can be used for some settings. The preferred method for defining the Weather Display log file units is through the use of the units configuration option.
When defining the import log file units either the units configuration option should be used or the individual temperature , pressure , rain and speed units defined but not both. If both the units configuration option is defined as well as the individual temperature , pressure , rain and speed units defined then the units configuration option takes precedence and all other units settings are ignored.
By default imported Weather Display data is mapped to the corresponding WeeWX archive fields using a default field map. The default field map will likely suit most users; however, depending on the station capabilities and the in-use WeeWX database schema, a custom field map may be required if Weather Display monthly logs contain data from additional sensors that cannot be stored in the WeeWX archive using the default field map.
A custom field map also makes it possible to limit the Weather Display monthly log data fields that are imported into WeeWX. The available Weather Display import field names are listed in the table below.
The [WeatherCat] section contains the options relating to the import of observational data from WeatherCat monthly. The full path to the directory containing the year directories that contain the WeatherCat monthly. The WeatherCat monthly. This option is identical in operation to the CSV interval option but applies to WeatherCat imports only. As WeatherCat monthly. The most appropriate setting will depend on the completeness and time accuracy of the WeatherCat data being imported.
The character used as the decimal point in the WeatherCat monthly. This option is identical in operation to the CSV tranche option but applies to WeatherCat imports only. The [[Units]] stanza defines the units used in the WeatherCat monthly. Unit settings are required for temperature , pressure , rain and speed. As WeatherCat supports a different suite of possible units only a subset of the available WeeWX unit names can be used for some settings. If WeeWX must remain running e.
The CSV source file must be structured as follows:. Capitalisation is ignored as are any spaces, hyphens or other white space. At present only English abbreviations and directions are supported. If these derived fields exist in the in-use database schema they will be saved to the database as well.
The output includes details about the data source, the destination of the imported data and some other details on how the data will be processed. The import will then be performed but no data will be written to the WeeWX database. Upon completion a brief summary of the records processed is provided. This will result in a short preamble similar to that from the dry run.
At the end of the preamble there will be a prompt:. The line commencing with Unique records processed should update as records are imported with progress information on number of records processed, number of unique records imported and the date time of the latest record processed.
A brief summary should be displayed similar to the following:. In such cases you should take note of the timestamp of the record s concerned and make a decision about whether to delete the pre-existing record and re-import the record or retain the pre-existing record.
As such, the data is analogous to the WeeWX archive table. For example, if the API response has no solar radiation field the WeeWX radiation archive field will have no data stored. Note As Weather Underground imports at times contain nonsense values, particularly for fields for which no data were uploaded to Weather Underground by the PWS, the use of quality control checks on imported data can prevent these nonsense values from being imported and contaminating the WeeWX database.
In this case the --from and --to options have been used to import Weather Underground records from pm on 20 January to am on 23 January inclusive. Note If the --date option is omitted, or a date not date-time range is specified using the --from and --to options during a Weather Underground import, then one or more full days of history data will be imported.
This includes records timestamped from inclusive at the start of the day up to but NOT including the record at the end of the last day. As the timestamped record refers to observations of the previous interval, such an import actually includes one record with observations from the previous day the record at the start of the day.
Such imports may be best handled as a series of imports of smaller time spans. This will result in a short preamble with details on the data source, the destination of the imported data and some other details on how the data will be processed.
The import will then be performed but no data will written to the WeeWX database. Note Any periods for which no data could be obtained will be skipped.
A short explanatory note to this effect will be displayed against the period concerned and an entry included in the log. This will result in a short preamble similar to that of a dry run. If the import spans multiple days then a new Period line is created for each day.
Note The new Weather Underground API appears to have an issue when obtaining historical data for the current day. However, subsequent later API queries during the same day return the same set of records rather than all records up to and including the time of the latest API query. Users importing Weather Underground data that includes data from the current day are advised to carefully check the WeeWX log to ensure that all expected records were imported. If some records are missing from the current day try running an import for the current day again using the --date option setting.
If this fails then wait until the following day and perform another import for the day concerned again using the --date option setting. In all cases confirm what data has been imported by referring to the WeeWX log. A Cumulus monthly log file records weather station observations for a single month. These files are accumulated over time and can be considered analogous to the WeeWX archive table. Note The nine periods correspond to the nine monthly log files used for this import.
The lack of data may be due to a missing Cumulus monthly log file. This will result in a preamble similar to that of a dry run.
In addition, if the --date option is used then source data that falls outside the date or date range specified with the --date option is ignored. In such cases the preamble may look similar to:. Again if there is more than one Cumulus monthly log file and if the --date option is used then the progress information may instead look similar to:.
If the import spans multiple months ie multiple monthly log files then a new Period line is created for each month. In such cases take note of the timestamp of the record s concerned and make a decision about whether to delete the pre-existing record and re-import the record or retain the pre-existing record. Weather Display records observational data on a monthly basis in a number of either space delimited. The Weather Display monthly log files record observational data using a nominal 1 minute interval with each file recording various observations for the month and year designated by the MM and YYYY components of the file name.
The WeeWX archive fields populated during the import of Weather Display data depends on the field mapping specified in [[FieldMap]] stanza in the import configuration file. A given WeeWX field will be populated if:. The following WeeWX archive fields will be populated from other settings or configuration options and need not be included in the field map:. Note Due to some peculiarities of the Weather Display log structure it may be prudent to use the --suppress--warnings option during the initial dry run so the overall progress of the import can be observed.
Note The five periods correspond to the five months of log files used for this import. The lack of data may be due to a missing Weather Display log file. Note The --suppress--warnings option has been used to suppress the previously encountered warnings. Again if there is more than one month of Weather Display monthly log files and if the --date option is used then the progress information may instead look similar to:.
The line commencing with Unique records processed should update as records are imported with progress information on number of unique records processed and the date time of the latest record processed.
If the import spans multiple months then a new Period line is created for each month. A WeatherCat monthly. Note If a field in the WeatherCat monthly. Note Whilst WeatherCat monthly. For this reason the field map used for WeatherCat imports includes fields that may not exist in some WeatherCat monthly. These warnings can be extensive and may detract from the ability of the user to monitor the progress of the import. It may be prudent to use the --suppress--warnings option during the initial dry run so the overall progress of the import can be more easily observed.
Note The eight periods correspond to the eight monthly. The lack of data may be due to a missing WeatherCat monthly. If the warnings relate to fields that are not included in the import source data the warning may be safely ignored.
0コメント