[weewx-user] rain 10x

[gjr80]

Hi,

I suggest that when you have some rain coming you run WeeWX in debug mode 
(debug = 1 in weewx.conf) and then post a log extract from when it was raining. 
That way we can see what data is being collected via SDR and how the packet is 
assembled so we can look at where the issue is.

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/8e506d5a-249c-4415-8574-2818985e9640%40googlegroups.com.

[weewx-user] Interceptor.py - unrecognized parameter

[Chris McLeod]

Hello, 

I have interceptor up and runnign with a DNS redirect from my Acurite 
Access and getting the data using the wu-client option in interceptor. The 
only issue I am having is that my logs are getting spammed with the 
following:

interceptor: MainThread: unrecognized parameter rainin=0.00

I turned logging to debug and can see the following with the unrecognized 
parmeter line highlighted:

Jul 26 13:34:11 wxstation weewx[]: interceptor: ServerThread: GET: 
ID=KCOTHORN74==myAcuRite=now=updateraw=1=35=30.24=6=19=94.7=1=100=3=100=46.0=0.00=0.00
Jul 26 13:34:11 wxstation weewx[]: interceptor: MainThread: raw data: 
ID=KCOTHORN74=YdrxbW2U=myAcuRite=now=updateraw=1=35=30.24=6=19=94.7=1=100=3=100=46.0=0.00&
*rainin=0.00*
Jul 26 13:34:11 wxstation weewx[]: interceptor: MainThread: using 
rain_total 0.0 from dailyrainin
Jul 26 13:34:11 wxstation weewx[]: interceptor: MainThread: firmware 
myAcuRite: baromin is barometer
Jul 26 13:34:11 wxstation weewx[]: interceptor: MainThread: *unrecognized 
parameter rainin=0.00*
Jul 26 13:34:11 wxstation weewx[]: interceptor: MainThread: ignored 
parameter softwaretype=myAcuRite
Jul 26 13:34:11 wxstation weewx[]: interceptor: MainThread: ignored 
parameter realtime=1
Jul 26 13:34:11 wxstation weewx[]: interceptor: MainThread: ignored 
parameter rtfreq=35
Jul 26 13:34:11 wxstation weewx[]: interceptor: MainThread: ignored 
parameter action=updateraw
Jul 26 13:34:11 wxstation weewx[]: interceptor: MainThread: ignored 
parameter PASSWORD=
Jul 26 13:34:11 wxstation weewx[]: interceptor: MainThread: ignored 
parameter ID=KCOTHORN74
Jul 26 13:34:11 wxstation weewx[]: interceptor: MainThread: raw packet: 
{'wind_speed': 1.0, 'barometer': 30.24, 'wind_gust': 3.0, 'dewpoint': 46.0, 
'humidity_out': 19.0, 'uv': 6.0, 'rain': 0.0, 'dateTime': 1564169651, 
'temperature_out': 94.7, 'wind_dir': 100.0, 'rain_total': 0.0, 
'wind_gust_dir': 100.0, 'usUnits': 1}
Jul 26 13:34:11 wxstation weewx[]: interceptor: MainThread: mapped 
packet: {'barometer': 30.24, 'dewpoint': 46.0, 'outHumidity': 19.0, 'UV': 
6.0, 'rain': 0.0, 'dateTime': 1564169651, 'windDir': 100.0, 'outTemp': 
94.7, 'windSpeed': 1.0, 'windGust': 3.0, 'usUnits': 1, 'windGustDir': 100.0}

I can see that there are several other parmeters that are ignored and many 
that are recognized and mapped. 

I am running version 0.46 of the interceptor driver on version 3.9.2 of 
weewx and I can see at line 1206 that 'rainin' is one of several assigned 
to a variable called IGNORED_LABELS and that set also includes all the 
items shown as ignored in the debug output above. 

IGNORED_LABELS = ['relbaro', 'rainin',
  'weeklyrain', 'monthlyrain',
  'weeklyrainin', 'monthlyrainin',
  'realtime', 'rtfreq',
  'action', 'ID', 'PASSWORD', 'PASSKEY', 'dateutc',
  'softwaretype']

Can anyone see why rainin isn't being ignored while the others are? I am 
assuming there is good reason for it to be ignored or it wouldn't be in the 
IGNORED_LABELS grouping. 

Thanks, 

Chris 

-- 
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/136d6394-ebd1-46c1-bb3d-6f377012ae33%40googlegroups.com.

[weewx-user] Re: total rain in graph

[Andrew Milner]

I bet it was raining at midnight and the difference is the rain value from 
the archive record timestamped 00:00 - the contents of which actually refer 
to the previous day.



On Saturday, 27 July 2019 00:48:32 UTC+3, Pepe wrote:
>
> Hi
>
> I have Belchertown skin and I am observing that the total rainfall 
> readings that appear in the graph are always 0.2 mm higher than the main 
> reading. Any ideas about it? 
>
> best regards.
>

-- 
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/714e-376f-4092-b0ea-437afe9abd5e%40googlegroups.com.

Re: [weewx-user] Re: Customised logwatch

[Andrew Milner]

Leon - the thread was about logwatch not logrotate.



On Saturday, 27 July 2019 04:14:04 UTC+3, Leon Shaner wrote:
>
> The Linux logrotate always works for anything I need.  It's very flexible. 
>  I have an example on my weewx clone on GitHub in the watchdog util branch:
>
> https://github.com/UberEclectic/weewx/tree/watchdog/examples/watchdog
>
> Regards,
> Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPhone)
>
> On Jul 25, 2019, at 2:49 PM, gjr80 > 
> wrote:
>
> The logwatch script needs to be modularised so that users can easily 
> extend the basic logwatch script functionality to cater for extensions and 
> other customisations the user may have installed. The current top to bottom 
> ‘if..elif..else’ structure does not lend itself to being easily extended in 
> a manner that survives upgrades etc.
>
> We are aware of the issue but it will probably take until we find the 
> roundtoit before we get around to it.
>
> 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...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/99093fab-14af-4c1e-adf9-6d79599f460f%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/1199a321-44a9-4860-91c4-8c3c02795a0c%40googlegroups.com.

Re: [weewx-user] rain 10x

[Kike .Asekas]

The station is a fine offset wh1080, but the driver is SDR.
# WEEWX CONFIGURATION FILE
#
# Copyright (c) 2009-2019 Tom Keffer 
# See the file LICENSE.txt for your rights.

##

# This section is for general configuration information.

# Set to 1 for extra debug info, otherwise comment it out or set to zero
debug = 0

# Root directory of the weewx data file hierarchy for this station
WEEWX_ROOT = /

# Whether to log successful operations
log_success = True

# Whether to log unsuccessful operations
log_failure = True

# How long to wait before timing out a socket (FTP, HTTP) connection
socket_timeout = 20

# Do not modify this. It is used when installing and updating weewx.
version = 3.9.1

##

#   This section is for information about the station.

[Station]

# Description of the station location
location = "Areal, Padrón"

# Latitude and longitude in decimal degrees
latitude = 42.8002
longitude = -8.63527

# Altitude of the station, with unit it is in. This is downloaded from
# from the station if the hardware supports it.
altitude = 57, meter

# Set to type of station hardware. There must be a corresponding stanza
# in this file with a 'driver' parameter indicating the driver to be 
used.
station_type = SDR

# If you have a website, you may specify an URL
#station_url = http://www.example.com

# The start of the rain year (1=January; 10=October, etc.). This is
# downloaded from the station if the hardware supports it.
rain_year_start = 1

# Start of week (0=Monday, 6=Sunday)
week_start = 6

##

[FineOffsetUSB]
# This section is for the Fine Offset series of weather stations.

# The station model, e.g., WH1080, WS1090, WS2080, WH3081
model = WS2080

# How often to poll the station for data, in seconds
polling_interval = 60

# The driver to use:
driver = weewx.drivers.fousb

##

[SDR]
driver = user.sdr
cmd = rtl_433 -q -F json -R 32 -M utc -f 868.3M
path = /usr/local/bin
#ld_library_path = /usr/local/lib:/opt/rtl-sdr/lib
[[sensor_map]]
windDir = wind_dir.*.FOWHx080Packet
windSpeed = wind_speed.*.FOWHx080Packet
outTemp = temperature.*.FOWHx080Packet
outHumidity = humidity.*.FOWHx080Packet
rain_total = rain_total.*.FOWHx080Packet
inTemp = temperature.*.FOWHx080Packet
inHumidity = humidity.*.FOWHx080Packet

##


#   This section is for uploading data to Internet sites

[StdRESTful]

[[StationRegistry]]
# To register this weather station with weewx, set this to true
register_this_station = false

[[AWEKAS]]
# This section is for configuring posts to AWEKAS.

# If you wish to do this, set the option 'enable' to true,
# and specify a username and password.
# To guard against parsing errors, put the password in quotes.
enable = false
username = replace_me
password = replace_me

[[CWOP]]
# This section is for configuring posts to CWOP.

# If you wish to do this, set the option 'enable' to true,
# and specify the station ID (e.g., CW1234).
enable = false
station = replace_me

# If this is an APRS (radio amateur) station, uncomment
# the following and replace with a passcode (e.g., 12345).
#passcode = replace_me (APRS stations only)

[[PWSweather]]
# This section is for configuring posts to PWSweather.com.

# If you wish to do this, set the option 'enable' to true,
# and specify a station and password.
# To guard against parsing errors, put the password in quotes.
enable = false
station = replace_me
password = replace_me

[[WOW]]
# This section is for configuring posts to WOW.

# If you wish to do this, set the option 'enable' to true,
# and specify a station and password.
# To guard against parsing errors, put the password in quotes.
enable = false
station = replace_me
password = replace_me

[[Wunderground]]
# This section is for configuring posts to the Weather Underground.

# If you wish to do this, set the option 'enable' to true,
# and specify a station (e.g., 'KORHOODR3') and password.
# To guard against parsing errors, put the password in quotes.
enable = false
station = replace_me
password = replace_me

# Set the following to True 

Re: [weewx-user] Re: Customised logwatch

[Leon Shaner]

The Linux logrotate always works for anything I need.  It's very flexible.  I 
have an example on my weewx clone on GitHub in the watchdog util branch:

https://github.com/UberEclectic/weewx/tree/watchdog/examples/watchdog

Regards,
Leon
--
Leon Shaner :: Dearborn, Michigan (iPhone)

> On Jul 25, 2019, at 2:49 PM, gjr80  wrote:
> 
> The logwatch script needs to be modularised so that users can easily extend 
> the basic logwatch script functionality to cater for extensions and other 
> customisations the user may have installed. The current top to bottom 
> ‘if..elif..else’ structure does not lend itself to being easily extended in a 
> manner that survives upgrades etc.
> 
> We are aware of the issue but it will probably take until we find the 
> roundtoit before we get around to it.
> 
> 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/99093fab-14af-4c1e-adf9-6d79599f460f%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/73E95A25-8757-48AA-8EAC-C044D2485766%40isylum.org.

Re[2]: [weewx-user] Errno 32 Pipe error

[coho1202]

I have been starting it remotely
sudo /etc/init.d/weewx start
Will read through the section you referenced a little more tonight.

-- Original Message --
From: "Thomas Keffer" 
To: "weewx-user" 
Sent: 7/25/2019 4:28:24 AM
Subject: Re: [weewx-user] Errno 32 Pipe error


How are you running weewx?

By running it directly 
? You can get a 
"pipe error" by starting up weewx in a console window, then closing it.


Or, are you running it as a daemon 
?


-tk

On Wed, Jul 24, 2019 at 1:35 AM Craig Courey  
wrote:
Hoping to get some help with my setup. Have been trying to get this 
working for a week or so. Did a reinstall and finally got it to start 
reporting to Weather Underground. That's all I really want to achieve 
is consistent reliable updates to Weather underground, but I am very 
much a novice at this. Keep getting the same error ( Errno 32 pipe 
error ). Weewx will seem to work fine for a couple hours then error 
out. If I reboot the pi it usually starts working again but get the 
same result. Any help is much appreciated. I believe the debug file 
attached is a day or two old and might not reflect the current config 
but should be very close. Mylog and conf files were from this evening.


--
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/462e792b-68da-45dd-bcbe-a3d4ddc0586c%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/CAPq0zEBwK-q2NuHM2QDJrJQPnLEzz2rCcL0bfEDx2F3sZBUrKw%40mail.gmail.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/emf6eb2c67-8bb4-4a0f-9e10-870b15214b72%40familyroom-pc.

[weewx-user] Re: rain 10x

[Kike .Asekas]

My weewx.conf
# WEEWX CONFIGURATION FILE
#
# Copyright (c) 2009-2019 Tom Keffer 
# See the file LICENSE.txt for your rights.

##

# This section is for general configuration information.

# Set to 1 for extra debug info, otherwise comment it out or set to zero
debug = 1

# Root directory of the weewx data file hierarchy for this station
WEEWX_ROOT = /

# Whether to log successful operations
log_success = True

# Whether to log unsuccessful operations
log_failure = True

# How long to wait before timing out a socket (FTP, HTTP) connection
socket_timeout = 20

# Do not modify this. It is used when installing and updating weewx.
version = 3.9.1

##

#   This section is for information about the station.

[Station]

# Description of the station location
location = "Areal, Padrón"

# Latitude and longitude in decimal degrees
latitude = 42.8002
longitude = -8.63527

# Altitude of the station, with unit it is in. This is downloaded from
# from the station if the hardware supports it.
altitude = 57, meter

# Set to type of station hardware. There must be a corresponding stanza
# in this file with a 'driver' parameter indicating the driver to be 
used.
station_type = SDR

# If you have a website, you may specify an URL
#station_url = http://www.example.com

# The start of the rain year (1=January; 10=October, etc.). This is
# downloaded from the station if the hardware supports it.
rain_year_start = 1

# Start of week (0=Monday, 6=Sunday)
week_start = 6

##

[FineOffsetUSB]
# This section is for the Fine Offset series of weather stations.

# The station model, e.g., WH1080, WS1090, WS2080, WH3081
model = WS2080

# How often to poll the station for data, in seconds
polling_interval = 60

# The driver to use:
driver = weewx.drivers.fousb

##

[SDR]
driver = user.sdr
cmd = rtl_433 -q -F json -R 32 -M utc -f 868.3M
path = /usr/local/bin
#ld_library_path = /usr/local/lib:/opt/rtl-sdr/lib
[[sensor_map]]
windDir = wind_dir.*.FOWHx080Packet
windSpeed = wind_speed.*.FOWHx080Packet
outTemp = temperature.*.FOWHx080Packet
outHumidity = humidity.*.FOWHx080Packet
rain_total = rain_total.*.FOWHx080Packet
#inTemp = temperature.*.FOWHx080Packet
#inHumidity = humidity.*.FOWHx080Packet
[[deltas]]
rain = rain_total # derive rain from difference betrween successive 
rain_total   

##


#   This section is for uploading data to Internet sites

[StdRESTful]

[[StationRegistry]]
# To register this weather station with weewx, set this to true
register_this_station = true

[[AWEKAS]]
# This section is for configuring posts to AWEKAS.

# If you wish to do this, set the option 'enable' to true,
# and specify a username and password.
# To guard against parsing errors, put the password in quotes.
enable = false
username = replace_me
password = replace_me

[[CWOP]]
# This section is for configuring posts to CWOP.

# If you wish to do this, set the option 'enable' to true,
# and specify the station ID (e.g., CW1234).
enable = false
station = replace_me

# If this is an APRS (radio amateur) station, uncomment
# the following and replace with a passcode (e.g., 12345).
#passcode = replace_me (APRS stations only)

[[PWSweather]]
# This section is for configuring posts to PWSweather.com.

# If you wish to do this, set the option 'enable' to true,
# and specify a station and password.
# To guard against parsing errors, put the password in quotes.
enable = false
station = replace_me
password = replace_me

[[WOW]]
# This section is for configuring posts to WOW.

# If you wish to do this, set the option 'enable' to true,
# and specify a station and password.
# To guard against parsing errors, put the password in quotes.
enable = false
station = replace_me
password = replace_me

[[Wunderground]]
# This section is for configuring posts to the Weather Underground.

# If you wish to do this, set the option 'enable' to true,
# and specify a station (e.g., 'KORHOODR3') and password.
# To guard against parsing errors, put the password in quotes.
enable = false
station = replace_me

[weewx-user] total rain in graph

[Pepe]

Hi

I have Belchertown skin and I am observing that the total rainfall readings 
that appear in the graph are always 0.2 mm higher than the main reading. 
Any ideas about it? 

best regards.

-- 
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/3861d685-d5c1-4386-91f5-b9d46bf85cad%40googlegroups.com.

[weewx-user] Re: Customised logwatch

[vince]

On Friday, July 26, 2019 at 12:35:34 PM UTC-7, gjr80 wrote:
>
>  The WeeWX installer does not ‘install’ the WeeWX logwatch files, rather 
> the user must install them separately as per the wiki. The suggested 
> approach is to create symlinks (in the relevant logwatch directories) to 
> the supplied files. 
>

Agree - if you want to install the utility once and thereafter run it 
unedited then you get free upgrades essentially afterward if the copy that 
comes with weewx changes.  Same for the systemd or init.d startup files or 
anything else that needs to hook into the os as either a mandatory thing or 
optional user-installed utility.

Of course you can make a copy of the script elsewhere, modify it to suit 
> your needs and then link to that file instead (this is what I do). Problem 
> is if there is a change to the core WeeWX logging, and the WeeWX logwatch 
> script is changed accordingly, then those logwatch script changes will not 
> flow through to the copied/modified script being used.


Of course.  If you choose to edit it you are taking the responsibility to 
own your edited copy and handle any breakage if weewx moves under your 
feet, so to speak, in a future release.

The other approach is to create another separate script, a link for which 
> can be placed in the appropriate logwatch directory. Works fine but you 
> will now have a second logwatch report being produced, it will not be part 
> of the logwatch report produced by the logwatch script shipped with WeeWX. 
> Have never been a sysadmin but I don’t think either approach is appropriate 
> or acceptable. 
>
>
I've been a sysadmin for 30+ years and would say there are a variety of 
appropriate/acceptable approaches especially when logging is involved.

Personally I like componentization and the ability to turn stuff on+off as 
well as the ability to add new things.  That's why I like .d directories so 
much (or sites-enabled if you think webservers etc.).

The risk I think I'm trying to bring up is there seems to be a natural 
tension between making weewx infinitely extensible+configurable vs. keeping 
it 'wee'.My opinion is this particular one's original request violates 
the 'keep it wee' mindset perhaps, maybe, depending on implementation.

It's kinda like crontabs.   You violate 'wee' if you just edit the system 
crontab.  You are nice and componentized if you use crontabs (directory) 
and drop in pieces as components you can easily add/supersede/delete into 
what happens as an aggregated whole.

If logwatch could be made to work that way, seems worth thinking about 
trying to do when getroundtoit happens.





-- 
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/823543da-faec-45a3-a188-e3b976caad7d%40googlegroups.com.

Re: [weewx-user] Sunshine Time

[gjr80]

As for changing the W/m2 try setting the config option ‘y_label’ to an empty 
string, something like (untested):

y_label = “”

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/4138621f-2302-4d65-82e4-892340170cab%40googlegroups.com.

Re: [weewx-user] Sunshine Time

[gjr80]

To change the bar colour try using the config option ‘fill_color’. The config 
option ‘color’ will set the outline colour of the bar.

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/2c10abe8-54d0-4191-9ea0-5d4b0f4c8a98%40googlegroups.com.

[weewx-user] Re: Customised logwatch

[gjr80]

I’m sorry but I don’t understand the confusion here. WeeWX ships with 3 
logwatch files; 2 config files and a script. The script is what analyses the 
WeeWX log and produces the WeeWX logwatch report. The WeeWX installer does not 
‘install’ the WeeWX logwatch files, rather the user must install them 
separately as per the wiki. The suggested approach is to create symlinks (in 
the relevant logwatch directories) to the supplied files.

Of course you can make a copy of the script elsewhere, modify it to suit your 
needs and then link to that file instead (this is what I do). Problem is if 
there is a change to the core WeeWX logging, and the WeeWX logwatch script is 
changed accordingly, then those logwatch script changes will not flow through 
to the copied/modified script being used. The other approach is to create 
another separate script, a link for which can be placed in the appropriate 
logwatch directory. Works fine but you will now have a second logwatch report 
being produced, it will not be part of the logwatch report produced by the 
logwatch script shipped with WeeWX. Have never been a sysadmin but I don’t 
think either approach is appropriate or acceptable.

This is very similar to customising some WeeWX function. You can modify the 
core code on your install and it will certainly work as you want, though you 
now have an orphan that will likely fail post upgrade. Alternatively, you can 
create a custom service, driver or whatever, place it in the user directory and 
call it appropriately from weewx.conf and it will coexist quite happily with 
WeeWX into the future even across upgrades.

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/eb566540-37d9-4376-87da-29b6a7563cba%40googlegroups.com.

[weewx-user] Re: Customised logwatch

[vince]

On Friday, July 26, 2019 at 10:01:47 AM UTC-7, Andrew Milner wrote:
>
> because logwatch is updated as weewx is updated if messages are altered - 
> so if weewx provides an updated version the stashed away copy with the 
> customisation becomes unusable basically.
>
>  
Again - confused here.

Does weewx install something logwatch-related so that logwatch does 
something different than before weewx was present ?
I'm not aware of that.

Looked to me like the setup.py just sticks files into the /home/weewx/utils 
directory like lots of other things it we can use as-is, or not use, or 
hack on, or not hack on, at our discretion.

-- 
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/95ff5d99-9f44-48cf-90bd-01ab7a1d5b3e%40googlegroups.com.

[weewx-user] Re: Customised logwatch

[Andrew Milner]

because logwatch is updated as weewx is updated if messages are altered - 
so if weewx provides an updated version the stashed away copy with the 
customisation becomes unusable basically.

On Friday, 26 July 2019 17:52:02 UTC+3, vince wrote:
>
> On Thursday, July 25, 2019 at 11:49:39 AM UTC-7, gjr80 wrote:
>>
>> The current top to bottom ‘if..elif..else’ structure does not lend itself 
>> to being easily extended in a manner that survives upgrades etc. 
>>
>>
>>
> Agree - if you keep the file in weewx's directory namespace that is.
>
> Doesn't logwatch typically search a configurable set of locations ?   Why 
> not just stash a (modified) copy someplace outside a directory weewx would 
> overwrite on a version update ?
>
> Or am I missing something ?
>
> (just curious - I don't use logwatch for my sites)
>
>

-- 
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/01317324-5032-4c10-86db-85dd5eb78a1a%40googlegroups.com.

[weewx-user] Re: Database - Data not archived correctly

[Danie Cillie]

Thanks, I got it working a short while ago and is busy testing.



On Friday, 26 July 2019 16:37:26 UTC+2, Andrew Milner wrote:
>
> try copying in the code that reads the sensor used at startup would be a 
> good starting point, and you may need to declare humidity as a global.  
>
>
>
> On Friday, 26 July 2019 16:46:47 UTC+3, Danie Cillie wrote:
>>
>> Thanks Gary, I came to the same conclusion but have not been able to 
>> figure out how to get sampleAndDisplay() to read the humidity sensor.
>>
>> Any ideas?
>>
>> On Thursday, 25 July 2019 21:19:49 UTC+2, gjr80 wrote:
>>>
>>> genLoopPackets() assigns the variable ‘humidity’ to the ‘outHumidity’ 
>>> field in the loop packet (line 341) but when genLoopPackets() is iterating 
>>> continuously it calls the sampleAndDisplay() method to (presumably) obtain 
>>> updated sensor values. As far as I can tell variable ‘humidity’ is not set 
>>> by sampleAndDisplay(). ‘humidity’ is only set at line 254 when the driver 
>>> module is first loaded. This probably explains why the value is only 
>>> correct/updated when WeeWX is started/restarted. 
>>>
>>> I think you need to revise you driver to ensure that that variable 
>>> ‘humidity’ is in fact updated on a regular basis. 
>>>
>>> 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/0a8fb616-4218-421b-8ded-965506ce8da5%40googlegroups.com.

[weewx-user] Re: Customised logwatch

[vince]

On Thursday, July 25, 2019 at 11:49:39 AM UTC-7, gjr80 wrote:
>
> The current top to bottom ‘if..elif..else’ structure does not lend itself 
> to being easily extended in a manner that survives upgrades etc. 
>
>
>
Agree - if you keep the file in weewx's directory namespace that is.

Doesn't logwatch typically search a configurable set of locations ?   Why 
not just stash a (modified) copy someplace outside a directory weewx would 
overwrite on a version update ?

Or am I missing something ?

(just curious - I don't use logwatch for my sites)

-- 
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/06a45eb1-276b-42fa-91a4-7ff8e8652a92%40googlegroups.com.

[weewx-user] Re: Database - Data not archived correctly

[Andrew Milner]

try copying in the code that reads the sensor used at startup would be a 
good starting point, and you may need to declare humidity as a global.  



On Friday, 26 July 2019 16:46:47 UTC+3, Danie Cillie wrote:
>
> Thanks Gary, I came to the same conclusion but have not been able to 
> figure out how to get sampleAndDisplay() to read the humidity sensor.
>
> Any ideas?
>
> On Thursday, 25 July 2019 21:19:49 UTC+2, gjr80 wrote:
>>
>> genLoopPackets() assigns the variable ‘humidity’ to the ‘outHumidity’ 
>> field in the loop packet (line 341) but when genLoopPackets() is iterating 
>> continuously it calls the sampleAndDisplay() method to (presumably) obtain 
>> updated sensor values. As far as I can tell variable ‘humidity’ is not set 
>> by sampleAndDisplay(). ‘humidity’ is only set at line 254 when the driver 
>> module is first loaded. This probably explains why the value is only 
>> correct/updated when WeeWX is started/restarted. 
>>
>> I think you need to revise you driver to ensure that that variable 
>> ‘humidity’ is in fact updated on a regular basis. 
>>
>> 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/0ae28e0d-cfa1-4d90-aa2c-a5795358d3c9%40googlegroups.com.

[weewx-user] Almanac reverts to northern hemisphere Lat Lon

[Pat]

Just curious, have you restarted weewx after making those lat/lon changes?

-- 
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/fbffdcfc-7089-4ef6-961e-91086106c727%40googlegroups.com.

[weewx-user] Re: Database - Data not archived correctly

[Danie Cillie]

Thanks Gary, I came to the same conclusion but have not been able to figure 
out how to get sampleAndDisplay() to read the humidity sensor.

Any ideas?

On Thursday, 25 July 2019 21:19:49 UTC+2, gjr80 wrote:
>
> genLoopPackets() assigns the variable ‘humidity’ to the ‘outHumidity’ 
> field in the loop packet (line 341) but when genLoopPackets() is iterating 
> continuously it calls the sampleAndDisplay() method to (presumably) obtain 
> updated sensor values. As far as I can tell variable ‘humidity’ is not set 
> by sampleAndDisplay(). ‘humidity’ is only set at line 254 when the driver 
> module is first loaded. This probably explains why the value is only 
> correct/updated when WeeWX is started/restarted. 
>
> I think you need to revise you driver to ensure that that variable 
> ‘humidity’ is in fact updated on a regular basis. 
>
> 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/0cdae0b4-433f-468b-bb44-036900bc8a9b%40googlegroups.com.

[weewx-user] Re: Godaddy FTP problem

[Bob Grattan]

Thanks, Andy, I’ve wanted to try rsync but wasn’t sure how to set it up with 
Godaddy. I’ll make an attempt as it seems the better method. Not real sure of 
myself in this area.
Bob

-- 
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/5c28bb17-2be2-4c3f-8d26-75c88813b2a4%40googlegroups.com.

Re: [weewx-user] Re: WU Wind graphs

[Andrew Milner]

i doubt it very much.  what weather station do you have?
changing the rf frequency changes the upload to wu interval but the station 
will still be being polled as before.  Does the station provide the gust 
value in the LOOP data?  If not then the gust value is an artificial one 
created by weewx from loop records wind speeds received.  If your station 
provides partial packets as LOOP data you could always try and set the wu 
flag that set specifies windGust must be present before rf is uploaded

On Friday, 26 July 2019 10:42:14 UTC+3, Praveen Chandrasekaran wrote:
>
> If I set rtfreq to a higher value like 5 seconds, should that resolve the 
> issue? 
>
> On Fri, 26 Jul 2019 at 11:57, Andrew Milner  > wrote:
>
>> if from rf it has no gusts it cannot graph them.  non rf sites will 
>> provide a gust value per archive interval.  who knows what wu do when they 
>> receive both rf and archive record data!!  The tables may well create an 
>> artificial gust value from rf speeds, but again who knows what wu use to 
>> create the graphs!!
>>
>>
>>
>> On Friday, 26 July 2019 09:01:30 UTC+3, Praveen Chandrasekaran wrote:
>>>
>>> The table somehow has it right. The graph alone is wrong.
>>>
>>> On Fri, 26 Jul 2019 at 11:29, Andrew Milner  
>>> wrote:
>>>
 I would suspect WU ignore windgust on rapidfire because you need a 
 sustained period of I think 3 seconds for the gust to count as a gust in 
 metereological definitions - and the rf interval is probably too short - 
 so 
 gust will always equal speed in rf situations.  

 On Friday, 26 July 2019 08:26:49 UTC+3, Praveen Chandrasekaran wrote:
>
> Related wxforum post:
>
> https://www.wxforum.net/index.php?topic=36611.msg386071#msg386071
>
>
> On Friday, 26 July 2019 10:45:52 UTC+5:30, Praveen Chandrasekaran 
> wrote:
>>
>> Hi,
>>
>> I am seeing that on stations with rapdifire, WU is not 
>> differentiating wind speed and wind gust in graph correctly. However in 
>> stations without rapidfire it is fine.
>>
>> Example my station with rapidfire:
>>
>> https://www.wunderground.com/dashboard/pws/IBANGALO9
>>
>> Another station without rapidfire:
>>
>> https://www.wunderground.com/dashboard/pws/IMUMBAI16
>>
>> Is this issue arising from weewx by any chance?
>>
>> Regards,
>> Praveen
>>
> -- 
 You received this message because you are subscribed to a topic in the 
 Google Groups "weewx-user" group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/weewx-user/E5uzJiv_ThY/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 weewx...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/weewx-user/51caf745-7385-40f9-ad35-81cfed29553e%40googlegroups.com
  
 
 .

>>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "weewx-user" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/weewx-user/E5uzJiv_ThY/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> weewx...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/e1c86274-2f2a-4005-a3e3-8ac0d9028b66%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/d7771e29-b520-444a-b39a-8c637a1b9ffe%40googlegroups.com.

Re: [weewx-user] Re: WU Wind graphs

[Andrew Milner]

i would doubt it very much but you could try.  it certainly would not help 
it if wu just ignores gust from rf feeds anyway.

On Friday, 26 July 2019 10:42:14 UTC+3, Praveen Chandrasekaran wrote:
>
> If I set rtfreq to a higher value like 5 seconds, should that resolve the 
> issue? 
>
> On Fri, 26 Jul 2019 at 11:57, Andrew Milner  > wrote:
>
>> if from rf it has no gusts it cannot graph them.  non rf sites will 
>> provide a gust value per archive interval.  who knows what wu do when they 
>> receive both rf and archive record data!!  The tables may well create an 
>> artificial gust value from rf speeds, but again who knows what wu use to 
>> create the graphs!!
>>
>>
>>
>> On Friday, 26 July 2019 09:01:30 UTC+3, Praveen Chandrasekaran wrote:
>>>
>>> The table somehow has it right. The graph alone is wrong.
>>>
>>> On Fri, 26 Jul 2019 at 11:29, Andrew Milner  
>>> wrote:
>>>
 I would suspect WU ignore windgust on rapidfire because you need a 
 sustained period of I think 3 seconds for the gust to count as a gust in 
 metereological definitions - and the rf interval is probably too short - 
 so 
 gust will always equal speed in rf situations.  

 On Friday, 26 July 2019 08:26:49 UTC+3, Praveen Chandrasekaran wrote:
>
> Related wxforum post:
>
> https://www.wxforum.net/index.php?topic=36611.msg386071#msg386071
>
>
> On Friday, 26 July 2019 10:45:52 UTC+5:30, Praveen Chandrasekaran 
> wrote:
>>
>> Hi,
>>
>> I am seeing that on stations with rapdifire, WU is not 
>> differentiating wind speed and wind gust in graph correctly. However in 
>> stations without rapidfire it is fine.
>>
>> Example my station with rapidfire:
>>
>> https://www.wunderground.com/dashboard/pws/IBANGALO9
>>
>> Another station without rapidfire:
>>
>> https://www.wunderground.com/dashboard/pws/IMUMBAI16
>>
>> Is this issue arising from weewx by any chance?
>>
>> Regards,
>> Praveen
>>
> -- 
 You received this message because you are subscribed to a topic in the 
 Google Groups "weewx-user" group.
 To unsubscribe from this topic, visit 
 https://groups.google.com/d/topic/weewx-user/E5uzJiv_ThY/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 weewx...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/weewx-user/51caf745-7385-40f9-ad35-81cfed29553e%40googlegroups.com
  
 
 .

>>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "weewx-user" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/weewx-user/E5uzJiv_ThY/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> weewx...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/e1c86274-2f2a-4005-a3e3-8ac0d9028b66%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/104f826c-0b25-447c-bce5-38335b255358%40googlegroups.com.

Re: [weewx-user] Re: WU Wind graphs

[Praveen Chandrasekaran]

If I set rtfreq to a higher value like 5 seconds, should that resolve the
issue?

On Fri, 26 Jul 2019 at 11:57, Andrew Milner 
wrote:

> if from rf it has no gusts it cannot graph them.  non rf sites will
> provide a gust value per archive interval.  who knows what wu do when they
> receive both rf and archive record data!!  The tables may well create an
> artificial gust value from rf speeds, but again who knows what wu use to
> create the graphs!!
>
>
>
> On Friday, 26 July 2019 09:01:30 UTC+3, Praveen Chandrasekaran wrote:
>>
>> The table somehow has it right. The graph alone is wrong.
>>
>> On Fri, 26 Jul 2019 at 11:29, Andrew Milner  wrote:
>>
>>> I would suspect WU ignore windgust on rapidfire because you need a
>>> sustained period of I think 3 seconds for the gust to count as a gust in
>>> metereological definitions - and the rf interval is probably too short - so
>>> gust will always equal speed in rf situations.
>>>
>>> On Friday, 26 July 2019 08:26:49 UTC+3, Praveen Chandrasekaran wrote:

 Related wxforum post:

 https://www.wxforum.net/index.php?topic=36611.msg386071#msg386071


 On Friday, 26 July 2019 10:45:52 UTC+5:30, Praveen Chandrasekaran wrote:
>
> Hi,
>
> I am seeing that on stations with rapdifire, WU is not differentiating
> wind speed and wind gust in graph correctly. However in stations without
> rapidfire it is fine.
>
> Example my station with rapidfire:
>
> https://www.wunderground.com/dashboard/pws/IBANGALO9
>
> Another station without rapidfire:
>
> https://www.wunderground.com/dashboard/pws/IMUMBAI16
>
> Is this issue arising from weewx by any chance?
>
> Regards,
> Praveen
>
 --
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "weewx-user" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/weewx-user/E5uzJiv_ThY/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> weewx...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-user/51caf745-7385-40f9-ad35-81cfed29553e%40googlegroups.com
>>> 
>>> .
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/E5uzJiv_ThY/unsubscribe.
> To unsubscribe from this group and all its topics, 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/e1c86274-2f2a-4005-a3e3-8ac0d9028b66%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/CA%2BW%3DTmU9dNRg036aA9sf%2BXxofPhCyE%3DkCFE1uTLstNKYEtq-9g%40mail.gmail.com.

[weewx-user] Re: maxSolarRad not available

[peter]

Gary, thanks a lot for this... I did follow your suggestion to verify if 
ephem was installed

> $ python
> Python 2.7.13 (default, Sep 26 2018, 18:42:22) 
> [GCC 6.3.0 20170516] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import ephem
> >>> quit()
>
> If no errors where thrown by python pyephem is installed fine.
>

... and it worked OK, no errors returned.

But I just reran the 

sudo pip install pyephem


and restarted weewx. maxSolarRad works!

Thanks again!

Dne petek, 26. julij 2019 08.28.12 UTC+2 je oseba gjr80 napisala:
>
> In that case pyephem is either not installed or not installed properly 
> (previous post re import seems to indicate the latter). Try uninstalling 
> pyephem then install following the instructions in the User’s Guide (
> http://weewx.com/docs/setup.htm). 
>
> 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/c47cfb60-8cad-4c88-8ce2-9d1644203123%40googlegroups.com.

[weewx-user] Almanac reverts to northern hemisphere Lat Lon

[Bobski]

After updating from 3.9.1 to 3.9.2 my almanac times revert to northern 
hemisphere. I set the lat to -30. and lon to 150. and for the first refresh 
after running wee_reports it is correct but after the next webpage update 
it goes to the northern hemisphere times. If I resave the weewx.conf file 
without changing the lat lon settings it is correct initially but after the 
next webpage update it is wrong again. Is there any other location for the 
lat lon settings that it uses? 

thanks in advance
Bobski

-- 
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/338d9581-17c8-4a0d-b654-81e385fe1d02%40googlegroups.com.

[weewx-user] Re: maxSolarRad not available

[gjr80]

In that case pyephem is either not installed or not installed properly 
(previous post re import seems to indicate the latter). Try uninstalling 
pyephem then install following the instructions in the User’s Guide 
(http://weewx.com/docs/setup.htm).

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/e4121dd8-f72d-4c92-9eb6-0f0b1b9e2dd3%40googlegroups.com.

Re: [weewx-user] Re: WU Wind graphs

[Andrew Milner]

if from rf it has no gusts it cannot graph them.  non rf sites will provide 
a gust value per archive interval.  who knows what wu do when they receive 
both rf and archive record data!!  The tables may well create an artificial 
gust value from rf speeds, but again who knows what wu use to create the 
graphs!!



On Friday, 26 July 2019 09:01:30 UTC+3, Praveen Chandrasekaran wrote:
>
> The table somehow has it right. The graph alone is wrong.
>
> On Fri, 26 Jul 2019 at 11:29, Andrew Milner  > wrote:
>
>> I would suspect WU ignore windgust on rapidfire because you need a 
>> sustained period of I think 3 seconds for the gust to count as a gust in 
>> metereological definitions - and the rf interval is probably too short - so 
>> gust will always equal speed in rf situations.  
>>
>> On Friday, 26 July 2019 08:26:49 UTC+3, Praveen Chandrasekaran wrote:
>>>
>>> Related wxforum post:
>>>
>>> https://www.wxforum.net/index.php?topic=36611.msg386071#msg386071
>>>
>>>
>>> On Friday, 26 July 2019 10:45:52 UTC+5:30, Praveen Chandrasekaran wrote:

 Hi,

 I am seeing that on stations with rapdifire, WU is not differentiating 
 wind speed and wind gust in graph correctly. However in stations without 
 rapidfire it is fine.

 Example my station with rapidfire:

 https://www.wunderground.com/dashboard/pws/IBANGALO9

 Another station without rapidfire:

 https://www.wunderground.com/dashboard/pws/IMUMBAI16

 Is this issue arising from weewx by any chance?

 Regards,
 Praveen

>>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "weewx-user" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/weewx-user/E5uzJiv_ThY/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> weewx...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/weewx-user/51caf745-7385-40f9-ad35-81cfed29553e%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/e1c86274-2f2a-4005-a3e3-8ac0d9028b66%40googlegroups.com.

[weewx-user] Re: maxSolarRad not available

[peter]

Good point. Extended almanac is not available in Setup 2. I need to show 
$almanac.sunset to get the sun set time. In Setup 1, I get it through 
$almanac.sun.set; extended almanac works properly in Setup 1.
I use neowx skin in both setups but did modifications to it.


Dne petek, 26. julij 2019 08.14.49 UTC+2 je oseba gjr80 napisala:
>
> Given the maxSolarRad pre-requisites I still think we need to make sure 
> pyephem is not somehow causing the calculation to be aborted (and set to 
> None as a result). Is WeeWX producing the Standard or Seasons skin? If so 
> is it publicly visible or are the extended sun properties (elevation, 
> azimuth, right ascension, declination etc) being populated (note on the 
> Seasons skin you need to click on ‘Celestial’ to see them)? 
>
> 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/21d7ea97-55ba-4754-abcf-d9c441d39d3f%40googlegroups.com.

[weewx-user] Re: maxSolarRad not available

[gjr80]

Given the maxSolarRad pre-requisites I still think we need to make sure pyephem 
is not somehow causing the calculation to be aborted (and set to None as a 
result). Is WeeWX producing the Standard or Seasons skin? If so is it publicly 
visible or are the extended sun properties (elevation, azimuth, right 
ascension, declination etc) being populated (note on the Seasons skin you need 
to click on ‘Celestial’ to see them)?

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/06dcfc6a-c814-4ae9-afea-616bb7a77aef%40googlegroups.com.

[weewx-user] Re: maxSolarRad not available

[peter]

OK, focus on Setup 2 but let me just remind that the issue is the weewx 
doesn't output maxSolarRad.

I have a conditions.html file (generated by weewx every minute) with few 
entries; e.g.: radiation | maxSolarRad | sunrise | sunset | extraTemp1 | 
outTemp
Of course I use raw values so I get values only (no units). A bash script 
parses the conditions.html file every minute. Verifies it's daytime (from 
sunrise/sunset times) and calculates dT=extraTemp1-outTemp.
It then writes a dT into a simple solar.txt file that a template uses to 
update the weewx database entries. I actually write into 2 entries (just 
for now, for debugging): dT goes into extraTemp2 and dT * factor goes into 
radiation.
I verified entries a minute ago and they correspond to my equations and 
current temperature conditions. All works well up to this level.
Now I need to get the maxSolarRad :-)

Dne petek, 26. julij 2019 07.56.01 UTC+2 je oseba Andrew Milner napisala:
>
> right - so we can forget setup 1 then since that is working with a 
> radiation field provided.
>
> so for setup 2 you are storing a temperature in extraTemp1 in the database 
> - correct?
> is that being populated as expected?
>
> where is the calculation being performed?  If in a template can you post 
> the template.
>
> try dT= extraTemp1.raw - outTemp.raw
>
>
>

-- 
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/7b052cae-5961-432a-938e-ea20c117a559%40googlegroups.com.

Re: [weewx-user] Re: WU Wind graphs

[Praveen Chandrasekaran]

The table somehow has it right. The graph alone is wrong.

On Fri, 26 Jul 2019 at 11:29, Andrew Milner 
wrote:

> I would suspect WU ignore windgust on rapidfire because you need a
> sustained period of I think 3 seconds for the gust to count as a gust in
> metereological definitions - and the rf interval is probably too short - so
> gust will always equal speed in rf situations.
>
> On Friday, 26 July 2019 08:26:49 UTC+3, Praveen Chandrasekaran wrote:
>>
>> Related wxforum post:
>>
>> https://www.wxforum.net/index.php?topic=36611.msg386071#msg386071
>>
>>
>> On Friday, 26 July 2019 10:45:52 UTC+5:30, Praveen Chandrasekaran wrote:
>>>
>>> Hi,
>>>
>>> I am seeing that on stations with rapdifire, WU is not differentiating
>>> wind speed and wind gust in graph correctly. However in stations without
>>> rapidfire it is fine.
>>>
>>> Example my station with rapidfire:
>>>
>>> https://www.wunderground.com/dashboard/pws/IBANGALO9
>>>
>>> Another station without rapidfire:
>>>
>>> https://www.wunderground.com/dashboard/pws/IMUMBAI16
>>>
>>> Is this issue arising from weewx by any chance?
>>>
>>> Regards,
>>> Praveen
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/E5uzJiv_ThY/unsubscribe.
> To unsubscribe from this group and all its topics, 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/51caf745-7385-40f9-ad35-81cfed29553e%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/CA%2BW%3DTmX6LaPdY03KgOCrYY8a7-MRJzypRv-XeG8uXx7nfQdoDQ%40mail.gmail.com.

[weewx-user] Re: WU Wind graphs

[Andrew Milner]

I would suspect WU ignore windgust on rapidfire because you need a 
sustained period of I think 3 seconds for the gust to count as a gust in 
metereological definitions - and the rf interval is probably too short - so 
gust will always equal speed in rf situations.  

On Friday, 26 July 2019 08:26:49 UTC+3, Praveen Chandrasekaran wrote:
>
> Related wxforum post:
>
> https://www.wxforum.net/index.php?topic=36611.msg386071#msg386071
>
>
> On Friday, 26 July 2019 10:45:52 UTC+5:30, Praveen Chandrasekaran wrote:
>>
>> Hi,
>>
>> I am seeing that on stations with rapdifire, WU is not differentiating 
>> wind speed and wind gust in graph correctly. However in stations without 
>> rapidfire it is fine.
>>
>> Example my station with rapidfire:
>>
>> https://www.wunderground.com/dashboard/pws/IBANGALO9
>>
>> Another station without rapidfire:
>>
>> https://www.wunderground.com/dashboard/pws/IMUMBAI16
>>
>> Is this issue arising from weewx by any chance?
>>
>> Regards,
>> Praveen
>>
>

-- 
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/51caf745-7385-40f9-ad35-81cfed29553e%40googlegroups.com.