currentWeather from OpenWeatherMap shows no data on ESPaper everything else is fine

Question

I switched from the WeatherUnderground version to the new OpenWeatherMap code (downloaded 10th October 2018 from GitHub). ESPaper is connected to my WiFi, data is updating, forecast is showing plausible values but no icon for current weather and no description text for current weather. Temp is showing 0. I tried two different OPEN_WEATHER_MAP_LOCATION_IDs both show same effect (with different data for forecast).

Is the struct OpenWeatherMapCurrentData still uptodate (in file ./Arduino/libraries/ESP8266_Weather_Station/src/OpenWeatherMapCurrent.h)?

Thanks for any help.

Ingo

Answer 1

You can check the OWM response for 'current weather' like this:

http://api.openweathermap.org/data/2.5/weather?q=London,UK&APPID=your_API_key&mode=json&units=metric&cnt=1

Add your apI key and see what the JSON response is, like this, check for 'e.g. 'Clouds':

{"coord":{"lon":-0.13,"lat":51.51},"weather":[{"id":803,"main":"Clouds","description":"broken clouds","icon":"04d"}],"base":"stations","main":{"temp":19.49,"pressure":1003,"humidity":68,"temp_min":18,"temp_max":21},"visibility":10000,"wind":{"speed":7.2,"deg":170},"clouds":{"all":75},"dt":1539262200,"sys":{"type":1,"id":5093,"message":0.0057,"country":"GB","sunrise":1539238704,"sunset":1539278097},"id":2643743,"name":"London","cod":200}

Comments

I’m thinking network hardware/performance not your ESP. Extenders can in my experience be slow devices and you have recorded slower connection/transit times than most, noting you seem to have a problem that others don’t. The question remains why?

---

I pinged again the OWM server this morning. I measured from my computer connected via ethernet cable: 34ms. Then computer via wifi: 37ms. Then I unplugged the repeater: 37ms. The wifi strength was down to 44%, but still ok.

---

I think I might not be the only one with this problem, Marcel said that some other people reported a 0-temp-issue too. I also don't think that my problem has something to do with the quality of my connection, which I think is above average (I agree that it is 50% slower than yours!). David, you think that the data is transferred and buffered and then the connection is already closed before the next line of code tested an open connection. I agree with that. One difference between your processing of your json data and mine is a difference in length of the json return string because of different languages and different current weather conditions. Maybe we are working just at the length of the buffer. Maybe OWM is treating not all members equal. I can imagine that they use different servers with different response times or treating members with older contracts different than members with newer contracts.
But for a solution can we not just drop the outer loop test? I think that people who got their currentWeather data in their buffer (like me) don't need it and people who still have an open connection (like you) might not need it too. Even if one has still an open connection the data will be all there while the parser is going through the stream (or not? Actually I am not 100% sure).
We have not found the answer to this anomalous behaviour. We have ideas for several probable causes. I still want to find an answer and I will test everything I can here on my side!

---

What's odd is the problem should be deterministic, it is the same code and (ESP) hardware, so why is it behaving differently, this is why I was focussing on network performance as it is the only thing that is variable. It is possible and I have seen this, that OWM data comes from different servers, as I currently have 3 of my designs running on the bench using identical code and yet often the displayed values especially weather forecasts are different! Values such as temperature and pressure are generally the same , so when I investigated deeper I saw different server addresses, it very subtle but it points to OWM (and the same of WU) not having or using identical software on their servers.

I would leave out the connected test as you have now and see how it performs. We don't know how much of the buffer / free RAM the streaming parser of ThingPulse consumes or how it streams/handshakes, but it looks like this is where the issue is likely to be especially when small amounts of data are being received. It never seems to go wrong with the forecast section for example.

---

Let's continue here: https://github.com/ThingPulse/esp8266-weather-station/issues/140