Help on forecastClient.setAllowedHours

[GnFlala]

Can someone help on how i can have the forecasts show days instead of specific hours of next days?

uint8_t allowedHours[] = {12};
    forecastClient.setAllowedHours(allowedHours, sizeof(allowedHours));
    forecastClient.updateForecasts(forecasts, OPEN_WEATHER_MAP_APP_ID, OPEN_WEATHER_MAP_LOCATION, MAX_FORECASTS);

This returns the forecast for next days for 14:00 if i am not wrong.

Changing allowedHours to 24 returns nothing.

Thanks in advance

[bill-orange]

Here's a partial answer.

I am not an authority on this but I think allowed hour is what the name implies, the hour integers that are allowed. In other words to get a forecast for 11:00 AM and and 2:00 PM you would use:

uint8_t allowedHours[] = {11, 14}; Since the range is 0 to 23, 24 would return nothing, explaining your result.

Not sure how to change the day without knowing what example you are using.

[marcelstoer]

@bill-orange thanks

[twfry]

I also struggled with this and figured it out after a late night. Sharing here since this is the first page google lists.

There are two key items:

1. allowedHours is in UTC time.
2. Open weather map only returns forecasts in every 3 hour increments, i.e. it only returns values for 12am, 3am, 6am, 9am, 12pm, 3pm, 6pm, 9pm again in UTC time.

The way the library operates is it simply checks the allowedHours provided against the values Open weather map returns. This means the only valid values for allowedHours are { 0, 3, 6, 9, 12, 15, 18, 21 }. Any other values provided simply will not match any data returned.

As a result you need to find the closest UTC time available to the local time you want and specify that in allowedHours. For example if you want values at 12am, 6am, 12pm, 6pm in local time and you are located in Eastern US time which is -5 from UTC, then setting "allowedHours = {18, 12, 6, 0};" will map to 1am, 7am, 1pm, 7pm EST which is the closest you can gather from the data returned.

Hope this helps

[marcelstoer]

I vaguely remember having had the same discussion with a user/customer not too long ago somewhere. However, I don't remember where that was. Either somewhere here on GitHub or on our support forum. I went looking but only found https://support.thingpulse.com/1424/the-kit-works-well-but-why-is-10-am-and-10-pm-set-for-forecasts?show=1432#c1432 that is related.

[twfry]

I tested the above logic with a few different requested times and believe what I outlined above is accurate for how to use allowedHours. It probably would be helpful to add an explanation in the comments where allowedHours is defined so users understand how to properly use it as it makes no sense otherwise and its usage is very non-intuitive.

[marcelstoer]

It probably would be helpful to add an explanation in the comments where allowedHours is defined

When the need for a longish explanation for the user/developer arises I take it as a sign that my implementation probably isn't as good as it should be. Not saying this be easy, though. I see three issues with the current approach (apart from the fact that documentation is lacking):

• The variable/function could have a more expressive name. Which one? It's hard to deduce what "allowed hours" really means in the context of the library but this may be subjective.
• allowedHours being in UTC is not ideal. The library isn't fully timezone-aware and where it tries to be in the examples (e.g. https://github.com/ThingPulse/esp8266-weather-station/blob/master/examples/WeatherStationDemo/WeatherStationDemo.ino#L54-L55) it's overly simplistic. We have (open-source) applications that use this library which do have proper timezone support (-> https://github.com/ThingPulse/esp8266-weather-station-color/blob/master/settings.h#L75). However, if you configure a timezone for the application somewhere, it's certainly unexpected that not all time-related operations or settings respect it.
• The library should hide that it actually only supports the 3h intervals {0, 3, ...} for allowedHours. It should treat this as an implementation limitation currently imposed by the use of the OpenWeatherMap API. Hence, it should allow you to set any 0-23 integer and automatically map it to the nearest forecast window.