Tankerkoenig Binding now available on the marketplace

Add-ons Bindings
,
37

Thanks for the fedback.
Personally I can’t say if there is a solution for your problem, my knowledge isn’t that wide.
I’m not even sure who could help. Searching…

38

Got a hint from @mstormi.

The adjusted setting:

-Djdk.tls.client.protocols=“TLSv1,TLSv1.1,TLSv1.2”

SHOULD be worth a try.
Where exactly did you insert your setting into the karaf file?

[Update]
I tried your setting in the IDE and got the same error! Changing the setting as suggested above removed the error!
Could you try it on your system with both bindings and report back?
…and the question where to put that line in the karaf file is still open (for me), setting the same in the IDE is defferent!

39

@rene54321
Just read your post in the other thread, that it isn’t working for the RWE binding.
?? I’m out of clues ATM, have to go thinking…

40

Did some thinking.
You used the Http binding successfully. At a first glance this binding uses the same HttpUtil as Tankerkoenig. IF THAT IS CORRECT there has to be a difference in the usage, which, when found, could be changed in the Tankerkoenig binding.
But that will take some time.

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