Large scale radar map works then repeats old radar data

[feh123]

PiClock has been working well on my RPI3 with 7" monitor for the last year. In the last two weeks the large scale radar map (the top map) as, intermittently, repeated one (always the same one) old sequence of radar data. The map corrects itself after around 5 minutes. The RHS data fields and the top left summary are always correct.

I tried a reboot and an update (I get the message up to date) - but this had no effect. My question is - am I updating PiClock properly - what are the best commands? I am using an android VNC viewer app to connect to the PiClock.

Or is there another issue? Thanks Fred

[merky1]

I have the same issue in both the preview and full size radars. I am not sure if this is PiClock's fault or wxunderground's amazing api. I have noticed on several aspects of the API that things just don't work like they should, or using my zip code vs. gps coordinates can result in a 5 degree difference.

[SerBrynden]

I noticed a similar problem. One of the radar windows is correct, but the other window randomly shows a radar for what looks like another location and the timestamps in the top left are in UTC timezone. This happens on both screens. My guess is the coordinates are getting messed up and it's showing the radar for 0.00 lat and 0.00 long.

[feh123]

Hi thanks for the confirmation I am not the only one. Yes my full size radar maps show the same and lately both maps too. Can PiClock cache this data and is that the source? I thought maybe there was an intermittent wifi issue that was causing this but even when I use an ethernet connection to the RPI3 the error still occurs. I will try doing a complete re-installation on a fresh SD card.

I wonder if PiClock could be pointed to a different weather API supplier?

[feh123]

Hi, thanks for info. In my case the "wrong" data set looks to be using the right lat/lon - I still see the expected map area. The radar data that is wrong looks to be a data set I received about 14 day ago. Do you see a radar picture that looks familiar? Both my timestamps are UTC as is normal. I tried the satellite map but that seems rather useless as a weather indicator - although in the time I tried it (only one day) it did seem to behave. For info I am using PiClock in the UK. I certainly think it could be WU and maybe they do corrupt the data request in some way - are there other weather data sources? I would also like to know if PiClock does cache data - I will try a fresh installation to see if that fixes it.

[SerBrynden]

Upon further investigation, I also believe it's a wxunderground API problem. Seems to be replaying old radars when the times are similar.

[feh123]

Thanks. I have not tried re-installing yet but I will check to see if mine too replays old data at regular times.

[merky1]

If you look in the logs, you can see the API request made to wxunderground. One of the things I have noticed is the timestamp in the upper left is generated by wxunderground, and that appears to be one of the things that becomes nonsensical when pulling the radar image.

This reinforces that the error is upstream from PiClock, and there is little we can do to compensate for it.

Did some more digging, and hitting the wxapi directly, getting different results on different options :

http://api.wunderground.com/api/[key]/animatedradar/q/VA/Ashburn.gif?timelabel=1&timelabel.y=10&num=5&delay=50&newmaps=1 - Clock is accurate, weather appears empty.

http://api.wunderground.com/api/[key]/animatedradar/q/VA/Ashburn.gif?timelabel=1&timelabel.y=10&num=5&delay=50&newmaps=0 - clock is UTC, no rain detected.

http://api.wunderground.com/api/[key]/animatedradar/q/VA/Ashburn.gif?timelabel=1&timelabel.y=10&num=5&delay=50 - Clock is accurate, slight spots of precipitation.

Basically, bottom line is the weather provider is giving different results on every pull.

[n0bel]

I'm really happy to see people commenting and helping others out. Great to see! I've been following the thread since it started. Here's some of my experiences with similar issues in the early PiClock. There was a time when I had a house fire and I was required to move to an apartment, then an extended stay hotel, and some other places.

When I was in the hotel, I started noticing weirdness in the radar... stuck old radars, stuck weather conditions. After experimenting with browsers and curl, I discovered that when I had failures, it was due to caching by whatever ISP I was using.

Normally people think that web traffic goes from point to point directly by TCP/IP. This is not always the case. Some ISPs intercept http and https and cache pages locally in order to lower their total bandwidth.

At that time I introduced a random factor into the WU API ( ?r= ). This makes the URL request unique and defeats any caching. This worked well. I did it both for the json api and the gif radar image retrieval.

Some months later, the radar images stopped working entirely. What I found is that WU was generating an error from the unknown parameter 'r'. So I removed it from the radar image retrieval. A the time I was not using that ISP that I proved was doing caching, so if there was a new issue I would not have had the issue anymore. This was all about 2 years ago.

So, it could be a WU issue, or it could be an ISP issue.

The radar retrieval is done around line 480 of PyQtPiClock.py in case someone wants to try the random parameter again.

[feh123]

Hi Kevin it’s a great clock! Thanks for the ideas, I will contact my ISP to see what they are doing and if they cache. Hopefully as we do see the maps the extra parameter would work. I will pass on to everyone my ISP’s reply.

[feh123]

Hi my ISP does not cache at all and suggests it is the upstream server or a CDN issue (not sure what that means). So my only thought is - can we replace WU with another radar data supplier? Or just live with the error? The other weather data (pressure, temperature, wind, rain (including weather icons) all seem fine. For me the PiClock always repeats the same gif pictures so I know when it is wrong.

[n0bel]

Since the entire PiClock is hard coded for the WU api, it is not a simple task to "swap".

On the development branch of PiClock, (PiClock²) the idea is to make the entire structure of PiClock more plugin driven. Work is stalled on this at the moment, however. Check out some of the work done so far, as well as the discussion items about the project.

[feh123]

Hi Kevin, thanks for the info. Somehow I did not think it would be easy. I will just keep using it has is and update when PiClock2 or versions of that are ready for a beginner. At the moment I have never seen both maps wrong so in practice PiClock radar is still fine. I admire your skill to have made it.

[merky1]

It looks as though wunderground had a problem one their side, and it should be resolved as of today.

https://apicommunity.wunderground.com/weatherapi/topics/radar-rogue-image :

"Brendan Hayes, Official Rep

There was a radar issue but it should be fixed now"

[feh123]

Looks an identical issue. I hope Brendan’s idea that it’s fixed works out - I am away at the moment so cannot check. Thanks for finding this thread. I thought we had reached an end point but maybe not if WU are now involved.

Sent from Yahoo Mail for iPhone

On Tuesday, November 28, 2017, 11:11 am, Merky1 notifications@github.com wrote:

It looks as though wunderground had a problem one their side, and it should be resolved as of today.

https://apicommunity.wunderground.com/weatherapi/topics/radar-rogue-image :

"Brendan Hayes, Official Rep

There was a radar issue but it should be fixed now"

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.