Adjust code to display high/low temps in forecast?

[jurassic73]

Missing feature

High/Low temperature display in forecast?

Justification

I currently see what looks like the low temperature displayed only in the forecast view. Curious if this can be adjusted to display both the high and low temperatures in the forecast view? If I configure the following, I see tempMin twice which is the same value returned for temp:

String temp = String(forecasts[dayIndex].tempMin, 0) + ("/") + String(forecasts[dayIndex].tempMax, 0) + (IS_METRIC ? "°C" : "°F");

I just need to know what to change to pull the tempMin and tempMax through from the API call

Workarounds

None

[NeTgHoStKiLlEr]

I have the same Issue. It appears to be showing forecast data for night-time only, even the weather icons are in night-mode; showing moons instead of suns. Been working at this to try and finish before Fathers Day...!

As you can see, the Current Weather data is fine, but it then decides to show only night-time data for the forecast.

[marcelstoer]

The min / max is actually "broken" (our opinion) in the OWM API, see #172.

[NeTgHoStKiLlEr]

Should I open another Issue topic for my slightly different issue? I just don't understand why its showing moon icons during the day. I wouldn't even care if it showed the projected forecast for only one hour of the next three days, just that it needs to show daytime temps; it gets HOT here. That shouldn't have anything to do with the temp_min or temp_max confusion.. correct?

I'm guessing somewhere in this function, having something to do with the ObservationTimeStamp or DayIndex values is where the issue lies?

void drawForecastDetails(OLEDDisplay *display, int x, int y, int dayIndex) {
  time_t observationTimestamp = forecasts[dayIndex].observationTime;
  struct tm* timeInfo;
  timeInfo = localtime(&observationTimestamp);
  display->setTextAlignment(TEXT_ALIGN_CENTER);
  display->setFont(ArialMT_Plain_10);
  display->drawString(x + 20, y, WDAY_NAMES[timeInfo->tm_wday]);

  display->setFont(Meteocons_Plain_21);
  display->drawString(x + 20, y + 12, forecasts[dayIndex].iconMeteoCon);
  String temp = String(forecasts[dayIndex].temp, 0) + (IS_METRIC ? "°C" : "°F");
  display->setFont(ArialMT_Plain_10);
  display->drawString(x + 20, y + 34, temp);
  display->setTextAlignment(TEXT_ALIGN_LEFT);
}

I don't need the high/low for the current day, just need the 3 day forecast to show daytime temps instead of night. Ty!

EDIT: I suspect the original code was meant to get the current time of day, and show either Day or Night forecast data based on if its morning or afternoon time. This is the part that I can't find how it works to correct it.

[marcelstoer]

Looks like I misinterpreted the issue at first.

[NeTgHoStKiLlEr]

Well, the OP wanted additional functionality to display both night and day high/low temps at the same time. I just added onto this issue because I thought he realized it wasn't only supposed to show the low/night time temps during the day. I don't think he does, now. Hence me wondering if I should create a NEW topic! :)

[happybono]

@marcelstoer @NeTgHoStKiLlEr I think this issue is related to the time zones for specific countries. I set location on the Open Weather Map to Antarctica on the Weather Station, and it seems to display correctly with morning/afternoon weather, however, when I set location to London, Seoul, or Tokyo it displays night weather information.

[KevinGroninga]

I too am having the same issue with the forecast temps appearing to be the low temps for each of the three days. Living in Phoenix Arizona, our concern is more with high temps for a given day (as you could imagine.) There was a previous request to display both Min and Max. I agree that would be ideal.

I did a little research and debugging on my own and took a look at the data being returned by the API from OpenWeatherMap. Very, very odd. It appears that for forecast data, it's sending data in 3 hour increments. So you're actually getting 8 different data sets for a given data. It also appears that in my case with the timezone offset that it's using the temp data from the 12:00 hour (middle of the day), but yet those temps appear to be the absolute lowest. So appears there's some sort of time offset issue as well.

Having said that, would it make any sense to look at all 8 data elements within a given forecast day and do some comparisons and then capture the highest temp_max value as well as the lowest temp_min value and use those to display?

Really would like to have this working...

Perhaps instead of having just one page with all three of the forecast days, we could fit more info for each day by having a separate page for each?

[KevinGroninga]

Oh, just another thing I saw in the OpenWeatherMapForecast.cpp file. This 'could' potentially be part of the issue. Since I'm not an Arduino code developer, I'm not 100% certain. But in the following code, is there any accounting for the 'TZ' offset that was defined in the WeatherStationDemo sketch?

 if (allowedHoursCount > 0) {
      time_t time = data[currentForecast].observationTime;
      struct tm* timeInfo;
      **timeInfo = gmtime(&time);
      uint8_t currentHour = timeInfo->tm_hour;**
      for (uint8_t i = 0; i < allowedHoursCount; i++) {
        if (currentHour == allowedHours[i]) {
          isCurrentForecastAllowed = true;
          return;
        }
      }

[marcelstoer]

is there any accounting for the 'TZ' offset

I wondered as well the other day. gmtime returns UTC.

[KevinGroninga]

Well, this has been disappointing. Went to some effort to put this together and even designed a 3D printed enclosure for it, the charge controller and small 3.7v battery. Now come to find out, the forecast info is basically useless. Hmmmm...

[marcelstoer]

Maybe there's both a conceptual and a coding problem (not sure, haven't been around this code for a while).

With https://github.com/ThingPulse/esp8266-weather-station/blob/master/examples/OpenWeatherMapForecastDemo/OpenWeatherMapForecastDemo.ino#L101-L102

  uint8_t allowedHours[] = {0,12};
  client.setAllowedHours(allowedHours, 2);

you're basically limiting the forecasts to midnight and noon. I guess this assumes that min temp is around midnight and high temp around noon. For many places this is likely not true. The coding problem then maybe is that 0/12 doesn't consider the timezone.

[KevinGroninga]

Well, I'm wondering if making an overriding OpenWeatherForecast.cpp would be an option. I looked at the return data and oddly the lowest 'temp' value in a given day (8 data sets) was at the 12:00 timeframe. If you know Arizona, you know that isn't true. Seems like it should read all 8 of the timeframes in a given forecast day and save the highest temp_max and the lowest temp_min. In any case, it seems there's an issue with the TZ offset as well. Typically for AZ the highest temp will be at about 15:00. If we look at the OpenWeatherMap web site and how they show the high/low for the forecast days, you'd think it would be possible to show the same info. So someone could look at the site and compare to the ESP01 and see the same results. Then they'd know for sure their app key and location code are correct. I could be wrong, but I think people would consider that a 'win' if the two compared. But long story short, there's something really off about that section of code that is currently capturing the tempMax. FYI, I'm definitely not an Arduino developer. I'm Actually an old school COBOL and RPG developer. So I can often deduce things by looking at the code.

Quote: I can't describe porn, but I know it when I see it!

[marcelstoer]

I looked into this again today. It's complicated I'm afraid and I don't see a satisfactory solution. Below is a kind-of note to self so I don't have to start from scratch next time I arrive here again.

• The OWM API in question is the "hourly forecast" API: https://openweathermap.org/api/hourly-forecast#JSON
• It provides 96 3h forecasts i.e. roughly for the next 4 days (starting around now).
• It does not include the daily min/max temperatures.
• The forecast hours are fixed: 00:00, 03:00, 06:00 and so on.
• Forecast time is Unix/UTC/GMT! Examples:
  • Zurich, Switzerland: https://api.openweathermap.org/data/2.5/forecast?id=2657896&appid=xxx has a forecast for dt: 1660608000, dt_txt: "2022-08-16 00:00:00" but that is not midnight in Zurich.
  • Phoenix, AZ: https://api.openweathermap.org/data/2.5/forecast?id=5308655&appid=xxx has a forecast with exactly the same values dt: 1660608000, dt_txt: "2022-08-16 00:00:00" but again, that does not represent midnight in Phoenix.
• As a consequence, if you want the forecast for Zurich or Phoenix at midnight local time you are out of luck. Zurich is UTC/GMT +2h (+1 in winter due to DST) while Phoenix is UTC/GMT -7h - 1/2/7 are not multiples of 3. However, if the location configured in this library is in a timezone that is a multiple of 3h ahead or behind UTC one could compensate this by picking next/previous forecasts.
• The forecast demo intends to get the forecast at midnight and noon by saying

  uint8_t allowedHours[] = {0,12};
  client.setAllowedHours(allowedHours, 2);
  

  For the reasons stated above this fails and I get the forecast at 2am and 2pm instead for Zurich (UTC +2).
• The code in this library could actually inspect all forecasts (something it currently doesn't) and derive the daily local min/max temperature. OWM provides the min/max for each 3h segment.

[KevinGroninga]

Thanks for looking into this a bit deeper. Yeah, sort of sad that the base code doesn’t do a better job of parsing those return values. I really liked this little project and I still have mine running right in front of my keyboard so I can see at a glance just how blazing hot it is outside here in Phoenix. But the forecasts show in the low 80’s, and I know for sure that we hit well over 100 here each and every day during this time of year.

Thanks again!

[tjlanctx]

I know I am late here, but hoping to shed some light. For the time offset, In your .ino that you are implementing, there is a line #define TZ. I have mine set to -7 (utc -7 hours for Mountain Time Zone. Extra code could be added for DST. For adding minimum and maximum to the forcast straight from the OpenWeathermap.org site, use tempMin and tempMax in the drawForcastDetails section. Currently uses only temp. You will have to duplicate the section that prints the temp variable and modify the xy coordinates to make room. The code below is from WeatherStationDemo.ino.

void drawForecastDetails(OLEDDisplay display, int x, int y, int dayIndex) { Serial.println("in drawForecastDetails"); time_t observationTimestamp = forecasts[dayIndex].observationTime; struct tm timeInfo; timeInfo = localtime(&observationTimestamp); display->setTextAlignment(TEXT_ALIGN_CENTER);

//Display forcast weekday names at top tlj display->setFont(ArialMT_Plain_10); display->drawString(x + 20, y, WDAY_NAMES[timeInfo->tm_wday]);

//Draw weather Icons tlj display->setFont(Meteocons_Plain_21); display->drawString(x + 20, y + 16, forecasts[dayIndex].iconMeteoCon);

//Display low temps at bottom of screen tlj String tempMin = String(forecasts[dayIndex].tempMin, 0) + (IS_METRIC ? "°C" : "°F"); display->setFont(ArialMT_Plain_10); display->drawString(x + 20, y + 34, tempMin);

//display max temps above icon tlj String tempMax = String(forecasts[dayIndex].tempMax, 0) + (IS_METRIC ? "°C" : "°F"); display->setFont(ArialMT_Plain_10); display->drawString(x + 20, y + 10, tempMax);

I am not getting the correct temps and I am also getting the half moon icon on the forecast section. I am debugging libraries and think the problem may be in OpenWeatherMapForecast lib, but not certain of that.

As a reminder, the code provided is FREE and DEMO. Some of the declarations are outdated, and some would say that certain standards are not followed. The programmer provided this code to us free of charge to use and modify however we want so we do not have to re-invent the wheel every time we do a project. They state up front there is no guarantee how and if it will work. For those that are disappointed, go pay a programmer or buy what you want, then you should expect it to work.

Thank you to @squix78, ThingPulse and others who have contributed to the code. I look forward to seeing any other solutions others may have.

[marcelstoer]

FWIW For our new kit I addressed these issues in the sample application.

• collect all the forecast information we get from OWM: https://github.com/ThingPulse/esp32-weather-station-touch/blob/master/src/settings.h#L115-L119
• then process the data to manually find the daily min/max: https://github.com/ThingPulse/esp32-weather-station-touch/blob/master/src/settings.h#L115-L119

[tjlanctx]

Thank you very much @marcelstoer for the fast response! I had not looked at the code for the new kit with touch screen. I should have read your solution above (#172). And your work is much appreciated here. I am a retired programmer and unfortunately I have some cognitive disability issues making some of this far more difficult than it should be.