The things stopping after 24 to 36 hours and go to offline
This time I saw the following message:
ERROR: could not extend file “base/16384/1700287”: Auf dem Gerät ist kein Speicherplatz mehr verfügbar HINT: Check free disk space.
The disk has got ca. 500 GB free.
Must be space from openhab
Please give some more details on this problem you observed.
What kind of system (RaspberryX or…)
Installation type (openhabian, manual installation or…)
Please show complete error message ( from reading the posted log, I would not correlate with tankerkoenig )
What does PaperUI show as a message for the things that went offline?
That was the Message from paperui. First there was status uninfitialized, then these message appears behind main thing.
Using │ 2.5.0.201902190011 of tankerkönig, newer snapshots has other problems.
System is ubuntu 18.04 Lts newest version, with newest java jdk 8
2019-02-23 14:48:04.919 [hingStatusInfoChangedEvent] - ‘tankerkoenig:station:WebserviceName:AviaNk’ changed from UNINITIALIZED to UNINITI2019-02-23 14:48:04.921 [hingStatusInfoChangedEvent] - ‘tankerkoenig:webservice:WebserviceName’ changed from OFFLINE (COMMUNICATION_ERROR): ERROR: could not extend file “base/16384/1700287”: Auf dem Gerät ist kein Speicherplatz mehr verfügbar
HINT: Check free disk space. to UNINITIALIZED
That’s the message from event log, no messages from openhab for the binding
Not easy to post from handy. The Messetage before was: no valid response from the web request
I understand the problem, however you seem to be able to look onto your system from elsewhere. Since moving to a highspeed internet-connection I am missing that (no VPN due to a DualStackLite connection).
Since I was observing a problem also (no updates since thursday, however all things remain online) I asked Tankerkönig.de.
The answer (in german) read something like: “The use of a module in iobroker, which has a problem and which which is used by many users, cause the server to be overloaded.
The users in question have been written to and asked to use an updare of that module. That overload situation will exist until all users of that module did the update.”
So I have to wait for further updates as well!
So, to the best of my knowledge, the observed problem is NOT caused by the openhab Tankerkoenig-binding and it is affecting ALL installations (snapshot, milestone and stable)!
Users of the openHAB binding are easily identified by Tankerkoenig since a specific “user-agent” is set as was requested by Tankerkoenig when creating the binding! Reading the issue report on that one I feel realy glad for having a specific user agent already.
Original Mesage text.
Hi,
die Mail geht an alle, die aktuell Probleme mit dem Spritpreisbezug unserer API haben.
Ursache ist ein Modul, das in ioBroker verwendet wird:
https://github.com/Pix---/ioBroker.tankerkoenig
ein Bug in dieser SW, die ziemlich verbreitet ist, sorgt dafür, dass unser Server mit Anfragen überlastet wird.
Falls Du das Modul installiert hast: bitte umgehend deaktivieren und eine gefixte Version (2.0.5 oder höher) installieren.
An alle anderen: bis alle ioBroker Clients abgeschaltet, bzw. durch eine neue Version ersetzt wurden, wird es diese Probleme geben - ich kann leider nicht sagen, wie lange das dauert. Die Verursacher wissen jedenfalls Bescheid
In case you believe your observed problem is different:
The initial error message (“No valid response from the web-request!”) is coming from the binding in case of an recieved empty message from tankerkoenig. Due to such a return all things wil go offline. However the scheduled job to request such returns is still running, hence the things should come back ONLINE if a complete return is revieved (I’m keeping my fingers crossed). Since the failure situation is still on, a following return might be empty again, causing all to start over again. That might be the case for my system (showing online ATM, but might have been OFFLINE before).
Nächstes mal schreibe ich in deutsch 
Thanks for information. Think this is solved here.
Bitteschön.
Could you please mark the thread as resolved AND change the topic to “Problems with Addon Tankerkönig”
Solution allready marked, title changed now too
@Jensh Could you tell me if it is working again on your side? I only get a response on the daily Details request. But I’m still away and can’t look into the logs.
I don’t looked to the details too, because had been away some days too.
Restarted openhab this morning by other reasons and at the moment it looks good
Thanks, however the initial report will be from a Details request. The frequent Prices update is the one in question.
For me it was only restart the binding via Karaf.
I got several updates so far
Thanks again. In this case a restart of the periodic request seems to be necessary (should not be that way).Such could be done by changing the time-intervall. A restart of the the bundle or openHAB in total would do also (but not needed). Since I can’t do such from elsewhere I am stuck.
But I’m glad the service is runnung for you.
No VPN connection to your home?!? 
Nope. As said before I have a new ISP. Great speed but IPv6 DualStackLite (so no real usable IPv4 adress, hence no VPN 
).
And VPN over IPv6 doesn’t work?
Back on my LAN, restarted the Bbundle via Karaf and all is working again.
Will have a deeper look into the logs in order to find the reason why the scheduled job got cancelled.
Additionally, the reason why I couldn’t restart the scheduled job by simply changing the timestep for the Webservice was my FILE-based set up. If I would have done it via PaperUI such change would have been possible via myopenhab.org.
Think on an error a job should retry on its own in getting longer Intervalls
Something like that is already implemented, however only in “known” specific cases. For example, in case of a banned account (Tankerkoenig might do that) the job should stop. So I can only reschedule if the case is known AND wanted.
In all cases where the user SHOULD take a look, the restart of the bundle or the sole change of the update time-intervall will restart the job. IMHO such is acceptable.