Re: [weewx-user] Re: New GW1000 Driver available for testing

[pa...@pauland.net]

Bill
About not being able to run the driver directly, If you have python 2 on 
your system, but have installed WeeWX to use python 3 you may not have 
installed the prerequisites for python 2. If you have a setup.py install 
and try to run:
PYTHONPATH=/home/weewx/bin python -m user.gw1000 --test-driver
You will get an error message that includes "ImportError: No module named 
configobj"
What you can do is specify python 3 on the command and it should run fine:
PYTHONPATH=/home/weewx/bin python3 -m user.gw1000 --test-driver

Have Fun!
Paul
On Friday, July 24, 2020 at 2:43:30 PM UTC-4 wa4...@gmail.com wrote:

> I started as you and later added a WiFi-less console.  I'm not sure where 
> to look for the WH65 designation. 
> No, I didn't change the map. I was unable to run the driver directly to 
> test, so I just launched it blindly... and it worked.
> I am seeing an anomaly with pressure, too. I'm looking at the output as 
> reported to CWOP. I'm seeing 989mb where I expect 1019mb
> So...I have some work to do.
> On Friday, July 24, 2020 at 1:28:27 PM UTC-5 steep...@gmail.com wrote:
>
>> That is the same array that I am using with gw1000 except I do not have a 
>> console. Does this show up as WH65? I have anomaly with the barometer but I 
>> cannot understand why. Have you changed the sensor map at all?
>>
>>
>> On Fri, 24 Jul 2020 at 19:17, Bill Arthur  wrote:
>>
>>> Hi Ian,
>>> I have the Ambient Weather WS-2902 array:  temperature, rainfall, 
>>> humidity, wind speed & direction, UV and solar.  Indoor and pressure is 
>>> from the GW-1000
>>>
>>> On Friday, July 24, 2020 at 1:07:41 PM UTC-5 steep...@gmail.com wrote:
>>>
 Hi Bill,
 What sensors do you have connected?

 On Fri, 24 Jul 2020 at 19:06, Bill Arthur  wrote:

> Ian,
> Yes, just the simple Seasons skin for now. I now have 12 hours of data 
> and it's looking good. 
> I've compared it to my weather station console and the data all looks 
> correct.
>
> On Friday, July 24, 2020 at 12:56:01 PM UTC-5 steep...@gmail.com 
> wrote:
>
>> Hi Bill,
>> No need to be sorry. Just wanted to exchange notes on experiences. I 
>> assume you then using the default Seasons skin. How is that looking?
>> Ian
>>
>> On Fri, 24 Jul 2020 at 18:12, Bill Arthur  wrote:
>>
>>> Hi Ian
>>> No, I don't have Weather34 on the RasPi that I'm testing the GW1000 
>>> extension, it's a fresh install.
>>> It'll be a while until I'm ready to modify the RasPi that has 
>>> Weather34. Sorry.
>>>
>>> On Friday, July 24, 2020 at 10:09:08 AM UTC-5 steep...@gmail.com 
>>> wrote:
>>>
 Hi Bill,

 Are you still using the Weather34 skin. If so, I am interested what 
 barometer reading you are displaying when using the gw1000 driver.

 Thanks,
 Ian 


 On Friday, July 24, 2020 at 4:02:17 AM UTC+1, Bill Arthur wrote:
>
> I couldn't get it to run from the command line.
> When I  did   python -m user.gw1000 --help
> I get   /usr/bin/python: No module named user.gw1000
>
> But I have it up and running, everything looks good on my Seasons 
> page.
> I'll give the data a closer look tomorrow.
>
> But I'm scratching my head trying to find how to specify the IP 
> address in weewx.conf
> I have three GW1000s here, I have no idea which one is being used  
> On Thursday, July 23, 2020 at 9:06:47 PM UTC-5 Bill Arthur wrote:
>
>> This link works: 
>> https://github.com/gjr80/weewx-gw1000/releases/download/v0.1.0b4/gw1000-0.1.0b4.tar.gz
>>
>> On Thursday, July 23, 2020 at 8:57:49 PM UTC-5 Bill Arthur wrote:
>>
>>> FYI:
>>> wget -P /var/tmp 
>>> https://github.com/gjr80/weewx-gw1000/releases/download/v0.1.0b4/weewx-gw1000-0.1.0b4.tar.gz
>>>  
>>> gives me an Error 404 
>>>
>>> On Thursday, July 23, 2020 at 3:22:07 PM UTC-5 galfert wrote:
>>>
 There is a thread in the developer section where some questions 
 were asked that were not directly related to development. This 
 thread is 
 good. I'm just inviting people to ask their questions here in this 
 thread 
 rather than in the developer section.


 On Thursday, July 23, 2020 at 2:56:51 PM UTC-4, steeple ian 
 wrote:

> ???
>
> On Thu, 23 Jul 2020 at 19:39, galfert  
> wrote:
>
 For anyone discussing this new GW1000 API driver in the WeeWX 
>> development section STOP. Use this user section instead to 
>> discuss its use.
>>
>>
>> -- 
>> You received this message because you are s

Re: [weewx-user] Re: New GW1000 Driver available for testing

[Vetti52]

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.
In addition, 'radiation': 'solar_radiation', is missing in default_field_map 
in gw1000.py. 

hopefully easy to correct.
Thanks
Peter

Am Freitag, 24. Juli 2020 15:44:57 UTC+2 schrieb gjr80:
>
> My apologies all round Bill, a few typos and a wrong assumption about 
> package installs - have rewritten and simplfied the GitHub readmes this 
> afternoon. They should be correct now. Perhaps a bit late now but to run 
> the driver directly the following should work:
>
> $ PYTHONPATH=/usr/share/weewx python -m user.gw1000 --help
>
> When you used wee_config --reconfigure to reconfigure WeeWX to use the 
> driver it should have prompted you for the IP address, unfortunately I 
> included --no-prompt in the wee_config command and that left you with no 
> IP address set (in which case the driver uses the first GW1000 that 
> replies). You can run the following command and step through the prompts 
> until you are asked for an IP address and then enter the IP address of the 
> GW1000 you wish to use:
>
> $ wee_config --reconfigure --driver=user.gw1000
>
> Alternatively you can just edit weewx.conf and add a line ip_address 
> under [GW1000]:
>
> [GW1000]
> 
> ip_address = 1.2.3.4
>
> Either way you will need to restart once you have set the IP address.
>
> Gary
>
> On Friday, 24 July 2020 13:02:17 UTC+10, Bill Arthur wrote:
>>
>> I couldn't get it to run from the command line.
>> When I  did   python -m user.gw1000 --help
>> I get   /usr/bin/python: No module named user.gw1000
>>
>> But I have it up and running, everything looks good on my Seasons page.
>> I'll give the data a closer look tomorrow.
>>
>> But I'm scratching my head trying to find how to specify the IP address 
>> in weewx.conf
>> I have three GW1000s here, I have no idea which one is being used  
>> On Thursday, July 23, 2020 at 9:06:47 PM UTC-5 Bill Arthur wrote:
>>
>>> This link works: 
>>> https://github.com/gjr80/weewx-gw1000/releases/download/v0.1.0b4/gw1000-0.1.0b4.tar.gz
>>>
>>> On Thursday, July 23, 2020 at 8:57:49 PM UTC-5 Bill Arthur wrote:
>>>
 FYI:
 wget -P /var/tmp 
 https://github.com/gjr80/weewx-gw1000/releases/download/v0.1.0b4/weewx-gw1000-0.1.0b4.tar.gz
  
 gives me an Error 404 

 On Thursday, July 23, 2020 at 3:22:07 PM UTC-5 galfert wrote:

> There is a thread in the developer section where some questions were 
> asked that were not directly related to development. This thread is good. 
> I'm just inviting people to ask their questions here in this thread 
> rather 
> than in the developer section.
>
>
> On Thursday, July 23, 2020 at 2:56:51 PM UTC-4, steeple ian wrote:
>
>> ???
>>
>> On Thu, 23 Jul 2020 at 19:39, galfert  wrote:
>>
> For anyone discussing this new GW1000 API driver in the WeeWX 
>>> development section STOP. Use this user section instead to discuss its 
>>> use.
>>>
>>>
>>> -- 
>>> 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...@googlegroups.com.
>>
>>
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/91d513a8-cf9a-4cf2-8e16-261a02b67bebo%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
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/37425d62-b4ef-467b-9bcb-f3fe70b6b246o%40googlegroups.com.

[weewx-user] Sun Shine Hours

[Phil Owers]

Hi All

Have been using the Instromet Stand Alone Sun Duration sensor which if 
connected to a Davis Vantage Pro2 system needs to go to a spare rain socket 
in the ISS.
Each 0.01 is equivalent to 36 seconds of sunshine and I have converted that 
to hours and minutes on my web page. 
The next stage was to produce a graph per hour using the rain field in the 
database  and to adjust that  reading.either with another field in the 
database or when the plot/graph was produced .
I did have a look in the vantage.py and came across  loop_packet['rain'] = 
delta. 
So im asking is this the place to do this or am I totally in the wrong 
place to achieve a field with with rain * 36 in.
Thanks in Advance

-- 
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/e7cbf097-2b2d-412c-b84f-86df450613c9o%40googlegroups.com.

[weewx-user] Extra temperature sensors Belchertown

[Arend]

I have a WS6in1 station, and I was wondering if the observation data from 
extra sensors could be displayed in the index_hook_after_station_info and 
updated with MQTT like the data from the main sensor. At the moment I have 
only one extra sensor but I am planning on expanding in the future. I made 
a small example of what I had in mind:

[image: Extra sensors Belchertown.png].

-- 
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/ac8a39c1-d7df-460d-92cc-e9e6fe754212n%40googlegroups.com.

[weewx-user] Re: evapotranspiration on fine off-set weather station

[Jim Pace]

Just as I was going to check the db for the entries you said, my 
Weatherflow station started having radiation and windspeed sensor fails. 
Now that I have a replacment up and running, I did the db check and I do 
have all the parameters in there as well as ET calculations but the result 
is so small(in the 0.001 range) that Weewx rounds down to zero it appears. 
What numbers should I expect here in the Willamette Valley this time of 
year?

On Tuesday, February 18, 2020 at 3:20:23 AM UTC-8, Francesco Scaramella 
wrote:
>
> Hello I have a question for all users of weewx: I own of fine-offset 
> weather stations that make available the data of solar radiation and ev and 
> when I have this type of sensors I have among the parameters also published 
> that of evapotranspiration, but the I always find zero. What one knows how 
> this parameter is generated and if there are any adjustments to be made for 
> this brand of stations?? 
> Francesco
>

-- 
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/d3326076-6a1d-4453-b1dd-d7a8665cdbcbo%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[gjr80]

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/d146267b-db89-4b4e-92b3-031a12f91c4eo%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[gjr80]

I am not sure if this impacts on the WH65 issue mentioned below but I now 
have the driver distinguishing whether there is a WH65 or WH24 connected to 
the GW1000. This will (I hope) have a flow on affect on battery status 
fields but given the manner in which the API works I don't believe it will 
impact any weather related observations. I should have b6 in the next 
couple of days.

Gary
On Saturday, 25 July 2020 04:50:38 UTC+10, steeple ian wrote:
>
> That’s exactly what I am seeing. I am going to look at the interceptor map 
> for WH65 and see where things appear to deviate.
>
> On Fri, 24 Jul 2020 at 19:43, Bill Arthur  wrote:
>
>> I started as you and later added a WiFi-less console.  I'm not sure where 
>> to look for the WH65 designation. 
>> No, I didn't change the map. I was unable to run the driver directly to 
>> test, so I just launched it blindly... and it worked.
>> I am seeing an anomaly with pressure, too. I'm looking at the output as 
>> reported to CWOP. I'm seeing 989mb where I expect 1019mb
>> So...I have some work to do.
>> On Friday, July 24, 2020 at 1:28:27 PM UTC-5 steep...@gmail.com wrote:
>>
>>> That is the same array that I am using with gw1000 except I do not have 
>>> a console. Does this show up as WH65? I have anomaly with the barometer but 
>>> I cannot understand why. Have you changed the sensor map at all?
>>>
>>>
>>> On Fri, 24 Jul 2020 at 19:17, Bill Arthur  wrote:
>>>
 Hi Ian,
 I have the Ambient Weather WS-2902 array:  temperature, rainfall, 
 humidity, wind speed & direction, UV and solar.  Indoor and pressure is 
 from the GW-1000

 On Friday, July 24, 2020 at 1:07:41 PM UTC-5 steep...@gmail.com wrote:

> Hi Bill,
> What sensors do you have connected?
>
> On Fri, 24 Jul 2020 at 19:06, Bill Arthur  wrote:
>
>> Ian,
>> Yes, just the simple Seasons skin for now. I now have 12 hours of 
>> data and it's looking good. 
>> I've compared it to my weather station console and the data all looks 
>> correct.
>>
>> On Friday, July 24, 2020 at 12:56:01 PM UTC-5 steep...@gmail.com 
>> wrote:
>>
>>> Hi Bill,
>>> No need to be sorry. Just wanted to exchange notes on experiences. I 
>>> assume you then using the default Seasons skin. How is that looking?
>>> Ian
>>>
>>> On Fri, 24 Jul 2020 at 18:12, Bill Arthur  wrote:
>>>
 Hi Ian
 No, I don't have Weather34 on the RasPi that I'm testing the GW1000 
 extension, it's a fresh install.
 It'll be a while until I'm ready to modify the RasPi that has 
 Weather34. Sorry.

 On Friday, July 24, 2020 at 10:09:08 AM UTC-5 steep...@gmail.com 
 wrote:

> Hi Bill,
>
> Are you still using the Weather34 skin. If so, I am interested 
> what barometer reading you are displaying when using the gw1000 
> driver.
>
> Thanks,
> Ian 
>
>
> On Friday, July 24, 2020 at 4:02:17 AM UTC+1, Bill Arthur wrote:
>>
>> I couldn't get it to run from the command line.
>> When I  did   python -m user.gw1000 --help
>> I get   /usr/bin/python: No module named user.gw1000
>>
>> But I have it up and running, everything looks good on my Seasons 
>> page.
>> I'll give the data a closer look tomorrow.
>>
>> But I'm scratching my head trying to find how to specify the IP 
>> address in weewx.conf
>> I have three GW1000s here, I have no idea which one is being 
>> used  
>> On Thursday, July 23, 2020 at 9:06:47 PM UTC-5 Bill Arthur wrote:
>>
>>> This link works: 
>>> https://github.com/gjr80/weewx-gw1000/releases/download/v0.1.0b4/gw1000-0.1.0b4.tar.gz
>>>
>>> On Thursday, July 23, 2020 at 8:57:49 PM UTC-5 Bill Arthur wrote:
>>>
 FYI:
 wget -P /var/tmp 
 https://github.com/gjr80/weewx-gw1000/releases/download/v0.1.0b4/weewx-gw1000-0.1.0b4.tar.gz
  
 gives me an Error 404 

>>>

-- 
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/4297800f-cd83-414a-aa3a-9e395c9f599co%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[Greg Troxel]

gjr80  writes:

> Some folks derive field radiation from luminosity though I believe the
> relationship is somewhat complex.

I'm not at all clear on what labels the various stations use.

I would use "solar irradiance" or less pedantically "solar radiation".
The term "field radiation" is interesting and I have not previously
encountered it.

For the arriving light per unit area, the term is Illuminance.
Luminosity strictly refers to total power departing a light source.

https://en.wikipedia.org/wiki/Solar_irradiance
https://en.wikipedia.org/wiki/Illuminance

One cannot accurately convert illuminance to irradiance, because
illuminance applies wavelength-based weights to power based on human
visual response.  So, two light sources arriiving at a surface, having
the same illuminance, will in general have differenrt irradiances.  But
people assume "sunlight" and then onc can make a reasonable
approximation.

My previous rant:

  https://github.com/weewx/weewx/wiki/Watts-and-lux

and something I just found that seems interesting

  
https://ieee-dataport.org/open-access/conversion-guide-solar-irradiance-and-lux-illuminance

> 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.

Agreed.

-- 
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/rmiy2n7tdbu.fsf%40s1.lexort.com.

[weewx-user] Re: Sun Shine Hours

[gjr80]

Hi,

If I am understanding you correctly you have a field that is being 
populated in the WeeWX database. The field data is such that you display 
cumulative values or sums (ala rain) rather than point in time values (like 
temperature, pressure etc). You have been scaling that field on your web 
page. You would now like to plot that field but you wish to plot the scaled 
data rather than the data stored in the field.

The WeeWX plot engine is fairly limited in abilities and essentially any 
observation you want to plot needs to be stored in your archive. One 
approach you could take is to use the StdCalibrate service to do your 
scaling for you and provided the field containing the scaled value is 
stored in the archive you can just plot the scaled value. For example, say 
your data is coming from the console in field new_obs, something like:

[StdCalibrate]
[[Corrections]]
new_obs = new_obs * 36 if new_obs is not None else None

would result in your field new_obs now containing your scaled data and 
provided new_obs is in the db schema it will be saved to archive and able 
to be plotted. An alternative if you want to keep the original data in 
new_obs would be to place the scaled data in a new field:

[StdCalibrate]
[[Corrections]]
another_obs = new_obs * 36 if new_obs is not None else None

This will result in your original sensor data remaining in field new_obs 
and the scaled data being in field another_obs. Provided another_obs is in 
your schema it will be saved to archive and able to be plotted. This data 
will be in seconds and I suspect there will be some scaling issues on your 
plots. You could alter the scaling formula to store your scaled data in 
decimal hours and that may plot better, something like:

[StdCalibrate]
[[Corrections]]
another_obs = new_obs * 36/3600 if new_obs is not None else None

Rather than re-using existing database fields it is quite straightforward 
to add new fields to the database. You can find information on adding new 
fields to the database in the section Adding a new type to the database 
 in the 
Customization Guide.

Hope that helps and I have not misunderstood your question.

Gary

On Sunday, 26 July 2020 02:39:58 UTC+10, Phil Owers wrote:
>
> Hi All
>
> Have been using the Instromet Stand Alone Sun Duration sensor which if 
> connected to a Davis Vantage Pro2 system needs to go to a spare rain socket 
> in the ISS.
> Each 0.01 is equivalent to 36 seconds of sunshine and I have converted 
> that to hours and minutes on my web page. 
> The next stage was to produce a graph per hour using the rain field in the 
> database  and to adjust that  reading.either with another field in the 
> database or when the plot/graph was produced .
> I did have a look in the vantage.py and came across  loop_packet['rain'] = 
> delta. 
> So im asking is this the place to do this or am I totally in the wrong 
> place to achieve a field with with rain * 36 in.
> Thanks in Advance
>

-- 
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/1a7f573a-344a-4634-aefc-7d90a5e1890do%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[gjr80]

On Sunday, 26 July 2020 08:55:08 UTC+10, Greg Troxel wrote:
>
> gjr80 writes: 
>
> > Some folks derive field radiation from luminosity though I believe the 
> > relationship is somewhat complex. 
>
> I'm not at all clear on what labels the various stations use. 
>
> I would use "solar irradiance" or less pedantically "solar radiation". 
> The term "field radiation" is interesting and I have not previously 
> encountered it. 
>
>
You will notice the highlight on the word radiation (but not the word 
field) in my original post, this was in reference to the WeeWX field named 
radiation, not to something known as 'field radiation'.
 

> For the arriving light per unit area, the term is Illuminance. 
> Luminosity strictly refers to total power departing a light source. 
>
> https://en.wikipedia.org/wiki/Solar_irradiance 
> https://en.wikipedia.org/wiki/Illuminance 
>
> One cannot accurately convert illuminance to irradiance, because 
> illuminance applies wavelength-based weights to power based on human 
> visual response.  So, two light sources arriiving at a surface, having 
> the same illuminance, will in general have differenrt irradiances.  But 
> people assume "sunlight" and then onc can make a reasonable 
> approximation. 
>
> My previous rant: 
>
>   https://github.com/weewx/weewx/wiki/Watts-and-lux 
>
> and something I just found that seems interesting 
>
>   
> https://ieee-dataport.org/open-access/conversion-guide-solar-irradiance-and-lux-illuminance
>  
>
>
I don't disagree but irrespective the GW1000 API has no ability to return 
data that is suitable to be placed in the WeeWX field called radiation. If 
the user wishes to derive values to place in any WeeWX fields that of 
course is their call and whilst WeeWX has the machinery to do such things 
it is left as an exercise for the user.

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/0ca7e6ae-39d5-4d9f-982b-6e487473a4d4o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[Greg Troxel]

gjr80  writes:

> You will notice the highlight on the word radiation (but not the word 
> field) in my original post, this was in reference to the WeeWX field named 
> radiation, not to something known as 'field radiation'.

Sorry, reading in plain text so I did not actually notice that :-)

> I don't disagree but irrespective the GW1000 API has no ability to return 
> data that is suitable to be placed in the WeeWX field called radiation. If 

Sure, didn't mean to come across as questioning that as all.

> the user wishes to derive values to place in any WeeWX fields that of 
> course is their call and whilst WeeWX has the machinery to do such things 
> it is left as an exercise for the user.

In the glorious future, there might be a stdconvert routine to create
radiation from illuminace, perhaps enabled with a config variable
becusae 1) not everybody wants it and 2) it's not really sound.  I meant
to be in agreement and offer pointers to further info for people looking
into this.

-- 
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/rmih7tvtbcx.fsf%40s1.lexort.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[gjr80]

Agreed completely :)

Gary

On Sunday, 26 July 2020 09:37:41 UTC+10, Greg Troxel wrote:
>
> gjr80 writes: 
>
> > You will notice the highlight on the word radiation (but not the word 
> > field) in my original post, this was in reference to the WeeWX field 
> named 
> > radiation, not to something known as 'field radiation'. 
>
> Sorry, reading in plain text so I did not actually notice that :-) 
>
> > I don't disagree but irrespective the GW1000 API has no ability to 
> return 
> > data that is suitable to be placed in the WeeWX field called radiation. 
> If 
>
> Sure, didn't mean to come across as questioning that as all. 
>
> > the user wishes to derive values to place in any WeeWX fields that of 
> > course is their call and whilst WeeWX has the machinery to do such 
> things 
> > it is left as an exercise for the user. 
>
> In the glorious future, there might be a stdconvert routine to create 
> radiation from illuminace, perhaps enabled with a config variable 
> becusae 1) not everybody wants it and 2) it's not really sound.  I meant 
> to be in agreement and offer pointers to further info for people looking 
> into this. 
>

-- 
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/26657fff-83ac-4d07-b396-19ea0757829do%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[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/4c8c99bb-3a88-411e-bd70-41ff4bfc6de5o%40googlegroups.com.

Re: [weewx-user] Re: evapotranspiration on fine off-set weather station

[Tom Keffer]

It should be numbers like 0.01 or 0.02 inch per hour. I'm just around the
corner in Hood River, and my max value today was 0.024/hr, but it is
probably a bit drier here (RH today was 25%). So, if you have a 5 minute
archive interval, 0.001 sounds about right.

ET is best viewed as summed over a day. I know the Seasons skin doesn't do
that, but it really should.

-tk

On Sat, Jul 25, 2020 at 1:13 PM Jim Pace  wrote:

> Just as I was going to check the db for the entries you said, my
> Weatherflow station started having radiation and windspeed sensor fails.
> Now that I have a replacment up and running, I did the db check and I do
> have all the parameters in there as well as ET calculations but the result
> is so small(in the 0.001 range) that Weewx rounds down to zero it appears.
> What numbers should I expect here in the Willamette Valley this time of
> year?
>
> On Tuesday, February 18, 2020 at 3:20:23 AM UTC-8, Francesco Scaramella
> wrote:
>>
>> Hello I have a question for all users of weewx: I own of fine-offset
>> weather stations that make available the data of solar radiation and ev and
>> when I have this type of sensors I have among the parameters also published
>> that of evapotranspiration, but the I always find zero. What one knows how
>> this parameter is generated and if there are any adjustments to be made for
>> this brand of stations??
>> Francesco
>>
> --
> 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/d3326076-6a1d-4453-b1dd-d7a8665cdbcbo%40googlegroups.com
> 
> .
>

-- 
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/CAPq0zEBZZ79kZ%3Dr97LrJaaBfxrWaKZMQjKJOxy2uC10E_Uc%3DuQ%40mail.gmail.com.

[weewx-user] Re: Sun Shine Hours

[Phil Owers]

Hi Gary
Thanks for your quick response.
You have confirmed the best way is to populate a new field to get the graph 
Im looking for.
Im happy with adding a new field to the database
This new field would have the 0.01 * 36 but im not sure how to do that
Is that done in the vantage.py file, and if so how please, or somewhere else
Phil


On Saturday, July 25, 2020 at 5:39:58 PM UTC+1, Phil Owers wrote:
>
> Hi All
>
> Have been using the Instromet Stand Alone Sun Duration sensor which if 
> connected to a Davis Vantage Pro2 system needs to go to a spare rain socket 
> in the ISS.
> Each 0.01 is equivalent to 36 seconds of sunshine and I have converted 
> that to hours and minutes on my web page. 
> The next stage was to produce a graph per hour using the rain field in the 
> database  and to adjust that  reading.either with another field in the 
> database or when the plot/graph was produced .
> I did have a look in the vantage.py and came across  loop_packet['rain'] = 
> delta. 
> So im asking is this the place to do this or am I totally in the wrong 
> place to achieve a field with with rain * 36 in.
> Thanks in Advance
>

-- 
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/cdd0c7e8-a905-4e7d-9cc9-c0216d0641f8o%40googlegroups.com.

[weewx-user] Re: DIY weather station + Weewx on Raspberry Pi - how to join them?

[Rob Shorrock]

I have been running weewx on a zeropi with wifi connected to my home 
network . The zeropi gets the weather station data through a usb connection 
to a Acurite 5in 1 PWS and I can access the weewx dashboard from my 
browser.  The weewx also uploads the data to a PWSWeather.com to allow 
viewing on the web. Unfortunately my Acurite has ceased functioning and I 
need a new system. Could a zeropi w  run software to read the sensors and 
load the data into weewx also running on the zeropi w ?. The zeropi runs at 
low loads when running weewx but may need extra hardware to read the analog 
sensors??

On Friday, 24 July 2020 at 18:03:15 UTC+10 Tomasz Lewicki wrote:

> Dear Weewx users.
>
> It's my first post. I looked into wiki and docs but still are stuck so I 
> ask here.
>
> My configuration is as follows:
>
> 1. DIY solar powered WiFi weather station (built from here: 
> https://www.instructables.com/id/Solar-Powered-WiFi-Weather-Station-V20/ 
> - the project known to some of you, I suppose), based on Wemos D1 Mini Pro 
> (ESP8266) with own IP address in local network
>
> 2. Raspberry Pi 3 used as cheap airplane tracking station (ADS-B stick).
>
> Now I want to extend RPi with Weewx fed and weather station data.
>
> Because my station is hand-made, I can't use any of standard hardware 
> drivers. As far I installed Weewx with Simulator driver and it works - 
> http://stationIP/weewx shows many plots and data. I was even able to send 
> it periodically to my other, public available, webserver by FTP.
>
> But of course I don't need fake, static data. I want to RPi with Weewx to 
> communicate periodically with weather station, grab the data (or weather 
> station push it periodically to RPi, which is the same, I suppose) and view 
> it live via the webserver.
>
> So finally I come to the important question: is such connection possible? 
> I suppose yes, but my experience with such hardware is very poor and I 
> don't know where should I go. I'm experienced Linux user so it is no 
> problem in this field. I only expect that someone will point me in the 
> right direction, some keyword to look for. Maybe someone has similar 
> configuration and could help?
>

-- 
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/2b282e1c-817e-480c-8863-90742b4ee725n%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

['NanoG5Kite' via weewx-user]

Is‘t it better to post possible errors on Githup? In addition to Radiation 
I‘m also missing rain and current rain rate now.
Will open issues on Github now.

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/b6c408c8-a350-4629-b1e3-c145b62449d4o%40googlegroups.com.

[weewx-user] Re: Sun Shine Hours

[gjr80]

Phil,

No need to modify vantage.py, in fact modifying one of the core WeeWX files 
is seldom a good solution when others exist. You open yourself up to losing 
your changes over an upgrade or if you place your modified file in 
/home/weewx/bin/user (or /usr/share/weewx/user) so it is safe from 
upgrades, you risk missing changes to the core WeeWX files. In this case 
you can use StdCalibrate to create your new field. Once you create your new 
field, if you change you db schema to include it your new field will be 
automatically saved in the database. Once it is in the database you can 
plot it. Let's assume the name of the field that has your current sunshine 
data is 'sunshine_field'. As an experiment try this swapping 
'sunshine_field' for the field name that presently has your sunshine data:

1. edit weewx.conf and add the highlighted lines under [StdCalibrate] 
[[Corrections]]:

[StdCalibrate]
[[Corrections]]
 
 sunshine_seconds = sunshine_data * 36

2. look through weewx.conf and see if you have an [Accumulator] stanza, if 
so add the highlighted lines, if you don't have an [Accumulator] stanza 
create one and add the highlighted lines:

[Accumulator]
[[sunshine_seconds]]
extractor = sum

3. save weewx.conf.

4. stop WeeWX if it is running and run WeeWX directly 
. You should see 
loop packets (lines starting with LOOP:) every few seconds and archive 
records (lines starting with REC:) every archive interval. You should see 
your 'sunshine_field' and you should see the new sunshine_seconds field. 
Note that sunshine_seconds is not being saved to database yet as 
(presumably) you have not yet added a sunshine_seconds field to your db 
schema, once you do it will be saved to database and you can then use the 
field in plots.

You can stop WeeWX with ctrl-C or ctrl-Z and restart the daemon.

I failed to mention the [Accumulator] stanza before, the [Accumulator] 
stanza, among other things, is used to tell WeeWX how to create an archive 
record field out of the accumulated loop data for that field. In this case, 
just like rain, we want the sum of the data over the archive interval (most 
obs want the default which is average, eg temperature, pressure etc)

Gary

On Sunday, 26 July 2020 15:57:38 UTC+10, Phil Owers wrote:
>
> Hi Gary
> Thanks for your quick response.
> You have confirmed the best way is to populate a new field to get the 
> graph Im looking for.
> Im happy with adding a new field to the database
> This new field would have the 0.01 * 36 but im not sure how to do that
> Is that done in the vantage.py file, and if so how please, or somewhere 
> else
> Phil
>
>
> On Saturday, July 25, 2020 at 5:39:58 PM UTC+1, Phil Owers wrote:
>>
>> Hi All
>>
>> Have been using the Instromet Stand Alone Sun Duration sensor which if 
>> connected to a Davis Vantage Pro2 system needs to go to a spare rain socket 
>> in the ISS.
>> Each 0.01 is equivalent to 36 seconds of sunshine and I have converted 
>> that to hours and minutes on my web page. 
>> The next stage was to produce a graph per hour using the rain field in 
>> the database  and to adjust that  reading.either with another field in the 
>> database or when the plot/graph was produced .
>> I did have a look in the vantage.py and came across  loop_packet['rain'] 
>> = delta. 
>> So im asking is this the place to do this or am I totally in the wrong 
>> place to achieve a field with with rain * 36 in.
>> Thanks in Advance
>>
>

-- 
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/b048a8b6-d8c7-49c6-b226-ef349ce2ab2eo%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

['NanoG5Kite' via weewx-user]

https://github.com/gjr80/weewx-gw1000/issues

Am Sonntag, 26. Juli 2020 08:39:19 UTC+2 schrieb NanoG5Kite:
>
> Is‘t it better to post possible errors on Githup? In addition to Radiation 
> I‘m also missing rain and current rain rate now.
> Will open issues on Github now.
>
> 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/36981b0c-54d7-44f6-81c2-4089771e75e8o%40googlegroups.com.

Re: [weewx-user] Re: New GW1000 Driver available for testing

[gjr80]

I don't mind, Github is probably easier for tracking and hopefully keeps 
one problem per issue unlike posts here which tend to grow many heads. All 
I ask is that some appropriate details of the problem are included (eg an 
explanation of the problem and a startup debug log extract - a list of 
attached sensors/stations would help too) rather than ' does not work'

Gary

On Sunday, 26 July 2020 16:39:19 UTC+10, NanoG5Kite wrote:
>
> Is‘t it better to post possible errors on Githup? In addition to Radiation 
> I‘m also missing rain and current rain rate now.
> Will open issues on Github now.
>
> 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/98df7446-1562-4186-8f9b-fd6da1eabd9do%40googlegroups.com.