Author Topic: Adding New Temperatures  (Read 2975 times)

0 Members and 1 Guest are viewing this topic.

Offline wcndave

  • Member
  • *
  • Posts: 46
Adding New Temperatures
« on: August 04, 2018, 03:35:55 PM »
I have read the section on adding new types to the database, however I felt there might be a simpler way I'm missing for types of data that already exist.

I see there's extraTemp2 etc, however they run out, and I'd like some for a series of greenhouses, attic, garage, shed, workshop if possible.

Is there an easy way to add more of an existing type of reading?

Also in http://www.weewx.com/docs/customizing.htm#units I can't see how lightning strikes and distance are handled.

Thanks for any help

Dave

Offline gjr80

  • Member
  • *
  • Posts: 45
Re: Adding New Temperatures
« Reply #1 on: August 04, 2018, 08:47:43 PM »
Hi,

There are a few ways to add additional data fields to the database, the simplest being to use a currently unused field. The disadvantage is you are stuck with the existing field names and as you say in your case you need more than is currently available. The other approaches involve defining a custom database schema and then using that schema to define your database structure.

When you say that you read the section on adding new types to the database, I presume you mean the Add a new type to the archive database section in the Customization Guide. The example given there is fine and quite appropriate if you have written some code (such as in the electricity.py example) to add extra fields to the loop and/or archive packets/records. What isn't covered is the case where your station/driver already provides the extra data you require but the database has no suitable field(s). In such cases it is unlikely you have some code like electricity.py so where do you add the code to customize the database? The answer is you add it to the file user/extensions.py, so given the electricity example mentioned you would simply add the database schema code to extensions.py as follows:

Code: [Select]
import locale
# This will use the locale specified by the environment variable 'LANG'
# Other options are possible. See:
# http://docs.python.org/2/library/locale.html#locale.setlocale
locale.setlocale(locale.LC_ALL, '')

import schemas.wview
schema_with_electricity = schemas.wview.schema + [('electricity', 'REAL')]

in your case replace electricity with whatever field name you want, for multiple fields just duplicate + [('electricity', 'REAL')] replacing electricity with the field name required.

You need to then follow the rest of the steps in the recipe. Though if you are starting from scratch, once you have completed step 2 (modify wx_binding) you can just delete your existing database then start WeeWX and WeeWX will automatically create the database using your new schema. Steps 3 to 6 actually cover the situation where you are adding fields to an existing database.

I did mention there were other approaches, one is essentially a slight variation of the modified database schema. If you are in the situation of adding many fields to the database it may be simpler and clearer to just define a new schema and tell WeeWX to use that schema. You will find the default WeeWX schema defined in schemas/wview.py, you can just straight define a new schema in extensions.py noting that there are a number of mandatory fields (dateTime, interval and usUnits).

Another approach is to leave the WeeWX database as is and utilise a second database for your extra data. This is a more elegant but complex approach that requires a few more python skills. I won't go into it here.

So in summary the following approaches (in order of complexity) are available:
1. utilise existing but unused database fields
2. use a customised database schema by adding to the existing schema
3. use a customised database schema by creating a new schema
4. use a second database

With regards to your units question, I am not sure what exactly you are after. You will find no mention of lightning strikes and (lightning) distance in the table you linked as lightning is not handled natively by WeeWX (but easily added). If you were to add lightning strike counts and lightning distance to WeeWX then they would use the unit groups group_count and group_distance respectively. Looking at the table I note that group_count is not listed, I am not sure why it was omitted, it is not used often but is used for leaf wetness and other unitless obs. Will make sure it is added.

If you were after some other information re lightning units please let us know.

Gary

PS. You will find that the active WeeWX support forums are on Google groups not here. weewx-user for general user queries and weewx-development for development related issues. Searching weewx-user should reveal numerous threads regarding customising the database and recording lightning data.

Offline wcndave

  • Member
  • *
  • Posts: 46
Re: Adding New Temperatures
« Reply #2 on: August 05, 2018, 03:08:19 AM »
Wow, many thanks for the detailed response, options two and three almost certainly what I'm after.

I noticed a couple of years back users were actively working on lightning. Surprised It's not standard now in weewx, but I get that it's all peoples free time...

Many thanks!

Offline vreihen

  • El Niņo chaser
  • Forecaster
  • *****
  • Posts: 1216
  • K2BIG
Re: Adding New Temperatures
« Reply #3 on: August 05, 2018, 09:15:10 AM »
When I get a chance to add the lightning sensor stuff to my weewx driver, I'm going to follow this as the minimum:

https://github.com/weewx/weewx/wiki/as3935
WU Gold Stars for everyone! :lol:

Offline wcndave

  • Member
  • *
  • Posts: 46
Re: Adding New Temperatures
« Reply #4 on: August 05, 2018, 11:39:19 AM »
I have an acurite sensor and am receiving data, although it doesn't make complete sense, and there's nowhere to put it.  There was another thread with a group working on this but it closed two years ago, so I thought it might all be in weewx by now..
« Last Edit: August 06, 2018, 09:07:22 AM by wcndave »

Offline wcndave

  • Member
  • *
  • Posts: 46
Re: Adding New Temperatures
« Reply #5 on: August 18, 2018, 04:50:44 PM »
Thanks, I was able to add extraHumid3 and see that working.

what was odd, was that I assumed I'd also need to assign to a group, so I added

Code: [Select]
import weewx.units
weewx.units.obs_group_dict['extraHumid3'] = 'group_percent'

However, even before I did that, the values showed as % in my reports.

How did it know to do that? and do I therefore not need the group definitions above?



With regards to your units question, I am not sure what exactly you are after. You will find no mention of lightning strikes and (lightning) distance in the table you linked as lightning is not handled natively by WeeWX (but easily added). If you were to add lightning strike counts and lightning distance to WeeWX then they would use the unit groups group_count and group_distance respectively. Looking at the table I note that group_count is not listed, I am not sure why it was omitted, it is not used often but is used for leaf wetness and other unitless obs. Will make sure it is added.

If you were after some other information re lightning units please let us know.


I will try to do that.  I assume that a group count will show the difference between readings in order to actually display data?  Or is there some other way to do that in the skin template, or in the calculations section.


PS. You will find that the active WeeWX support forums are on Google groups not here. weewx-user for general user queries and weewx-development for development related issues. Searching weewx-user should reveal numerous threads regarding customising the database and recording lightning data.

Thanks, I had searched there, and as there was a topic on wxF I posted here instead.

Will post new enquiries to the google group.

Many thanks again!

Dave

Offline gjr80

  • Member
  • *
  • Posts: 45
Re: Adding New Temperatures
« Reply #6 on: August 18, 2018, 08:57:50 PM »
Thanks, I was able to add extraHumid3 and see that working.

what was odd, was that I assumed I'd also need to assign to a group, so I added

Code: [Select]
import weewx.units
weewx.units.obs_group_dict['extraHumid3'] = 'group_percent'

However, even before I did that, the values showed as % in my reports.

How did it know to do that? and do I therefore not need the group definitions above?

There are a couple of processes at play here that are not apparent to the user. Firstly, there is the creation of the archive record and its processing/interpretation by WeeWX. Archive records are either generated by the station and passed to WeeWX (ie hardware record generation, Davis stations being a prime example) or WeeWX generates the archive record based on loop data (loop data being the frequent point-in-time data being received from the station). The latter is known as software record generation. In either case if a given field is provided by the station/driver it will appear in the archive record being processed by WeeWX. Now WeeWX knows how to interpret a number of fields, outTemp being an obvious and common one. If you have a look at bin/weewx/units.py and look at the obs_group_dict dictionary (circa line 57) you will see all of the obs WeeWX knows about and the observation groups they belong to. You will see extraHumidity3 is included. Why, well extraHumidity3 (and a few others) are used by some Davis stations so it made sense I guess to include them(the vantage driver was the first written and the Davis protocol is freely available).

The second process that goes on is that of saving data to the database. Simply put WeeWX will only save those obs that are common to the archive record and the database schema being used. WeeWX defaults to using the wview schema, you can find the wview schema in bin/schemas/wview.py. You will see in the wview schema there is only extraHumidity1 and extraHumidity2; no extraHumidity3. Why, largely because when WeeWX was developed the decision was made to use the wview schema as the default schema and the wview schema does not include extraHumidity3. So in the case of extraHumidity3 even though we have extraHumidity3 in the archive record and WeeWX knows how to interpret it, it will not be saved to the database and hence we can't plot it or display any historical extraHumidity3 stats, you are limited to only using/displaying the current value.

As for the final part of your question, do I need the definition. Well no you don't as WeeWX is already aware of which observation group extraHumidity3 belongs to. Does the extra definition hurt, no it doesn't and there is no real processing penalty as the definition is a statement that is processed once when WeeWX starts.

Gary

Offline wcndave

  • Member
  • *
  • Posts: 46
Re: Adding New Temperatures
« Reply #7 on: August 19, 2018, 05:55:17 PM »
Thanks, it makes sense now. H3 is known by groups def, however is not in the db as default.

Thanks again!

 

anything