Forecasts not updated properly on cold boot and reset.

[manj9501]

Whenever I cold boot my setup or reset it, only a few number of forecasts are updated, with the rest appearing blank as shown below in attached pictures

However, after one or two updates of the forecasts after the specified UPDATE_INTERVAL_SECS, the issue gets resolved sometimes.
Can someone please point me to what I am doing wrong?

[ackbad]

I just built my own yesterday and have the exact same issue.

[marcelstoer]

Can someone please point me to what I am doing wrong?

Maybe it's not you but the ESP8266 Arduino Core. Which version are you using? https://docs.thingpulse.com/guides/wifi-color-display-kit/#install-the-esp8266-toolchain

Also, are you using v2 of the weather station lib as per https://github.com/ThingPulse/esp8266-weather-station/releases?

[manj9501]

I am using version, 2.6.3, of the ESP8266 Arduino Core, which happens to be the latest, as of now.
And yes, I am using the version 2.0.0 of the ESP8266 Weather Station library, as I could see from the Arduino Library Manager.

Plus, I want to add that that I tested the WeatherStationDemo example of the ESP8266 Weather Station library with my 0.96" I2C OLED display and observed similar anomalous behavior, wherein forecasts were not updating properly.

[marcelstoer]

Thanks for that extra information. I guess the behavior is not surprising considering that the parsing & mapping of the data happens in the weather station library. -> I'll transfer the issue

[ackbad]

Hey try installing "ESP8266 WEATHER STATION " Version 1.6.1. Works for me now.

[manj9501]

I was actually using version 1.6.6 of the library in December.
Back then, things were absolutely fine.

[marcelstoer]

You are invited to test the fix that @reiyawea provided in #179.

[manj9501]

Just tested the fix provided by @reiyawea. And I'd say the probability of timeout happens to be more than 90% on my color display with nodeMCU setup.
The system is stuck on Updating Forecasts screen and resets after that.
See the logs attached.

Connecting to WiFi Terrace/9620666222
..........Connected...Initializing touch screen...
Mounting file system...
SPIFFS opened: OK
.
Current time: 1584315588
Getting url: http://api.openweathermap.org/data/2.5/weather?id=1277333&appid=4c27f8d598e23e3fb84398e90a049bb1&units=metric&lang=en
[HTTP] GET...
[HTTP] GET... code: 200
start document
Getting url: http://api.openweathermap.org/data/2.5/forecast?id=1277333&appid=4c27f8d598e23e3fb84398e90a049bb1&units=metric&lang=en
[HTTP] GET...
[HTTP] GET... code: 200
start document
lost in client with a timeout

 ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x4010f000, len 1392, room 16 
tail 0
chksum 0xd0
csum 0xd0
v3d128e5c
~ld

As a side note, am yet to test this fix on my I2C display setup. Will update in a few hours from now.

[manj9501]

Exactly similar behavior observed on I2C display setup with nodeMCU.
The system resets after the Updating forecasts... screen (shown below) and the same process repeats. Haven't had a single success with the WeatherStationDemo after this fix.
Notably, it did work once or twice on the other setup once or twice, with the probability of timeout I mentioned earlier.

The debugging log is completely identical to the one I posted for the color display setup, though of course, it's missing the SPIFFS related portion.

[IcingTomato]

I have tested version 1.6.6, 1.6.5 and 1.6.4 library,the monitor works and http calls back 200.
But I used version 2.0 ,http calls error code likes -11 , -00 and so on.
So I think the V2.0 library has bugs.

[IcingTomato]

1.6.6 version can't get the proper data now.

[reiyawea]

It seems that the HTTP library has some trouble dealing with HTTP response with large payload. Maybe we shall try using TCP socket directly, which may be tough to code, but hopefully memory-efficient.

[marcelstoer]

It's not tough to code at all - at least not for basic HTTP operations. True, it's a major PITA for things like multi-part file upload over HTTPs as we experienced first-hand. I argue that the code in the fix I will propose is at least as legible as the current version. Let's see how that turns out once I'm done. Give me a few days.

[marcelstoer]

Based on the discussions here and in #179 I created a new PR #180 that supersedes #179. I encourage everyone to test that one so we can verify it also works outside my test bed. The essentials of the new code:

esp8266-weather-station/src/OpenWeatherMapForecast.cpp

Lines 55 to 87 in 9a59df2

	Serial.printf("[HTTP] Requesting resource at http://%s:%u%s\n", host.c_str(), port, path.c_str());
	WiFiClient client;
	if(client.connect(host, port)) {
	bool isBody = false;
	char c;
	Serial.println("[HTTP] connected, now GETting data");
	client.print("GET " + path + " HTTP/1.1\r\n"
	"Host: " + host + "\r\n"
	"Connection: close\r\n\r\n");
	while (client.connected() || client.available()) {
	if (client.available()) {
	if ((millis() - lost_do) > lostTest) {
	Serial.println("[HTTP] lost in client with a timeout");
	client.stop();
	ESP.restart();
	}
	c = client.read();
	if (c == '{' || c == '[') {
	isBody = true;
	}
	if (isBody) {
	parser.parse(c);
	}
	// give WiFi and TCP/IP libraries a chance to handle pending events
	yield();
	}
	}
	client.stop();
	} else {
	Serial.println("[HTTP] failed to connect to host");
	}

[manj9501]

I've tested the code with both my SPI color LCD as well the I2c OLED display and I can say that the changes made in the PR #180 have caused both the setups to work just fine.

Also, during my testing, I observed no timeouts as such, so as @reiyawea believes, it must have something to do with bad network condition.

[marcelstoer]

@manj9501 Thanks for testing so thoroughly and for the encouraging feedback.

[marcelstoer]

The fix was shipped with v2.0.1: https://twitter.com/thingpulse/status/1242136395336036360

[manj9501]

I've updated to the latest and it works like a charm!
Thanks for the prompt intervention!