ESP8266 WiFi Weather Station stopped showing weather data

[cowanbm]

Not sure if this is a”bug”…

I built the ESP8266 WiFi Weather Station (Adafruit kit) in the summer of 2020. It worked fine till this spring (2024). It still displays the correct time, but there is no weather information (shows “?” In all the fields). It also does not update the moon-phase data anymore. No changes made to the code or wifi setup.

I requested a new key from OpenWeatherMap, updated the settings.h file, recompiled and uploaded the code, I replaced the ESP8266 and I also reset my WiFi service. But nothing has resolved the issue. I see no errors in the serial console output, and see that the upload works OK.

Has anybody else had this problem? Any suggestions on what to do? I don’t know how to debug this. Any test code I can add?

Thanks

[utpluvia]

Looks like opeweathermap stopped providing access to their api through http. You can try to use https instead. For now, I'm experiencing troubles with setting up https access on my esp32 board, but at least when I try to access to openweathermap through https via browser, it shows everything well. So, the next main step is to set up secure access via esp32

[marcelstoer]

Looks like opeweathermap stopped providing access to their api through http.

I can't confirm that.

curl -v 'http://api.openweathermap.org/data/2.5/weather?id=2660857&appid=my-id&units=metric&lang=en'
* Host api.openweathermap.org:80 was resolved.
* IPv6: (none)
* IPv4: 146.185.152.21
*   Trying 146.185.152.21:80...
* Connected to api.openweathermap.org (146.185.152.21) port 80
> GET /data/2.5/weather?id=2660857&appid=my-id&units=metric&lang=en HTTP/1.1
> Host: api.openweathermap.org
> User-Agent: curl/8.7.1
> Accept: */*
> 
* Request completely sent off
< HTTP/1.1 200 OK

[utpluvia]

Looks like opeweathermap stopped providing access to their api through http.

I can't confirm that.

And yet all my weather stations that use openweathermap suddenly stopped showing weather, browser via http shows ERR_CONNECTION_RESET as well. curl shows the same. Many people on internet say about that propblem. Probably it depends on user's location. Via https everything works well

[marcelstoer]

Interesting observation but I'm still somewhat doubtful OWM is to blame for that. Just to be sure, I briefly checked back with their support and they confirmed.

Our API supports both HTTP and HTTPS.

HTTP - port 80 HTTPS - port 443

So, I suggest you contact them directly if HTTP ain't working for you. Maybe include the full cURL debug output.

[MuellerOtto]

See the same issue. After rebuilding the project the serial monitor gets stuck at Serial.println("[HTTP] connected, now GETting data");

[MuellerOtto]

We need to update the api calls: "Please use Geocoder API if you need automatic convert city names and zip-codes to geo coordinates and the other way around.

Please note that API requests by city name, zip-codes and city id have been deprecated. Although they are still available for use, bug fixing and updates are no longer available for this functionality."

[utpluvia]

I was able to get kinda workaround for the issue by adding do{} while() cycle into my code like this:

 do{
  client.updateCurrentById(&data, OPEN_WEATHER_MAP_APP_ID, OPEN_WEATHER_MAP_LOCATION_ID);
  delay(10000);
  } while(data.cod != 200);

instead of just client.updateCurrentById(&data, OPEN_WEATHER_MAP_APP_ID, OPEN_WEATHER_MAP_LOCATION_ID); If the service is unavailable right now, after some attempts my weather station is able to get the data from openweathermap. You should also declare the 'cod' variable in the OpenWeatherMapCurrent.h and OpenWeatherMapCurrent.cpp files. If I understood it right, the cod = 200 means succesful retrieving the data. As to forecast call, you can add the cycle like this:

  foundForecasts = forecastClient.updateForecastsById(forecastData, OPEN_WEATHER_MAP_APP_ID, OPEN_WEATHER_MAP_LOCATION_ID, MAX_FORECASTS);
  delay(10000);
  } while (foundForecasts != MAX_FORECASTS);

It works for me now.

[MuellerOtto]

I took a slightly different brute force route and "hard" coded my coordinates into OpenWeatherMapCurrent.cpp

String OpenWeatherMapCurrent::buildPath(String appId, String locationParameter) {
  String units = metric ? "metric" : "imperial";
  locationParameter = "lat=xx.yyyy&lon=a.bbbb";
  return "/data/2.5/weather?" + locationParameter + "&appid=" + appId + "&units=" + units + "&lang=" + language;
}

and OpenWeatherMapForecast.cpp

String OpenWeatherMapForecast::buildPath(String appId, String locationParameter) {
  String units = metric ? "metric" : "imperial";
  locationParameter = "lat=xx.yyyy&lon=a.bbbb";  
  return "/data/2.5/forecast?" + locationParameter + "&appid=" + appId + "&units=" + units + "&lang=" + language;
}

by setting locationParameter with lat and lon received from an http call.

[marcelstoer]

That's odd. I am aware that the API-by-city-id has been deprecated for a long time. However, as long as they don't remove it completely, it is not supposed to fail. Hence, their current promise is, that it shouldn't matter whether you query by city ID or lat/lon.

[MuellerOtto]

Hello Marcel, That was my understanding, too. The device is based on Adafruit's version of the code. So it was using CityName,Countrycode for calling the API. The device stopped working a couple of weeks ago, like shown by [cowanbm]. The http request shown in the serial monitor worked fine when copied into a browser, The GET call resulted in a 400 Bad Request error. Cheers, Otto