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
--
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 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
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:
>
>
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
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,
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
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,
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
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
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,
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
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
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.
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,
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
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
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
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
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
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
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
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,
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
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()
>
>
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
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
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
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
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,
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
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
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
33 matches
Mail list logo
