New OH2 binding: Tankerkoenig

This was the part of your log from Tankerkoenig. The part in bold makes me wonder! I would have expected something like: HTTP/1.1" 200 266 “-” “Jetty/9.2.19.v20160908” 0.003
79.238.201.187

That states the use of jetty (the webserver of OH). Presently I have no idea why your system isn’t using jetty for the Tankerkoenig web-requests. I would have assumed that the same would happen with the WeaterUndergrounf binding, but as seen this binding is working.
I’ll have a closer look into both codes in order to spot the differences.

You misunderstood me, because I wrote:

I never saw any request from the TK-Binding in the exported TK-Log. The log you quoted is from my test via desktop browser Epiphany direct on the Pi desktop. I wanted to check, that the connection from the Pi to TK is working and I wanted to exclude any connection errors.

OK, Thanks for pointing that out. I was on wrong path.

I had a look already into the WeatherUnderGround code, the main difference (beside the use of another overload of “executeURL”) is a TimeOut of 30 seconds.
I can’t believe that a further extended TimeOut would help, but I’ll give it a try.
I can’t compile from work, so you have to wait until tonight.

Maybe following information can help. I’ve run tcpdump on my Pi, filtered for the IP of creativecommons.tankerkoenig.de. There is only one line and it looks like the DNS response (*.1.99 is my Router, *.1.48 is the Pi):

13:21:21.291450 IP 192.168.1.99.domain > 192.168.1.48.42147: 12092 1/0/0 A 188.68.35.147 (65)

For comparison here the same with dumping all with the IP of api.wunderground.com. The DNS response is a little bit different and I think, your binding dont even try to open a connection and the binding except before.

13:26:45.824582 IP 192.168.1.99.domain > 192.168.1.48.60560: 47231 3/0/0 CNAME api.wunderground.com.edgekey.net., CNAME e12930.g.akamaiedge.net., A 23.53.166.130 (134)
13:26:45.826121 IP 192.168.1.48.53167 > a23-53-166-130.deploy.static.akamaitechnologies.com.http: Flags [S], seq 3497460722, win 29200, options [mss 1460,sackOK,TS val 25244367 ecr 0,nop,wscale 7], length 0
13:26:45.854850 IP a23-53-166-130.deploy.static.akamaitechnologies.com.http > 192.168.1.48.53167: Flags [S.], seq 3022217929, ack 3497460723, win 28960, options [mss 1460,sackOK,TS val 1122679933 ecr 25244367,nop,wscale 5], length 0
13:26:45.855055 IP 192.168.1.48.53167 > a23-53-166-130.deploy.static.akamaitechnologies.com.http: Flags [.], ack 1, win 229, options [nop,nop,TS val 25244369 ecr 1122679933], length 0
13:26:45.866506 IP 192.168.1.48.53167 > a23-53-166-130.deploy.static.akamaitechnologies.com.http: Flags [P.], seq 1:244, ack 1, win 229, options [nop,nop,TS val 25244371 ecr 1122679933], length 243: HTTP: GET /api/03800101a14c990f/conditions/forecast10day/lang:DE/q/50.95868301,13.43252182.json HTTP/1.1
13:26:45.907002 IP a23-53-166-130.deploy.static.akamaitechnologies.com.http > 192.168.1.48.53167: Flags [.], ack 244, win 939, options [nop,nop,TS val 1122679977 ecr 25244371], length 0
13:26:46.224067 IP 192.168.1.99.domain > 192.168.1.48.38566: 22422 1/0/0 PTR a23-53-166-130.deploy.static.akamaitechnologies.com. (109)
13:26:46.236194 IP a23-53-166-130.deploy.static.akamaitechnologies.com.http > 192.168.1.48.53167: Flags [.], seq 1:1449, ack 244, win 939, options [nop,nop,TS val 1122680313 ecr 25244371], length 1448: HTTP: HTTP/1.1 200 OK
13:26:46.236342 IP 192.168.1.48.53167 > a23-53-166-130.deploy.static.akamaitechnologies.com.http: Flags [.], ack 1449, win 251, options [nop,nop,TS val 25244408 ecr 1122680313], length 0
13:26:46.236466 IP a23-53-166-130.deploy.static.akamaitechnologies.com.http > 192.168.1.48.53167: Flags [.], seq 1449:2897, ack 244, win 939, options [nop,nop,TS val 1122680313 ecr 25244371], length 1448: HTTP
13:26:46.236508 IP 192.168.1.48.53167 > a23-53-166-130.deploy.static.akamaitechnologies.com.http: Flags [.], ack 2897, win 274, options [nop,nop,TS val 25244408 ecr 1122680313], length 0
13:26:46.236628 IP a23-53-166-130.deploy.static.akamaitechnologies.com.http > 192.168.1.48.53167: Flags [.], seq 2897:4345, ack 244, win 939, options [nop,nop,TS val 1122680313 ecr 25244371], length 1448: HTTP
13:26:46.236677 IP 192.168.1.48.53167 > a23-53-166-130.deploy.static.akamaitechnologies.com.http: Flags [.], ack 4345, win 296, options [nop,nop,TS val 25244408 ecr 1122680313], length 0
13:26:46.236851 IP a23-53-166-130.deploy.static.akamaitechnologies.com.http > 192.168.1.48.53167: Flags [.], seq 4345:5793, ack 244, win 939, options [nop,nop,TS val 1122680313 ecr 25244371], length 1448: HTTP
13:26:46.236883 IP 192.168.1.48.53167 > a23-53-166-130.deploy.static.akamaitechnologies.com.http: Flags [.], ack 5793, win 319, options [nop,nop,TS val 25244408 ecr 1122680313], length 0
13:26:46.237108 IP a23-53-166-130.deploy.static.akamaitechnologies.com.http > 192.168.1.48.53167: Flags [.], seq 5793:7241, ack 244, win 939, options [nop,nop,TS val 1122680313 ecr 25244371], length 1448: HTTP
13:26:46.237150 IP 192.168.1.48.53167 > a23-53-166-130.deploy.static.akamaitechnologies.com.http: Flags [.], ack 7241, win 342, options [nop,nop,TS val 25244408 ecr 1122680313], length 0
13:26:46.237296 IP a23-53-166-130.deploy.static.akamaitechnologies.com.http > 192.168.1.48.53167: Flags [.], seq 7241:8689, ack 244, win 939, options [nop,nop,TS val 1122680313 ecr 25244371], length 1448: HTTP
13:26:46.237330 IP 192.168.1.48.53167 > a23-53-166-130.deploy.static.akamaitechnologies.com.http: Flags [.], ack 8689, win 364, options [nop,nop,TS val 25244408 ecr 1122680313], length 0
13:26:46.238765 IP a23-53-166-130.deploy.static.akamaitechnologies.com.http > 192.168.1.48.53167: Flags [.], seq 8689:10137, ack 244, win 939, options [nop,nop,TS val 1122680313 ecr 25244371], length 1448: HTTP
13:26:46.238838 IP 192.168.1.48.53167 > a23-53-166-130.deploy.static.akamaitechnologies.com.http: Flags [.], ack 10137, win 387, options [nop,nop,TS val 25244408 ecr 1122680313], length 0
13:26:46.239062 IP a23-53-166-130.deploy.static.akamaitechnologies.com.http > 192.168.1.48.53167: Flags [.], seq 10137:11585, ack 244, win 939, options [nop,nop,TS val 1122680313 ecr 25244371], length 1448: HTTP
13:26:46.239123 IP 192.168.1.48.53167 > a23-53-166-130.deploy.static.akamaitechnologies.com.http: Flags [.], ack 11585, win 410, options [nop,nop,TS val 25244408 ecr 1122680313], length 0
13:26:46.239511 IP a23-53-166-130.deploy.static.akamaitechnologies.com.http > 192.168.1.48.53167: Flags [.], seq 11585:13033, ack 244, win 939, options [nop,nop,TS val 1122680313 ecr 25244371], length 1448: HTTP: ": 265
13:26:46.239547 IP 192.168.1.48.53167 > a23-53-166-130.deploy.static.akamaitechnologies.com.http: Flags [.], ack 13033, win 432, options [nop,nop,TS val 25244408 ecr 1122680313], length 0
13:26:46.239718 IP a23-53-166-130.deploy.static.akamaitechnologies.com.http > 192.168.1.48.53167: Flags [.], seq 13033:14481, ack 244, win 939, options [nop,nop,TS val 1122680313 ecr 25244371], length 1448: HTTP
13:26:46.239759 IP 192.168.1.48.53167 > a23-53-166-130.deploy.static.akamaitechnologies.com.http: Flags [.], ack 14481, win 455, options [nop,nop,TS val 25244408 ecr 1122680313], length 0
13:26:46.239883 IP a23-53-166-130.deploy.static.akamaitechnologies.com.http > 192.168.1.48.53167: Flags [.], seq 14481:15929, ack 244, win 939, options [nop,nop,TS val 1122680313 ecr 25244371], length 1448: HTTP
13:26:46.239916 IP 192.168.1.48.53167 > a23-53-166-130.deploy.static.akamaitechnologies.com.http: Flags [.], ack 15929, win 477, options [nop,nop,TS val 25244408 ecr 1122680313], length 0
13:26:46.240087 IP a23-53-166-130.deploy.static.akamaitechnologies.com.http > 192.168.1.48.53167: Flags [.], seq 15929:17377, ack 244, win 939, options [nop,nop,TS val 1122680313 ecr 25244371], length 1448: HTTP
13:26:46.240134 IP 192.168.1.48.53167 > a23-53-166-130.deploy.static.akamaitechnologies.com.http: Flags [.], ack 17377, win 500, options [nop,nop,TS val 25244408 ecr 1122680313], length 0
13:26:46.240442 IP a23-53-166-130.deploy.static.akamaitechnologies.com.http > 192.168.1.48.53167: Flags [.], seq 17377:18825, ack 244, win 939, options [nop,nop,TS val 1122680313 ecr 25244371], length 1448: HTTP
13:26:46.240549 IP 192.168.1.48.53167 > a23-53-166-130.deploy.static.akamaitechnologies.com.http: Flags [.], ack 18825, win 523, options [nop,nop,TS val 25244408 ecr 1122680313], length 0
13:26:46.240636 IP a23-53-166-130.deploy.static.akamaitechnologies.com.http > 192.168.1.48.53167: Flags [.], seq 18825:20273, ack 244, win 939, options [nop,nop,TS val 1122680313 ecr 25244371], length 1448: HTTP
13:26:46.240669 IP 192.168.1.48.53167 > a23-53-166-130.deploy.static.akamaitechnologies.com.http: Flags [.], ack 20273, win 545, options [nop,nop,TS val 25244408 ecr 1122680313], length 0
13:26:46.248581 IP a23-53-166-130.deploy.static.akamaitechnologies.com.http > 192.168.1.48.53167: Flags [P.], seq 20273:21636, ack 244, win 939, options [nop,nop,TS val 1122680313 ecr 25244371], length 1363: HTTP
13:26:46.248695 IP 192.168.1.48.53167 > a23-53-166-130.deploy.static.akamaitechnologies.com.http: Flags [.], ack 21636, win 568, options [nop,nop,TS val 25244409 ecr 1122680313], length 0
13:26:56.275531 IP 192.168.1.48.53167 > a23-53-166-130.deploy.static.akamaitechnologies.com.http: Flags [F.], seq 244, ack 21636, win 568, options [nop,nop,TS val 25245412 ecr 1122680313], length 0
13:26:56.325773 IP a23-53-166-130.deploy.static.akamaitechnologies.com.http > 192.168.1.48.53167: Flags [F.], seq 21636, ack 245, win 939, options [nop,nop,TS val 1122690403 ecr 25245412], length 0
13:26:56.325909 IP 192.168.1.48.53167 > a23-53-166-130.deploy.static.akamaitechnologies.com.http: Flags [.], ack 21637, win 568, options [nop,nop,TS val 25245417 ecr 1122690403], length 0

Thanks.
This is a bit above my present knowledge. So I’ll need some time on that.

I have another approach to look for the cause of the problem.
Before I had finished the binding, I’ve create rule to do fetch the prices (My poste rule).
You could try this rule as well and look if that runs through.
The rule does also use the httpUtil (as did the bindings you tested), that way you are testing if the problem might be the https call (WeatherUnderground is http!).

Yes, I’m fishing in the blind!

The last reported problem is further discussed in here.
Anyone who has further problems/request regarding the Tankerkoenig binding is asked to start a new thread!

My problem discussed here in the lines above and in the separate thread is solved, after usage the latest java version from oracle, available for my RaspPi.

But there is an existing problem with the 2.1.0-binding, if the response JSON contains a NULL value instead a price. In this case you have to switch to the snapshot version 2.2.

A big thanks fly out to @opus and @martinvw for the support, hints and patience with me.

1 Like

Hi Dennis,

thank you for your binding.
Actually I have some problem to get it run.
My openhab2 runs on a raspberry pi with based on debian 8.

Now I had connection-problems based on SSL-Errors.
PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
I read your FAQ and installed the startssl-certs but it didn’t work.:disappointed_relieved:

But now I noticed, that tankerkoenig now uses Let’s Encrypt
And that was my problem:
In the default repo there is only JDK 8u65 and the Let’s Encrypt certs are not included in the ca-store of this version.

The solution was to install a newer version of the jdk.
In my case i had to use the ppa-package of WEB UPD8: http://www.webupd8.org/2012/09/install-oracle-java-8-in-ubuntu-via-ppa.html and set this JDK as default.

After a reboot of the machine everything works fine! :grinning:

Maybe you can add this information to your FAQ, this could be helpful for people with the same problem. :grinning:

Which Readme did you look at, the one for OH2.2 does included that in there: https://docs.openhab.org/addons/bindings/tankerkoenig/readme.html#preparation
Note: As long as OH2.2 isn-t releases as stable, the readme can be switched from 2.1 to 2.2.

I looked at https://docs.openhab.org/addons/bindings/tankerkoenig/readme.html#faq for the 2.2-snapshot.
There is the following section:

That indicates a missing certificate for the https-connection on the system. In order to get the required certificate on a Linux-system one needs to perform these steps:
sudo wget http://www.startssl.com/certs/ca.crt
keytool -import -keystore cacerts -alias startssl -file ca.crt

But Tankerkönig now uses a ceritficate from Let’s Encrypt and they are compatible with java 8 since update 101

So the information in the FAQ is out-dated.

It’s required that openhab runs with a JDK which is compatible with the certificates from Let’s Encrypt

Maybe you can add the information, that you have to check the certificate from https://creativecommons.tankerkoenig.de and the keystore of the java version, if you have any connection problems.

Ah, you were talking about that!
My comment was referring to the new part of the readme that states the requirement for a java version newer then 1.8.0_101-b13 .
That the observed problem with a missing ssl certificate is obsolete when using a newer java version was/is not obvious to me. I’ll try to have a look into that.
Thanks for the input.

[Edit]
IMHO the way to get a/the certificate is a described in the readme, there is no way to get it from Tankerkoenig direct.
Does the use of an actual java version in some way automatically load the certificate without any user interaction ? I would need a completely clean system with an old java version to test that.
As long as such can be confirmed I think that FAQ should remain in the readme.

Yes the information how to install a certificate in a keyfile is correct. :+1:
But the information that you should use the certificate from startssl is out-dated, because tankerkoenig now uses a certificate from Let’s Encrypt.

For me was the missing key-information, that you first have to check which certificate tankerkoenig is using and then check if it’s is in your java-keystore.

The way to import the certificate to the java-keystore is in my opinion just a workaround, because if you don’t update your jdk, you will get further ssl-connection-problems in future, when the certificates stored in the keystore expire.

It makes more sense to use a up-to-date jdk, because they update the keystore with the jkd-updates. So you would have no problems to connect to hosts with a certificate from a trusted certificate authory.

For all that, it could make sense to update the FAQ with more detailed information.

I would add the following:

  • Check the certificate of https://creativecommons.tankerkoenig.de
  • Check if it’s in your java-keystore (Maybe add a how-to, i can write somethig if you want)
  • Add the certificate to the right keystore (determine which jdk you are using and where the keystore is stored, detailled how to)
  • OR install a up-to-date java-version
  • restart your machine

Shure that’s not a problem from the binding, but the information would help other users and they can save time. :wink:

Just want to help :wink:

I have to admit that the description on how the load a certificate was only a paste and copy. My knowledge on that topic is very limited. My (false) understanding is/was that the posted description would load the actual certificate (IMHO Let’s encrypt is in use since the end of 2015).

I would really appreciate if you would write something. You can post it here or on github as an issue.

Hey,

I thought about a tutorial and i think this is a good description of the problem and the solution.
Maybe you want to update the FAQ of the version 2.2


-The Station(s) and Webservice stay OFFLINE

Set the logging level for the binding to DEBUG (Karaf-Console command: “log:set DEBUG org.openhab.binding.tankerkoenig”. Create a new Station (in order to start the “initialize” routine). Check the openhab.log for entries like:

 2017-06-25 16:02:12.679 [DEBUG] [ig.internal.data.TankerkoenigService] - getTankerkoenigDetailResult IOException:
java.io.IOException: java.util.concurrent.ExecutionException: javax.net.ssl.SSLHandshakeException: General SSLEngine problem

That indicates a missing certificate of a certificate authority in the certificate-store of your java jdk under which your openhab2 runs.
In most cases it helps that you update to the latest jdk version, because the store of the cacerts are maintained with the java versions.
So you’ll get the missing certificate with the new java version.
After the java-update you have to restart your openhab2.

If you have an old linux installation which has only old java-versions in his package-repositories, you have three possibilities:

  1. Update your linux-system and install the latest java-versions
  2. Install a newer java-version on a different way
  1. Update the store of the cacerts / Import the missing certificate to the ca-store
  • This ist the worst option, because in future you will have problems to access further websites with https, because the certificates of the certificate authorities in the ca-store will expire

If you still want to go the way with the import of the certificate you can use this as a little help:

  1. Check which java package you have installed:
>> sudo dpkg -l | grep java
>> ii  oracle-java8-jdk                    8u65                             armhf        Java™ Platform, Standard Edition 8 Development Kit
  1. Find the ca-store of your jdk
>> sudo dpkg -L oracle-java8-jdk | grep cacerts
>> /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt/jre/lib/security/cacerts
  1. Check which certificate authory has validated the certificate
  1. Import the certificate to the ca-store which you have found
>> cd /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt/jre/lib/security
>> keytool -import -keystore cacerts -alias LetsEncrypt -file ca.crt

The required password is “changeit”.

  1. Restart your server

Do you think this is ok?

Thanks for that.
As stated before my knowledge on that topic is rather limited.
I did some changes in the wording and filed a pull request on Github.

Thanks for this binding.
I will try to get it to run.
I like your:
„Geben ist seliger als Nehmen“ :slight_smile:
I’m not yet able to give a lot back except some personal experience to share in one or the other post.

Anyway, is it also possible to get the cheapest station in a specific range to compare with my local one?

Good Morning and thanks for the feedback!

Some thoughts on your request:

The Tankerkoenig API does have such a request ( so it could be done). This request however returns a ( long) list of stations, showing only the one with the lowest price (for the selected gas type) would be one way. What do you think? What would you like to be presented for that station price, name, adress?

When it comes to coding that request, I like to postpone it a bit.

[Edit]
You made me start thinking about!
Such a request (search all stations in a range and determine the cheapest) would only be made ON CALL, wouldn’t that be better/more correctly implemented in an Action? Although I think doing such would be an overkill (creating an Action which is used by a single special case only).

Thanks for your quick response.

My main goal would be:
Check my standard station’s diesel price and compare with the cheapest one in around few km.
With this I could judge if my stardard stations price is far too high or reasonable (Telegram message if the difference is too high.

It’ not urgent, just consider this please for an future extension.

Hey,
I’m doing this in rules in some way already. I’m watching the price of 4 gas stations and persist the values with influx.
In case the gas price changes a rule is triggered that checks the chapest station and compares it to the minimum value of the last 3 days.
In case gas has the cheapest value since 3 days, I do send a telegram with the price and the station. Only enhancement on the list is putting all stations in a group and work on the group to easily add and remove stations.