On Tuesday, 22 September 2020 at 07:52:28 UTC+10 [email protected] wrote: > OK.... I thought the uvradiation field from the sensor corresponded to > the radiation field in the DB given luminosity was a separate field in > its own right. > No, the GW1000 API provides two UV related obs; one labelled UV that is a value in microwatts per square metre (I believe the GW1000 UV values are in the order of 10s of thousands of microwatts per square metre whereas the WeeWX field radiation field is of the order of 100s of watts per square metre) and one labelled UVI which is an index from 0 to 15. The UVI field is mapped by default to the WeeWX UV field and the GW1000 UV field is mapped to WeeWX field uvradiation (because the GW1000 UVI field is mapped to WeeWX field UV the GW1000 UV field needed to be mapped to another field name so hence uvradiation). The GW1000 light field (Ecowitt term) in lux is (by default) mapped to the WeeWX field luminosity.
> I'll go make those changes to see what I get. I'll move the PM2.5 sensor > back to ch1 and see if the data appears in the DB. > In terms of getting an observation from a station saved to the WeeWX database it is a simple case of getting a number of holes to line up in the cheese. First the driver needs to obtain and decode the sensor value from the station. Then the driver needs to map this sensor value to a field name in the loop packet/archive records emitted by the driver. Finally, the field name in the loop packet/archive record emitted by the driver must exist in the WeeWX database schema. If all three of these conditions are met and all things being equal, the data will be saved to database, if one of the conditions is not met the data will not be saved to database. Consider the light data from the GW1000. The driver reads this data from the API, decodes it and saves it in a field named 'light'. The driver's default field map maps the GW1000 light field to the WeeWX luminosity field. The GW1000 driver emits loop packets containing a field named luminosity that contains the GW1000 light data. If the WeeWX database schema contains the field luminosity (eg if the wview_extended schema is being used) then the luminosity value will be stored in the database. There are a few other parts to the machine but that is it in its simplest form. If the user was using the old wview schema that does not include luminosity then the luminosity value would not be saved to database. If you consider your PM2.5 sensor. If your sensor connected to channel 1 your PM2.5 data would appear in the GW1000 field pm251. The default field map maps pm251 to WeeWX field pm2_5. If you are using the wview_extended schema then the PM2.5 data would be saved to database in the pm2_5 field. If your sensor connected to channel 2 your PM2.5 data would appear in the GW1000 field pm252. The default field map maps pm252 to WeeWX field pm2_52. If you are using the wview_extended (or the wview) schema there is no pm2_52 field so the PM2.5 data would not be saved to database. How to fix? The easiest approach will be to make sure your sensor always maps to the same channel. You could add all possible PM2.5 fields to your database schema, at least you won't miss any data but if your sensors change channels (say after a GW1000 firmware update or reset) you won't know which data is from which sensor. Do not attempt to map every PM2.5 channel to WeeWX field pm2_5, even if you only have one sensor it will almost certainly cause issues within the driver. Similar but slightly different for the PM2.5 battery state data. I hope the above explains somewhat how things work and why you are seeing what you are seeing. Gary -- 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/995885a7-b46b-4494-8fd0-b57698df23cbn%40googlegroups.com.
