Hey Tom! Thanks for your help! I am actually a bit confused how I overlooked these sections in the customisation guide... maybe because I was not aware that the left navigation menu was scrollable and I always stopped scrolling down the main page once I reached the section about "The Standard skin.conf".
It worked all like a charm (expect some small hiccups like not properly expecting 'None' and how to properly import local python modules). Cheers eddy On Thursday, 28 December 2017 00:57:39 UTC+1, Tom Keffer wrote: > > 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 <[email protected] <javascript:>> > 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 >> > >
