I think you would be happiest if you wrote a simple service to calculate
SVD and AVD, then add them to the archive records. If you include them in
your database schema, then they will also appear in the database, making
them easy to use in reports. A last step to making them first-class
citizens in WeeWX would be to have WeeWX recognize them as members of the
unit group, group_pressure.
The new service is very simple. Something like (NOT TESTED):
import weewx.engine
import weewx.units
import weewx.uwxutils
class VaporPressure(weewx.engine.StdService):
"""Service that calculates vapor pressure and adds it to an archive
record"""
def __init__(self, engine, config_dict):
# Pass the initialization information on to my superclass:
super(VaporPressure, self).__init__(engine, config_dict)
# When a new archive record appears, call the function addVP()
self.bind(weewx.NEW_ARCHIVE_RECORD, self.addVP)
def addVP(self, event):
"""Add vapor pressure to a record"""
# Convert the record to Metric units:
recordM = weewx.units.to_METRICWX(event.record)
event.record['SVP'] =
weewx.uwxutils.TWxUtils.SaturationVaporPressure(recordM['outTemp'])
event.record['AVP'] = record['outHumidity'] * event.record['SVP'] /
100.0
Here, I've used the SVP calculation algorithm already present in WeeWX, but
you can substitute your own.
For more information on writing a custom service, see the section *Adding a
service <http://weewx.com/docs/customizing.htm#Adding_a_service>* in the
Customizing Guide.
To add AVP and SVP to the database schema, see the section *Adding a new
type to the database
<http://weewx.com/docs/customizing.htm#add_archive_type>* in the
Customizing Guide.
To have AVP and SVP be recognized as members of group_pressure, see the
section *Assigning a unit group
<http://weewx.com/docs/customizing.htm#Assigning_a_unit_group>* in the
Customizing Guide.
This is not a hard project, but it will have its challenges if you are not
familiar with Python.
-tk
On Wed, Dec 27, 2017 at 3:03 PM, Eddy B <farn...@gmail.com> wrote:
> Hey all!
>
> For a christmas present I set up a weewx instance running on a rasberry pi
> for my father-in-law. He is using a KlimaLogg Pro station for a while with
> all 8 additional sensors in use.
> Up until now he used a self-created excel sheet, where he imported the
> data using the windows software of the KlimaLogg. In this excel sheet he
> implemented a formula to calculate the Saturation Vapor Density and the
> Actual Vapor Density (SVD & AVD) to get the actual amount of water in the
> air (in g/m^3). With this information he decides wether he has to air his
> rooms.
>
> Now he really would like to have this information available somehow at the
> HTML report page created by weewx. (I guess the dewpoint is probably
> providing more or less the same information, but he seems to be quite proud
> of his formula).
>
> So I started to look into possible ways of doing this and would be
> interested in more professional opinions.
>
> First idea: I considered to just replace the formula to calculate the
> heatindex in bin/weewx/wxformulas.py. This would probably be the easiest
> way for me since he is not interested in the actual heat index and I would
> only have to change 1-2 lines of python code (and some configs to re-label
> the heatindex). But of course this could get complicated to maintain with
> future upgrades of weewx itself.
>
> Second idea: Making use of the user/ folder to place the custom functions
> in there. But I am a bit of a loss here of how to actually hook it up
> properly. My original plan was to extend the database by additional columns
> similar to heatindex and dewpoint but it does not seem to be too trivial
> nor do I really fully grasped how weewx works on the internal level to feel
> confident about this change for now.
>
> Third idea: I also read the "Defining new tags" section on the
> customization guide which sounded promising by using the Cheetah template
> enginge. I wouldn't have the data in the database but I wouldn't mind that
> too much. The two examples listed in the guides were all about aggregating
> existing information in a different way, so I am not exactly sure if I
> could also use this approach to basically derive a new number for every
> datapoint read out of the database?
>
> Fourth idea: Instead of modifying the core files I considered extending
> the klimalogg python module by basically extending the section where the
> interaction for the dewpoint and heatindex calculations happen by a third
> calculation. But again this might get complicated with future updates of
> the klimalogg driver and the klimalogg driver already seems to make heavy
> use of re-labeling existing observables to support all 9 sensors for each
> temperature and humidity and adding 9 more seems to be problematic at first
> glance.
>
> Fifth and final idea: It seems like I could also generate a PHP file
> instead of a HTML file, so I could just do all my db calls and calculations
> as some kind of post-processing happening after weewx and cheetah do their
> work.
>
> So what do the experts think?
>
> eddy
>
