hello marco!

this sounds like a wonderful project!  i am working on a community-oriented 
water level project that measures tide depths using maxbotix sensors for 
sea level rise analysis - we are hoping to get accuracies that are 
acceptable for use by the US NOAA in their research.

short answer:

assuming that you use a single database, and assuming that you emit all of 
the sensor data to a single text file that is read by the fileparse driver: 
you should use names that correspond directly to the names in the schema.  
in the case of observations related to water level, i would suggest the 
following:

temperature - use 'extraTemp1' (or extraTemp2 or 3 or ... if 1 is already 
in use)
Battery_SOH - use 'batteryStatus1' (or 2 or 3 or ... corresponding to the 
temperature)
level - use 'snowDepth'

in the weewx config file, add label entries in a [Defaults] section of 
[StdReport] so they show up in every skin.  you might have to set the units 
on snowDepth - try it first as-is, then if the units are not right in the 
Seasons skins you can adjust.

long answer:

let's look at your problem from two points of view.  first, how to collect 
the data.  it sounds like you are doing that already use the fileparse 
driver: your software collects data from sensors, saves the data to a 
single file, then the fileparse driver reads the file.  with this 
configuration, the names used in fileparse map directly to database field 
names.  so if there is a name in fileparse that does not exist in the 
database schema, that observation will not be retained (but you can still 
see it in LOOP/archive data when you run weewx directly).

a more advanced approach (but not necessarily better!) would be to write 
your own weewx driver.  in this case, the driver would poll the sensors map 
the observations directly to database field names.  this approach 
eliminates the need for saving to file and reading from file on every 
LOOP/archive.  you can write the drive so that it can be tested directly, 
such as when you need to test the code that communicates with the sensors 
(see other weewx drivers such as weewx-maxbotix, weewx-gw1000, weewx-sdr, 
for examples of how to do this).

second point of view is how to store the data.  for this part there are two 
approaches: (a) overload existing fields in the standard schema, or (b) 
define your own schema.

if you do not have many additional observations, then overloading existing 
fields is the easiest, yet still robust and maintainable option.  however, 
beware that you might have to override the units, and you will almost 
certainly have to define your own labels.  do the units overrides in your 
bin/user/extensions.py file.  do the label overrides in the weewx.conf 
file, preferably in a [Defaults] section so that they show up in every 
skin, whether it is a standard weewx skin or something you create.

defining your own schema can be done within a driver file (see the 
weewx-maxbotix driver as an example), or in the bin/user/extensions.py 
file, or a standalone schema file in the bin/user directory.  this is a 
good option if you have more than 10 observations that do not correspond 
well to existing fields, or if you are already using all of the existing 
fields. i'm not sure if we have a section in the customization guide yet 
about using an entirely different schema...


-- 
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 on the web visit 
https://groups.google.com/d/msgid/weewx-user/e0da8b62-e85b-4b81-86d9-4850d6b87a9an%40googlegroups.com.

Reply via email to