REST/SSE is broken in Chrome

[chriscolden]

Any updates to an item cause the Offline: waiting for connection to become available message to appear when accessed via chrome.

This is on port 8080 with no reverse proxy. Edge seems fine and I've been unable to produce the issue. Chrome seems to do it on any update. This causes the gui to seemingly hang, until it trys to refresh and the connection is reestablished.

Looking into developer options, there is no events ever received in the EventStream, but clearly its when an update is sent that Chrome displays the Offline message.

[kirantpatil]

Hi,

I am testing SSE with android using cordova.

I am not getting events.

Do you think it is related crome browser of Android since I am using cordova to build android app ?

Thanks.

[chriscolden]

Mine seems to have randomly fixed itself after changing the ip on my openhab server. I dont see why this is related though, but seems to coincide with the only change at the time.

@kirantpatil sorry I cannot add anything to your issue.

[lolodomo]

I just tested Basic UI with Chrome on 2 Android devices (last version of Chrome) and I see no refresh issue. I am running server snapshot 1389. So I don't believe there is a general issue with SSE and Chrome. @chriscolden : please close your issue if you solve it by yourself doing a correct setup.

[kirantpatil]

@chriscolden, thanks.

We found the issue. We had to install the latest Android chrome browser which supports SSE (server sent events).

[chriscolden]

@kirantpatil for me it is chrome on a windows 10 desktop. I keep getting the offline message. This is through nginx and direct on port 8080.

[maggu2810]

@chriscolden Wouldn't it make sense to test without nginx and other non-ESH related software layer between your client and the server? If the problem exists without nginx etc. I would assume it is a bug in the current code base (are you using the master?), otherwise it is not ESH related. Do you agree or do I miss some point here?

[chriscolden]

That's what I'm saying if I bypass nginx and go direct to port 8080 its still doesn't work. Keeps going offline.

Other non esh websites (not hosted on only he pi granted) work fine in chrome.

Chris Colden

On 9 Nov 2018 10:09, "Markus Rathgeb" notifications@github.com wrote:

@chriscolden https://github.com/chriscolden Wouldn't it make sense to test without nginx and other non-ESH related software layer between your client and the server? If the problem exists without nginx etc. I would assume it is a bug in the current code base (are you using the master?), otherwise it is not ESH related. Do you agree or do I miss some point here?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/eclipse/smarthome/issues/6403#issuecomment-437312563, or mute the thread https://github.com/notifications/unsubscribe-auth/ATYYTApAT16NdEYJJMn4lsUJYraBeMPNks5utVRcgaJpZM4X2zLU .

[justClouds]

I experiene the Offline messages too in Chrome with OH 2.4.0. release version.

[justClouds]

Using a very simple sitemap in OH2.4.0.Release with BasicUI, with just a few Items that get updated by the Astro binding, the "Offline"issue can be reproduced with Chrome 71.0.3578.98 on Windows 10 64-bit. There are no errors in the log with that simple sitemap. There is no difference between direct connection to OH instance or via NGINX.

The sitemap used for this test:

sitemap default label="Thuis" { Frame label="Test" { Text item=Current_DateTime label="Datum [%1$tA, %1$td.%1$tm.%1$tY]" icon="sun_clouds" Text item=Sunset_Time icon="sunset" visibility=[Sun_Elevation>=0] Text item=Sun_Elevation icon="sun" visibility=[Sun_Elevation>=0] Text item=Sun_Direction icon="sun" visibility=[Sun_Elevation>=0] } }

Using Edge browser, there are no "Offline" messages but the openhab.log shows errors: `2018-12-30 10:06:19.902 [WARN ] [org.eclipse.jetty.server.HttpChannel] - /rest/sitemaps/default/default javax.servlet.ServletException: javax.servlet.ServletException: A MultiException has 1 exceptions. They are:

1. java.lang.IllegalStateException: ServiceLocatorImpl(__HK2_Generated_211,212,53288936) has been shut down

   at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:88) ~[?:?] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) ~[84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.Server.handle(Server.java:531) ~[84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:352) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:260) [84:org.eclipse.jetty.server:9.4.11.v20180605] at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281) [75:org.eclipse.jetty.io:9.4.11.v20180605] at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) [75:org.eclipse.jetty.io:9.4.11.v20180605] at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) [75:org.eclipse.jetty.io:9.4.11.v20180605] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:333) [87:org.eclipse.jetty.util:9.4.11.v20180605] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:310) [87:org.eclipse.jetty.util:9.4.11.v20180605] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168) [87:org.eclipse.jetty.util:9.4.11.v20180605] at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:126) [87:org.eclipse.jetty.util:9.4.11.v20180605] at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:366) [87:org.eclipse.jetty.util:9.4.11.v20180605] at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:762) [87:org.eclipse.jetty.util:9.4.11.v20180605] at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:680) [87:org.eclipse.jetty.util:9.4.11.v20180605] at java.lang.Thread.run(Thread.java:748) [?:?] Caused by: javax.servlet.ServletException: A MultiException has 1 exceptions. They are:

2. java.lang.IllegalStateException: ServiceLocatorImpl(__HK2_Generated_211,212,53288936) has been shut down

   at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:489) ~[?:?] at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427) ~[?:?] at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388) ~[?:?] at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341) ~[?:?] at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228) ~[?:?] at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service(ServletContainerBridge.java:76) ~[?:?] at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:865) ~[?:?] at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:535) ~[?:?] at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) ~[?:?] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) ~[?:?] at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) ~[?:?] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) ~[?:?] at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) ~[?:?] at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595) ~[?:?] at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) ~[?:?] at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317) ~[?:?] at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:293) ~[?:?] at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) ~[?:?] at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473) ~[?:?] at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564) ~[?:?] at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) ~[?:?] at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219) ~[?:?] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) ~[?:?] at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) ~[?:?] ... 15 more Caused by: org.glassfish.hk2.api.MultiException: A MultiException has 1 exceptions. They are:

3. java.lang.IllegalStateException: ServiceLocatorImpl(__HK2_Generated_211,212,53288936) has been shut down

   at org.jvnet.hk2.internal.FactoryCreator.getFactoryHandle(FactoryCreator.java:106) ~[?:?] at org.jvnet.hk2.internal.FactoryCreator.dispose(FactoryCreator.java:173) ~[?:?] at org.jvnet.hk2.internal.SystemDescriptor.dispose(SystemDescriptor.java:526) ~[?:?] at org.glassfish.jersey.process.internal.RequestScope$Instance.remove(RequestScope.java:532) ~[?:?] at org.glassfish.jersey.process.internal.RequestScope$Instance.release(RequestScope.java:549) ~[?:?] at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:319) ~[?:?] at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305) ~[?:?] at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154) ~[?:?] at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473) ~[?:?] at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427) ~[?:?] at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388) ~[?:?] at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341) ~[?:?] at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228) ~[?:?] at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service(ServletContainerBridge.java:76) ~[?:?] at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:865) ~[?:?] at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:535) ~[?:?] at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) ~[?:?] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) ~[?:?] at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) ~[?:?] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) ~[?:?] at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) ~[?:?] at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595) ~[?:?] at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) ~[?:?] at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317) ~[?:?] at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:293) ~[?:?] at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) ~[?:?] at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473) ~[?:?] at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564) ~[?:?] at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) ~[?:?] at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219) ~[?:?] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) ~[?:?] at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) ~[?:?] ... 15 more Caused by: java.lang.IllegalStateException: ServiceLocatorImpl(__HK2_Generated_211,212,53288936) has been shut down at org.jvnet.hk2.internal.ServiceLocatorImpl.checkState(ServiceLocatorImpl.java:2288) ~[?:?] at org.jvnet.hk2.internal.ServiceLocatorImpl.getServiceHandleImpl(ServiceLocatorImpl.java:629) ~[?:?] at org.jvnet.hk2.internal.ServiceLocatorImpl.getServiceHandle(ServiceLocatorImpl.java:622) ~[?:?] at org.jvnet.hk2.internal.ServiceLocatorImpl.getServiceHandle(ServiceLocatorImpl.java:640) ~[?:?] at org.jvnet.hk2.internal.FactoryCreator.getFactoryHandle(FactoryCreator.java:103) ~[?:?] at org.jvnet.hk2.internal.FactoryCreator.dispose(FactoryCreator.java:173) ~[?:?] at org.jvnet.hk2.internal.SystemDescriptor.dispose(SystemDescriptor.java:526) ~[?:?] at org.glassfish.jersey.process.internal.RequestScope$Instance.remove(RequestScope.java:532) ~[?:?] at org.glassfish.jersey.process.internal.RequestScope$Instance.release(RequestScope.java:549) ~[?:?] at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:319) ~[?:?] at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305) ~[?:?] at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154) ~[?:?] at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473) ~[?:?] at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427) ~[?:?] at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388) ~[?:?] at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341) ~[?:?] at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228) ~[?:?] at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service(ServletContainerBridge.java:76) ~[?:?] at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:865) ~[?:?] at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:535) ~[?:?] at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) ~[?:?] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:146) ~[?:?] at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548) ~[?:?] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132) ~[?:?] at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:257) ~[?:?] at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1595) ~[?:?] at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:255) ~[?:?] at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1317) ~[?:?] at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:293) ~[?:?] at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:203) ~[?:?] at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:473) ~[?:?] at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1564) ~[?:?] at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:201) ~[?:?] at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1219) ~[?:?] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:144) ~[?:?] at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) ~[?:?] ... 15 more`

[lolodomo]

Edge does not use SSE to refresh data so it is expected that you don't see the OFFLINE message. Sorry I can't reproduce immediately because Chrome is not installed on my Windows 10 PC.

SSE is working well with Firefox on my PC.

Please name your sitemap with something else than default and have the file with this name, that is file toto.sitemap containing "sitemap toto label=..." for example.

[lolodomo]

@resetnow : could you please check that in case you have Windows 10 with Chrome installed ?

[chriscolden]

@lolodomo my site map is not called default and file name and sitemap header match.

[justClouds]

@lolodomo using another name and label for the sitemap still gives the offline message whenever an item gets updated (using Chrome). And with Firefox (64.0) I also witness 'offline' messages, both with and without a proxy in between. I just checked and Chrome (71.0.3578.99) on Android 8.0 also shows the 'offline' message.

All with the simple (and renamed) sitemap shown above having only a handfull of items to display.

[lolodomo]

I just installed Chrome Version 71.0.3578.98 (Build officiel) (64 bits) on my Windows 10 PC. I can't reproduce your problem, I got no OFFLINE message and widgets are refreshed as expected.

[lolodomo]

Tested again on my Android tablet with last version of Chrome: no problem for me.

So for me, this is ok on Android 5 and on Windows 10.

Sorry guys but your problem is very probably specific to your setup.

[justClouds]

@lolodomo unfortunate that it is not reproducable by you. Must be configuration dependent somehow, although there are quite some reports over the last year about this issue in the OpenHAB forum (I quickly counted 16 topics).

I noticed (in the Chrome network console tab) that there is a pending eventsource like: <some guid>?sitemap=thuis&pageid=thuis | 200 | eventsource | other | 141 B | Pending.

At DateTime Item refresh it ends (e.g. after 49.3s) and then the Offline message appears. I suspect this is part of normal behaviour but just wanted to mention it.

[lolodomo]

I have to mention that my tests of today were done with server 2.5.0 build 1480.

[justClouds]

I am running 2.4.0. Release. Will try 2.5.0-SNAPSHOT and report back.

[lolodomo]

I don"t think your problem is 2.4 vs 2.5 (I was before on v2.4 snapshots without your problem), maybe more something relative to your specific setup. Have you setup a reverse proxy for example ? Have you something special on your network ? On what hardware is installed openHAB and what java version are you running ? ... etc

[justClouds]

I have NGINX running as reverse proxy, but the behaviour is the same with or without proxy (just verified again).

My network is quite ordinary: the laptop I run this on is connected to a Netgear R8000 router via 5GHz WiFi (speedtest above 400Mbps) which is wired to a Netgear managed switch (60Gbps throughput capable), as is the OH server (an Atom J3455 with 8GB RAM and 250GB SSD running Debian and only OH related stuff like InfluxDB and Grafana).

The Java version is Java 8u192 (Zulu 8.33.0.1-linux64).

[lolodomo]

You have something to check because I think openHAB requires a JRE 32 bits and not 64 bits.

Avoid any reverse proxy in a first time, setup of reverse proxy for openHAB seems to not be very easy and this can directly impact SSE.

[lolodomo]

https://www.openhab.org/docs/installation/

Java 32 bits is recommended at least for ARM platform.

[justClouds]

Yes, it's mentioned for ARM, not Intel and in particular for serial access. Everything else works like a charm on my OH setup, but can't hurt to try...

[chriscolden]

Hi All,

Just looking at my java setup. I have the following

openjdk version "1.8.0_152" OpenJDK Runtime Environment (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 1.8.0_152-b76) OpenJDK Client VM (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 25.152-b76, mixed mode, Evaluation)

Basic setup also.

[chriscolden]

Just upgraded to 2.5.0 and at the moment I'm not having the problem, however I seem to remember it happens after a while of openhab being started. I will report back in a few days once I've had more time to test.

[justClouds]

Running 32-bit Java makes no difference, I'm affraid. I'll wait for @chriscolden to see what 2.5.0 does... ;o)

[lolodomo]

In case it happens only after several days, it would mean that some SSE subscriptions are not released. I already improved that 6 months ago: See #5910 But there is a case (not reproduced by myself) where a device produces a lot of subscription requests. Cf #5957 . Maybe you are in such a case. I made the maximum number of SSE subscriptions a parameter. Cf #5648 . Even if this is not really a solution, you could at least increase this parameter: org.eclipse.smarthome.sitemapsubscription:maxSubscriptions=XX

[vlad-ivanov-name]

I scrolled through the thread and I can't seem to find any mentions of messages in the browser Developer Tools' console (F12). Perhaps there are some Javascript errors?

[vlad-ivanov-name]

I would also check the following: is there any network filter software or browser extension that would snoop the traffic for some reason or another?

[chriscolden]

@justClouds @lolodomo 2.5.0 seems pretty stable at the moment. Been running for a good few days. I noticed that the direct connections on port 8080 were no longer showing the issue on 2.5.0 where I had them previously. However nginx did have the issues still. So I went digging and found the following settings in nginx seem to have solve the issues when connecting via the reverse proxy.

#This deals with the Aggregating issue
    chunked_transfer_encoding off;
    proxy_buffering off;
    proxy_cache off;

#This deals with the connection closing issue
    proxy_set_header Connection keep-alive;
    proxy_connect_timeout 3600;
    proxy_send_timeout 3600;
    proxy_read_timeout 3600;
    keepalive_timeout 3600;

I'll report back if I notice anything strange again, but I think this is resolved for me now, 2.5.0 was the answer.

[justClouds]

@chriscolden great find. I will try that too.

[lolodomo]

So finally it was really only a problem of reverse procy setup ?!

[chriscolden]

@lolodomo no. I had the issue with and without the reverse proxy. in 2.4.X if I went direct to openhab on port 8080 in the browser (no reverse proxy) I had the issue. In 2.5.0 I didn't have the issue when going direct on port 8080, but did still have it when going via the reverse proxy. So two separate issues. It looks like 2.5.0 fixed it for me though.

[lolodomo]

I think there were no change in the way SSE subscriptions areamages.

I suddenly realized that i am very probably using only HTTPS. So if the problem is with HTTP, I could have missed it.

[chriscolden]

Quite possibly. I'm using nginx to do all my ssl at the moment which was the old way of doing it.

[justClouds]

Updating the NGINX proxy settings, given by @chriscolden, seem to have fixed it for me, even on 2.4.0 (although I'm not sure why it happened before without proxy).

[chriscolden]

The issue has resurfaced for me after several weeks of running just fine and there have been no changes to openhab or nginx. I've been able to repeat the issue even when bypassing nginx by going to port 8080 direct.

[mhilbush]

You might want to have a read through this issue.

https://github.com/eclipse/smarthome/issues/4871

[lolodomo]

If it happens after several weeks, it could be because some subscriptions are never released and finally after several weeks, the limit is reached. Can you confirmed that the problem is solved if you restarft your OH server ?

[lolodomo]

The limit is updatable (setting) so a workaround would be to put a bigger value.

[mhilbush]

@lolodomo Don't you get a different message than "Offline: waiting for connection to become available" when the limit is reached?

[lolodomo]

I think you're right, I have probably created a different message for the reached limit.

[chriscolden]

Restarting OH server has resolved the problem. It was definitely the same message being displayed in the browser.