One thing I forgot, a side effect of the *StdCalibrate* approach is that loop packets and archive records will contain both fields *pm25_2* and *extraTemp2* and they will contain the same data. The GW1000 field map approach will result in *extraTemp2* but not *pm25_2* appearing in loop packets and archive records. Having both fields appear is not a problem as *pm25_2* is essentially ignored as it does not appear in the database schema.
Gary On Tuesday, 22 December 2020 at 16:06:11 UTC+10 gjr80 wrote: > Rainer, > > There are a few approaches that would solve you problem. You could use the > *StdCalibrate* service to simply assign your existing sensor data to a > another field or if you needed to do something beyond the limited > capabilities of the *StdCalibrate* service could write your own custom > service to do what you need. The other alternative for data that comes from > a driver with a sensor/field map is to simply change the sensor/field map > so that the driver places the data concerned into the field you wish to use > right from the start. > > Please note, in the following examples I have used *extraTemp2* as the > field to be recycled, this is a poor choice for a couple of reasons; > firstly it is quite possible a GW1000 user would want to use *extraTemp2* > for additional temperature sensors. Secondly, *extraTemp2* normally holds > temperature data and we will now be storing non-temperature data in the > field, better to use a field that stores the same type of data if possible > (more precisely the same unit type, eg pressure, concentration, speed etc). > In this case the use of WeeWX field *no2* or *pm1_0* may have been better. > > In your case I would customise the GW1000 driver field map. In this > example let's assume you want to store your second PM2.5 sensor in WeeWX > field *extraTemp2* and your GW1000 is emitting data from your second > PM2.5 sensor in field *pm25_2*. In order to change the sensor map for the > GW1000 we need to know two things, what field we are mapping from and what > field we are mapping to. We know we are mapping to *extraTemp2* but we > are not actually mapping from *pm25_2*, we are actually mapping from > GW1000 internal field *pm252* (in many cases the internal GW1000 field is > the same as the field name that appears in the loop packet but some are > different for a number of reasons that I will not go into here). You will > find details of the GW1000 driver default field map and internal field > names in the GW1000 driver Field map wiki entry > <https://github.com/gjr80/weewx-gw1000/wiki/Field-map>. If we want to > alter just a small number of field map entries we can do so using the > *[[field_map_extensions]]* stanza (if we wanted to re-define the entire > field map we would use the *[[field_map]]* stanza) under *[GW1000]* in > *weewx.conf* as follows: > > [GW1000] > .... > [[field_map_extensions]] > extraTemp2 = pm252 > > There is one other step you will need to follow and that is to ensure that > your 'recycled' field is set to the appropriate unit group. All fields in > the WeeWX database schema are assigned to a unit group, that way WeeWX > knows the data in, for example, WeeWX field *outTemp* is a temperature > and not a pressure. In this case, we have used *extraTemp2* and by > default WeeWX will treat any data in that field as temperature. We need to > change that, this can be done in a number of ways but the simplest is to > simply assign the appropriate unit group in the file *extensions.py *( > *extensions.py* is located in */home/weewx/bin/user* or > */usr/share/weewx/user* depending on how you installed WeeWX). In this > case edit *extensions.py* and add the following lines to the bottom of > the file: > > import weewx.units > weewx.units.obs_group_dict['extraTemp2'] = 'group_concentration' > > In this case we have re-assigned field *extraTemp2* to belong to the unit > group *group_concentration* (the WeeWX unit group used for > concentrations). A similar but slightly different approach is covered in > the Assigning a unit group > <http://weewx.com/docs/customizing.htm#Assigning_a_unit_group> section in > the Customization Guide <http://weewx.com/docs/customizing.htm>. > > Note the *extensions.py* modification was necessary because the > destination field and and source data are of different unit groups, if they > were the same then there is no need to change any unit groups. > > Save *weewx.conf* and *extensions.py* and restart WeeWX and the PM2.5 > data from the second sensor will appear in field *extraTemp2* in loop > packets emitted by the GW1000 driver. WeeWX will accumulate this loop data > and *extraTemp2* will be included in archive records synthesised by > WeeWX. You can then use *extraTemp2* in tags in WeeWX report templates. > > That covers the GW1000 field map approach. For the sake of completeness I > will cover the *StdCalibrate* approach as well. > > To achieve the same result with the *StdCalibrate* service we add an > entry under *[StdCalibrate] [[Corrections]]* in *weewx.conf*. In this > case we would use: > > [StdCalibrate] > .... > [[Corrections]] > .... > extraTemp2 = pm25_2 > > Note that in this case we used field *pm25_2* as we are actually using > the field from the loop packet and archive record rather than an internal > field in the GW1000 driver. > > You would also need to make the same addition to *extensions.py* to deal > with the units as was done with the GW1000 field map example above. > > Gary > On Tuesday, 22 December 2020 at 14:44:50 UTC+10 lang....@googlemail.com > wrote: > >> I have several sensors which in my observation do not have a counterpart >> in the extended weewx database schema. >> >> But I still want them stored in the weewx database and have them and >> their history displayed in the web interface under >> http://IP-address/weewx >> >> E.g. there seems to be only one (1) field for PM2.5 sensors, however I've >> got two of the WH41 sensors and the GW1000 provides values for both. >> I already managed to get one of them displayed in the current conditions >> and daily chart page (and also making them show on the weekly, monthly, >> yearly pages is now just a matter a >> >> I suspect that the second simply gets lost as there is no standard field >> in the database to accommodate them. >> >> In a post in the WXforum Gary mentions several approaches how to store >> ("archive" in weewx terminology) such sensor values ("observations") in the >> weewx database. >> https://www.wxforum.net/index.php?topic=34857.0 >> >> "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" >> >> I want to go for number 1 but didn't find instructions how (and where) to >> do so. >> >> Can anyone provide guidance here please ? >> >> Thanks and regards >> >> Rainer >> > -- 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 weewx-user+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/8d1779b0-1caa-48b4-9510-4098b373d6f9n%40googlegroups.com.
