A little note on your usage of the Http binding. You are calling the details script, which in turn is NOT suggested by tankerkoenig for frequent price-updates.
I havenāt tried it using a rule with your special TLS setting. If a rule would be working, you could use mine. I had it with the opening - time mode included (posted a couple of month ago, Iād have to search for it). Since OH2.1 is a bit more picky on syntax there might be some hickups, but it was running.
I tried to test it in the tankerkoenig binding with ānull,nullā also, finding it working with the setting of
-Djdk.tls.client.protocols=TLSv1
While trying to confirm that this change was the cause, I couldnāt raise the error again! Not without the original usage of the HttpUtil, nor with any setting. ???
Am I doing it correct in Eclipse,
I did add the ā-Djdk.tls.client.protocols=TLSv1ā to the end of the āVM Argumentsā on the āDebug Configurationsā window, Tab ā(x)=Argumentsā.
Anybody? @martinvw?
Thanks for the feedback.
My question for you was, did I correctly put in the āTLSā setting into Eclipse.
As @rene54321 reported while using the setting (TLSv1) set into the Karaf file he wasnā t to use the tankerkoenig binding. However using the Http binding to do the request works for him.
I checked both codes are using HttpUtil for the request.
When trying to force the error (not working Http request) using the setting as stated initially the error appeared as posted. However after adding the Http binding the error disappeared, even after uninstalling the Http binding.
If I did the setting correctly in the IDE I will do further checks regarding this topic.
Another option is that the http binding configures something, but I cannot find the sources of http binding, do you have an idea in which sub project they live
I guess I found MY stupid mistake. This setting needs to be added a the end of the existing settings at the VM arguments WITH a space before it!
Iāll have to continue the search tonight, , so far I couldnāt get it to work with the http binding.
Additionally: Since I did the checks on my Windows maschine (from which I never connected OH to my.openhab) that could be a valid point! (I at work now and canāt check. @rene54321 could you check which Java Version you have on your system?
That will call the openhab1 http binding which uses a httpUtil with the package āorg.openbab.io.net.httpā, while Iām using a httpUtil with a package of āorg.eclipse.smarthome.io.net.httpā. The one from openhab is using an āorg.apache.commons.httpclientā while the eclipse one uses the jetty versions.
Iād say the reason that it works with the http binding is just this difference. However that doesnāt solve the problem that RWE-Smarthome and Tankerkoenig are not working in paralell.
Iām not sure if the differences of those httpUtils (besides the different httpclient) are intended that way.
I use the following version:
java version "1.8.0_101"
Javaā¢ SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpotā¢ Client VM (build 25.101-b13, mixed mode)
I did some more thinking and research:
The problem is caused by the OH1 binding RWE smarthome ( it needs TLSv1 to used solely ). Setting the TLS version for the whole OH system has negative effects to other (OH2 ) bindings.
RWE smarthome uses a different Http client then the one used by OH2 bindings.
A solution COULD be to change the RWE binding in order to enforce to sole use of TLSv1 within the binding ( not for the whole system). That ould only be done by a person that holds those components (for testing) and that can code such a change.
A change of a OH2 binding is IMHO no solution. @martinvw: Assuming my observation and conclusion is correct, should that be noted somehow in the Readme of the RWE smarthome binding?
you are right - if you set TLSv1, other bindings may have problems. The successor innogy SmartHome binding therefore does not work together with the RWE binding either. At the times I wrote the RWE binding, this was the easy and also given way by one guy that initially did a proof of concept. If anyone knows how to do it, help is greatly appreciated.
Thanks for the feedback.
If this binding works for the RWE hardware as the old binding, why isnāt it mentioned in the Readme?
My suggestion was to put something like the following into the Readme of RWE:
The setting of TLSv1 could have side-effects on other bindings using web-requests.
Yes, Iāll add a comment to the RWE binding readme. The innogy binding works fine with the RWE hardware, but needs the firmware to be updated to the new innogy system.
I like to stay at the RWE binding as this is not cloud based as the Innogy one. Maybe there is a way to only use TLS1 for the RWE binding but an higher version for all other bindings as JĆ¼rgen suggested. I still dont understand what has changed as the Tankerkoenig Binding was working perfectly in the older OH2 snapshot release.
Regarding the changes in the Tankerkoenig Binding, IMHO there hasnāt been a change in the use the Http request since the binding was initially released.
That doesnāt say that your statement is wrong, the change might be somewhere deeper and the sole usage of an older release of the binding might not help.
The fact that it still works using the Http binding is caused by the usage if a different Http client ( which should not be used in OH2 bindings).
Yes, thatās a reason. I think there is a way to set the http client in the binding to use TLSv1, but as I simply reused the code from another developer, I am not sure how to do it and do not have the time right now to dig deeper into it.
The observation points that way, however as stated above the code in the Tankerkoenig binding doesnāt have anything in that direction.
I have also used a code package (httpUtil) as suggested for such requests. The technology behind it is above my knowledge.
I can only ASSUME that a change of the HttpUtil or code even deeper in jetty has been changed in a way that prevents the use of TSLv1.