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

[gjr80]

I have released v0.1.0b8 on Github 
 which:

- fixes an incorrect mapping of GW1000 field relbarometer that will have 
resulted in incorrect barometer and altimeter fields in WeeWX
- changes default field mappings of GW1000 fields rainhour, rainday, 
rainweek, rainmonth, rainyear, raintotals and rainevent to hourRain, 
dayRain, weekRain, monthRain, yearRain, totalRain and stormRain respectively
- changes default field mapping of GW1000 field uv from uvRadiaition to 
uvradiation
- fixes a bug that resulted in battery state mappings not being included in 
the default field map displayed with the --default-map command line option
- adds extractors for all fields from default field map (incl battery state 
map) that need an extractor function other than avg

As b8 includes extractor functions for a number of fields b8 requires 
changes to weewx.conf. For this reason the best way to upgrade to or 
install b8 is by downloading the extension package and installing using 
wee_extension. I will update the manual install instructions on the GW1000 
driver wiki shortly. Upgrading by installing the extension package should 
retain any customised settings you may have made to weewx.conf, in any case 
a timestamped backup copy of weewx.conf is made by wee_extension and it 
might pay to check that any customisations in the [GW1000] stanza have been 
retained.

For those that may have incorrect barometer/altimeter data as a result of 
the incorrect relbarometer mapping, users of WeeWX 4.0.0 or later should be 
able to recalculate the incorrect data by first deleting the incorrect 
barometer and altimeter data from the archive and then running wee_database 
using the --calc-missing action. You will then need to rebuild your daily 
summaries using --rebuild-daily. i will publish some detailed instructions 
later tonite.

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/ca5ef782-8fd5-4efa-aea4-de3240290907o%40googlegroups.com.

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

[gjr80]

Thanks for the input Paul, I believe your are correct. As soon as you see 
Rel Offset being calculated as an altitude only offset it is pretty clear 
it is altimeter and that means the pressure you are offsetting from must be 
pressure. I am not sure why I put down barometer, perhaps it was the 
liberal of the word barometer throughout the Ecowitt calibration 
instructions.Will be fixed in b8.

One nagging thought I have have had this afternoon is what pressure value 
is the GW1000 uploading to WU, WU expects what WeeWX calls barometer but on 
the face of it that is the one pressure value the GW1000 does not have. I 
did set my GW1000 to do a customised upload in WU protocol to one of my VMs 
and it included fields named baromabsin and baromrelin being the two GW1000 
pressure values in inches Hg. If I had the time I would intercept the 
GW1000 actual upload to WU but I somehow suspect it will be the same.

Gary

On Thursday, 30 July 2020 10:50:16 UTC+10, Paul Anderson wrote:
>
> Should we map  'altimeter': 'relbarometer' ?
>
> Gw1000 produces 2 pressure readings:
> As defined by Ecowitt Calibration of barometric pressure settings 
> 
> *Absolute Pressure*
> "Absolute barometric pressure, can be calibrated at manufacturing time by 
> comparing with a precise instrument that measures pressure at the same 
> location. In practice, sometimes small adjustments of a few hPa may be 
> needed"
> *Relative Pressure*
> "The relative pressure represents what the air pressure would indicate if 
> your station was at sea level and depends on the altitude of your console 
> and cannot be known in advance. This is why it needs an adjustment"
>
> If you work your way thru there cal procedure you will see that you use 
> the  WS View app to set 2 offsets:
> Abs Offset
> Rel Offset
> To set Rel Offset they have you determine station elevation and direct you 
> to a site that produces a offset based solely on elevation. So *Rel 
> Offset* is a *STATIC *offset applied against your Absolute Pressure. It 
> never changes if we set a Rel Offset of 6.0 hPa then Relative Pressure will 
> always read 6.0 hPa higher than Absolute Pressure.
> As we see in WeeWX Wiki
>
> Station or Gauge Pressure (key *pressure*): This is the absolute, raw 
> pressure as measured by your instrument. It is not corrected for altitude 
> or pressure. Pilots call this QFE
> Sea-level Pressure (*barometer*): This is the pressure corrected for 
> altitude, temperature, and (frequently) humidity. Pilots call this QFF. 
> This is the value displayed by the standard skin.
> Altimeter Pressure (*altimeter*) : This is the pressure corrected for 
> altitude, using a standard temperature profile. Pilots call this QNH.
>
> Because we are on a very limited device which does not attempt in any way 
> to apply a temperature compensation I believe that mapping   'altimeter': 
> 'relbarometer' may be more appropriate. StdWXCalculate will calculate 
> barometer for us when it appears in a template. 
> Thanks
> Paul
>
>
>>
>> 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/F82E7D44-2090-4C09-9BA6-8355FE73841F%40gmail.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/a9efe943-d23e-4458-b475-3daed4d3cac5o%40googlegroups.com.

Re: [weewx-user] FTP Stopped Working After Updating Station Hardware

[Pat W.]

As instructed...


On Tuesday, July 28, 2020 at 6:05:15 PM UTC-5, Tom Keffer wrote:
>
> OK, seeing as how that's the only value in the database, let's start 
> afresh. Can you delete the database, then restart weewx? Keep debug=2. Post 
> the log from the restart for the first couple of report cycles (10 minutes 
> or so).
>
> -tk
>
> On Tue, Jul 28, 2020 at 3:33 PM Pat W. > 
> wrote:
>
>> Affirmative.
>>
>>
>> On Tuesday, July 28, 2020 at 3:55:25 PM UTC-5, Tom Keffer wrote:
>>>
>>> That's the only value in the database?
>>>
>>> On Tue, Jul 28, 2020 at 1:24 PM Pat W.  wrote:
>>>
 The problem seems consistent. DB query here:

 sqlite> select datetime(dateTime,'unixepoch','localtime') from archive 
 order by dateTime desc limit 10;
 2020-07-26 16:05:00



 On Tuesday, July 28, 2020 at 8:59:43 AM UTC-5, Tom Keffer wrote:
>
> Could you please post the results of the database query? I want to 
> compare the timestamps with the raw data output of the WeatherFlow.
>
> Also, is this problem consistent? Or, does it come and go?
>
> -tk
>
> On Mon, Jul 27, 2020 at 1:16 PM Pat W.  wrote:
>
>> Tom,
>>
>> 1. Using your sqlite commands (thanks!) I see only one entry in the 
>> database, and its from yesterday when I was fiddling with things.
>>
>> 2. Same here, html and png files were created at least once 
>> yesterday. Nothing today.
>>
>> Pat W.
>>
>> On Sunday, July 26, 2020 at 6:22:11 PM UTC-5, Tom Keffer wrote:
>>>
>>> I have my suspicions about what's going on here, but first let me 
>>> ask you two questions.
>>>
>>> 1. Is there any evidence that anything is getting stored in the 
>>> database? Take a look in your database. This will show the timestamps 
>>> of 
>>> the last 10 records that have been stored in the database:
>>>
>>> *sqlite3 /var/lib/weewx/weewx.sdb*
>>> sqlite> *select datetime(dateTime,'unixepoch','localtime') from 
>>> archive order by dateTime desc limit 10;*
>>>
>>> 2. Is there any evidence that reports have been generated at all 
>>> (let alone FTP'd)? 
>>>
>>>
>>> *ls -l /var/www/html/weewx*
>>>
>>> -tk
>>>
>>> On Sun, Jul 26, 2020 at 3:24 PM Pat W.  wrote:
>>>
 Hi All,

 I've been using weewx for a couple years with an old WMR-918 and 
 all works fine, including an FTP upload to my personal web page every 
 five 
 minutes. Recently bought a Weatherflow Tempest and installed the 
 WeatherFlowUDP extension. Weewx appears to be receiving data from the 
 station properly, but the FTP function has stopped working and I can't 
 find 
 any references to it in the syslog. I reinstalled weewx from scratch 
 (installed via apt-get on Raspberry Pi 4) after the hardware change to 
 no 
 avail. 

 I'm a linux novice but can find my way around. This one has me 
 stumped. Any help is appreciated. mylog and wee_debug files attached

 Pat W.

 -- 
 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/d5cd1209-4b4c-4165-b857-39f237300f8co%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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/c74fba6c-92cf-49aa-8732-9302e8ff8525o%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...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/weewx-user/7d99645c-d737-4d32-87f6-7b1377ea7881o%40googlegroups.com
  
 
 .

>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "weewx-user" group.
>> To un

[weewx-user] Rainfall inaccuracies (using weewx-sdr)

[Brian Wilson]

Weewx 4.1.1, Python 3, using weewx-sdr on Raspberry PI 3 w/ sqlite 
database, 1min archive times, outdoor thermometer is an Acurite 5n1. 

We've had quite a bit of rain recently, so it's given me several 
opportunities to notice that the Acurite app rainfall numbers vary greatly 
with Weewx. Given that they are using the same data gathered over the air, 
I tried to dig into what might be causing it.

I too today's rainfall and gathered info out of the weewx logs to determine 
how much rain we got - that jives with what is in the Acurite App.  Here is 
the first and last (stopped measuring at 5:47) entries. My math tells me we 
have had .66 in between midnight and 5:47.

Jul 29 00:00:34 localhost weewxd: sdr: MainThread: packet={u'windDir': 22.5, 
u'windSpeed': 0.0, u'rain_total': 13.8, 'usUnits': 1, 'dateTime': 1595995230
}
...
Jul 29 17:47:06 localhost weewx[8995] DEBUG user.sdr: packet={'windDir': 
247.5, 'windSpeed': 5.139, 'rain_total': 14.46, 'dateTime': 1596059222, 
'usUnits': 1}


I dumped the rainfall records out of the sqlite db to see what it gathered. 
Out of 890 rows for this time period, 49 of them are empty (for instance, 
the record at 5:38).  So I add up all the non-empty numbers for the day and 
get .44 in- which matches what Weewx shows me for the day. 

2020-07-29 00:00:00|0.0
2020-07-29 00:01:00|0.0
2020-07-29 00:02:00|0.0
2020-07-29 00:03:00|0.0
2020-07-29 00:04:00|0.0
2020-07-29 00:05:00|0.00979
2020-07-29 00:06:00|0.0
2020-07-29 00:07:00|0.0
2020-07-29 00:08:00|0.0
2020-07-29 00:09:00|0.0
...
2020-07-29 17:38:00|
2020-07-29 17:39:00|0.0
2020-07-29 17:40:00|0.0
2020-07-29 17:41:00|0.0
2020-07-29 17:42:00|0.0
2020-07-29 17:43:00|0.0
2020-07-29 17:44:00|0.0
2020-07-29 17:45:00|0.0116
2020-07-29 17:46:00|0.0
2020-07-29 17:47:00|0.0
2020-07-29 17:48:00|0.0
2020-07-29 17:49:00|0.0
2020-07-29 17:50:00|0.0

# cat jul29-sqlite-rain | awk -F'|' '{print $2}' | grep 0. | paste -sd+ - | 
bc
.44951


I'm thinking the blank entries might be due to a database lock error 
(mid-day, I turned on debug logging and found the error below), but I'm 
still not seeing how 49 out of 890 empty records could skew the numbers 
this much, but I guess it could? If all the numbers in the logs add up to 
the right amount, does this mean weewx might have seen it, but didn't get 
that record written? I suppose if it was pouring (like it has been), this 
might cause some meaningful records to get lost. Any thoughts from users 
who might have seen this?  I did adjust the sqlite write timeout and it 
hasn't crapped out on me, so perhaps the next time I get rain I will know, 
but wondering if anyone else had seen this much variance between weewx and 
other apps.  Don't get me wrong - I love weewx because I own my data, but I 
need the data to be accurate, so hopefully it is the database lock issue. I 
will report back.

Jul 26 02:14:19 localhost weewxd: bmp280a: found pressure value of 
29.9625272895 mbar
Jul 26 02:14:19 localhost weewxd: PoolService: found entry Temperature -> 
extraTemp1 with value of 85.7 using offset of 0.1 to get 85.8
Jul 26 02:14:19 localhost weewx[6062] INFO weewx.manager: Added record 2020-
07-26 02:14:00 EDT (1595744040) to database 'weewx.sdb'
Jul 26 02:14:19 localhost weewx[6062] INFO weewx.manager: Added record 2020-
07-26 02:14:00 EDT (1595744040) to daily summary in 'weewx.sdb'
Jul 26 02:14:24 localhost weewx[6062] INFO weewx.engine: Main loop exiting. 
Shutting engine down.
Jul 26 02:14:24 localhost weewx[6062] INFO weewx.engine: Shutting down 
StdReport thread
Jul 26 02:14:31 localhost weewx[6062] ERROR weewx.reportengine: Caught 
unrecoverable exception in generator 
'user.belchertown.HighchartsJsonGenerator'
Jul 26 02:14:31 localhost weewx[6062] ERROR weewx.reportengine:  
 database is locked
Jul 26 02:14:31 localhost weewx[6062] ERROR weewx.reportengine:  
 Traceback (most recent call last):
Jul 26 02:14:31 localhost weewx[6062] ERROR weewx.reportengine:  
   File "/usr/share/weewx/weewx/reportengine.py", line 197, in run
Jul 26 02:14:31 localhost weewx[6062] ERROR weewx.reportengine:  
 obj.start()
Jul 26 02:14:31 localhost weewx[6062] ERROR weewx.reportengine:  
   File "/usr/share/weewx/weewx/reportengine.py", line 280, in start
Jul 26 02:14:31 localhost weewx[6062] ERROR weewx.reportengine:  
 self.run()
Jul 26 02:14:31 localhost weewx[6062] ERROR weewx.reportengine:  
   File "/usr/share/weewx/user/belchertown.py", line 1158, in run
Jul 26 02:14:31 localhost weewx[6062] ERROR weewx.reportengine:  
 start_ts = archive.firstGoodStamp()
Jul 26 02:14:31 localhost weewx[6062] ERROR weewx.reportengine:  
   File "/usr/share/weewx/weewx/manager.py", line 243, in firstGoodStamp
Jul 26 02:14:31 localhost weewx[6062] ERROR weewx.reportengine:  
 _row = self.getSql("SELECT MIN(dateTime) FROM %s" % self.table_name)
Jul 2

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

[Paul R Anderson]

Should we map  'altimeter': 'relbarometer' ?

Gw1000 produces 2 pressure readings:
As defined by Ecowitt Calibration of barometric pressure settings

*Absolute Pressure*
"Absolute barometric pressure, can be calibrated at manufacturing time by
comparing with a precise instrument that measures pressure at the same
location. In practice, sometimes small adjustments of a few hPa may be
needed"
*Relative Pressure*
"The relative pressure represents what the air pressure would indicate if
your station was at sea level and depends on the altitude of your console
and cannot be known in advance. This is why it needs an adjustment"

If you work your way thru there cal procedure you will see that you use
the  WS View app to set 2 offsets:
Abs Offset
Rel Offset
To set Rel Offset they have you determine station elevation and direct you
to a site that produces a offset based solely on elevation. So *Rel Offset* is
a *STATIC *offset applied against your Absolute Pressure. It never changes
if we set a Rel Offset of 6.0 hPa then Relative Pressure will always
read 6.0 hPa higher than Absolute Pressure.
As we see in WeeWX Wiki

Station or Gauge Pressure (key *pressure*): This is the absolute, raw
pressure as measured by your instrument. It is not corrected for altitude
or pressure. Pilots call this QFE
Sea-level Pressure (*barometer*): This is the pressure corrected for
altitude, temperature, and (frequently) humidity. Pilots call this QFF.
This is the value displayed by the standard skin.
Altimeter Pressure (*altimeter*) : This is the pressure corrected for
altitude, using a standard temperature profile. Pilots call this QNH.

Because we are on a very limited device which does not attempt in any way
to apply a temperature compensation I believe that mapping   'altimeter':
'relbarometer' may be more appropriate. StdWXCalculate will calculate
barometer for us when it appears in a template.
Thanks
Paul


>
> 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/F82E7D44-2090-4C09-9BA6-8355FE73841F%40gmail.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/CAOAVAefsj387Cx%2B8ffLt%2BjLS3vhnrwGp2%2Bpy3zUeuc2h7etKDg%40mail.gmail.com.

[weewx-user] default_field_map 'barometer': 'relbarometer' SHOULD BE altimeter': 'relbarometer'

[pa...@pauland.net]

Gw1000 produces 2 pressure readings:
As defined by Ecowitt Calibration of barometric pressure settings 

*Absolute Pressure*
"Absolute barometric pressure, can be calibrated at manufacturing time by 
comparing with a precise instrument that measures pressure at the same 
location. In practice, sometimes small adjustments of a few hPa may be 
needed"
*Relative Pressure*
"The relative pressure represents what the air pressure would indicate if 
your station was at sea level and depends on the altitude of your console 
and cannot be known in advance. This is why it needs an adjustment"

If you work your way thru there cal procedure you will see that you use 
the  WS View app to set 2 offsets:
Abs Offset
Rel Offset
To set Rel Offset they have you determine station elevation and direct you 
to a site that produces a offset based solely on elevation. So *Rel Offset* is 
a *STATIC *offset applied against your Absolute Pressure. It never changes 
if we set a Rel Offset of 6.0 hPa then 
Relative Pressure will always read 6.0 hPa higher than Absolute Pressure.
As we see in WeeWX Wiki

Station or Gauge Pressure (key *pressure*): This is the absolute, raw 
pressure as measured by your instrument. It is not corrected for altitude 
or pressure. Pilots call this QFE

Sea-level Pressure (*barometer*): This is the pressure corrected for 
altitude, temperature, and (frequently) humidity. Pilots call this QFF. 
This is the value displayed by the standard skin.

Altimeter Pressure (*altimeter*) : This is the pressure corrected for 
altitude, using a standard temperature profile. Pilots call this QNH.

Because we are on a very limited device which does not attempt in any way 
to apply a temperature compensation I believe that mapping   'altimeter': 
'relbarometer' may be more  appropriate. StdWXCalculate will calculate 
barometer for us when it appears in a template. 



Thanks
Paul'




-- 
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/935bed8d-3c63-4f6b-bdde-1c358735e449n%40googlegroups.com.

Re: [weewx-user] Re: wind chill for Vantage Pro 2

[Tom Keffer]

>
> On a side note, when I tried running weewx directly without a config file
> argument, it would not run, even though my config file is located at
> /etc/weewx/weewx.conf. Is that a bug?
>

No, but it suggests that you may not be editing the weewx.conf file that
weewxd is actually using.

At this point, I have to ask for a log. Restart weewx, let it run through
the first reporting cycle. Post the resultant log.

-tk

-- 
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/CAPq0zEBKBVmCwbnBgFQU_8AuhZsONkzsviri%2Bs-N_WfA5-B0fQ%40mail.gmail.com.

Re: [weewx-user] Re: wind chill for Vantage Pro 2

[brisguy foo]

OK, I tried stopping the daemon and running directly. The LOOP data shows 
no difference between outTemp and windchill although the console shows a 4 
degree difference. I have attached my conf file in case I messed up 
something. I see that when the change to support LOOP2 was submitted, a 
request was made for testers. Was it ever tested?

On a side note, when I tried running weewx directly without a config file 
argument, it would not run, even though my config file is located at 
/etc/weewx/weewx.conf. Is that a bug?

Thanks!


On Tuesday, July 28, 2020 at 5:56:38 PM UTC-7, gjr80 wrote:
>
> On Wednesday, 29 July 2020 10:00:01 UTC+10, brisguy foo wrote:
>>
>> UPDATE:
>>
>> Changed by weewx,conf file to read:
>> [Vantage]
>> ...
>> # Use LOOP2 data in order to get access to wind_chill
>> loop_request = 2
>>
>> Restarted weewx
>>
>> After only an hour or so, I saw that my console was reporting wind-chill 
>> that was 2 to 3 degrees lower than outside temp, but the weewx graph showed 
>> no difference.
>>
>
> Using the plots to check what is happening can give misleading results; 
> not saying that is the case here but some plots are not generated every 
> cycle and there can be caching issues. Best evidence is to look at what is 
> in the database or loop packets/archive records or look at the database.
>  
>
>>
>> Checked the syslog file today, and at the time of the restart found the 
>> following odd statement:
>> 16:40:18 raspberrypi weewx[30378]: wxcalculate: The following values will 
>> be calculated: barometer=prefer_hardware, windchill=prefer_hardware, 
>> dewpoint=prefer_hardware, appTemp=prefer_hardware, 
>> rainRate=prefer_hardware, windrun=prefer_hardware, 
>> heatindex=prefer_hardware, maxSolarRad=prefer_hardware, 
>> humidex=prefer_hardware, pressure=prefer_hardware, 
>> inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardware, 
>> cloudbase=prefer_hardware
>>
>> It seems odd that weewx would report it is calculating values that have 
>> been set to 'prefer_hardware', plus I only used that for five parameters, 
>> and weewx is reporting it has been set for several more.
>>
>> So now I have two issues:
>> 1. How can I tell whether LOOP2 packets ate being used (the graph 
>> indicates they are not)
>>
>
> There is no direct way that I know of. I would stop WeeWX and then run it 
> directly so you see the loop packets and archive records on the console. 
> What do you see in the loop packets (lines starting with LOOP:) and archive 
> records (lines starting REC:) on the console? How does windchill compare to 
> outTemp? If you are seeing THSW in the loop packets then WeeWX is receiving 
> the LOOP2 format loop packet, if THSW is not there then I suspect you are 
> still using the LOOP format loop packets. 
>  
>
>> 2. Why is weewx reporting it is calculating values that have been set to 
>> 'prefer_hardware'?
>>
>
> If WeeWX is calculating windchill it is most likely because windchill is 
> not being received by WeeWX. Change 'prefer_hardware' to 'hardware' for 
> windchill and restart/reload WeeWX. If windchill disappears it will be 
> because WeeWX is not receiving windchill which implies you are still using 
> LOOP format loop packets.
>
> @tkeffer. Tom, I see the vantage driver does not log what format loop 
> packet is being used, perhaps it should?
>
> Gary
>
>>
>> Thanks,  Stan
>>
>>
>> On Monday, July 27, 2020 at 4:47:41 PM UTC-7, brisguy foo wrote:
>>>
>>> Thanks for the replies guys!
>>>
>>> I did update my conf file as suggested, however I am confused by the 
>>> comment that wind chill "is not in the LOOP or archive record from the 
>>> console".
>>>
>>> I know I was able to see wind chill in historical data downloaded from 
>>> the console logger and displayed using WeatherLink. If you are referring to 
>>> the weewx archive, then I am concerned that the not all LOOP 2 data is 
>>> being stored.
>>>
>>> Please help me understand if you don't mind. I should be able to see the 
>>> result in a few days anyway, but I'd like to know how this works.
>>>
>>> Thanks!
>>>
>>>
>>>
>>> On Friday, July 24, 2020 at 5:21:48 PM UTC-7, Tom Keffer wrote:

 Geez, Gary, you're right! So, you would also have to specify LOOP2 
 packets. See the section [Vantage] 
  in the User's 
 Guide.

 [Vantage]
   loop_request = 2


 -tk

 On Fri, Jul 24, 2020 at 5:13 PM gjr80  wrote:

> Windchill is only in included in the Davis LOOP2 packet, it’s not in 
> the LOOP packet or archive record (the defaults) from the console. So 
> unless you have set WeeWX to use the LOOP2 packet WeeWX will never see 
> windchill from the console, irrespective of StdWXCalculate settings.
>
> 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 

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

[Graham Eddy]

> Not sure why you think ‘uvi’ is mapped to ‘uv’, it is and always has been 
> mapped to ‘UV’.

i misread the code and thought the case was wrong (it isn’t). i blame my 
spectacles. cheers

-- 
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/F82E7D44-2090-4C09-9BA6-8355FE73841F%40gmail.com.

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

[gjr80]

I must admit that I only looked at the wview-extended schema when developing 
the default field map and did not consider weewx.units.obs_group_dict, though 
it makes sense to use weewx.units.obs_group_dict where possible. Will change 
the default mapping for the three rain fields as suggested.

Not sure why you think ‘uvi’ is mapped to ‘uv’, it is and always has been 
mapped to ‘UV’.
 
The GW1000 API supports two UV related observations, these are labelled UV and 
UVI with supporting comments that UV is in micro watts/sq metre and UVI is an 
index from 0 to 15. UVI is mapped to WeeWX field UV. The GW1000 UV value is not 
what WeeWX knows as radiation. The discussion at 
https://github.com/gjr80/weewx-gw1000/issues/6 revealed the GW1000 derives what 
WeeWX knows as radiation from a luminosity observation. Also, the units don’t 
gel, the GW1000 UV field uses 2 bytes and thus a maximum of 65536 micro 
watts/sq metre, solar isolation on the other hand is of the order of hundreds 
of watts/sq metre. I am happy to be corrected but for now will be leaving 
uvRadiation mapping as is (actually will change uvRadiation to uvradiation).

Changes will appear in b8.

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/e7a4355e-6eab-4b64-aea5-3445be39906do%40googlegroups.com.

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

[Graham Eddy]

i expect my new GW1000 (to augment my vp2) to arrive monday so have started 
planning…

looking at gw1000 driver default_field_map, there seem to be a few mislabelled 
mappings into wview_extended.schema and weewx.units.obs_group_dict, they should 
be:
gw1000 → weewx
rainday → dayRain   (not passed thru unchanged)
rainhour → hourRain (not passed thru unchanged)
rainmonth → monthRain   (not passed thru unchanged)
uvi → UV(misspelt as uv)
uv → radiation  (misspelt as uvRadiation)

-- 
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/56AE06A5-AB87-4755-9AFA-86DD72C95C74%40gmail.com.