Weather Underground resetting forecast date to January

Hi,

I have an issue with the Weather Underground Binding and hope someone can point me in the right direction.
Since a few days the date for my current weather and forecast items refreshes to January.

My items are configured as follows:

DateTime ForecastTime_t0 "Forecast time [%1$tH:%1$tM]" <clock>  {channel="weatherunderground:weather:local:forecastToday#forecastTime"}

In the logs I can see that the date changes on each refresh (sometimes goes back to the correct date, sometimes sets the January date):

==> /var/log/openhab2/events.log <==
2018-05-16 12:01:02.713 [vent.ItemStateChangedEvent] - CurrentDate changed from 2018-05-16T12:00:02.690+0200 to 2018-05-16T12:01:02.697+0200
2018-05-16 12:01:40.704 [vent.ItemStateChangedEvent] - ObservationTime changed from 2018-05-16T11:50:54.000+0200 to 2018-05-16T11:57:58.000+0200
2018-05-16 12:01:41.092 [vent.ItemStateChangedEvent] - ForecastTime_t0 changed from 2018-05-16T19:00:00.000+0200 to 2018-01-03T11:00:00.000+0100
2018-05-16 12:01:41.231 [vent.ItemStateChangedEvent] - ForecastTime_t1 changed from 2018-05-17T19:00:00.000+0200 to 2018-01-04T11:00:00.000+0100
2018-05-16 12:01:41.092 [vent.ItemStateChangedEvent] - ForecastTime_t0 changed from 2018-05-16T19:00:00.000+0200 to 2018-01-03T11:00:00.000+0100
2018-05-16 12:01:41.231 [vent.ItemStateChangedEvent] - ForecastTime_t1 changed from 2018-05-17T19:00:00.000+0200 to 2018-01-04T11:00:00.000+0100
2018-05-16 12:01:41.378 [vent.ItemStateChangedEvent] - ForecastTime_t2 changed from 2018-05-18T19:00:00.000+0200 to 2018-01-05T11:00:00.000+0100
2018-05-16 12:01:41.529 [vent.ItemStateChangedEvent] - ForecastTime_t3 changed from 2018-05-19T19:00:00.000+0200 to 2018-01-06T11:00:00.000+0100
2018-05-16 12:11:42.159 [vent.ItemStateChangedEvent] - ForecastTime_t0 changed from 2018-01-03T11:00:00.000+0100 to 2018-05-16T19:00:00.000+0200
2018-05-16 12:11:42.335 [vent.ItemStateChangedEvent] - ForecastTime_t1 changed from 2018-01-04T11:00:00.000+0100 to 2018-05-17T19:00:00.000+0200
2018-05-16 12:11:42.521 [vent.ItemStateChangedEvent] - ForecastTime_t2 changed from 2018-01-05T11:00:00.000+0100 to 2018-05-18T19:00:00.000+0200
2018-05-16 12:11:42.676 [vent.ItemStateChangedEvent] - ForecastTime_t3 changed from 2018-01-06T11:00:00.000+0100 to 2018-05-19T19:00:00.000+0200

Any ideas?

Thank you
Christian

Look at what Wunderground is returning when it starts to go to January.

When debugging problems like this you need to work your way up the path from the data source to the display (in this case the logs) and verify at each step that the data is correct. At some point you will find where it is in error.

Hi @rlkoshak,

Thanks - this might be a stupid question, but: how can I check what Wunderground is returning?
All I can see in the logs is the update to January:

ForecastTime_t2 changed from 2018-05-18T19:00:00.000+0200 to 2018-01-05T11:00:00.000+0100

So how can I check which data the binding is fetching?

Ok, I think I answered my own question. I was able to do an API call with my location and it seems that Wunderground is sending the invalid date:

http://api.wunderground.com/api/xxxxx/forecast/q/53.55961976055846,9.904380932540876.xml

<simpleforecast><forecastdays><forecastday><date><epoch>1514973600</epoch><pretty_short>11:00 AM CET</pretty_short><pretty>11:00 AM CET on January 03, 2018</pretty><day>3</day><month>1</month><year>2018</year><yday>2</yday><hour>11</hour><min>00</min><sec>0</sec><isdst>0</isdst><monthname>January</monthname><monthname_short>Jan</monthname_short><weekday_short>Wed</weekday_short><weekday>Wednesday</weekday><ampm>AM</ampm><tz_short>CET</tz_short><tz_long>Europe/Berlin</tz_long></date>

But I have no idea how to solve it now…

Anyone else having this issue?

Well, if the bad data is coming from Wunderground there isn’t much you can do about it. Maybe try a different station.

I changed the location from the longer latitude and longitude to the shorter version in the Thing-configuration.
That seems to have corrected the behavior.

Thanks for pointing me into the right direction - for some reason I did not even considered the API for checking…