The setting 'radiation': 'solar_radiation', is copied from interceptor.py, 
which is propagated into radiation in weewx. When changing to gw1000 api 
driver, the data are lost. So I went back to the interceptor.py. You can 
see the little gap in the graph during my test of the gw1000 driver:

[image: radiation.jpg]
I have changed the title into German in Weewx.conf 

[[[[Generic]]]]
                radiation = Sonnenstrahlung

So, somewhere the observation type radiation has to be filled with data. In 
interceptor.py, this is done by 'solar_radiation' which comes from the 
ecowitt-customized upload. I would just like to continue with these data.

Am Sonntag, 26. Juli 2020 02:13:38 UTC+2 schrieb gjr80:
>
> Whilst there definitely is nothing in the API for retrieving what WeeWX 
> knows as 'radiation', there is a calibration setting labelled 'SolarRad 
> Gain' in the WS View app (interestingly there is no gain setting for 
> anything to do with 'light', luminosity, illuminance etc so it could be a 
> mis-labelling/inconsistent labelling of the parameter in the app). If you 
> have been obtaining 'radiation' data via the interceptor driver can you 
> please give me some further details, it may be a case of the GW1000 
> deriving a radiation value suitable for on-line weather services such as WU 
> and that is how WeeWX has obtained the 'radiation' data or, more unlikely, 
> it may be that there is something else available in the API that is not 
> documented.
>
> Gary
>
> On Sunday, 26 July 2020 08:37:10 UTC+10, gjr80 wrote:
>>
>> On Sunday, 26 July 2020 00:54:03 UTC+10, Vetti52 wrote:
>>>
>>> When running reconfigure with prompts, there are two changes, that 
>>> occured in my case without asking:
>>> group_pressure turns to inHg, and group_speed and group_speed2 turn to 
>>> mile_per_hour 
>>> and ~2 respectively.You better diff old and new version before 
>>> restarting.
>>>
>>
>> This almost certainly is an issue with wee_config and your config; the 
>> GW1000 driver has no ability to change WeeWX units/unit system. I do have a 
>> vague recollection that there was a previous issue that was raised (and 
>> fixed) regarding unexpected unit changes (it may have been on upgrade). I 
>> will make a note to look into this.
>>  
>>
>>> In addition, 'radiation': 'solar_radiation', is missing in 
>>> default_field_map 
>>> in gw1000.py. 
>>>
>>
>> This is intentional. Unfortunately the GW1000 API has no ability to 
>> obtain what in WeeWX parlance we know as field radiation (solar 
>> insolation). The API can return what the API terms 'light' or luminosity in 
>> Lux as well as UV index and what the API terms 'UV' in microWatts per 
>> square metre. Some folks derive field radiation from luminosity though I 
>> believe the relationship is somewhat complex. It's not the place for the 
>> GW1000 driver to derive obs such as radiation from other obs, rather 
>> derived observations should be derived by the StdWXCalculate service. 
>> Whilst the StdWXCalculate service does not really lend itself at present 
>> to the addition of user defined derived obs, a user can add simple derived 
>> obs by adding appropriate entries under [StdCalibrate] [[Corrections]] 
>> in weewx.conf, for example:
>>
>> [StdCalibrate]
>>     [[Corrections]]
>>         new_obs = outTemp * 2.5 + 2 * (windSpeed - barometer)
>>
>> would create the field new_obs using the (nonsense) formula shown. The 
>> default GW1000 driver mapping passes the light, UV and UV index 
>> observations through to the WeeWX loop packet (UV index is mapped to WeeWX 
>> field UV) so they are available for use in StdCalibrate as required.
>>
>> 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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/5c834bb5-bd4a-4a60-9732-14329617a7c1o%40googlegroups.com.

Reply via email to