I think I'll go with those schema names to keep things easy.
I'm fuzzy on the "rain", though. What time interval is that supposed to cover? The polling interval set in fileparse?
If I remember correctly, the way I hacked simulator was take the 36 seconds (the reporting rate of the hardware) and divided it by 2.5 seconds (the simulator loop interval) to get 14.4. I then divided the amount of rain in 36 seconds by 14.4.
So should I set "rain" to the 36-second rain amount divided by 14.4, or is there a better way to do it?
Oh, another issue I have is the initial accumulation of data for weewx. I'm getting around this now by delaying the start of weewx until 70 seconds after I start collecting data from the bridge to ensure I have a full set of valid data in the file. With the fileparse extension, is there a particular value I could start with that weewx would understand as not being valid data and pass over it? Perhaps "Null" or something similar?
a weewx driver only needs to report raw data from the sensors, in one of METRIC, METRICWX, or US systems (see the weewx customization guide for details about unit systems and conversions).
quality control, filtering, calculation of derived quantities, unit conversions, data storage, reporting, and uploading are all done in other weewx services. the driver should be simple; its job is simply to collect raw data from the hardware. this lets us share code, features, and extensibility across many different types of hardware and hardware architectures.
the fileparse driver has a polling_interval parameter - that determines how often it will read the file. assuming that data from the sensors are written to the file on every sensor read, set the polling_interval to the shortest sensor update interval, which would be 18 seconds for the acurite hardware.
the observation 'rain' is a 'delta' reading - it is the amount of rain since the last observation. rainRate is automatically calculated by the StdWXCalculate service, as are other derived quantities such as dewpoint, windchill, cloudbase, etc. so if your hardware reports a cumulative value for rain, call it rain_total, then the driver should remember the last rain_total and report 'rain' as the difference between last rain_total and current rain_total.
temperature, pressure, and most other observations are 'gauge' readings.
any rainfall totals happen in the reporting layer, typically by querying the database. for example, if you want to answer "how much rain fell last week" you simply do an sql query. the sql query has been simplified for many common meterological reports in the weewx report template system. in this case, the expression:
$week.rain
would do that sql query and return the amount of rainfall in the past week. the template syntax enables you to optionally display/convert units, format the numeric value, etc. its pretty powerful for creating web pages, json data, xml, raw text reports. once again, see the weewx customization guide for many, many, more options and heaps of examples.
finally, if you start using weewx in april, but you know that you have had 100 inches of rain since january 1 and you want that included in your reports, just do something like this:
#set $totalrain = 100 + $year.rain.inch.raw
rain this year: $totalrain
m