How to force a refresh of a binding? Scheduled update time is too high

I installed some time ago the iCalendar binding and configure it to pick an online disposal calendar.
Until a week ago, it worked perfectly. Since then, however, it no longer gets an update.
While searching for the cause, I found this log entry:
2022-03-07 10:28:49.243 [DEBUG] [ar.internal.handler.ICalendarHandler] - Scheduled update in 106671 seconds
This is approx. 30 hours left. But I set the refresh interval to 360 minutes = 21600 seconds.
Restarting the binding via Karaf Console does not change anything.
Is there any way to change this Scheduled Countdown?
Can I force an update?
Can I see this internal Scheduled Update Timer somewhere?

I had this issue months ago, but before my full error analysis, I ran into a problem with the SD card and had to reinstall my system.

Will appreciate any tips.

Not sure if it will help but I would either change thing configuration (e.g. change refresh from 21600 to 60 seconds, save thing, wait, and change back) or disable & enable the thing again

1 Like

You are seeing the next scheduled update of the channels. That is a different timer from the download of a calendar. So the output is expected. If you calculate, the time printed there should be exactly the beginning or end of an event.

1 Like

Interesting. Yes, if I add the seconds to the current time, then the end time of the current event comes up.

OK - so how can I see when and what the iCalendar Bridge picks up from the target URL? Maybe that’s where the error is.

You’ve already got DEBUG on your binding, what doesn’t that tell you?

@rossko57 - Thanks for pushing me in this direction.
In openhab.log DEBUG of icalendar binding shows me every 6 hours a timeout:

2022-03-07 19:22:50.481 [WARN ] [g.icalendar.internal.handler.PullJob] - Download of calendar timed out (waited too long for headers).
2022-03-07 19:22:50.486 [DEBUG] [g.icalendar.internal.handler.PullJob] - TimeoutException message is: null
2022-03-08 01:23:50.491 [WARN ] [g.icalendar.internal.handler.PullJob] - Download of calendar timed out (waited too long for headers).
2022-03-08 01:23:50.495 [DEBUG] [g.icalendar.internal.handler.PullJob] - TimeoutException message is: null
2022-03-08 07:24:50.500 [WARN ] [g.icalendar.internal.handler.PullJob] - Download of calendar timed out (waited too long for headers).
2022-03-08 07:24:50.502 [DEBUG] [g.icalendar.internal.handler.PullJob] - TimeoutException message is: null
2022-03-08 13:25:50.506 [WARN ] [g.icalendar.internal.handler.PullJob] - Download of calendar timed out (waited too long for headers).
2022-03-08 13:25:50.513 [DEBUG] [g.icalendar.internal.handler.PullJob] - TimeoutException message is: null

Every 6 hours (=360 minutes) is exactly the interval I defined.

Downloading of the URL within browser and cURL works as expected.

How can I deeper analyse why the icalendar binding run in timeout?

Other bindings may also not work when using http connections in that state. A code based workaround is in progress. Until its ready, the only workaround is to restart openhab.

The state is caused by a once broken request. The bridge has a channel showing the last successful pull, so you are able to detect the broken state.

@damihe Thanks for the short explanation.

After an openHAB restart, retrieving the calendar data works again.

Can I leave a subscription somewhere to be notified when the code-based workaround is available?

OH 3.3 is the planned release containing a try for a fix. See this PR for technical details. It is already merged, so you may try a snapshot build. Some feedback in the pull request (not here please!) would be nice e.g. if with the current version the download breaks after a day typically, it should work at least 3 or 4 days before it’s a “success”. I was not able to reproduce the issue so external impressions are required.