From 065ff4e1ebe4fa779453bdef8bd3fcef9ac0c123 Mon Sep 17 00:00:00 2001 From: Tom Keffer Date: Sat, 25 Oct 2014 20:23:19 +0000 Subject: [PATCH] Fixed some HTML errors. Clarified wording on how to write a custom driver. --- docs/customizing.htm | 73 ++++++++++++++++++++++++++++---------------- 1 file changed, 47 insertions(+), 26 deletions(-) diff --git a/docs/customizing.htm b/docs/customizing.htm index 221927f6..8a99d112 100644 --- a/docs/customizing.htm +++ b/docs/customizing.htm @@ -24,7 +24,7 @@ table#stattypes td {

Customizing weewx
Version: 2.7.0 - +

Table of Contents

@@ -1576,12 +1576,12 @@ class MyXSearch(SearchList): #1 
 [Extras]
     radar_img = http://radar.weather.gov/ridge/lite/N0R/RTX_loop.gif
-    radar_url = http://radar.weather.gov/ridge/radar.php?product=NCR&rid=RTX&loop=yes
+ radar_url = http://radar.weather.gov/ridge/radar.php?product=NCR&rid=RTX&loop=yes

results in a nice image of a radar centered on Portland, Oregon. When you click on it, it gives you a detailed, animated view. - Take a look at + If you live in the USA, take a look at the NOAA radar website - to find a nice one for you in the USA. In other countries, you + to find a nice one that will work for you. In other countries, you will have to consult your local weather service.

googleAnalyticsId

@@ -2656,7 +2656,7 @@ class MyAlarm(StdService): how to do this, using the utility $BIN_ROOT/wee_config_database.

This utility also has the ability to check a sqlite version of the archive - database for embedded strings (where a float is expected).

+ database for embedded strings (where a float is expected).

Before starting, it's worth running the utility with the --help flag to see how it is used:

$BIN_ROOT/wee_config_database --help
@@ -2932,23 +2932,31 @@ class="symcode">$CONFIG_ROOT/weewx.conf will use the new unit system.

Porting to new weather station hardware

-

Naturally, this is an advanced topic but, nevertheless, I'd +

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! It's expensive, - and my roof would look like a weather station farm.

+ course, I have selfish reasons for doing this: I don't want to + buy every weather station ever invented, and I don't want my roof + to look like a weather station farm!

Here's the general strategy for doing a port.

Implement the driver

Inherit from the abstract base class weewx.abstractstation.AbstractStation. Try to implement as many of its methods as you can. At the - very minimum, you must implement the first two - methods, hardware_name - and genLoopPackets.

-

hardware_name

-

Return a string with a short nickname for the hardware, such - as "ACME X90"

-

genLoopPackets

+ very minimum, you must implement the first two, the attribute + hardware_name, + and the function genLoopPackets().

+ +

+ hardware_name +

+

+ This can be either an attribute, or a property + function. It should return a string with a short nickname for + the hardware, such as "ACME X90." +

+ +

genLoopPackets()

This should be a generator function that yields loop packets, one after @@ -2975,13 +2983,13 @@ class="symcode">$CONFIG_ROOT/weewx.conf -

Then include any observation types you have in the dictionary. Every +

Then include any observation types you have into 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 has an error and you don't have a value, you can either leave it out of the dictionary or (preferred) set its value to None.

-

A couple of observation types are tricky. In particular, rain. +

A couple of observation types are tricky. In particular, rain. Generally, weewx expects to see a packet with the amount of rain that fell in that packet period included as observation 'rain'. It then sums up all the @@ -3030,36 +3038,49 @@ class="symcode">$CONFIG_ROOT/weewx.conf -

-

genArchiveRecords

+ +

genArchiveRecords()

If your hardware does not have an archive record logger, then weewx can do the record generation for you. It will automatically collect all the types it sees in your loop packets then emit a record with the averages (in some cases the sum or max value) of all those types. If it doesn't see a type, then it won't appear in the - emitted record. If your hardware does have a logger, then you + emitted record.

+

However, if your hardware does have a logger, then you should implement method - genArchiveRecords as well. It should + genArchiveRecords() as well. It should be a generator function that returns all the records since a given time.

-

getTime

+ +

archive_interval

+

If you implement function genArchiveRecords() + above, then you should also implement archive_interval + as either an attribute, or as a property + function. It should return the archive + interval in seconds.

+ +

getTime()

If your hardware has an onboard clock and supports reading the time from it, then you may want to implement this method. It takes no argument. It should return the time in Unix Epoch Time.

-

setTime

+ +

setTime()

If your hardware has an onboard clock supports setting it, then you may want to implement this method. It takes no argument and does not need to return anything.

-

closePort

+ +

closePort()

If the driver needs to close a serial port, terminate a thread, close a database, or perform any other activity before the application terminates, then you must supply this function. Weewx will call it if it needs to shut down your console (usually in the case of an error).

-

loader

+ +

loader()

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.