Can you just send me the dump, so that I can analyze it myself? Normally I would use the follow TCP-stream to get the summary I can not easily follow it from such a screenshot. I only work with Wireshark a few times per year 
I would, however, say that red-on-black part looks like a problem on the shelly side of things.
Do we also have a TCP-dump with the HttpUtil method? Because I still cannot believe that Jetty would be completely wrong on breaking.
sent you a PM with the dump file
Okay, all knowledge was indeed a bit rusty but refreshed now.
What I see when opening it in Wireshark:
Filtering on tcp.stream eq 18 gives us a successful call to open:
It does a SYN to setup the TCP connection, it fails, so a second later it sends a new SYN, this succeeds and the rest of the communication is handled in 0,1 seconds.
Next one, filtering on tcp.stream eq 19 shows something interesting, the communication initiation starts good and the response is received after 0,02 seconds however the connection is NOT closed, that happens on second 35 of the dump. And could indicate a flaw in the connection handling in the (new) code. The call is to: /shelly/event/shellyswitch25-f36f94/roller/0?type=roller_open does that maybe follow a different path?
Next one, filtering on tcp.stream eq 20 - tcp.stream eq 27 show us failed attempts to setup a connection with the Shelly device. The first one at 5.578 seconds in the dump, later on we do succeed in getting a response on the SYN.
Looking at tcp.stream eq 28 (20 seconds after the first attempt and the connection from stream 19 is still open) our connection succeeds and we receive a response in 0,1 seconds.
Next we have a call to fetch some settings this one takes 0,5 seconds and contains a retransmission because the openHAB system believes the ACK was not received. Most other calls look okay.
So sometimes the shelly does not listen SYN’s so we cannot establish a connection this could be linked to the connection which somehow remains stuck.
When load testing the device I would combine one unclosed transaction with a lot of smaller requests and maybe some settings calls in parallel because they seem heavy.
that’s good input, thanks
I’ll forward your analysis to the Shelly QA team
That is the only strange peace for me, because code-wise if should close the session after each request.
Would it then be that request which caused the timeout error, so that being a request which looks to be waiting for something. Is there a way to find the more likely call to trigger the error for which we have the stacktrace in the Shelly thread.
I think it is not related to a specific URI
Java shows connect timeouts, which would correspond to your analysis
Example 1 from Shelly Binding thread
Example 2 from Shelly Binding thread
Is is the dump from the first example?
Yes it is from the use of the dev-version of the binding and it is the same situation the dump was made. But it is not actually the one the dump was made.
update: Alterco confirmed that this could be related to the firmware. The OS running on the device does not have multi tasking capabilities. Therefore it can’t process multiple requests at the same time, which means while sending data (e.g. their cloud or sending http event updates to the App) a REST API request will not be processed, which then leads into a connect timeout. I’m in discussion with them how to fix this or find a work around. Their recommendation: Use http only to issue commands and Coap to receive status updates, but this requires some extension to their Coap status updates. They confirmed to work on that and have it on the roadmap for version 1.6 - let’s see.
In parallel I’ll include a work around: Retry on connect timeout or connection reset. Not sure if that could be achieved by using HttpUtil or if I need to keep the switch to java.net.HttpURLConnection.
I suppose it should work as well with HttpUtil because the logs did not show anything that should be working completely different with direct JDK http connections. But if it’s needed it’s needed.
how to gwt the info on connect timeout or connection reset from HttpUtil, „Timeout“ as http response strong is very unspecific, I would also prefer the http response code rather than the response string
Then please use the HttpClientFactory it will give you full access to a managed Jetty client. And Jetty is default implementation for openHAB (HttpUtil uses it internally as well)
Hi @martinvw,
I try to switch to HttpClient. I changed the code, Eclipse doesn’t show an error, but when I try to result the dependencies ([Resolve]) I get the following error:
When I run mvn I get
[ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.2.7:verify (karaf-feature-verification) on project org.openhab.binding.shelly: Feature resolution failed for [openhab-binding-shelly/2.5.3.SNAPSHOT]
[ERROR] Message: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=openhab-binding-shelly; type=karaf.feature; version=2.5.3.SNAPSHOT; filter:="(&(osgi.identity=openhab-binding-shelly)(type=karaf.feature)(version>=2.5.3.SNAPSHOT))" [caused by: Unable to resolve openhab-binding-shelly/2.5.3.SNAPSHOT: missing requirement [openhab-binding-shelly/2.5.3.SNAPSHOT] osgi.identity; osgi.identity=org.openhab.binding.shelly; type=osgi.bundle; version="[2.5.3.202003122105,2.5.3.202003122105]"; resolution:=mandatory [caused by: Unable to resolve org.openhab.binding.shelly/2.5.3.202003122105: missing requirement [org.openhab.binding.shelly/2.5.3.202003122105] osgi.wiring.package; filter:="(&(osgi.wiring.package=io.netty.handler.codec.http)(version>=4.1.0)(!(version>=5.0.0)))"]]
[ERROR] Repositories: {
[ERROR] file:/Users/markus/Dev/openhab-2-5-x/git/openhab-addons/bundles/org.openhab.binding.shelly/target/feature/feature.xml
[ERROR] mvn:org.apache.karaf.features/framework/4.2.7/xml/features
[ERROR] mvn:org.apache.karaf.features/standard/4.2.7/xml/features
[ERROR] mvn:org.openhab.core.features.karaf/org.openhab.core.features.karaf.openhab-core/2.5.0/xml/features
[ERROR] mvn:org.openhab.core.features.karaf/org.openhab.core.features.karaf.openhab-tp/2.5.0/xml/features
[ERROR] mvn:org.ops4j.pax.web/pax-web-features/7.2.11/xml/features
[ERROR] }
...
I checked other bindings, but can’t find additional dependencies for feature.xml, pom.xml etc.
I added the following to the HandlerFactory and Discovery handler
import org.eclipse.jetty.client.HttpClient;
import org.eclipse.smarthome.core.thing.binding.BaseThingHandlerFactory;
public class ShellyHandlerFactory extends BaseThingHandlerFactory {
private @Nullable HttpClient httpClient;
...
}
@Reference
protected void setHttpClientFactory(HttpClientFactory httpClientFactory) {
this.httpClient = httpClientFactory.getCommonHttpClient();
}
protected void unsetHttpClientFactory(HttpClientFactory httpClientFactory) {
this.httpClient = null;
}
also adding @Reference HttpClient httpClient to the injected constructor’s parameter list doesn’t work.
Any idea?
Do you have the branch pushes somewhere? Does it work in Maven?
Did you add them to feature.xml:
I would expect the transport-http like in: https://github.com/openhab/openhab-addons/blob/88c489091862784167ce0880c4fbde2d8a0b6c0c/bundles/org.openhab.binding.spotify/src/main/feature/feature.xml
Hi,
those are my dependencies
<feature name="openhab-binding-shelly" description="Shelly Binding" version="${project.version}">
<feature>openhab-runtime-base</feature>
<feature>openhab-transport-http</feature>
<feature>openhab-transport-coap</feature>
<feature>openhab-transport-mdns</feature>
<bundle start-level="80">mvn:org.openhab.addons.bundles/org.openhab.binding.shelly/${project.version}</bundle>
</feature>
My repo ist here (branch shelly_snapshot)
@martinvw I checked my CarNet binding, which is under development. There I also use jetty httpClient and event don’t have openhab-transport-http in feature.xml
I must admit that I didn’t develop bindings from scratch so I did not have to work with such things that often. Maybe one of the other guys knows maybe @J-N-K, @wborn or @hilbrand? Thanks
just found out that it works without the org.openhab.transport-http line - he he
grr, after debuggung was finised (everything is working fine) I tried to generate a new jar and hit the same thing (at least loiks like that):
ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.2.7:verify (karaf-feature-verification) on project org.openhab.binding.shelly: Feature resolution failed for [openhab-binding-shelly/2.5.3.SNAPSHOT]
[ERROR] Message: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=openhab-binding-shelly; type=karaf.feature; version=2.5.3.SNAPSHOT; filter:="(&(osgi.identity=openhab-binding-shelly)(type=karaf.feature)(version>=2.5.3.SNAPSHOT))" [caused by: Unable to resolve openhab-binding-shelly/2.5.3.SNAPSHOT: missing requirement [openhab-binding-shelly/2.5.3.SNAPSHOT] osgi.identity; osgi.identity=org.openhab.binding.shelly; type=osgi.bundle; version="[2.5.3.202003151920,2.5.3.202003151920]"; resolution:=mandatory [caused by: Unable to resolve org.openhab.binding.shelly/2.5.3.202003151920: missing requirement [org.openhab.binding.shelly/2.5.3.202003151920] osgi.wiring.package; filter:="(&(osgi.wiring.package=io.netty.handler.codec.http)(version>=4.1.0)(!(version>=5.0.0)))"]]
[ERROR] Repositories: {
[ERROR] file:/Users/markus/Dev/openhab-2-5-x/git/openhab-addons/bundles/org.openhab.binding.shelly/target/feature/feature.xml
[ERROR] mvn:org.apache.karaf.features/framework/4.2.7/xml/features
[ERROR] mvn:org.apache.karaf.features/standard/4.2.7/xml/features
[ERROR] mvn:org.openhab.core.features.karaf/org.openhab.core.features.karaf.openhab-core/2.5.0/xml/features
[ERROR] mvn:org.openhab.core.features.karaf/org.openhab.core.features.karaf.openhab-tp/2.5.0/xml/features
[ERROR] mvn:org.ops4j.pax.web/pax-web-features/7.2.11/xml/features
[ERROR] }
[ERROR] Resources: {
[ERROR] mvn:com.eclipsesource.jaxrs/publisher/5.3.1
[ERROR] mvn:com.google.guava/failureaccess/1.0.1
[ERROR] mvn:com.google.guava/guava/18.0
[ERROR] mvn:com.google.guava/guava/27.1-jre
[ERROR] mvn:commons-codec/commons-codec/1.6
[ERROR] mvn:commons-collections/commons-collections/3.2.1
[ERROR] mvn:commons-io/commons-io/2.2
[ERROR] mvn:commons-lang/commons-lang/2.6
[ERROR] mvn:commons-net/commons-net/3.3
[ERROR] mvn:de.jollyday/jollyday/0.5.8
[ERROR] mvn:de.maggu2810.p2redist/com.google.inject/3.0.0.v201312141243
[ERROR] mvn:de.maggu2810.p2redist/org.antlr.runtime/3.2.0.v201101311130
[ERROR] mvn:javax.annotation/javax.annotation-api/1.2
[ERROR] mvn:javax.annotation/javax.annotation-api/1.3
The HttpClientFactory is provided by the org.openhab.core.io.net bundle for which you don’t need any additional feature dependencies.
It might work better if you also use constructor injection for the HttpClientFactory not the HttpClient. It’s impossible to inject the HttpClientFactory into the ShellyHandlerFactory using the setter before it has been created using the constructor.