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

Add-ons Bindings
1

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.

2

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
3

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
4

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.

5

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

6

@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?

7

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.

8

@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?

9

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.