Tom,
At least it is apparent from the log why the CWOP posts are failing, but
what is the underlying cause is another matter. By default CWOP posts the
relevant data from the archive record every 10 minutes; however, when the
data is to be posted it's age is checked and it's considered as stale if it
is older than 60 seconds. If you look at the log extract you provided you
can see the 11:20:00 archive record was generated and saved to database at
11:21:33:
Aug 29 11:21:33 raspberrypi2 weewx[26138]: manager: Added record 2018-08-29
11:20:00 EDT (1535556000) to database 'weewx.sdb'
Aug 29 11:21:33 raspberrypi2 weewx[26138]: manager: Added record 2018-08-29
11:20:00 EDT (1535556000) to daily summary in 'weewx.sdb'
WeeWX attempted to post the 11:20:00 data to CWOP at 11:21:33 but by that
time the archive record data was 93 seconds old (11:21:33 - 11:20:00) and
hence it was skipped:
Aug 29 11:21:33 raspberrypi2 weewx[26138]: restx: CWOP: record 2018-08-29 11
:20:00 EDT (1535556000) is stale (93 > 60).
I assume this is the case on each archive record and that is why no CWOP
records are being posted. However, the underlying reason is another matter.
I have never used the interceptor driver but it seems odd that the 11:20:00
record is saved to database at 11:21:33, I would expect that to happen
about 1 minute earlier, usually within a few seconds of the archive record
timestamp; perhaps this is a peculiarity of the interceptor driver. Perhaps
someone knowledgeable on the interceptor driver and your station can
comment.
In the meantime you get things working by explicitly setting the stale
config option for CWOP posts. To do this edit weewx.conf and locate the
[[CWOP]] stanza under [StdRESTful], add in a line stale = 120. You should
end up with something like:
[[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 = true
station = XXX obfuscated by wee_debug XXX
# If this is an APRS (radio amateur) station, uncomment
# the following and replace with a passcode (e.g., 12345).
passcode = "removed"
post_interval = 600
server_list = rotate.aprs.net:14580, rotate.aprs.net:14580
stale = 120
Save weewx.conf then restart WeeWX. Monitor your log and hopefully you will
see CWOP data being posted. Once you are happy you can set debug=0 again
(and restart WeeWX) to cut down on your log entries.
Gary
On Thursday, 30 August 2018 01:58:47 UTC+10, Boston Tom wrote:
>
> Thank you Gary. I have attached the weewx conf file and debug log.
>
> Please note that I have set-up an RPI as a wireless access point and am
> directing the weather station to send data to this WAP. I then sniff the
> data off the WAP and process it through weewx. This set-up has been
> working for over a year now, but my weather system hardware failed and the
> company sent me new hardware (Lacrosse). Ever since the new hardware, it
> won't upload to CWOP. It does upload to PWSWeather, so I know the data is
> being sniffed and processed. Any help on this matter is much appreciated.
> Thank you!
>
> Tom
>
> On Tuesday, August 28, 2018 at 8:14:15 PM UTC-4, gjr80 wrote:
>>
>> Hi,
>>
>> We need to have a good look at the log to see what is going on here. Can
>> I get you to edit weewx.conf, set debug = 1 (line 11), save weewx.conf
>> then restart WeeWX. Let WeeWX run for say 15 minutes then post an extract
>> from your log from when you restarted WeeWX through until the 15 minutes
>> elapsed. Posting your sanitised weewx.conf would also help, probably
>> easiest done by running wee_debug
>> <http://weewx.com/docs/utilities.htm#wee_debug_utility> and posting its
>> output. Just make sure you check the wee_debug output for any sensitive
>> info, wee_debug is pretty good at obfuscating sensitive info but it is
>> not perfect.
>>
>> Gary
>>
>> On Wednesday, 29 August 2018 01:49:42 UTC+10, Boston Tom wrote:
>>>
>>> I have a similar problem. restx says it is going to post to CWOP and
>>> PWSWeather, but is only posting to PWSWeather (see below)
>>>
>>> I'm not very good at finding things in Linux, so if you could please
>>> help me find where I can check my Pi for DNS name resolution, I would like
>>> to make sure it is showing the correct servers.
>>>
>>> Thank you!
>>>
>>>
>>>
>>> Aug 28 11:27:04 raspberrypi2 weewx[3754]: engine: Using binding
>>> 'wx_binding' to database 'weewx.sdb'
>>> Aug 28 11:27:04 raspberrypi2 weewx[3754]: manager: Starting backfill of
>>> daily summaries
>>> Aug 28 11:27:04 raspberrypi2 weewx[3754]: restx: StationRegistry:
>>> Registration not requested.
>>> Aug 28 11:27:04 raspberrypi2 weewx[3754]: restx: Wunderground: Posting
>>> not enabled.
>>> Aug 28 11:27:04 raspberrypi2 weewx[3754]: restx: PWSWeather: Data for
>>> station KC1ELF will be posted
>>> Aug 28 11:27:04 raspberrypi2 weewx[3754]: restx: CWOP: Data for station
>>> KC1ELF will be posted
>>> Aug 28 11:27:04 raspberrypi2 weewx[3754]: restx: WOW: Posting not
>>> enabled.
>>> Aug 28 11:27:04 raspberrypi2 weewx[3754]: restx: AWEKAS: Posting not
>>> enabled.
>>> Aug 28 11:27:04 raspberrypi2 weewx[3754]: engine: Starting up weewx
>>> version 3.7.1
>>> Aug 28 11:27:04 raspberrypi2 weewx[3754]: engine: Starting main packet
>>> loop.
>>> Aug 28 11:28:35 raspberrypi2 weewx[3754]: interceptor: MainThread:
>>> skipping rain measurement of 0.0: no last rain
>>> Aug 28 11:28:35 raspberrypi2 rsyslogd-2007: action 'action 17'
>>> suspended, next retry is Tue Aug 28 11:29:05 2018 [try
>>> http://www.rsyslog.com/e/2007 ]
>>> Aug 28 11:31:35 raspberrypi2 weewx[3754]: manager: Added record
>>> 2018-08-28 11:30:00 EDT (1535470200) to database 'weewx.sdb'
>>> Aug 28 11:31:35 raspberrypi2 rsyslogd-2007: action 'action 17'
>>> suspended, next retry is Tue Aug 28 11:32:05 2018 [try
>>> http://www.rsyslog.com/e/2007 ]
>>> Aug 28 11:31:35 raspberrypi2 weewx[3754]: manager: Added record
>>> 2018-08-28 11:30:00 EDT (1535470200) to daily summary in 'weewx.sdb'
>>> Aug 28 11:31:36 raspberrypi2 weewx[3754]: restx: PWSWeather: Published
>>> record 2018-08-28 11:30:00 EDT (1535470200)
>>> Aug 28 11:31:40 raspberrypi2 weewx[3754]: cheetahgenerator: Generated 14
>>> files for report StandardReport in 4.44 seconds
>>> Aug 28 11:31:41 raspberrypi2 weewx[3754]: imagegenerator: Generated 12
>>> images for StandardReport in 0.78 seconds
>>> Aug 28 11:31:41 raspberrypi2 weewx[3754]: copygenerator: copied 9 files
>>> to /var/www/html/weewx
>>> Aug 28 11:36:35 raspberrypi2 weewx[3754]: manager: Added record
>>> 2018-08-28 11:35:00 EDT (1535470500) to database 'weewx.sdb'
>>> Aug 28 11:36:35 raspberrypi2 rsyslogd-2007: action 'action 17'
>>> suspended, next retry is Tue Aug 28 11:37:05 2018 [try
>>> http://www.rsyslog.com/e/2007 ]
>>> Aug 28 11:36:35 raspberrypi2 weewx[3754]: manager: Added record
>>> 2018-08-28 11:35:00 EDT (1535470500) to daily summary in 'weewx.sdb'
>>> Aug 28 11:36:36 raspberrypi2 weewx[3754]: restx: PWSWeather: Published
>>> record 2018-08-28 11:35:00 EDT (1535470500)
>>> Aug 28 11:36:38 raspberrypi2 weewx[3754]: cheetahgenerator: Generated 14
>>> files for report StandardReport in 2.00 seconds
>>> Aug 28 11:36:38 raspberrypi2 weewx[3754]: imagegenerator: Generated 12
>>> images for StandardReport in 0.78 seconds
>>> Aug 28 11:36:38 raspberrypi2 weewx[3754]: copygenerator: copied 0 files
>>> to /var/www/html/weewx
>>> Aug 28 11:41:35 raspberrypi2 weewx[3754]: manager: Added record
>>> 2018-08-28 11:40:00 EDT (1535470800) to database 'weewx.sdb'
>>> Aug 28 11:41:35 raspberrypi2 rsyslogd-2007: action 'action 17'
>>> suspended, next retry is Tue Aug 28 11:42:05 2018 [try
>>> http://www.rsyslog.com/e/2007 ]
>>> Aug 28 11:41:36 raspberrypi2 weewx[3754]: manager: Added record
>>> 2018-08-28 11:40:00 EDT (1535470800) to daily summary in 'weewx.sdb'
>>> Aug 28 11:41:36 raspberrypi2 weewx[3754]: restx: PWSWeather: Published
>>> record 2018-08-28 11:40:00 EDT (1535470800)
>>> Aug 28 11:41:38 raspberrypi2 weewx[3754]: cheetahgenerator: Generated 14
>>> files for report StandardReport in 2.10 seconds
>>> Aug 28 11:41:38 raspberrypi2 weewx[3754]: imagegenerator: Generated 12
>>> images for StandardReport in 0.77 seconds
>>> Aug 28 11:41:38 raspberrypi2 weewx[3754]: copygenerator: copied 0 files
>>> to /var/www/html/weewx
>>>
>>> On Thursday, August 16, 2018 at 10:46:52 AM UTC-4, Michael Gray wrote:
>>>>
>>>> I have found/fixed my problem! As I suspected, it was nothing to do
>>>> with weewx per se... Somehow, my DNS config (resolv.conf etc.) was
>>>> changed
>>>> so my Pi was not resolving hostnames. This caused weewx rest code not
>>>> to resolve urls needed for posting to public servers:
>>>>
>>>> ./weewx/restx.py: rf_url = "
>>>> http://rtupdate.wunderground.com/weatherstation/updateweatherstation.php
>>>> "
>>>> ./weewx/restx.py: pws_url = "
>>>> http://weatherstation.wunderground.com/weatherstation/updateweatherstation.php
>>>> "
>>>> ./weewx/restx.py: default_servers = ['cwop.aprs.net:14580', '
>>>> cwop.aprs.net:23']
>>>>
>>>> Once I got name resolution back on the rails, weewx publishing started
>>>> working.
>>>>
>>>> I'm a little surprised that with all the error checking in the code,
>>>> weewx was silent on the issue of not being able to resolve the hostnames
>>>> in
>>>> the URLs
>>>> upon which it depends -- nothing about GET failing or anything...
>>>>
>>>> It looks like the except's on the try's to connect to the servers could
>>>> use some more generic error catching -- I might give it a go but my python
>>>> foo is not strong...
>>>>
>>>> Would a bug report be in order here? I know this wasn't weewx fault
>>>> per se, but had there been an error like "unknown host", I would have
>>>> probably found the
>>>> name resolution problem quickly...
>>>>
>>>> Thanks to all who looked at my post and sent along their thoughts --
>>>> great community here!
>>>>
>>>>
>>>> On Thursday, August 16, 2018 at 10:02:34 AM UTC-4, Michael Gray wrote:
>>>>>
>>>>> It's always said that -- I never explicitly requested "hardware
>>>>> generation" -- I'll try adding record_generation = software explicitly
>>>>>
>>>>> last restart before "upgrade" when all was well: Aug 14 15:17:11
>>>>> raspberrypi weewx[654]: engine: Record generation will be attempted in
>>>>> 'hardware'
>>>>> post-upgrade:
>>>>> Aug 15 22:01:18 raspberrypi weewx[29842]: engine: Record generation will
>>>>> be
>>>>> attempted in 'hardware'
>>>>>
>>>>> hardware is the default and comments suggest it will use hardware in
>>>>> devices that support it -- software if not... But I've added the
>>>>> following:
>>>>>
>>>>> # If possible, new archive records are downloaded from the station
>>>>> # hardware. *If the hardware does not support this, then new
>>>>> archive*
>>>>> * # records will be generated in software.*
>>>>> # Set the following to "software" to force software record
>>>>> generation.
>>>>> *# *record_generation = hardware
>>>>> * record_generation = software*
>>>>>
>>>>> Log now reports this:
>>>>>
>>>>> Aug 16 09:56:18 raspberrypi weewx[2791]: engine: *Record generation
>>>>> will be attempted in 'software'*
>>>>>
>>>>> No change in behavior -- still getting data, storing records and
>>>>> generating web pages -- but no publish...
>>>>>
>>>>> I'm wondering if something in all the linux updates (not updated for
>>>>> several months) changed -- python or some library weewx uses...
>>>>>
>>>>>
>>>>> On Thursday, August 16, 2018 at 8:15:00 AM UTC-4, gjr80 wrote:
>>>>>>
>>>>>> Let's try that again.
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Any reason you are using hardware record generation? As far as I am
>>>>>> aware the AcuRite stations only emit loop packets (in fact the AcuRite
>>>>>> driver does not have a genArchiveRecords() method necessary to generate
>>>>>> archive records from the hardware). Suggest you try setting
>>>>>> record_generation = software under [StdArchive] in weewx.conf. Once you
>>>>>> make the change you will need to restart weeWX.
>>>>>>
>>>>>> 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 [email protected].
For more options, visit https://groups.google.com/d/optout.
