[weewx-user] Re: Weexw 5.1 and Red Hat packages

[James Taylor]

Hi Matthew

Thanks for picking it up and solving it.   We've all been there and copied 
the wrong things around.

I'll add the testing repo to my yum.repos.d for next time :-)

James

On Saturday, July 6, 2024 at 12:49:33 PM UTC+1 matthew wall wrote:

> On Saturday, July 6, 2024 at 4:28:19 AM UTC-4 James Taylor wrote:
>
> Is somebody able to remove the beta packages from the yum repository, 
> otherwise dnf thinks the latest package is 5.1.0b6-1.el9 and installing 
> 5.1.0-2.el9 is a downgrade.
>
>
> fixed.  sorry about that, i was sloppy when i did the repo updates.  there 
> *is* a testing repo at http://weewx.com/yum-test 
>
> we always put the alpha and beta releases in the 'development_versions' 
> directory of downloads so we/you can test, then we put some of those into 
> the 'yum-test' repo for end-to-end testing.
>
> this time i mistakenly replicated the yum-test repo onto the production 
> repo.
>
> m
>

-- 
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/573634b2-bdde-4275-9a27-2bac33bfcf5fn%40googlegroups.com.

[weewx-user] Weexw 5.1 and Red Hat packages

[James Taylor]

Hello

Is somebody able to remove the beta packages from the yum repository, 
otherwise dnf thinks the latest package is 5.1.0b6-1.el9 and installing 
5.1.0-2.el9 is a downgrade.

Installed Packages
weewx.noarch5.1.0b6-1.el9 
@weewx
Available Packages
weewx.noarch5.0.0-1.el9   
weewx
weewx.noarch5.0.1-1.el9   
weewx
weewx.noarch5.0.1-2.el9   
weewx
weewx.noarch5.0.1-3.el9   
weewx
weewx.noarch5.0.2-1.el9   
weewx
weewx.noarch5.1.0-1.el9   
weewx
weewx.noarch5.1.0-2.el9   
weewx
weewx.noarch5.1.0b5-2.el9 
weewx
weewx.noarch5.1.0b6-1.el9 
weewx

Would it be more sensible to also have a weewx-beta repo so the beta 
releases are stored in a different folder so test users can enable that 
repo is they wish?

[weewx]
name=weewx
baseurl=http://weewx.com/yum/weewx/el$releasever
enabled=1
gpgcheck=1

[weewx-beta]
name=weewx
baseurl=http://weewx.com/yum/weewx-beta/el$releasever
enabled=0
gpgcheck=1

Thanks in advance

James

-- 
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/ca6fa7fa-52af-4319-9ff5-0b92718d05e7n%40googlegroups.com.

Re: [weewx-user] Change to daylight saving time stops data update

[James Taylor]

Hello

I just have a cronjob that runs that works for European clock changes.

02 02 25-31 3,10 * [ $(date +\%w) -eq '0' ] && /bin/weectl device 
--clear-memory >/dev/null 2>&1

James
On Monday, April 1, 2024 at 10:43:35 AM UTC+1 Devonian wrote:

> Regular 'issue' for me in UK too.
> I do this as I'm not yet on v5...amend as req'd.
>
> sudo service weewx stop
>
> sudo /home/weewx/bin/wee_device --dump  (or wherever your wee_device (or 
> weectl device --dump) command is located)
>
> sudo /home/weewx/bin/wee_device --clear  (or wherever your wee_device (or 
> weectl device --clear) command is located)
>
> sudo service weewx start
>
> Never lost any data yet and to speed things up after clocks change. I try 
> to remember the night before clocks change to clear the logger if all 
> current data is saved to the db.
>
> HTH
>
> Nigel
>
> On Monday 1 April 2024 at 00:05:08 UTC+1 Tom Keffer wrote:
>
>> Issue #247  explains the 
>> problem.
>>
>> On Sun, Mar 31, 2024 at 3:56 PM Stephen  wrote:
>>
>>> I have two Davis Vantage Pro 2 weather stations at different locations. 
>>> Both stations stopped updating their web pages at 2.00am last night, the 
>>> moment daylight saving started.
>>>
>>> I'm running Weewx v5.0.1 at both locations.  Both Vantage Pro2 consoles 
>>> are configured to automatically change to DST.
>>>
>>> There is an old thread from 2017 about this problem here 
>>> https://groups.google.com/g/weewx-user/c/rM2IDREAWiI/m/oloGcj7aAAAJ.
>>>
>>> Taking the advice in that thread I've got one of the stations working 
>>> again by executing  weectl device --dump.  I've left the other station as 
>>> it is at the moment.
>>>
>>> This has never happened before, but I wasn't running v5.0.1 this time 
>>> last year.
>>>
>>> Any idea what's going on?
>>>
>>> -- 
>>> 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+...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/bc83e9f6-5231-4702-8afc-758c645061cdn%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/a53a7b90-5284-4ddf-bc09-311d6f75f007n%40googlegroups.com.

Re: [weewx-user] weedb.OperationalError: no such function: RADIANS

[James Taylor]

 Correct.   V4.9.1 was released on the 25 October to cover the issue.

4.9.110/25/2022 
Fix problem with `wind` for older versions of sqlite. 

James
On Friday, October 28, 2022 at 5:47:58 AM UTC+1 kac...@gmail.com wrote:

> I don't see an error in today's log. Yesterday I upgraded to 4.9.1. As 
> Raffaello said, maybe this was problem only in 4.9.0?

-- 
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/beddeae7-da25-4a5c-bff1-18273fe6f366n%40googlegroups.com.

Re: [weewx-user] Calculating average wind direction when aggregate is higher than your archive period.

[James Taylor]

Given the update, I have just backed out to sqlite3 (3.34.1) and upgraded 
to weewx 4.9.1 and I can see I'm getting the same result with the 
changes.   Excellent coding Tom.

# python3 -c "import sqlite3; print(sqlite3.sqlite_version)"
3.34.1

obs_lookup is wind
Start time is 1665440100 and end time is 1665442800
x_domain entries are 1665440100 and 1665442800
archive is 
aggregate_type is vecdir
aggregate_interval is 900
([1665440100, 1665441000, 1665441900], 'unix_epoch', 'group_time')
([355.0, 357.7404188153435, 2.124825517227194], 'degree_compass', 
'group_direction')

On Monday, October 24, 2022 at 10:34:49 PM UTC+1 James Taylor wrote:

> No problems
>
> I wish!  My day job is mainly working with Red Hat and its derivatives 
> (Rocky / CentOS)
>
> James
>
> On Monday, October 24, 2022 at 10:08:48 PM UTC+1 tke...@gmail.com wrote:
>
>> Thanks for checking this, James!
>>
>> Nice to have a Debian whiz on board!
>>
>> On Mon, Oct 24, 2022 at 1:52 PM James Taylor <
>> ja...@blisteringbarnacles.co.uk> wrote:
>>
>>> Yes, I was surprised.  Hopefully Debian 12 ( Bookworm) when it comes 
>>> along in 2023 has a newer version as standard
>>>
>>> I just upgraded to the latest version, which I would only recommend for 
>>> those that are comfortable with this sort of thing.   It didn't actually 
>>> take that long to compile on my Pi4
>>>
>>> mkdir sqlite && cd sqlite
>>> wget https://www.sqlite.org/2022/sqlite-autoconf-3390400.tar.gz
>>> tar xvfz sqlite-autoconf-3390400.tar.gz
>>> cd sqlite-autoconf-3390400
>>> ./configure
>>> make
>>> sudo make install
>>> /usr/local/bin/sqlite3 --version # returns 3.39.4 2022-09-29 
>>>
>>> You also need to replace 
>>> /usr/lib/arm-linux-gnueabihf/libsqlite3.so.0.8.6 with the version compiled 
>>> under sqlite-autoconf-3390400/.libs/, so python3 will start using the newer 
>>> instance (Note if somebody is reading this, it is at their risk and 
>>> understand the consequencies
>>>
>>> # python3 -c "import sqlite3; print(sqlite3.sqlite_version)"
>>> 3.39.4
>>>
>>> However it is now working using the example from my original email
>>>
>>> obs_lookup is wind
>>> Start time is 1665440100 and end time is 1665442800
>>> x_domain entries are 1665440100 and 1665442800
>>> archive is 
>>> aggregate_type is vecdir
>>> aggregate_interval is 900
>>> ([1665440100, 1665441000, 1665441900], 'unix_epoch', 'group_time')
>>> ([355.0, 357.7404188153435, 2.124825517227194], 'degree_compass', 
>>> 'group_direction')
>>>
>>> James
>>> On Monday, October 24, 2022 at 8:39:19 PM UTC+1 tke...@gmail.com wrote:
>>>
>>>> That's unfortunate. Bullseye has been out for a while, so I had just 
>>>> assumed that it had 3.35.
>>>>
>>>> I think sqlite maintains their own repository. You could try upgrading 
>>>> from that.
>>>>
>>>> On Mon, Oct 24, 2022 at 11:54 AM James Taylor <
>>>> ja...@blisteringbarnacles.co.uk> wrote:
>>>>
>>>>> Cool.
>>>>>
>>>>> Just need to find a way to upgrade sqlite3 on Raspberry PI.The 
>>>>> packaged version is 3.34.1 on is Raspbian 11 (Bullseye) and this is 
>>>>> wanting 
>>>>> at least 3.35.
>>>>>
>>>>> James
>>>>>
>>>>> On Saturday, October 22, 2022 at 10:26:27 PM UTC+1 tke...@gmail.com 
>>>>> wrote:
>>>>>
>>>>>> Fixed with commit 407602c 
>>>>>> <https://github.com/weewx/weewx/commit/407602c03d307945284c2f6544f3f500731699ea>,
>>>>>>  
>>>>>> to appear in V4.9.
>>>>>>
>>>>>> On Tue, Oct 18, 2022 at 4:53 PM Tom Keffer  wrote:
>>>>>>
>>>>>>> You're right that the wind direction plots that come with the 
>>>>>>> Seasons skin are not very useful. They might make sense for short time 
>>>>>>> periods that do not use aggregation, but not for longer periods. 
>>>>>>> Unfortunately, the way vecdir is set up now, aggregation intervals have 
>>>>>>> to 
>>>>>>> be multiples of a day. Hence, your example works, but it won't for 
>>>>>>> plots 
>>>>

Re: [weewx-user] Calculating average wind direction when aggregate is higher than your archive period.

[James Taylor]

No problems

I wish!  My day job is mainly working with Red Hat and its derivatives 
(Rocky / CentOS)

James

On Monday, October 24, 2022 at 10:08:48 PM UTC+1 tke...@gmail.com wrote:

> Thanks for checking this, James!
>
> Nice to have a Debian whiz on board!
>
> On Mon, Oct 24, 2022 at 1:52 PM James Taylor <
> ja...@blisteringbarnacles.co.uk> wrote:
>
>> Yes, I was surprised.  Hopefully Debian 12 ( Bookworm) when it comes 
>> along in 2023 has a newer version as standard
>>
>> I just upgraded to the latest version, which I would only recommend for 
>> those that are comfortable with this sort of thing.   It didn't actually 
>> take that long to compile on my Pi4
>>
>> mkdir sqlite && cd sqlite
>> wget https://www.sqlite.org/2022/sqlite-autoconf-3390400.tar.gz
>> tar xvfz sqlite-autoconf-3390400.tar.gz
>> cd sqlite-autoconf-3390400
>> ./configure
>> make
>> sudo make install
>> /usr/local/bin/sqlite3 --version # returns 3.39.4 2022-09-29 
>>
>> You also need to replace /usr/lib/arm-linux-gnueabihf/libsqlite3.so.0.8.6 
>> with the version compiled under sqlite-autoconf-3390400/.libs/, so python3 
>> will start using the newer instance (Note if somebody is reading this, it 
>> is at their risk and understand the consequencies
>>
>> # python3 -c "import sqlite3; print(sqlite3.sqlite_version)"
>> 3.39.4
>>
>> However it is now working using the example from my original email
>>
>> obs_lookup is wind
>> Start time is 1665440100 and end time is 1665442800
>> x_domain entries are 1665440100 and 1665442800
>> archive is 
>> aggregate_type is vecdir
>> aggregate_interval is 900
>> ([1665440100, 1665441000, 1665441900], 'unix_epoch', 'group_time')
>> ([355.0, 357.7404188153435, 2.124825517227194], 'degree_compass', 
>> 'group_direction')
>>
>> James
>> On Monday, October 24, 2022 at 8:39:19 PM UTC+1 tke...@gmail.com wrote:
>>
>>> That's unfortunate. Bullseye has been out for a while, so I had just 
>>> assumed that it had 3.35.
>>>
>>> I think sqlite maintains their own repository. You could try upgrading 
>>> from that.
>>>
>>> On Mon, Oct 24, 2022 at 11:54 AM James Taylor <
>>> ja...@blisteringbarnacles.co.uk> wrote:
>>>
>>>> Cool.
>>>>
>>>> Just need to find a way to upgrade sqlite3 on Raspberry PI.The 
>>>> packaged version is 3.34.1 on is Raspbian 11 (Bullseye) and this is 
>>>> wanting 
>>>> at least 3.35.
>>>>
>>>> James
>>>>
>>>> On Saturday, October 22, 2022 at 10:26:27 PM UTC+1 tke...@gmail.com 
>>>> wrote:
>>>>
>>>>> Fixed with commit 407602c 
>>>>> <https://github.com/weewx/weewx/commit/407602c03d307945284c2f6544f3f500731699ea>,
>>>>>  
>>>>> to appear in V4.9.
>>>>>
>>>>> On Tue, Oct 18, 2022 at 4:53 PM Tom Keffer  wrote:
>>>>>
>>>>>> You're right that the wind direction plots that come with the Seasons 
>>>>>> skin are not very useful. They might make sense for short time periods 
>>>>>> that 
>>>>>> do not use aggregation, but not for longer periods. Unfortunately, the 
>>>>>> way 
>>>>>> vecdir is set up now, aggregation intervals have to be multiples of a 
>>>>>> day. 
>>>>>> Hence, your example works, but it won't for plots with shorter 
>>>>>> aggregation 
>>>>>> intervals.
>>>>>>
>>>>>> I've created Issue #800 <https://github.com/weewx/weewx/issues/800> 
>>>>>> to track.
>>>>>>
>>>>>> On Mon, Oct 17, 2022 at 1:52 PM bell...@gmail.com  
>>>>>> wrote:
>>>>>>
>>>>>>> I'm still trying to wrap my head around wind data in WeeWX... Does 
>>>>>>> that mean that in the Seasons skin, the weekwinddir, monthwindir, and 
>>>>>>> yearwinddir plots are not a vector average? If yearwinddir plot was 
>>>>>>> something like below, would it generate a vector average?
>>>>>>> [[[yearwinddir]]]
>>>>>>> yscale = 0.0, 360.0, 45.0
>>>>>>> line_type = None
>>>>>>> marker_type = box
>>>>>>>   

Re: [weewx-user] Calculating average wind direction when aggregate is higher than your archive period.

[James Taylor]

 Yes, I was surprised.  Hopefully Debian 12 ( Bookworm) when it comes along 
in 2023 has a newer version as standard

I just upgraded to the latest version, which I would only recommend for 
those that are comfortable with this sort of thing.   It didn't actually 
take that long to compile on my Pi4

mkdir sqlite && cd sqlite
wget https://www.sqlite.org/2022/sqlite-autoconf-3390400.tar.gz
tar xvfz sqlite-autoconf-3390400.tar.gz
cd sqlite-autoconf-3390400
./configure
make
sudo make install
/usr/local/bin/sqlite3 --version # returns 3.39.4 2022-09-29 

You also need to replace /usr/lib/arm-linux-gnueabihf/libsqlite3.so.0.8.6 
with the version compiled under sqlite-autoconf-3390400/.libs/, so python3 
will start using the newer instance (Note if somebody is reading this, it 
is at their risk and understand the consequencies

# python3 -c "import sqlite3; print(sqlite3.sqlite_version)"
3.39.4

However it is now working using the example from my original email

obs_lookup is wind
Start time is 1665440100 and end time is 1665442800
x_domain entries are 1665440100 and 1665442800
archive is 
aggregate_type is vecdir
aggregate_interval is 900
([1665440100, 1665441000, 1665441900], 'unix_epoch', 'group_time')
([355.0, 357.7404188153435, 2.124825517227194], 'degree_compass', 
'group_direction')

James
On Monday, October 24, 2022 at 8:39:19 PM UTC+1 tke...@gmail.com wrote:

> That's unfortunate. Bullseye has been out for a while, so I had just 
> assumed that it had 3.35.
>
> I think sqlite maintains their own repository. You could try upgrading 
> from that.
>
> On Mon, Oct 24, 2022 at 11:54 AM James Taylor <
> ja...@blisteringbarnacles.co.uk> wrote:
>
>> Cool.
>>
>> Just need to find a way to upgrade sqlite3 on Raspberry PI.The 
>> packaged version is 3.34.1 on is Raspbian 11 (Bullseye) and this is wanting 
>> at least 3.35.
>>
>> James
>>
>> On Saturday, October 22, 2022 at 10:26:27 PM UTC+1 tke...@gmail.com 
>> wrote:
>>
>>> Fixed with commit 407602c 
>>> <https://github.com/weewx/weewx/commit/407602c03d307945284c2f6544f3f500731699ea>,
>>>  
>>> to appear in V4.9.
>>>
>>> On Tue, Oct 18, 2022 at 4:53 PM Tom Keffer  wrote:
>>>
>>>> You're right that the wind direction plots that come with the Seasons 
>>>> skin are not very useful. They might make sense for short time periods 
>>>> that 
>>>> do not use aggregation, but not for longer periods. Unfortunately, the way 
>>>> vecdir is set up now, aggregation intervals have to be multiples of a day. 
>>>> Hence, your example works, but it won't for plots with shorter aggregation 
>>>> intervals.
>>>>
>>>> I've created Issue #800 <https://github.com/weewx/weewx/issues/800> to 
>>>> track.
>>>>
>>>> On Mon, Oct 17, 2022 at 1:52 PM bell...@gmail.com  
>>>> wrote:
>>>>
>>>>> I'm still trying to wrap my head around wind data in WeeWX... Does 
>>>>> that mean that in the Seasons skin, the weekwinddir, monthwindir, and 
>>>>> yearwinddir plots are not a vector average? If yearwinddir plot was 
>>>>> something like below, would it generate a vector average?
>>>>> [[[yearwinddir]]]
>>>>> yscale = 0.0, 360.0, 45.0
>>>>> line_type = None
>>>>> marker_type = box
>>>>> marker_size = 2
>>>>> #windDir
>>>>> wind
>>>>> aggregate_type = vecdir
>>>>> When I changed the yearwinddir plot to the above, it ran and I got 
>>>>> what looked like a different plot.
>>>>> Thanks. rich
>>>>>
>>>>> On Monday, 17 October 2022 at 09:05:37 UTC-4 tke...@gmail.com wrote:
>>>>>
>>>>>> Calculating the vector averaged direction requires a vector, so the 
>>>>>> observation type is 'wind', which is a vector, not 'windDir'. The 
>>>>>> aggregation that returns direction from a vector is 'vecdir', so, you 
>>>>>> want:
>>>>>>
>>>>>> (start_ts, stop_ts, dirs) = weewx.xtypes.get_series('wind', x_domain, 
>>>>>> db_lookup(data_binding=binding), 'vecdir', aggregate_interval)
>>>>>>
>>>>>> Unfortunately, 'wind' appears only in the daily summaries. This means 
>>>>>

Re: [weewx-user] Calculating average wind direction when aggregate is higher than your archive period.

[James Taylor]

Cool.

Just need to find a way to upgrade sqlite3 on Raspberry PI.The packaged 
version is 3.34.1 on is Raspbian 11 (Bullseye) and this is wanting at least 
3.35.

James

On Saturday, October 22, 2022 at 10:26:27 PM UTC+1 tke...@gmail.com wrote:

> Fixed with commit 407602c 
> <https://github.com/weewx/weewx/commit/407602c03d307945284c2f6544f3f500731699ea>,
>  
> to appear in V4.9.
>
> On Tue, Oct 18, 2022 at 4:53 PM Tom Keffer  wrote:
>
>> You're right that the wind direction plots that come with the Seasons 
>> skin are not very useful. They might make sense for short time periods that 
>> do not use aggregation, but not for longer periods. Unfortunately, the way 
>> vecdir is set up now, aggregation intervals have to be multiples of a day. 
>> Hence, your example works, but it won't for plots with shorter aggregation 
>> intervals.
>>
>> I've created Issue #800 <https://github.com/weewx/weewx/issues/800> to 
>> track.
>>
>> On Mon, Oct 17, 2022 at 1:52 PM bell...@gmail.com  
>> wrote:
>>
>>> I'm still trying to wrap my head around wind data in WeeWX... Does that 
>>> mean that in the Seasons skin, the weekwinddir, monthwindir, and 
>>> yearwinddir plots are not a vector average? If yearwinddir plot was 
>>> something like below, would it generate a vector average?
>>> [[[yearwinddir]]]
>>> yscale = 0.0, 360.0, 45.0
>>> line_type = None
>>> marker_type = box
>>> marker_size = 2
>>> #windDir
>>> wind
>>> aggregate_type = vecdir
>>> When I changed the yearwinddir plot to the above, it ran and I got what 
>>> looked like a different plot.
>>> Thanks. rich
>>>
>>> On Monday, 17 October 2022 at 09:05:37 UTC-4 tke...@gmail.com wrote:
>>>
>>>> Calculating the vector averaged direction requires a vector, so the 
>>>> observation type is 'wind', which is a vector, not 'windDir'. The 
>>>> aggregation that returns direction from a vector is 'vecdir', so, you want:
>>>>
>>>> (start_ts, stop_ts, dirs) = weewx.xtypes.get_series('wind', x_domain, 
>>>> db_lookup(data_binding=binding), 'vecdir', aggregate_interval)
>>>>
>>>> Unfortunately, 'wind' appears only in the daily summaries. This means 
>>>> aggregate_interval must be multiples of one day. This restriction could be 
>>>> relaxed should someone want to write the necessary xtypes extension. 
>>>>
>>>>
>>>>
>>>> On Sun, Oct 16, 2022 at 6:35 AM James Taylor <
>>>> ja...@blisteringbarnacles.co.uk> wrote:
>>>>
>>>>> Hello
>>>>>
>>>>> Following on from https://github.com/weewx/weewx/issues/798, I've 
>>>>> been trying to replicate and understand weewx behaviour when it comes to 
>>>>> using get_series and get_aggregate.
>>>>>
>>>>> So if you are trying to aggregate winddir for graphing purposes, you 
>>>>> want to get a wind vector which I understand
>>>>>
>>>>> Here is my example where my data is being archived every 300 seconds
>>>>>
>>>>> (time_start_vt, time_stop_vt, obs_vt) = weewx.xtypes.get_series( 
>>>>> obs_lookup, x_domain, db_lookup(data_binding=binding), aggregate_type, 
>>>>> aggregate_interval)
>>>>>
>>>>> obs_lookup is windDir
>>>>> Start time is 1665440100 and end time is 1665442800
>>>>> x_domain entries are 1665440100 and 1665442800
>>>>> aggregate_type is avg 
>>>>> aggregate_interval is 300 
>>>>> ([355.0, 355.0, 355.0, 355.480837630687, 0.0, 0.0, 0.0, 0.0, 
>>>>> 4.249651034454402], 'degree_compass', 'group_direction') 
>>>>> aggregate_interval is 900 
>>>>> ([355.0, 118.49361254356234, 1.416550344818134], 'degree_compass', 
>>>>> 'group_direction')
>>>>>
>>>>> I can see for the second group it is returning an average rather than 
>>>>> a vector value of around 358.5, but trying to understand how we should be 
>>>>> coding it.
>>>>>
>>>>> If I can change to aggregate of vecdir or vecavg I get a UnknownType 
>>>>> error
>>>>>
>>>>> Any 

Re: [weewx-user] Calculating average wind direction when aggregate is higher than your archive period.

[James Taylor]

Thanks Tom for coming back to me and makes sense now on how 'wind' fits 
into it all.

On Monday, October 17, 2022 at 2:05:37 PM UTC+1 tke...@gmail.com wrote:

> Calculating the vector averaged direction requires a vector, so the 
> observation type is 'wind', which is a vector, not 'windDir'. The 
> aggregation that returns direction from a vector is 'vecdir', so, you want:
>
> (start_ts, stop_ts, dirs) = weewx.xtypes.get_series('wind', x_domain, 
> db_lookup(data_binding=binding), 'vecdir', aggregate_interval)
>
> Unfortunately, 'wind' appears only in the daily summaries. This means 
> aggregate_interval must be multiples of one day. This restriction could be 
> relaxed should someone want to write the necessary xtypes extension. 
>
>
>
> On Sun, Oct 16, 2022 at 6:35 AM James Taylor <
> ja...@blisteringbarnacles.co.uk> wrote:
>
>> Hello
>>
>> Following on from https://github.com/weewx/weewx/issues/798, I've been 
>> trying to replicate and understand weewx behaviour when it comes to using 
>> get_series and get_aggregate.
>>
>> So if you are trying to aggregate winddir for graphing purposes, you want 
>> to get a wind vector which I understand
>>
>> Here is my example where my data is being archived every 300 seconds
>>
>> (time_start_vt, time_stop_vt, obs_vt) = weewx.xtypes.get_series( 
>> obs_lookup, x_domain, db_lookup(data_binding=binding), aggregate_type, 
>> aggregate_interval)
>>
>> obs_lookup is windDir
>> Start time is 1665440100 and end time is 1665442800
>> x_domain entries are 1665440100 and 1665442800
>> aggregate_type is avg 
>> aggregate_interval is 300 
>> ([355.0, 355.0, 355.0, 355.480837630687, 0.0, 0.0, 0.0, 0.0, 
>> 4.249651034454402], 'degree_compass', 'group_direction') 
>> aggregate_interval is 900 
>> ([355.0, 118.49361254356234, 1.416550344818134], 'degree_compass', 
>> 'group_direction')
>>
>> I can see for the second group it is returning an average rather than a 
>> vector value of around 358.5, but trying to understand how we should be 
>> coding it.
>>
>> If I can change to aggregate of vecdir or vecavg I get a UnknownType error
>>
>> Any help will be appreciated here.
>>
>> James
>>
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/2ed7f92d-c030-45df-a241-2abde9c647een%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/weewx-user/2ed7f92d-c030-45df-a241-2abde9c647een%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/f7bb1df7-bfd3-4c9c-b6c0-27d732a15e6fn%40googlegroups.com.

[weewx-user] Calculating average wind direction when aggregate is higher than your archive period.

[James Taylor]

Hello

Following on from https://github.com/weewx/weewx/issues/798, I've been 
trying to replicate and understand weewx behaviour when it comes to using 
get_series and get_aggregate.

So if you are trying to aggregate winddir for graphing purposes, you want 
to get a wind vector which I understand

Here is my example where my data is being archived every 300 seconds

(time_start_vt, time_stop_vt, obs_vt) = weewx.xtypes.get_series( 
obs_lookup, x_domain, db_lookup(data_binding=binding), aggregate_type, 
aggregate_interval)

obs_lookup is windDir
Start time is 1665440100 and end time is 1665442800
x_domain entries are 1665440100 and 1665442800
aggregate_type is avg 
aggregate_interval is 300 
([355.0, 355.0, 355.0, 355.480837630687, 0.0, 0.0, 0.0, 0.0, 
4.249651034454402], 'degree_compass', 'group_direction') 
aggregate_interval is 900 
([355.0, 118.49361254356234, 1.416550344818134], 'degree_compass', 
'group_direction')

I can see for the second group it is returning an average rather than a 
vector value of around 358.5, but trying to understand how we should be 
coding it.

If I can change to aggregate of vecdir or vecavg I get a UnknownType error

Any help will be appreciated here.

James

-- 
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/2ed7f92d-c030-45df-a241-2abde9c647een%40googlegroups.com.

[weewx-user] Re: Wind Speed showing as km/h instead of knots

[James Taylor]

 Barry

group_speed = knot should be set under Groups, rather than at the 
[[[Units]]] level in weewx.conf.

James


On Wednesday, June 15, 2022 at 3:16:41 AM UTC+1 Barry wrote:

> Hi, using WeeWx 4.80 and Belchertown 1.2. All seems to working as I want 
> with the exception of the reporting of windspeed in the Belchertown skin 
> and graphs.
>
> in skin.conf under
> [UNITS]
>[[GROUPS]]
>
> I have
> group_speed  = knot
>
> I have the same in weewx.conf under
> [StdReport]
>[[Defaults]]
>unit_system = metric
>[[[Units]]] 
>   group_speed = knot
>
> I believe that unit_system = metric only affects the units for database 
> storage.
>
> Is there something else I need to set to get the speed in knots for 
> reports and graphs?
>
> Barry
>

-- 
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/bf3a83d8-a2b7-4f1f-af05-3dbff87a8ea1n%40googlegroups.com.

[weewx-user] Re: Wind Speed showing as km/h instead of knots

[James Taylor]

Barry

Have you got group_speed = knot set under Groups, rather than under 
[[[Units]]] in weewx.conf?

James
On Wednesday, June 15, 2022 at 3:16:41 AM UTC+1 Barry wrote:

> Hi, using WeeWx 4.80 and Belchertown 1.2. All seems to working as I want 
> with the exception of the reporting of windspeed in the Belchertown skin 
> and graphs.
>
> in skin.conf under
> [UNITS]
>[[GROUPS]]
>
> I have
> group_speed  = knot
>
> I have the same in weewx.conf under
> [StdReport]
>[[Defaults]]
>unit_system = metric
>[[[Units]]] 
>   group_speed = knot
>
> I believe that unit_system = metric only affects the units for database 
> storage.
>
> Is there something else I need to set to get the speed in knots for 
> reports and graphs?
>
> Barry
>

-- 
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/4cad337c-6ee2-4739-9d80-3194efa26baan%40googlegroups.com.

Re: [weewx-user] Re: Problem with units

[James Taylor]

This has been fixed in a commit to the belchertown code today (31st March).

This was due to the commit which means that count is now specified as %d in 
units.py.  This broke the Belchertown code for working out the rounding 
value on graphs as it was expecting a %.xf response  - 
https://github.com/weewx/weewx/commit/9a388867399a3453b437722f7bb727c87cb853f8.


On Wednesday, March 30, 2022 at 2:07:42 PM UTC+1 tke...@gmail.com wrote:

> Looks like a Belchertown problem. It's pretty similar to this post: 
> https://groups.google.com/g/weewx-user/c/VfpSRxNQits/m/8AlH4dv0AwAJ
>
> On Mon, Feb 28, 2022 at 1:11 AM Dani Talens  wrote:
>
>> Hi, 
>>
>> I have a similar error but with lightning_strike_count. I use Belchertown 
>> 1.3.b1 skin.
>>
>> Feb 28 09:58:24 minipc weewx[4152094] ERROR weewx.reportengine: 
>> File "/usr/share/weewx/weewx/reportengine.py", line 197, in run
>> Feb 28 09:58:24 minipc weewx[4152094] ERROR weewx.reportengine: 
>>   obj.start()
>> Feb 28 09:58:24 minipc weewx[4152094] ERROR weewx.reportengine: 
>> File "/usr/share/weewx/weewx/reportengine.py", line 378, in start
>> Feb 28 09:58:24 minipc weewx[4152094] ERROR weewx.reportengine: 
>>   self.run()
>> Feb 28 09:58:24 minipc weewx[4152094] ERROR weewx.reportengine: 
>> File "/usr/share/weewx/user/belchertown.py", line 2714, in run
>> Feb 28 09:58:24 minipc weewx[4152094] ERROR weewx.reportengine: 
>>   series_data = self.get_observation_data(
>> Feb 28 09:58:24 minipc weewx[4152094] ERROR weewx.reportengine: 
>> File "/usr/share/weewx/user/belchertown.py", line 3726, in 
>> get_observation_data
>> Feb 28 09:58:24 minipc weewx[4152094] ERROR weewx.reportengine: 
>>   usage_round = int(
>> Feb 28 09:58:24 minipc weewx[4152094] ERROR weewx.reportengine: 
>>   ValueError: invalid literal for int() with base 10: '%'
>> Feb 28 09:58:24 minipc weewx[4152094] ERROR weewx.reportengine: 
>>   Generator terminated
>>
>> If you comment on [[[lightning_strike_count]]] entry in graph.conf file, 
>> this error disappears.
>>
>> El dia dimarts, 15 de febrer de 2022 a les 18:22:11 UTC+1, 
>> udo.kl...@gmail.com va escriure:
>>
>>> Hi Gary,
>>>
>>> this was the solution for my unit problem. Thanks for your help, also 
>>> for the hint about using the extensions.py
>>>
>>> Many greetings
>>> Udo
>>>
>>> gjr80 schrieb am Montag, 14. Februar 2022 um 21:48:48 UTC+1:
>>>
 I see now there have been some changes have been introduced in WeeWX 
 v4.6.x to how default labelling and formatting of observation types is 
 determined and it appears that group_energy/watt_hour may have fallen 
 through the cracks. I think we can work around the issue in your case by 
 adding some additional lines to user/extensions.py:

 weewx.units.default_unit_format_dict['watt_hour'] = '%.1f'
 weewx.units.default_unit_label_dict['watt_hour'] = u' Wh' 

 Again you will need to restart WeeWX for the changes to take effect and 
 hopefully the first report cycle should add you missing units/formatting.

 Gary

 On Tuesday, 15 February 2022 at 04:18:53 UTC+10 udo.kl...@gmail.com 
 wrote:

> Hi Gary, unfortunately your tip did not work. "signal1" still has no 
> unit. Before the update it still did. 
>
> gjr80 schrieb am Montag, 14. Februar 2022 um 01:58:29 UTC+1:
>
>> Making changes to units.py  is a poor approach to dealing with 
>> problems and should be avoided, at best your changes will not survive a 
>> WeeWX upgrade; at worst your changes could unknowingly cause problems 
>> elsewhere with WeeWX.
>>
>> If you wish to assign an observation type to a unit group this is 
>> best done through the user/extensions.py file. user/extensions.py is 
>> intended for users to add code that is to be run during the WeeWX 
>> startup 
>> and allows user changes to the WeeWX environment to be made in a safe 
>> manner. Files in the user directory are protected during a WeeWX upgrade 
>> and will not be overwritten. I suggest you revert your changes to 
>> units.py and try adding the following to user/extensions.py 
>> (untested):
>>
>> import weewx.units
>> weewx.units.obs_group_dict['signal1'] = 'group_energy'
>>
>> Save extensions.py and restart WeeWX. Does that fix your problem?
>>
>> Gary
>> On Monday, 14 February 2022 at 01:14:14 UTC+10 udo.kl...@gmail.com 
>> wrote:
>>
>>> Hello all,
>>>
>>> I have updated this weekend to WeeWX version 4.6.2. Actually 
>>> everything works as usual, but in my photovoltaic data no units are 
>>> displayed anymore. I have changed the assignment in the units.py as 
>>> follows "signal1" : "group_energy", but without success.
>>>
>>> Who knows advice?
>>>
>> -- 
>>
> You received this me

[weewx-user] Re: windDir is None since upgrading to 4.6.2 from 4.5.1 on VP2

[James Taylor]

Thanks for the info.

James

On Friday, February 18, 2022 at 10:24:21 PM UTC gjr80 wrote:

> No problems James. 
>
> Regards the services, think of the [[Services]] stanza as a matrix. When 
> an event occurs (for example the arrival of a new archive record) WeeWX 
> works it way down each 'row' (ie each _services option) in turn 
> checking each 'column' (ie each service defined in that row) to see if that 
> service was bound to the event in question. If it is bound WeeWX executes 
> the designated code (method) for that service, if it's not bound WeeWX 
> moves on to the next 'column'/service. The services are loosely grouped by 
> type, but there is really no great difference between service types. Order 
> matters, typically services towards the top of the list (eg data) will be 
> doing things to the incoming data to maybe add observations, eg you may 
> have a service that reads air quality data from a separate sensor suite and 
> adds it to loop packets and archive records (such a service would likely be 
> bound to the new archive record and new loop packet events). You would not 
> put such a service after StdArchive as the data would not be saved to the 
> archive. Services that process the incoming data and perhaps change the 
> archive record (eg StdWxCalculate) need to be 'placed' after all of the 
> incoming data has been assembled but before StdArchive writes the archive 
> record to database.
>
> In your case some careful placement of your service in the processing 
> chain has solved the problem.
>
> Gary
>
> On Friday, 18 February 2022 at 19:42:43 UTC+10 James Taylor wrote:
>
>> Sorry Gary
>>
>> Yes I was also annoyed when I caught the extension and remembered why it 
>> was there :-(   I did learn a lot more about the code setup.  I had been 
>> running the debug at 2 and still missed it so therefore renamed it to 
>> windDir so it matches the same case at least!
>>
>> I'm still trying to fully understand the 'services' implementation, but 
>> yes I've moved it from data_services to the end of process_services, and 
>> also before weewx.engine.StdArchive and in both cases it continued to 
>> operate as expected.
>>
>> I will update Belchertown users in case they are using Pat's service.
>>
>> Thanks again and sorry for the long winded way of getting there.
>>
>> James
>>
>> On Friday, February 18, 2022 at 1:56:39 AM UTC gjr80 wrote:
>>
>>> So if I understand your post correctly you are running Pat's service to 
>>> delete windDir from archive records? If so that sort of info would have 
>>> been nice to know from the outset; that is why we ask for a startup log 
>>> with debug=1 - it gives us key WeeWX config info so we know what 
>>> services are being run and what aren't.
>>>
>>> Again if you are running Pat's service then the solution should be 
>>> fairly straightforward; instead of running the service as a data service, 
>>> run it as a process service but list it after StdWxCalculate. This way 
>>> StdWxCalculate can do whatever to the archive record and then Pat's 
>>> service will come along and delete windDir. When StdArchive steps in it 
>>> will extract windDir from the accumulator as before (assuming windDir 
>>> is in loop packets) and add it to the archive record before it is saved to 
>>> database. Making Pat's service an archive service would probably work as 
>>> well, as long as it was listed in archive_services in weewx.conf before 
>>> StdArchive.
>>>
>>> Gary
>>>
>>> On Thursday, 17 February 2022 at 23:49:56 UTC+10 James Taylor wrote:
>>>
>>>> Hello
>>>>
>>>> So this was broken by commit ec958a0 (
>>>> https://github.com/weewx/weewx/commit/ec958a0658612ef3bce90ab5c6e825ef0d329e8e
>>>> ).
>>>>
>>>> To give the history, to allow Belchertown to output / graph rxCheckPercent 
>>>> as discussed here 
>>>> https://www.mail-archive.com/weewx...@googlegroups.com/msg21816.html 
>>>> <https://www.mail-archive.com/weewx-user@googlegroups.com/msg21816.html>, 
>>>> it meant we delete windDir from the Vantage archive record which means we 
>>>> then process the loop packets as an accumulator
>>>>
>>>> I'm guessing this will need the brains / knowledge of Tom to comment???
>>>>
>>>> James
>>>> On Wednesday, February 16, 2022 at 10:55:01 PM UTC James Taylor wrote:
>>>>
>

[weewx-user] Re: windDir is None since upgrading to 4.6.2 from 4.5.1 on VP2

[James Taylor]

Hello

So this was broken by commit ec958a0 (
https://github.com/weewx/weewx/commit/ec958a0658612ef3bce90ab5c6e825ef0d329e8e
).

To give the history, to allow Belchertown to output / graph rxCheckPercent 
as discussed here 
https://www.mail-archive.com/weewx-user@googlegroups.com/msg21816.html, it 
meant we delete windDir from the Vantage archive record which means we then 
process the loop packets as an accumulator

I'm guessing this will need the brains / knowledge of Tom to comment???

James
On Wednesday, February 16, 2022 at 10:55:01 PM UTC James Taylor wrote:

> Tonight's debug
>
> So I've detected that I'm not getting windDir on the archive record from 
> the Vantage Pro 2 on the records coming every 5 mins, compared to any 
> archive records received after a restart, so possibly a hardware issue.
>
> PRESENT -
> Feb 16 21:41:02 pi weewx[5179] DEBUG weewx.drivers.vantage: Getting 
> archive packets since 2022-02-16 21:25:00 GMT (1645046700)
> Feb 16 21:41:02 pi weewx[5179] DEBUG weewx.drivers.vantage: Gentle wake up 
> of console successful
> Feb 16 21:41:02 pi weewx[5179] DEBUG weewx.drivers.vantage: Retrieving 1 
> page(s); starting index= 0
> Feb 16 21:41:02 pi weewx[5179] DEBUG weewx.engine: REC:  2022-02-16 
> 21:40:00 GMT (1645047600) 'barometer': '29.472', 'consBatteryVoltage': 
> 'None', 'dateTime': '1645047600', 'ET': '0.0', 'forecastRule': '192', 
> 'highOutTemp': '53.5', 'highRadiation': '0.0', 'highUV': '0.0', 
> 'inHumidity': '53.0', 'inTemp': '72.5', 'interval': '5', 'lowOutTemp': 
> '53.4', 'outHumidity': '86.0', 'outTemp': '53.5', 'radiation': '0.0', 
> 'rain': '0.0', 'rainRate': '0.0', 'rxCheckPercent': '19.6458332', 
> 'txBatteryStatus': 'None', 'usUnits': '1', 'UV': '0.0', 'wind_samples': 
> '23.0', 'windDir': '270.0', 'windGust': '13.0', 'windGustDir': '247.5', 
> 'windSpeed': '7.0'
> Feb 16 21:41:02 pi weewx[5179] INFO weewx.wxxtypes: Type beaufort has been 
> deprecated. Use unit beaufort instead.
>
> MISSING -
> Feb 16 22:30:15 pi weewx[5796] DEBUG weewx.engine: REC:  2022-02-16 
> 22:30:00 GMT (1645050600) 'barometer': '29.511', 'consBatteryVoltage': 
> '4.66', 'dateTime': '1645050600', 'ET': '0.0', 'forecastRule': '122', 
> 'highOutTemp': '52.1', 'highRadiation': '0.0', 'highUV': '0.0', 
> 'inHumidity': '50.0', 'inTemp': '75.6', 'interval': '5', 'lowOutTemp': 
> '51.9', 'outHumidity': '78.0', 'outTemp': '51.9', 'radiation': '0.0', 
> 'rain': '0.0', 'rainRate': '0.0', 'rxCheckPercent': '99.9375', 
> 'txBatteryStatus': '0', 'usUnits': '1', 'UV': '0.0', 'wind_samples': 
> '117.0', 'windGust': '14.0', 'windGustDir': '247.5', 'windSpeed': '8.0'
>
> I've also worked out that, I appear to be getting caught up with getting a 
> weewx.CannotCalculate (hence a None) from calc_windDir in wxxtypes.py, 
> because the default calculation is software for windDir under wxservices.py
>
> If I set it to windDir = hardware, then it uses the loop entries and 
> creates the averages!
>
> James
> On Wednesday, February 16, 2022 at 12:26:51 PM UTC James Taylor wrote:
>
>> Thanks Gary
>>
>> Yes - I forgot about the 12.5 multiples thing so yes gives me a possible 
>> idea on what is going to work out what has changed in behavior as the 
>> weewx.conf hasn't changed (apart from the version details)
>>
>> James
>>
>> On Wednesday, February 16, 2022 at 1:30:05 AM UTC gjr80 wrote:
>>
>>> The 4.5.1 archive record looks very much like a software generated 
>>> archive record, you can tell by the windDir value. The windDir value in 
>>> a hardware generated archive record from a VP2 appears in multiples of 12.5 
>>> degrees - that is fixed and a limitation of the archive record format 
>>> emitted from the console/logg

[weewx-user] Re: windDir is None since upgrading to 4.6.2 from 4.5.1 on VP2

[James Taylor]

Tonight's debug

So I've detected that I'm not getting windDir on the archive record from 
the Vantage Pro 2 on the records coming every 5 mins, compared to any 
archive records received after a restart, so possibly a hardware issue.

PRESENT -
Feb 16 21:41:02 pi weewx[5179] DEBUG weewx.drivers.vantage: Getting archive 
packets since 2022-02-16 21:25:00 GMT (1645046700)
Feb 16 21:41:02 pi weewx[5179] DEBUG weewx.drivers.vantage: Gentle wake up 
of console successful
Feb 16 21:41:02 pi weewx[5179] DEBUG weewx.drivers.vantage: Retrieving 1 
page(s); starting index= 0
Feb 16 21:41:02 pi weewx[5179] DEBUG weewx.engine: REC:  2022-02-16 
21:40:00 GMT (1645047600) 'barometer': '29.472', 'consBatteryVoltage': 
'None', 'dateTime': '1645047600', 'ET': '0.0', 'forecastRule': '192', 
'highOutTemp': '53.5', 'highRadiation': '0.0', 'highUV': '0.0', 
'inHumidity': '53.0', 'inTemp': '72.5', 'interval': '5', 'lowOutTemp': 
'53.4', 'outHumidity': '86.0', 'outTemp': '53.5', 'radiation': '0.0', 
'rain': '0.0', 'rainRate': '0.0', 'rxCheckPercent': '19.6458332', 
'txBatteryStatus': 'None', 'usUnits': '1', 'UV': '0.0', 'wind_samples': 
'23.0', 'windDir': '270.0', 'windGust': '13.0', 'windGustDir': '247.5', 
'windSpeed': '7.0'
Feb 16 21:41:02 pi weewx[5179] INFO weewx.wxxtypes: Type beaufort has been 
deprecated. Use unit beaufort instead.

MISSING -
Feb 16 22:30:15 pi weewx[5796] DEBUG weewx.engine: REC:  2022-02-16 
22:30:00 GMT (1645050600) 'barometer': '29.511', 'consBatteryVoltage': 
'4.66', 'dateTime': '1645050600', 'ET': '0.0', 'forecastRule': '122', 
'highOutTemp': '52.1', 'highRadiation': '0.0', 'highUV': '0.0', 
'inHumidity': '50.0', 'inTemp': '75.6', 'interval': '5', 'lowOutTemp': 
'51.9', 'outHumidity': '78.0', 'outTemp': '51.9', 'radiation': '0.0', 
'rain': '0.0', 'rainRate': '0.0', 'rxCheckPercent': '99.9375', 
'txBatteryStatus': '0', 'usUnits': '1', 'UV': '0.0', 'wind_samples': 
'117.0', 'windGust': '14.0', 'windGustDir': '247.5', 'windSpeed': '8.0'

I've also worked out that, I appear to be getting caught up with getting a 
weewx.CannotCalculate (hence a None) from calc_windDir in wxxtypes.py, 
because the default calculation is software for windDir under wxservices.py

If I set it to windDir = hardware, then it uses the loop entries and 
creates the averages!

James
On Wednesday, February 16, 2022 at 12:26:51 PM UTC James Taylor wrote:

> Thanks Gary
>
> Yes - I forgot about the 12.5 multiples thing so yes gives me a possible 
> idea on what is going to work out what has changed in behavior as the 
> weewx.conf hasn't changed (apart from the version details)
>
> James
>
> On Wednesday, February 16, 2022 at 1:30:05 AM UTC gjr80 wrote:
>
>> The 4.5.1 archive record looks very much like a software generated 
>> archive record, you can tell by the windDir value. The windDir value in 
>> a hardware generated archive record from a VP2 appears in multiples of 12.5 
>> degrees - that is fixed and a limitation of the archive record format 
>> emitted from the console/logger. In a WeeWX VP2 hardware generated archive 
>> record the wind direction values will be multiples of 12.5 or None. 
>> Software generated archive records contain an average of the loop packet 
>> windDir values. windDir in a VP2 loop packet is in whole degrees and not 
>> subject to the '12.5 degree multiple' effect. So in a software generated 
>> archive record windDir will be a float, usually with a number of decimal 
>> places and certainly (almost always) not a multiple of 12.5. I also see 
>> THSW in the archive records, THSW is only present in the LOOP2 archive 
>> packet so I am guessing you are using LOOP2 instead of the normal LOOP1 
>> packet. Should not be a problem but it's something out of the ordinary.
>>
>> Might help to see the WeeWX startup for each case an

[weewx-user] Re: windDir is None since upgrading to 4.6.2 from 4.5.1 on VP2

[James Taylor]

Thanks Gary

Yes - I forgot about the 12.5 multiples thing so yes gives me a possible 
idea on what is going to work out what has changed in behavior as the 
weewx.conf hasn't changed (apart from the version details)

James

On Wednesday, February 16, 2022 at 1:30:05 AM UTC gjr80 wrote:

> The 4.5.1 archive record looks very much like a software generated archive 
> record, you can tell by the windDir value. The windDir value in a 
> hardware generated archive record from a VP2 appears in multiples of 12.5 
> degrees - that is fixed and a limitation of the archive record format 
> emitted from the console/logger. In a WeeWX VP2 hardware generated archive 
> record the wind direction values will be multiples of 12.5 or None. 
> Software generated archive records contain an average of the loop packet 
> windDir values. windDir in a VP2 loop packet is in whole degrees and not 
> subject to the '12.5 degree multiple' effect. So in a software generated 
> archive record windDir will be a float, usually with a number of decimal 
> places and certainly (almost always) not a multiple of 12.5. I also see 
> THSW in the archive records, THSW is only present in the LOOP2 archive 
> packet so I am guessing you are using LOOP2 instead of the normal LOOP1 
> packet. Should not be a problem but it's something out of the ordinary.
>
> Might help to see the WeeWX startup for each case and weewx.conf to 
> understand your configuration. You say record generation is set to hardware 
> in weewx.conf, that is great but not necessarily what is used by WeeWX. 
> WeeWX will try hardware and if for some reason it doesn't work/isn't 
> available WeeWX will drop back to software record generation. Always best 
> to check what is in the log.
>
> I would also look at the loop packets, what wind direction values do you 
> see in loop packets? What appears in the subsequent archive record? No need 
> to modify WeeWX, just run WeeWX directly 
> <http://weewx.com/docs/usersguide.htm#Running_directly> and you will see 
> loop packets and archive records direct to console.
>
> Gary
> On Wednesday, 16 February 2022 at 03:02:54 UTC+10 James Taylor wrote:
>
>> Hello
>>
>> I've upgraded to weewx 4.6.2 and found out that my vantage Pro2 REC is 
>> giving a different output for windDir 
>>
>> record_generation is set to hardware in weewx.conf 
>>
>> I amended StdPrint to output new_archive_record to stdout and log.debug 
>> and I can see a difference
>>
>> 4.6.2 - 
>> Feb 15 16:30:15 pi weewx[21988] DEBUG weewx.engine: REC:   2022-02-15 
>> 16:30:00 GMT (1644942600) 'altimeter': '29.664795850933803', 'appTemp': 
>> '44.26912313212261', 'bar_calibration': '-0.0020013', 
>> 'bar_offset': '-0.010005', 'bar_reduction': 
>> '0.0020013', 'barometer': '29.673', 'beaufort': '2', 
>> 'cloudbase': '794.2252812978254', 'consBatteryVoltage': '4.65', 'dateTime': 
>> '1644942600', 'dayET': '0.013', 'dayRain': '0.1338582669002', 
>> 'dewpoint': '46.75340876228957', 'ET': '0.0', 'extraAlarm1': '0.0', 
>> 'extraAlarm2': '0.0', 'extraAlarm3': '0.0', 'extraAlarm4': '0.0', 
>> 'extraAlarm5': '0.0', 'extraAlarm6': '0.0', 'extraAlarm7': '0.0', 
>> 'extraAlarm8': '0.0', 'forecastIcon': '3.0', 'forecastRule': '158', 
>> 'heatindex': '47.3580004', 'highOutTemp': '48.5', 'highRadiation': 
>> '11.0', 'highUV': '0.0', 'hourRain': '0.0078740157', 'humidex': 
>> '49.280997613295085', 'inDewpoint': '50.40086122975667', 'inHumidity': 
>> '48.0', 'insideAlarm': '0.0', 'inTemp': '71.1', 'interval': '5', 
>> 'leafWet4': '0.0', 'lowOutTemp': '48.4', 'maxSolarRad': 
>> '46.94974186677293', 'monthET': '0.52', 'monthRain': '1.0787401509', 
>> 'outHumidity': '94.0', 'outsideAlarm1': '0.0', 'outsideAlarm2': '0.0', 
>> 'outTemp': '48.4', 'pressure': 

[weewx-user] Re: windDir is None since upgrading to 4.6.2 from 4.5.1 on VP2

[James Taylor]

Yes, unfortunately that isn't the case with my output :-(

On Tuesday, February 15, 2022 at 10:57:28 PM UTC vince wrote:

> Your windSpeed and windGust are 0.0 so there is no direction.
>
>

-- 
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/36f2c59c-c299-49af-8668-fa0f36dbc931n%40googlegroups.com.

[weewx-user] windDir is None since upgrading to 4.6.2 from 4.5.1 on VP2

[James Taylor]

Hello

I've upgraded to weewx 4.6.2 and found out that my vantage Pro2 REC is 
giving a different output for windDir 

record_generation is set to hardware in weewx.conf 

I amended StdPrint to output new_archive_record to stdout and log.debug and 
I can see a difference

4.6.2 - 
Feb 15 16:30:15 pi weewx[21988] DEBUG weewx.engine: REC:   2022-02-15 
16:30:00 GMT (1644942600) 'altimeter': '29.664795850933803', 'appTemp': 
'44.26912313212261', 'bar_calibration': '-0.0020013', 
'bar_offset': '-0.010005', 'bar_reduction': 
'0.0020013', 'barometer': '29.673', 'beaufort': '2', 
'cloudbase': '794.2252812978254', 'consBatteryVoltage': '4.65', 'dateTime': 
'1644942600', 'dayET': '0.013', 'dayRain': '0.1338582669002', 
'dewpoint': '46.75340876228957', 'ET': '0.0', 'extraAlarm1': '0.0', 
'extraAlarm2': '0.0', 'extraAlarm3': '0.0', 'extraAlarm4': '0.0', 
'extraAlarm5': '0.0', 'extraAlarm6': '0.0', 'extraAlarm7': '0.0', 
'extraAlarm8': '0.0', 'forecastIcon': '3.0', 'forecastRule': '158', 
'heatindex': '47.3580004', 'highOutTemp': '48.5', 'highRadiation': 
'11.0', 'highUV': '0.0', 'hourRain': '0.0078740157', 'humidex': 
'49.280997613295085', 'inDewpoint': '50.40086122975667', 'inHumidity': 
'48.0', 'insideAlarm': '0.0', 'inTemp': '71.1', 'interval': '5', 
'leafWet4': '0.0', 'lowOutTemp': '48.4', 'maxSolarRad': 
'46.94974186677293', 'monthET': '0.52', 'monthRain': '1.0787401509', 
'outHumidity': '94.0', 'outsideAlarm1': '0.0', 'outsideAlarm2': '0.0', 
'outTemp': '48.4', 'pressure': '29.21395918348061', 'pressure_raw': 
'29.2247995', 'radiation': '5.3995', 'rain': '0.0', 
'rain15': '0.0', 'rain24': '0.1338582669002', 'rainAlarm': '0.0', 
'rainRate': '0.0', 'rxCheckPercent': '97.375', 'soilLeafAlarm1': '0.0', 
'soilLeafAlarm2': '0.0', 'soilLeafAlarm3': '0.0', 'soilLeafAlarm4': '0.0', 
'stormRain': '0.1338582669002', 'stormStart': '1644883200.0', 
'sunrise': '1644912960.0', 'sunset': '1644949080.0', 'sunshineDuration': 
'0.0', 'THSW': '45.0', 'trendIcon': '-20.0', 'txBatteryStatus': '0', 
'usUnits': '1', 'UV': '0.0', 'wind_samples': '114.0', 'windchill': 
'45.762013144176095', 'windDir': 'None', 'windGust': '10.0', 'windGust10': 
'10.0', 'windGustDir': '247.5', 'windGustDir10': '247.0', 'windrun': '0.5', 
'windSpeed': '6.0', 'windSpeed2': '5.7', 'windSpeed10': '5.0', 'yearET': 
'1.13', 'yearRain': '1.527559045801'

Back to 4.5.1 and everything is good ( windDir: 237.52965750482582).

Feb 15 16:50:15 pi weewx[22480] DEBUG weewx.engine: REC:  2022-02-15 
16:50:00 GMT (1644943800) altimeter: 29.656827096532094, appTemp: 
45.77889412649187, bar_calibration: -0.0020013, bar_offset: 
-0.010005, barometer: 29.665, bar_reduction: 
0.0020013, beaufort: 1, cloudbase: 730.1419634508915, 
consBatteryVoltage: 4.65, dateTime: 1644943800, dayET: 0.013, dayRain: 
0.1338582669002, dewpoint: 46.83537536081608, ET: 0.0, extraAlarm1: 
0.0, extraAlarm2: 0.0, extraAlarm3: 0.0, extraAlarm4: 0.0, extraAlarm5: 
0.0, extraAlarm6: 0.0, extraAlarm7: 0.0, extraAlarm8: 0.0, forecastIcon: 
3.0, forecastRule: 158, heatindex: 47.185, highOutTemp: 48.2, 
highRadiation: 7.0, highUV: 0.0, hourRain: 0.0, humidex: 49.11495517097403, 
inDewpoint: 50.309529357501425, inHumidity: 48.0, insideAlarm: 0.0, inTemp: 
71.0, interval: 5, leafWet4: 0.0, lowOutTemp: 48.1, maxSolarRad: 0.0, 
monthET: 0.52, monthRain: 1.0787401509, outHumidity: 95.0, outsideAlarm1: 
0.0, outsideAlarm2: 0.0, outTemp: 48.2, pressure: 29.206088977429996, 
pressure_raw: 29.21954545454549, radiation: 4.2, rain: 0.0, rain15: 0.0, 
rain24: 0.1338582669002, rainAlarm: 0.0, rainRate: 0.0, rxCheckPercent: 
98.229166, soilLeafAlarm1: 0.0, soilLeafAlarm2: 0.0, 
soilLeafAlarm3: 0.0, soilLeafAlarm4: 0.0, stormRain: 0.1338582669002, 
stormStart: 1644883200.0, sunrise: 1644912960.0, sunset: 1644949080.0, 
sunshineDuration: 0.0, THSW: 45.664, trendIcon: -20.0, 
txBatteryStatus: 0, usUnits: 1, UV: 0.0, windchill: 48.2, windDir: 
237.52965750482582, windGust: 6.0, windGust10: 0.7, windGustDir: 225.0, 
windGustDir10: 225.0, windrun: 0.25, wind_samples: 115.0, windSpeed: 3.0, 
windSpeed10: 3.0, windSpeed2: 3.2, yearET: 1.13, yearRain: 1.5275590458

I've issued a clear-memory just in case it was corrupted, but I'm now 
thinking something else is going on.  The Loop data is fine and mqtt is 
working as expected.

Any idea on how to debug this some more?

Thanks

James

-- 
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/d047fde9-d15a-416c-aa2d-4e72198f973an%40googlegroups.com.

Re: [weewx-user] Re: Full day highcharts question

[James Taylor]

Thanks.

What I'm trying to work out is if this is expected / correct behavior of 
weewx now.   Reading Gary's comment back in June 2020 sort of makes sense, 
but I'm still not 100% sure.

James

On Monday, May 3, 2021 at 7:19:03 PM UTC+1 Arend wrote:

> This new behaviour is caused by this WeeWX 4.5.1 commit:
>
>
> https://github.com/weewx/weewx/commit/a6098878562e4a35345051c45ee6aadf31edbdce
>
> for stamp in weeutil.weeutil.intervalgen(startstamp, 
> stopstamp, aggregate_interval):
> # Get the aggregate as a ValueTuple
> agg_vt = get_aggregate(obs_type, stamp, do_aggregate, 
> db_manager)
> *if agg_vt[0] is None:*
> *continue*
> if unit:
> # It's OK if the unit is unknown (=None).
> if agg_vt[1] is not None and (unit != agg_vt[1] or 
> unit_group != agg_vt[2]):
>
> Comment out the text marked as bold in xtypes.py to restore previous 
> behaviour or wait for Pat (or someone else) to create a fix for Belchertown 
> skin.
> Op maandag 3 mei 2021 om 19:48:20 UTC+2 schreef James Taylor:
>
>> Not sure.   Under weewx 4.4.0 my Temperature chart were as follows under 
>> Belchertown
>> [image: IMG_2780.png]
>>
>> Under weewx 4.5.1 it was displaying as the following
>>
>> [image: IMG_2781.png]
>>
>> I made no changes other than upgrade to 4.5.1.
>>
>> # Global Chart Defaults
>> # These are fallback options that charts will use if an option is not 
>> defined.
>> aggregate_type = None
>> time_length = 9 # Last 25 hours
>> type = line
>> colors = "#7cb5ec, #b2df8a, #f7a35c, #8c6bb1, #dd3497, #e4d354, #268bd2, 
>> #f45b5b, #6a3d9a, #33a02c"
>> tooltip_date_format = "LLL"
>>
>> [day]
>> # Chart Timespan Defaults
>> title = "Today since Midnight"
>> show_button = true
>> button_text = "Day"
>> time_length = today
>> tooltip_date_format = "LLL"
>>
>> aggregate_type = max
>> aggregate_interval = 300
>> gapsize = 30 # This should be your archive_interval from 
>> weewx.conf multiplied by 1000 to get milliseconds. Standard is 5 minutes
>>
>> [[chart1]]
>> title = Temperature
>> start_at_midnight = true
>> [[[outTemp]]]
>> zIndex = 1
>> name = Temperature
>> [[[windchill]]]
>> [[[heatindex]]]
>> color = "#f7a35c"
>> [[[dewpoint]]]
>> color = purple
>>
>> Obviously 4.4.0 came out this year so I'm wondering if something has been 
>> changed in Tom's code.
>>
>> James
>>
>> On Friday, April 9, 2021 at 7:08:29 AM UTC+1 grua...@gmail.com wrote:
>>
>>> should this still work with weewx 4.5.1 ?
>>>
>>> i updated and my full day charts are gone
>>>
>>> Manfred Maier schrieb am Montag, 15. Juni 2020 um 11:12:27 UTC+2:
>>>
>>>> Thanks, Gary, for this comprehensive explanation.
>>>>
>>>> Based on what you wrote I was now able to plot an entire day.
>>>>
>>>> [image: Bildschirmfoto 2020-06-15 um 11.07.53.png]
>>>>
>>>> The trick is quite simple: I just had to define an aggregation for the 
>>>> daily charts. I.e. adding the following two lines to the graphs.conf:
>>>>
>>>> aggregate_type = max
>>>>
>>>> aggregate_interval = 300
>>>>
>>>>
>>>>
>>>>

-- 
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/e1cb79c1-15f1-460a-b2eb-31056bef7bb7n%40googlegroups.com.

Re: [weewx-user] Re: Full day highcharts question

[James Taylor]

Not sure.   Under weewx 4.4.0 my Temperature chart were as follows under 
Belchertown
[image: IMG_2780.png]

Under weewx 4.5.1 it was displaying as the following

[image: IMG_2781.png]

I made no changes other than upgrade to 4.5.1.

# Global Chart Defaults
# These are fallback options that charts will use if an option is not 
defined.
aggregate_type = None
time_length = 9 # Last 25 hours
type = line
colors = "#7cb5ec, #b2df8a, #f7a35c, #8c6bb1, #dd3497, #e4d354, #268bd2, 
#f45b5b, #6a3d9a, #33a02c"
tooltip_date_format = "LLL"

[day]
# Chart Timespan Defaults
title = "Today since Midnight"
show_button = true
button_text = "Day"
time_length = today
tooltip_date_format = "LLL"
aggregate_type = max
aggregate_interval = 300
gapsize = 30 # This should be your archive_interval from weewx.conf 
multiplied by 1000 to get milliseconds. Standard is 5 minutes

[[chart1]]
title = Temperature
start_at_midnight = true
[[[outTemp]]]
zIndex = 1
name = Temperature
[[[windchill]]]
[[[heatindex]]]
color = "#f7a35c"
[[[dewpoint]]]
color = purple

Obviously 4.4.0 came out this year so I'm wondering if something has been 
changed in Tom's code.

James

On Friday, April 9, 2021 at 7:08:29 AM UTC+1 grua...@gmail.com wrote:

> should this still work with weewx 4.5.1 ?
>
> i updated and my full day charts are gone
>
> Manfred Maier schrieb am Montag, 15. Juni 2020 um 11:12:27 UTC+2:
>
>> Thanks, Gary, for this comprehensive explanation.
>>
>> Based on what you wrote I was now able to plot an entire day.
>>
>> [image: Bildschirmfoto 2020-06-15 um 11.07.53.png]
>>
>> The trick is quite simple: I just had to define an aggregation for the 
>> daily charts. I.e. adding the following two lines to the graphs.conf:
>>
>> aggregate_type = max
>>
>> aggregate_interval = 300
>>
>>
>>
>>

-- 
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/395fa21c-a5a1-48e3-a1ef-07430c4ac2e8n%40googlegroups.com.

[weewx-user] Re: Vantage 3.2.0 driver not converting dayRain correctly for mm bucket sizes (weewx 4.0.0b5)

[James Taylor]

Ooops - I was trying to get my values right and my decimal place were all 
in the wrong place.  I mean 1.2cm and 1.5cm.

-- 
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/bf62567a-8016-45b1-a502-18d21d1bec0e%40googlegroups.com.

[weewx-user] Vantage 3.2.0 driver not converting dayRain correctly for mm bucket sizes (weewx 4.0.0b5)

[James Taylor]

Hello

Since installing and testing 4.0.0b5 (working really well) I noticed my 
rain reports were reporting incorrectly and going in jumps of 2.54mm rather 
than 2mm.

I looked at the data in the archive database (using METRIC), and it was 
reporting rain as 0.0254 (ie 0.254cm)

Looking at the loop data as well and it was reporting 0.06 inch for dayRain 
(0.15cm), though my weather station is reporting 0.12cm

LOOP:   2019-12-24 08:22:06 GMT (1577175726) appTemp: 40.77673899893075, 
barometer: 29.771, beaufort: 2, cloudbase: 653.4402820747907, 
consBatteryVoltage: 4.68, dateTime: 1577175726, dayET: 0.0, dayRain: 0.06, 
dewpoint: 43.92886275887092, extraAlarm1: 0, extraAlarm2: 0, extraAlarm3: 
0, extraAlarm4: 0, extraAlarm5: 0, extraAlarm6: 0, extraAlarm7: 0, 
extraAlarm8: 0, forecastIcon: 8, forecastRule: 120, heatindex: 45.0, 
humidex: 45.0, inDewpoint: 50.31047742263314, inHumidity: 50.0, 
insideAlarm: 0, inTemp: 69.8, leafWet4: 0.0, maxSolarRad: 
0.2677935114636761, monthET: 0.38, monthRain: 5.01, outHumidity: 96.0, 
outsideAlarm1: 0, outsideAlarm2: 0, outTemp: 45.0, pressure: 
29.32375790783909, radiation: 8.4, rain: None, rainAlarm: 0, rainRate: 0.0, 
soilLeafAlarm1: 0, soilLeafAlarm2: 0, soilLeafAlarm3: 0, soilLeafAlarm4: 0, 
stormRain: 0.0472440942, stormStart: 1577145600, sunrise: 1577174880.0, 
sunset: 1577205168.0, txBatteryStatus: 0, usUnits: 1, UV: 0.0, windchill: 
42.34519893957256, windDir: 221.0, windGust: 5.0, windGustDir: 221.0, 
windSpeed: 5.0, windSpeed10: 5.0, yearET: 27.93, yearRain: 29.23

In summary I started looking at the vantage.py code and I believe it is 
because dayRain said

'dayRain' : lambda p, k: float(p[k]) / 100.0,

and I think it should be calling the _decode_rain function

_loop_map = {
'altimeter'   : lambda p, k: float(p[k]) / 1000.0 if p[k] else None,
'barometer'   : lambda p, k: float(p[k]) / 1000.0 if p[k] else None,
'consBatteryVoltage': lambda p, k: float((p[k] * 300) >> 9) / 100.0,
'dayET'   : lambda p, k: float(p[k]) / 1000.0,
'dayRain' : _decode_rain,
'dewpoint': lambda p, k: float(p[k]) if p[k] & 0xff != 0xff 
else None,

Loop data is now reporting 0.0472440942 inch which equals 0.12cm.

LOOP:   2019-12-24 09:04:03 GMT (1577178243) appTemp: 42.50129603384309, 
barometer: 29.775, beaufort: 1, cloudbase: 717.0811874901804, 
consBatteryVoltage: 4.68, dateTime: 1577178243, dayET: 0.0, dayRain: 
0.0472440942, dewpoint: 44.64884277504321, extraAlarm1: 0, extraAlarm2: 0, 
extraAlarm3: 0, extraAlarm4: 0, extraAlarm5: 0, extraAlarm6: 0, 
extraAlarm7: 0, extraAlarm8: 0, forecastIcon: 8, forecastRule: 120, 
heatindex: 46.0, humidex: 46.040897257508945, inDewpoint: 
49.675285300449026, inHumidity: 49.0, insideAlarm: 0, inTemp: 69.7, 
leafWet4: 0.0, maxSolarRad: 20.265282927928308, monthET: 0.38, monthRain: 
5.01, outHumidity: 95.0, outsideAlarm1: 0, outsideAlarm2: 0, outTemp: 46.0, 
pressure: 29.327744885181772, radiation: 25.2, rain: None, rainAlarm: 0, 
rainRate: 0.0, soilLeafAlarm1: 0, soilLeafAlarm2: 0, soilLeafAlarm3: 0, 
soilLeafAlarm4: 0, stormRain: 0.0472440942, stormStart: 1577145600, 
sunrise: 1577174880.0, sunset: 1577205168.0, txBatteryStatus: 0, usUnits: 
1, UV: 0.0, windchill: 44.249603120917584, windDir: 212.0, windGust: 4.0, 
windGustDir: 212.0, windSpeed: 4.0, windSpeed10: 5.0, yearET: 27.93, 
yearRain: 29.23

James

-- 
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/3b89ba52-4c42-4426-8bb8-818248f32bb9%40googlegroups.com.