0 votes
in ESPaper by (210 points)
edited by

I've been playing around with the code, trying to change the 4 hourly forecasts to 3 daily ones. In that I think I've been successful. Here's a pic of what I've got so far: https://i.imgur.com/pOUXzrj.jpg, and here's the code if anyone's interested: https://pastebin.ca/3966703

The problem is, ever since yesterday morning I've been having problems downloading the data from WU. I modified WundergroundConditions.h, WundergroundForecast.h, etc to spit out the URL that they're trying to fetch, and every time, I paste it into my browser and I get valid JSON, however the serial monitor is saying "[HTTP] GET... code: -1".  According to ESP8266HTTPClient.h, this means "HTTPC_ERROR_CONNECTION_REFUSED"

Interestingly, if I rearrange the updateData() function so the calls to updateConditions, updateForecast etc are in a different order, it's always the first one that's successful, code 200. All the rest usually get -1. I guessed maybe it's rate-limiting, so I put a 5 second delay in between fetching, but that makes no difference. Very occasionally, it will update more than one thing. The pic above is one of the few times it updated the 10day forecast. (only partially, but I think that's maybe my code)

Any idea why this might be happening? Here's a typical serial log:

***********set register  end**********
Failed to open config file
State: 1
[(my ssid)][(my password)]..Writing buffer
full init
***********set register Start**********
***********set register  end**********
[HTTP] GET...http://api.wunderground.com/api/(my api key)/conditions/lang:EN/q/pws:(my weatherstation).json
[HTTP] GET... code: 200
start document
[HTTP] GET...http://api.wunderground.com/api/(my api key)/astronomy/lang:EN/q/pws:(my weatherstation).json
[HTTP] GET... code: -1
[HTTP] GET...http://api.wunderground.com/api/(my api key)/forecast10day/lang:EN/q/pws:(my weatherstation).json
[HTTP] GET... code: -1

Waiting for time

DST Rules Updated:
DST Start: Sun Mar 11 02:00:00 2018
DST End:   Sun Nov  4 01:00:00 2018

Writing buffer
full init
***********set register Start**********
***********set register  end**********

Edit: Alright, well I'm thoroughly stumped. For some reason yesterday it was updating the conditions, failing on astronomy, then updating the forecast successfully. Then I figured hey I'll just remove the astronomy section because I'm not so interested in moon phases. So then for the rest of the day, conditions were successful but forecast was getting error -1.

This morning I've added back the astronomy update. Even though the data isn't used anywhere, it gives an error in the serial log, and it makes updating take an extra 3 seconds, it works. Now conditions and forecast are updating successfully.

I really just don't know what's going on. API limit I'm guessing. Oh well, I think I'm just going to stick it on my fridge and be done with it.

Anyway, thanks again for the awesome libraries!

1 Answer

0 votes
by (16.4k points)
selected by
Best answer

To my knowledge there's no documented behavior for rate limit violations and users who ask explicitly don't get an answer. I'll be happy to be proven wrong, though.

Anyhow, I seriously doubt the "code -1" behavior is related to rate limiting. Sounds more like a low-level error thrown from the Espressif SDKs espconn layer. All sorts of things can trigger that.

Are you willing to mark this as resolved?

by (210 points)
Yes, after a while of watching weather underground's analytics page I'm beginning to doubt it's rate limiting. Still not sure what's causing it unfortunately, and in the last couple days it's gotten worse. Now I don't get any conditions, astronomy, or forecast. I get error -1 for all three. This is what it's looked like for the past couple days: https://i.imgur.com/Rccl0TF.jpg?1 - the only thing it fetches correctly now is the time from the NTP server.

Sure, we can mark this as solved. I have no idea what's causing this, but it's probably not a problem with your libraries.
by (16.4k points)
Btw, just to ask the obvious question: did you run the HTTP requests you send from the device to WU through an alternative client (e.g. browser, curl et.al.) to compare results?
by (210 points)
Yup, works fine, http code 200, valid json returned: https://i.imgur.com/zpiTEI2.png

I've seen it fail to get the time once or twice. It shows up as unix epoch, jan 1 1970, and once it failed at connecting to wifi. Dunno, maybe it's flaky hardware? It just seems weird that the wunderground requests are failing so consistently. I'll have to try flashing other things to this chip and see if I can isolate the issue, but I'm not sure if I have the patience. Soldering this thing was sorta a pain in the ass: https://i.imgur.com/vLlFZsr.jpg

Welcome to ThingPulse Q&A, where you can ask questions and receive answers from other members of the community.