Suddenly AVM Binding can no longer connect to Fritz!Box

  • Platform information:
    • Hardware: Intel Nuc NUC7CJYH Intel(R) Celeron(R) J4005/8GiB Systemspeicher/500GB Samsung SSD 860
    • OS: Ubuntu 22.04.3 LTS jammy
    • Java Runtime Environment: openjdk version “17.0.9” 2023-10-17 LTS OpenJDK Runtime / Environment Zulu17.46+19-CA (build 17.0.9+8-LTS) / OpenJDK 64-Bit Server VM Zulu17.46+19-CA (build 17.0.9+8-LTS, mixed mode, sharing)
    • openHAB version: openHAB 4.1.0

I started seting up openhab with version 4.0.x (don’t rember x) and installed the AVM binding and some other things. Then I added my han-fun items and everything went well.
Some days ago I updated to OH4.1, that means I run sudo apt-get update && sudo apt-get dist-upgrade and got the new openhab version. (Btw, this is the normal update route?)

Today the AVM binding to my fritz!box stopped connecting :" Status: OFFLINE COMMUNICATION_ERROR FRITZ!Box does not respond.". I tried to disable/enable the thing without luck. The delete the thing and added it again from the inbox. No luck again. Interestingly the han-fun channels do not show up also. The thing code is:

UID: avmfritz:fritzbox:e0bbd4b2d3
label: FRITZ!Box
thingTypeUID: avmfritz:fritzbox
configuration:
  syncTimeout: 2000
  password: <password>
  protocol: http
  asyncTimeout: 10000
  ipAddress: 198.168.178.1
  pollingInterval: 15
  user: <user>
channels:
  - id: incoming_call
    channelTypeUID: avmfritz:incoming_call
    label: Eingehender Anruf
    description: Zeigt Informationen zu anrufender und angerufener Telefonnummer an
      ("%2$s" anrufende Telefonnummer, "%1$s" angerufene Telefonnummer).
    configuration: {}
  - id: outgoing_call
    channelTypeUID: avmfritz:outgoing_call
    label: Ausgehender Anruf
    description: Zeigt Informationen zu angerufener und genutzter Telefonnummer an
      ("%1$s" angerufene Telefonnummer, "%2$s" genutzte Telefonnummer).
    configuration: {}
  - id: active_call
    channelTypeUID: avmfritz:active_call
    label: Aktiver Anruf
    description: Zeigt Informationen zur bestehenden Verbindung an ("%1$s" anrufende
      Telefonnummer, "%2$s" ist leer).
    configuration: {}
  - id: call_state
    channelTypeUID: avmfritz:call_state
    label: Anrufzustand
    description: Zeigt an, ob eine Anrufaktivität stattfindet.
    configuration: {}
  - id: apply_template
    channelTypeUID: avmfritz:apply_template
    label: Vorlage anwenden
    description: Ermöglicht die Anwendung einer vordefinierten Vorlage.
    configuration: {}

events.log:
events.log (26.7 KB)

The question is: “What can I do?”

  • did you try to clean the cache ?
  • you may try to set the binding to debug/trace level to check for more debug information and provide the openhab.log afterwards
  • was there an update on the Fritz!Box ?

That depends. In case you have openhabian-config you can use openhabian-config to do the update but in the backgroup the same / or similar command will be executed.
The way you did it is ok/correct/is the linux way to do the upgrade.

  • did you try to clean the cache ?

No, but did it now → No change

  • you may try to set the binding to debug/trace level to check for more debug information and provide the openhab.log afterwards

Not sure were to change this. I tried "Einstellungen > AVM Fritz!Box Binding > Drop down menu > Trace > Save → the events.log only shows [INFO ] see:

2024-01-05 18:34:47.996 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_178_1' changed from UNKNOWN to UNINITIALIZED                                 2024-01-05 18:34:48.003 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_178_1' changed from UNINITIALIZED to UNINITIALIZED (DISABLED)                2024-01-05 18:34:54.819 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_178_1' changed from UNINITIALIZED (DISABLED) to INITIALIZING                 2024-01-05 18:34:54.823 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_178_1' changed from INITIALIZING to UNKNOWN 
  • was there an update on the Fritz!Box ?

No, Last update was on 07.09.2023. Version 7.57.

The way you did it is ok/correct/is the linux way to do the upgrade.

Ok. That’s clear then.

I now deleted all items, the Fritz!Box thing, the AVM Binding and tried to re-install. But with no success.

Did you check the /var/log/openhab/openhab.log file. That file should contain the debug/trace information.

Did you check the /var/log/openhab/openhab.log file. That file should contain the debug/trace information.

No. Here are the last line of openhab.log:

2024-01-05 19:53:17.957 [TRACE] [amera.internal.onvif.OnvifConnection] - Sending ONVIF request: PullMessages
2024-01-05 19:53:18.455 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.178.44:80/SnapShot_Ch0.jpg
2024-01-05 19:53:18.981 [TRACE] [amera.internal.onvif.OnvifConnection] - ONVIF reply is: <?xml version="1.0" encoding="UTF-8"?><s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:e="http://www.w3.org/2003/05/soap-encoding" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:tns1="http://www.onvif.org/ver10/topics" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tt="http://www.onvif.org/ver10/schema" xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2" xmlns:wstop="http://docs.oasis-open.org/wsn/t-1" xmlns:tds="http://www.onvif.org/ver10/device/wsdl" xmlns:trt="http://www.onvif.org/ver10/media/wsdl" xmlns:tev="http://www.onvif.org/ver10/events/wsdl" xmlns:tptz="http://www.onvif.org/ver20/ptz/wsdl" xmlns:timg="http://www.onvif.org/ver20/imaging/wsdl" xmlns:tan="http://www.onvif.org/ver20/analytics/wsdl" xmlns:ter="http://www.onvif.org/ver10/error" ><s:Header><wsa:Action>http://www.onvif.org/ver10/events/wsdl/PullPointSubscription/PullMessagesResponse</wsa:Action></s:Header><s:Body><tev:PullMessagesResponse><tev:CurrentTime>2024-01-05T19:53:15Z</tev:CurrentTime><tev:TerminationTime>2024-01-05T19:54:15Z</tev:TerminationTime></tev:PullMessagesResponse></s:Body></s:Envelope>
2024-01-05 19:53:18.982 [TRACE] [amera.internal.onvif.OnvifConnection] - Sending ONVIF request: Renew
2024-01-05 19:53:19.454 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.178.44:80/SnapShot_Ch0.jpg
2024-01-05 19:53:20.010 [TRACE] [amera.internal.onvif.OnvifConnection] - ONVIF reply is: <?xml version="1.0" encoding="UTF-8"?><s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:e="http://www.w3.org/2003/05/soap-encoding" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:tns1="http://www.onvif.org/ver10/topics" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tt="http://www.onvif.org/ver10/schema" xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2" xmlns:wstop="http://docs.oasis-open.org/wsn/t-1" xmlns:tds="http://www.onvif.org/ver10/device/wsdl" xmlns:trt="http://www.onvif.org/ver10/media/wsdl" xmlns:tev="http://www.onvif.org/ver10/events/wsdl" xmlns:tptz="http://www.onvif.org/ver20/ptz/wsdl" xmlns:timg="http://www.onvif.org/ver20/imaging/wsdl" xmlns:tan="http://www.onvif.org/ver20/analytics/wsdl" xmlns:ter="http://www.onvif.org/ver10/error" ><s:Header><wsa:Action>http://www.onvif.org/ver10/events/wsdl/PullPointSubscription/PullMessagesResponse</wsa:Action></s:Header><s:Body><tev:PullMessagesResponse><tev:CurrentTime>2024-01-05T19:53:16Z</tev:CurrentTime><tev:TerminationTime>2024-01-05T19:54:16Z</tev:TerminationTime></tev:PullMessagesResponse></s:Body></s:Envelope>
2024-01-05 19:53:20.011 [TRACE] [amera.internal.onvif.OnvifConnection] - Sending ONVIF request: Renew
2024-01-05 19:53:20.056 [TRACE] [amera.internal.onvif.OnvifConnection] - ONVIF reply is: <?xml version="1.0" encoding="UTF-8"?><s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:e="http://www.w3.org/2003/05/soap-encoding" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:tns1="http://www.onvif.org/ver10/topics" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tt="http://www.onvif.org/ver10/schema" xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2" xmlns:wstop="http://docs.oasis-open.org/wsn/t-1" xmlns:tds="http://www.onvif.org/ver10/device/wsdl" xmlns:trt="http://www.onvif.org/ver10/media/wsdl" xmlns:tev="http://www.onvif.org/ver10/events/wsdl" xmlns:tptz="http://www.onvif.org/ver20/ptz/wsdl" xmlns:timg="http://www.onvif.org/ver20/imaging/wsdl" xmlns:tan="http://www.onvif.org/ver20/analytics/wsdl" xmlns:ter="http://www.onvif.org/ver10/error" ><s:Header><wsa:Action>http://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/RenewResponse</wsa:Action></s:Header><s:Body><wsnt:RenewResponse><wsnt:TerminationTime>2024-01-05T19:54:17Z</wsnt:TerminationTime><wsnt:CurrentTime>2024-01-05T19:53:17Z</wsnt:CurrentTime></wsnt:RenewResponse></s:Body></s:Envelope>
2024-01-05 19:53:20.057 [TRACE] [amera.internal.onvif.OnvifConnection] - Sending ONVIF request: PullMessages
2024-01-05 19:53:20.077 [TRACE] [amera.internal.onvif.OnvifConnection] - ONVIF reply is: <?xml version="1.0" encoding="UTF-8"?><s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:e="http://www.w3.org/2003/05/soap-encoding" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:tns1="http://www.onvif.org/ver10/topics" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tt="http://www.onvif.org/ver10/schema" xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2" xmlns:wstop="http://docs.oasis-open.org/wsn/t-1" xmlns:tds="http://www.onvif.org/ver10/device/wsdl" xmlns:trt="http://www.onvif.org/ver10/media/wsdl" xmlns:tev="http://www.onvif.org/ver10/events/wsdl" xmlns:tptz="http://www.onvif.org/ver20/ptz/wsdl" xmlns:timg="http://www.onvif.org/ver20/imaging/wsdl" xmlns:tan="http://www.onvif.org/ver20/analytics/wsdl" xmlns:ter="http://www.onvif.org/ver10/error" ><s:Header><wsa:Action>http://docs.oasis-open.org/wsn/bw-2/SubscriptionManager/RenewResponse</wsa:Action></s:Header><s:Body><wsnt:RenewResponse><wsnt:TerminationTime>2024-01-05T19:54:17Z</wsnt:TerminationTime><wsnt:CurrentTime>2024-01-05T19:53:17Z</wsnt:CurrentTime></wsnt:RenewResponse></s:Body></s:Envelope>
2024-01-05 19:53:20.078 [TRACE] [amera.internal.onvif.OnvifConnection] - Sending ONVIF request: PullMessages
2024-01-05 19:53:20.454 [TRACE] [era.internal.handler.IpCameraHandler] - Sending camera: GET: http://192.168.178.44:80/SnapShot_Ch0.jpg
2024-01-05 19:53:21.101 [TRACE] [amera.internal.onvif.OnvifConnection] - ONVIF reply is: <?xml version="1.0" encoding="UTF-8"?><s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:e="http://www.w3.org/2003/05/soap-encoding" xmlns:wsa="http://www.w3.org/2005/08/addressing" xmlns:tns1="http://www.onvif.org/ver10/topics" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tt="http://www.onvif.org/ver10/schema" xmlns:wsnt="http://docs.oasis-open.org/wsn/b-2" xmlns:wstop="http://docs.oasis-open.org/wsn/t-1" xmlns:tds="http://www.onvif.org/ver10/device/wsdl" xmlns:trt="http://www.onvif.org/ver10/media/wsdl" xmlns:tev="http://www.onvif.org/ver10/events/wsdl" xmlns:tptz="http://www.onvif.org/ver20/ptz/wsdl" xmlns:timg="http://www.onvif.org/ver20/imaging/wsdl" xmlns:tan="http://www.onvif.org/ver20/analytics/wsdl" xmlns:ter="http://www.onvif.org/ver10/error" ><s:Header><wsa:Action>http://www.onvif.org/ver10/events/wsdl/PullPointSubscription/PullMessagesResponse</wsa:Action></s:Header><s:Body><tev:PullMessagesResponse><tev:CurrentTime>2024-01-05T19:53:17Z</tev:CurrentTime><tev:TerminationTime>2024-01-05T19:54:17Z</tev:TerminationTime></tev:PullMessagesResponse></s:Body></s:Envelope>
2024-01-05 19:53:21.102 [TRACE] [amera.internal.onvif.OnvifConnection] - Sending ONVIF request: Renew
2024-01-05 19:56:53.257 [DEBUG] [ery.AVMFritzUpnpDiscoveryParticipant] - discovered on /192.168.178.38
2024-01-05 19:56:53.257 [DEBUG] [ery.AVMFritzUpnpDiscoveryParticipant] - discovered: AVM Berlin FRITZ!Box 7490 7490avm (FRITZ!Box 7490) at 192.168.178.1
2024-01-05 19:56:53.259 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'avmfritz:fritzbox:192_168_178_1' to inbox.
2024-01-05 19:58:48.782 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'avmfritz:fritzbox:192_168_178_1' takes more than 5000ms.
2024-01-05 20:00:08.519 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'avmfritz:fritzbox:192_168_178_1' takes more than 5000ms.

And the last lines of events.log:

2024-01-05 19:56:44.460 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_178_1' changed from UNKNOWN to REMOVING
2024-01-05 19:56:44.462 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_178_1' changed from REMOVING to REMOVED
2024-01-05 19:56:44.464 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_178_1' changed from REMOVED to UNINITIALIZED
2024-01-05 19:56:44.470 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_178_1' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
2024-01-05 19:56:45.109 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sensor_Schildkrote__Temperature' changed from 7.38 °C to 7.64 °C
2024-01-05 19:56:53.259 [INFO ] [openhab.event.InboxAddedEvent       ] - Discovery Result with UID 'avmfritz:fritzbox:192_168_178_1' has been added.
2024-01-05 19:57:10.656 [INFO ] [openhab.event.InboxRemovedEvent     ] - Discovery Result with UID 'avmfritz:fritzbox:192_168_178_1' has been removed.
2024-01-05 19:57:10.659 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_178_1' changed from UNINITIALIZED to INITIALIZING
2024-01-05 19:57:10.663 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_178_1' changed from INITIALIZING to UNKNOWN
2024-01-05 19:57:10.663 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_178_1' changed from UNKNOWN to OFFLINE (CONFIGURATION_ERROR): The 'password' parameter must be configured to use the AHA features.
2024-01-05 19:57:21.254 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_178_1' changed from OFFLINE (CONFIGURATION_ERROR): The 'password' parameter must be configured to use the AHA features. to UNKNOWN
2024-01-05 19:58:40.260 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_178_1' changed from UNKNOWN to UNINITIALIZED
2024-01-05 19:58:40.268 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_178_1' changed from UNINITIALIZED to UNINITIALIZED (DISABLED)
2024-01-05 19:58:43.774 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_178_1' changed from UNINITIALIZED (DISABLED) to INITIALIZING
2024-01-05 19:58:43.780 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_178_1' changed from INITIALIZING to UNKNOWN
2024-01-05 19:59:44.400 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'ipcamera:onvif:19216817844' changed from ONLINE to UNINITIALIZED
2024-01-05 19:59:44.415 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'ipcamera:onvif:19216817844' changed from UNINITIALIZED to UNINITIALIZED (DISABLED)
2024-01-05 19:59:53.227 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_178_1' changed from UNKNOWN to UNINITIALIZED
2024-01-05 19:59:53.236 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_178_1' changed from UNINITIALIZED to UNINITIALIZED (DISABLED)
2024-01-05 20:00:03.510 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_178_1' changed from UNINITIALIZED (DISABLED) to INITIALIZING
2024-01-05 20:00:03.516 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'avmfritz:fritzbox:192_168_178_1' changed from INITIALIZING to UNKNOWN
2024-01-05 20:01:43.866 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sensor_Schildkrote__Temperature' changed from 7.64 °C to 7.38 °C

Unfortunately, that doesn’t help me.

Put the trace level back to info level if your not actively trying to fault find an issue

Put the trace level back to info level if your not actively trying to fault find an issue

You are right, I’m trying to get my camera working with the ipcamera binding. I didn’t understand everything with it but I’m getting closer.

Set the level back. Nevertheless, the previously working AVM binding didn’t come back.

I now uninstalled openhab (2 time) completly und reinstalled it. Fritz!Box shows up again. Let’s see how long it will work.

Problem could also caused by the FritzBox itself that may block the login due to invalid password, too many retries and whatsoever.

I suggest to check/verify by : Stop openHAB, reboot FritzBox & start openHAB.
One could also try to remove en re-install the thing with a different userid/password (as already defined on the FritzBox).

If problems persist, check on FritzBox for any state of login of your openHAB userid. One may check the advanced-support log via https://fritz.box/support.lua log and search for section “##### BEGIN SECTION ctlmgr_sessions Active sessions” to check for related sessions.
To simplify this, I suggest to use/define a userid that solely used by openHAB.

The “5000mS” issue is often resolved by a clean stop and then manual start of openHAB.
Note: a “restart” which does do a stop en start, is slightly different and not recommended for this issue.

Prime cause for losing access is that after a while (1 - 1200seconds countdown) the active/established session (SID) time-outs and thereafter Fritz! bundle is no longer (cap)able to reset itself to do a cleanly executed re-login.
Instead of doing a complete re-install, try to re-install the bundle.

1 Like

Thank you for having a look into this topic. After the reinstall it didn’t happen again.

Therefore, for me, the problem is solved.

1 Like

I had a similarr problem with the Simatic S7 binding.
Suddenly the connection was lost. No reboot or what so ever could get it back. I even installed a second openhab server but couldn’t get the connection back.
Sometimes I feel like FritzBox is blocking something. I had such troubles with some other networkdevices some years back.

In the end it was very simple to fix…
I just neded to unplug the ethernet cable from the S7-300 CPU and reconnect it.
No further explaination can be given… :thinking:

tldr: cause is by design how openHAB utilizes the (jetty’ed) httpClient function
When a synchronously execute http-request of an addon Hander is not (yet) completed, all other requests - including those of other add-on - are queued.

Note: long story below is as have observed and tarry-tailed the inexplicable situation.

In general, whenever a httpClient synchronised taskrequest (by the add-on handler) is running, all other and subsquent httpClient requests (including of those of other add-ons) are queued until the blocking httpClient request, is cleanly completed.

In case the “httpClient” cannot be fulfilled (due for example network access, route, reboot or other device failures) this request (java wise) never complete.
When f.e. an endpoint reboots the established session login, is actually cleared while the openHAB handler still uses the previous “sid” which is no longer valid. In case of latest firmware changed FritzBox, this misuse is detected as security-breach and countered by clearing all sessions and imposing a login-delay. This in turn furthermore confuses the state of of mind of an add-on within openHAB.

The so called imposed timeout() function of synchronous executed “httpClient” requests, in our add-on handlers, is merely a timed cancellation of the Java- task-request.
This “timeout” value internally monitored via “java.util”-routine leading to a “java.util.concurrent.TimeoutException”.
The “timeout()” method is by no means nor will it removed of the in-progress executed org.eclipse.jetty.client.HttpClient task from the queue. The situation can become even worse as a http-timeout of unrelated other add-on’s can cause a cascaded failure. This makes debugging of an “unreponsive” add-on situation so difficult. The actual cause may have started routinely somewhere else (in the past).
Note: within the single task’ed java container instance, where the openHAB is executed, a HTTP-request is merely added to a (jetty controlled) ThreadPool-Queue which is dispatched by the central “task-manager”.

As long the in progress being (blocking method) httpClient-task is not cleanly terminated (meaning: orderly removed from the queue), all other and subsequent “httpClient” (in parallel) request are queued too until the “ThreadPool” (I think, default 1024 requests) is simply exhausted.
Note: to bypass this synchronous “block”, one should actually only use httpClient in non-blocking “callback” mode.
This in time can also result in a pool-exhaust but due to its size; not likely nor very quickly. When the http-request Threadpool fills up (by not yet finished requests) openHAB will become unresponsive. It may even cascade in completely other openHAB operations, that uses openHAB threadpools, all of a sudden for example corrupts “mqtt” as it is no longer serviced due to these internet-communication failures.

The bad thing of asynchronous communication is that a “Handler” routine looses the ability to control the required sequence of required http-requests as for example is required to establish a first http-session(id)-login password exchange.

Depending on the situation, the implicit enforced “timeout”-method causes a blocking of “httpClient” request (as handled by jetty) for a specific or all http destinations which can only be resolved by doing a “jetty.stop()/start()”.
In practice this means a full restart of the openHAB instance.
Note 1: doing a stop()/start() in a specific add-on, would also mean that alle other add-ons (handlers) using “httpClient” will be impacted.
Note 2: restarting or adding a ren-ewed bundle by Karaf and so on, is useless as the - restarted (java) - bundle remains in the OSGI-Karaf cache.

This may also explains that at termination of openHAB a whole range of warinng and errors are produced for not yet completed tasks that were already “disposed” from an openHAB point of view but not (yet) by OSGI.