Smarthome: sendHttpRequest - configuring Timeouts and possibly using answers

[binderth]

Expected Behavior

I'm using openHAB2 and in the config-file http.cfg you can define the timeout for http-binding, but the actions in ESH like sendHttpGetRequest are not using those configurations.

in the http-binding config file, I defined a 20sec timeout

# timeout in milliseconds for the http requests (optional, defaults to 5000)
timeout=20000

This timeout should be applied to every function/method of the binding or surrounding , in my case also for sendHttpGetRequest action.

Current Behavior

Current Behaviour is, the timeout doesn't apply to the sendHttpGetRequest call, but uses the hardwired timeout within the class.
I use the function in a rule:

    postUpdate(Nuki_EG_door_locked, OFF) 
    sendHttpGetRequest("http://192.168.xx.xx:8080/lockaction?token=xx&nukiid=xx&action=3")

at first, the item is changed, then the http-request ist sent (in this case a Nuki Smartlock, which holds the latch open for 5secs and needs possibly additional 10secs to open a locked door).
This is the result in the logfile:

2016-11-28 12:13:16.530 [INFO ] [.eclipse.smarthome.model.script.Nuki] - Der Zustand von Nuki wurde geändert: ON
2016-11-28 12:13:21.523 [ERROR] [.smarthome.model.script.actions.HTTP] - Fatal transport error: {}
java.io.IOException: java.util.concurrent.TimeoutException
    at org.eclipse.smarthome.io.net.http.HttpUtil.executeUrl(HttpUtil.java:236)
    at org.eclipse.smarthome.io.net.http.HttpUtil.executeUrl(HttpUtil.java:130)
    at org.eclipse.smarthome.io.net.http.HttpUtil.executeUrl(HttpUtil.java:86)
    at org.eclipse.smarthome.io.net.http.HttpUtil.executeUrl(HttpUtil.java:65)
    at org.eclipse.smarthome.model.script.actions.HTTP.sendHttpGetRequest(HTTP.java:40)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)[:1.8.0_111]
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)[:1.8.0_111]
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[:1.8.0_111]
    at java.lang.reflect.Method.invoke(Method.java:498)[:1.8.0_111]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeOperation(XbaseInterpreter.java:1085)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeOperation(XbaseInterpreter.java:1060)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._invokeFeature(XbaseInterpreter.java:1046)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.invokeFeature(XbaseInterpreter.java:991)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.smarthome.model.script.interpreter.ScriptInterpreter.invokeFeature(ScriptInterpreter.java:114)[127:org.eclipse.smarthome.model.script:0.9.0.201611191809]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:901)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:864)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:223)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:203)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:446)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:227)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:203)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:459)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:243)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:203)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:446)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:227)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:203)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:463)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:243)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:203)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter._doEvaluate(XbaseInterpreter.java:446)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.doEvaluate(XbaseInterpreter.java:227)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.internalEvaluate(XbaseInterpreter.java:203)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.xtext.xbase.interpreter.impl.XbaseInterpreter.evaluate(XbaseInterpreter.java:189)[143:org.eclipse.xtext.xbase:2.9.2.v20160428-1452]
    at org.eclipse.smarthome.model.script.runtime.internal.engine.ScriptImpl.execute(ScriptImpl.java:77)[128:org.eclipse.smarthome.model.script.runtime:0.9.0.201611191809]
    at org.eclipse.smarthome.model.script.engine.ScriptExecutionThread.run(ScriptExecutionThread.java:42)[127:org.eclipse.smarthome.model.script:0.9.0.201611191809]
Caused by: java.util.concurrent.TimeoutException
    at org.eclipse.jetty.client.util.FutureResponseListener.get(FutureResponseListener.java:109)
    at org.eclipse.jetty.client.HttpRequest.send(HttpRequest.java:655)
    at org.eclipse.smarthome.io.net.http.HttpUtil.executeUrl(HttpUtil.java:219)
    ... 35 more

Possible Solution

1. apply the timeout of the config-file to all functions and methods within the binding
2. put in more arguments for those functions, which could be used freely, like sendHttpGetRequest and enable different timeouts depending on Code
3. both! :)

Steps to Reproduce

_1. define timeout >5000ms in config_

1. use sendHttpGetRequest on a page loading longer than 5000ms
2. see timeout in log
3. additionally: interpret the answer of the requested URL

Context

In my case it's nothing broken, as the Nuki Smartlock is receiving the signals and behaving like intended. But there's ugly ERRORs in the logfile. In the Long run, I'd like to have an error-free log, so I can have notifications if there are any with an logfile-analyzer.
So, I could make a workaround using e.g. curl with executeCommandLine, so there's no more ERRORs in the logfile, but if there would be some problem with the Nuki-Call, it's a bit more complicated to get the answer (INFO or ERROR) in the openhab.log - if at all. I must check the system logs for ERRORs of curl also.
Plus, I could parse the answer of the requested URL (in this case the Nuki Smartlock) for a success statement (in this case the answer is JSON and also tells me if the batteries are running low, which could then be updating an item, telling me to change them... ;) )

Your Environment

• Version used: openHAB2, http-binding 1.9
• Environment name and version (e.g. Chrome 39, node.js 5.4, Java 8, ...): JAVA8
• Operating System and version (desktop or mobile, Windows 10, Raspbian Jessie, ...): Rasbian Jessie (openHAB2 Image starter)

[kaikreuzer]

The http binding (which does not exist in ESH at all) is completely unrelated to the action that can be used in scripts. It is hence not possible to re-use or share any configuration here.

So the best option to make the timeout configurable is imho adding additional methods, which accept a timeout parameter.

Would you want to create a PR for that?

[J-N-K]

I can prepare a PR for the timeouts, it's a diligent but routine piece of work. However, I don't get what is requested by

1. additionally: interpret the answer of the requested URL

As far as I can see the response is returned as String.

[binderth]

Hi there,

I just read and misinterpreted the comment on the Action

    /**
     * Send out a GET-HTTP request. Errors will be logged, returned values just ignored.
     *
     * @param url the URL to be used for the GET request.
     * @return the response body or <code>NULL</code> when the request went wrong
     */
    static public String sendHttpGetRequest(String url) {
        String response = null;
        try {
            return HttpUtil.executeUrl("GET", url, 5000);
        } catch (IOException e) {
            logger.error("Fatal transport error: {}", e);
        }
        return response;
    }

I read "just ignored" so, that the responses won't appear anywhere, but in the code I just saw return response;. So No 4 is already in place, I guess! 👍

[J-N-K]

I adjusted the doc, too.