Tankerkoenig Binding now available on the marketplace

Add-ons Bindings
,
41

Ok,

thanks for your help Jürgen. At least I have an workaround with the HTTP binding. Hopefully I am able to use the binding again with an later release.

best regards René

42

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.

The rule is posted here: Getting fuel prices from Tankerkoenig.de

43

Hi,

I give it a try thanks but still preferred is the binding :frowning:

1 Like
44

The code that the http binding is using is the same as in the tanlkerkoenig binding!
The usage in the http binding:

response = HttpUtil.executeUrl("GET", url, headers, null, null, timeout);

in the tankerkoenig binding:

return HttpUtil.executeUrl("GET", url, urlHeader, null, "", REQUEST_TIMEOUT);

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?

45

It sounds correct to me, strange that it first worked and then stopped working.

46

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.

47

Can it be related to this? OH2 my.openHAB shows offline and nothing in logs

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 :sweat_smile:

48

I believe the http binding is a OH1 binding.

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?

49

Back on the system:
My windows maschine is using java version “1.8.0_111”, so it is not this old problem!

@rene54321 posted to use something like:

Number Diesel “Diesel [%.3f €]” {http=“<[https://creativecommons.tankerkoenig.de/json/detail.php?id=xxxxxxxxxxxxxxxxxxxxxxx&apikey=xxxxxxxxxxxxxxxxxxxxxxxxxx:300000:JS(super.js)]”}

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.

50

Hi,

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)

51

Thanks for the feedback, although I already found that the java version is not the problem. See my post above.

52

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?

53

Maybe @oliver_kuhl can help us with that given that he wrote the RWE smarthome binding.

54

Hi,

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.

The other option is to upgrade to innogy and use the new binding, which can be downloaded here:
http://www.ollie.in/wp-content/uploads/2017/09/org.openhab.binding.innogysmarthome-2.1.0-SNAPSHOT-170823-1.jar
It is currently in code review. You can find more info here:

55

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.

56

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.

1 Like
57

Hi,

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.

58

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).

59

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.

60

Maybe the Tankerkoenig API accepted TLSv1 until recently and now denies it.