* On 2022 08 Feb 13:16 -0600, Phil Green wrote:
> Have re-enabled uploading to Wunderground.
> Seems like it is working again.
It appears to be. According to my logs it recovered around 1900z and
then a glitch at 2000z and two at 2015z and clean since.
> Thanks for your comments.
I'm
Have re-enabled uploading to Wunderground.
Seems like it is working again.
Thanks for your comments.
Regards
Phil
On Tuesday, February 8, 2022 at 5:48:03 PM UTC n0...@n0nb.us wrote:
> Wunderground is broken again so far most of this morning.
>
> - Nate
>
> --
> "The optimist proclaims that we
Wunderground is broken again so far most of this morning.
- Nate
--
"The optimist proclaims that we live in the best of all
possible worlds. The pessimist fears this is true."
Web: https://www.n0nb.us
Projects: https://github.com/N0NB
GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130
Same here for me.
On Tuesday, February 8, 2022 at 10:13:22 AM UTC-6 do...@dougjenkins.com
wrote:
> Specifically looking at my log, it started to fail at 9:15AM EST and
> continues to fail. I will restart my docker image and see if it will clear
> up. Sounds like this is all related to an api
Specifically looking at my log, it started to fail at 9:15AM EST and
continues to fail. I will restart my docker image and see if it will clear
up. Sounds like this is all related to an api endpoint issue.
On Tue, Feb 8, 2022 at 11:10 AM Tom Hogland wrote:
> Mine's been fine until this morning
Sounds like they had Rapid-Fire issues for a day or two, and now I'm unable
to upload as well. Didn't see anything in their news page except
complaints...
On Tuesday, February 8, 2022 at 7:08:05 AM UTC-9 do...@dougjenkins.com
wrote:
> I am also seeing the same issue with Wunderground and I am
Mine's been fine until this morning - dropped offline and logs show I'm
unable to connect to upload. Apparently the issues persist...
On Monday, February 7, 2022 at 7:40:52 AM UTC-9 Jeremy A wrote:
> Yes, seems to be working again. using RF as well
>
> On Monday, February 7, 2022 at 10:39:12 AM
I am also seeing the same issue with Wunderground and I am on WeeWX 4.5.1.
Nothing has changed in my configuration for over 30 days. I would assume at
this point wunderground is having connectivity issues or something has
changed in the API interface on their end.
On Tue, Feb 8, 2022 at 11:04
To mute this, add this in the weewx.conf
[[Wunderground]]
...
...
log_success = False
log_failure = False
David Schulz schrieb am Dienstag, 8. Februar 2022 um 17:01:43 UTC+1:
> Seems like Wunderground-PWS is down again. Got the same messages. You
> could disable this messages. I have already
Seems like Wunderground-PWS is down again. Got the same messages. You
could disable this messages. I have already had to do this with some
services.
Feb 8 15:28:29 weather weewx[182368] ERROR weewx.restx: Wunderground-PWS:
Failed to publish record 2022-02-08 15:28:00 CET (1644330480): Failed
Further to my first post I have set debug = 1 and reenabled the
Wunderground service and got these log entries:-
Feb 8 15:55:27 Pi3-Weewx weewx[1159] DEBUG weewx.restx: Wunderground-PWS:
Failed upload attempt 1: The read operation timed out
Feb 8 15:55:42 Pi3-Weewx weewx[1159] DEBUG
Hello,
I have just updated to 4.6.0 for my Vantage Vue connected to my Pi3B.
Locally everything works ok and I am running the default Skin.
I am uploading to PWSWeather and that is fine, but uploading to
Wunderground fails.
Log message:-
Feb 8 15:42:44 Pi3-Weewx weewx[964] ERROR weewx.restx:
Thanks for this - nice to be able to stash it elsewhere, and one of those
things that "I should be doing but haven't gotten around to yet". I checked
my NOAA folder, and it's only 1MB (and that's complete since 4/2003). No
reason not to include it, especially since text will crunch down to
However, I would like to point out that this issue should be bound to an
error hook - if the WeeWX does not run the reports for whichever reason,
the user should definitely know. From the UX point-of-view, this is an
unhandled exception.
My issue was probably caused by manual time correction
Hello, Tom,
thanks for pointing out the corrupted memory issue.
I chose to experiment a bit:
1) downloaded the station data to the WeeWX database
2) reflashed the very oddly responding station back to FW v1.90 - will
experiment with the newer versions later though and share the results
3)
If that's the case, it would be useful to see more of the log, in
particular of the time when the report should have been run.
It's possible that the logger in your Davis is suffering from corrupted
memory, but it's impossible to say without seeing the log. See the wiki
Hello, Tom,
thanks, the 30 min archive interval is set up on purpose.
However, after 12 hours, different configs and a full machine reinstall,
the system was able to create a report only once, then the index.html with
current weather has not been updated, but monthly reports were OK.
Then I
Hello, Markek
The first report is not generated until the end of the first archive
interval. No report is generated on catchup.
Your archive interval is rather long (1/2 hour), so you will have to wait a
bit to see the first one.
To change the archive interval, use the utility wee_device with
Hello, I have tried many threads any many things, however I am still
unsuccessful in getting WeeWX into the working state.
I have installed a HyperV VM (gen2) with Debian 11:
##
Icon name: computer-vm
Chassis: vm
Virtualization:
I have found my error:
To avoid posting my own weewx.conf (with account and password), I have
removed this file in the git process
Also version in weewx remained in 4.3.0.
I change in 4.6.1rc and it's OK now
Sorry for my previous message
Le mardi 8 février 2022 à 11:30:48 UTC+1,
I have updates weewx to 4.6 and lastrain-extension (compatible weewx 4.6)
But I have exactly the same error of Remy after reboot
I've checked lastrain.py and I have the correct §:
try:
# 4.6.0 breaking change - must specify either
context='short_delta' or context='long_delta'
21 matches
Mail list logo
