-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Tesla] Binding going offline #14435
Comments
I think it was fixed with #14300? |
Thanks for the hint. I’m currently running v 3.4.1 of the Tesla binding. Where to find the new version and how to install it? Can’t find it 🥴Regards,Hubert LemmensOp 18 feb. 2023 om 21:11 heeft Wouter Born ***@***.***> het volgende geschreven:
I think it was fixed with #14300?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
It depends on your installation method. openHABian has a tool for it: https://www.openhab.org/docs/installation/openhabian.html#openhabian-configuration-tool |
OK Wouter; thanks
I managed to install the version 3.4.2 of the Tesla binding. Hope this is the right one.
… On 19 Feb 2023, at 09:32, Wouter Born ***@***.***> wrote:
It depends on your installation method.
openHABian has a tool that for it:
https://www.openhab.org/docs/installation/openhabian.html#openhabian-configuration-tool <https://www.openhab.org/docs/installation/openhabian.html#openhabian-configuration-tool>
—
Reply to this email directly, view it on GitHub <#14435 (comment)>, or unsubscribe </~https://github.com/notifications/unsubscribe-auth/ADY6ZUL3N3RZMLL5JFLAWLTWYHLBDANCNFSM6AAAAAAVAOC6NY>.
You are receiving this because you authored the thread.
|
Does it fix your issue @hlemmens? |
Unfortunately not. But I'm not sure the #14300 fix was implemented in v3.4.2. . How to figure out? |
It should be part of it according to the release notes: /~https://github.com/openhab/openhab-distro/releases/tag/3.4.2 |
OK. Thanks. There is another modification ongoing or finalised: #14351. I think it’s not yet in the v3.4.2. Maybe this one can solve the problem? Where to find the .jar file?
… On 21 Feb 2023, at 18:09, Wouter Born ***@***.***> wrote:
It should be part of it according to the release notes:
/~https://github.com/openhab/openhab-distro/releases/tag/3.4.2 </~https://github.com/openhab/openhab-distro/releases/tag/3.4.2>
—
Reply to this email directly, view it on GitHub <#14435 (comment)>, or unsubscribe </~https://github.com/notifications/unsubscribe-auth/ADY6ZULFMCQOS2M5EN7YBU3WYTZDBANCNFSM6AAAAAAVAOC6NY>.
You are receiving this because you were mentioned.
|
The version 3.4.2 doesn't solve this #14435 issue. Any other hints? |
I don't use it myself, maybe @kaikreuzer or @kgoderis can help. |
I can't. For me it is absolutely stable. |
I don’t find any Tesla related messages neither in the openhab.log nor the event.log. But anyhow, 8 hours after re-enabling the bridge it went offline. Weird.
… On 21 Feb 2023, at 20:48, Kai Kreuzer ***@***.***> wrote:
I can't. For me it is absolutely stable.
What might help could be some debug logs from the moment when it goes offline.
—
Reply to this email directly, view it on GitHub <#14435 (comment)>, or unsubscribe </~https://github.com/notifications/unsubscribe-auth/ADY6ZULSI4IP6VZOYWIT3WDWYULXRANCNFSM6AAAAAAVAOC6NY>.
You are receiving this because you were mentioned.
|
You need to enable DEBUG logging. Documentation is here: TL;DR from the console: |
OK; thanks for the help. Debug is on now. Wait another 8 hours to see what happens.
… On 23 Feb 2023, at 10:28, lsiepel ***@***.***> wrote:
log:set DEBUG org.openhab.binding.tesla
|
This is what I could read in the log file: It seems the bridge had some trouble to get a fresh access token. After a few attempts, it succeeded. But often it fails and I have to disable the bridge and then enable it. |
The interesting part: Without the request and response it is hard to say why this end of file exception occurs. The binding does not have a trace logs set to capture those details, so without an updated binding version it is hard to tell what is causing this. It might also be something on the Tesla side, hard to tell. |
I have the same problem since a few month. Already surfaced the problem in the OH forum here. Eventually I wrote a script which restarts the binding every 8hrs which is not nice but works for me. |
I could write some workaround this weekend. That if a eof exception occurs it performs one or two retries. But that is just a workaround the real cause is not yet known. I might also improve the logging. |
Looking into the debug logs, I noticed some commands are no longer accepted (start charging, set charging amps), although the access key has not yet expired. At the same moment, the querying the vehicle seems to work. Here goes a subset of logs: |
Another snippet of logs shows that when the vehicle is not waked up, the charge-start command and set charging amps command fails. After waking up, it works well. Retrying to send the command set_charging_amps. |
It seems to be related to the vehicle state sleeping. the wake-up command doesn't always succeed. |
But restarting the binding always works? |
Not sure. It works when I restart the bridge and the vehicle thing after the access token has expired. I'm not sure I did it before . 2023-02-24 12:42:57.612 [DEBUG] [internal.handler.TeslaAccountHandler] - The access token has expired, trying to get a new one. At this moment, everything works fine. I will test whenever the communication stops. |
Latest logs: no reply on the request for a new access token. 2023-02-25 16:23:35.355 [DEBUG] [internal.handler.TeslaVehicleHandler] - Querying the vehicle, response : 401, Unauthorized |
Maybe waking the car prior to refreshing the token maight help, but i'm to unfamilair with the API and i don;t own such a car, so i think @kaikreuzer or @kgoderis might be of more help to proceed with these logs and a workaround. |
Hope somebody will take the challenge? Personally, I'm not at all familiar with Java and unable to do it. |
@oOMagicOo Would you be so kind to share your script with me? |
Same issue here. Since a restart of the binding always works, could it be that the httpClient is acting up? What if you pass in the httpClientFactory to the TeslaSSOHandler and getting a httpClient every time you call getAccessToken? |
Following changes seem to work for me: in TeslaSSOHandler, in method getAccessToken, create a new httpClient for each call
However, I don't know if creating clients every call is a good idea. There might be better ways but I don't know since I'm not a Java/OpenHab developer. |
@lavanden I implemented your fix for 3.4.4: This is the commit: thijslemmens@851d569 I can make an official PR, but I don't know if it has a chance of getting accepted. |
@thijslemmens It probably only hides the real problem. Switching from the common http client to a 'custom' client is not something i would advice. We should find out why the clients needs to be recreated. What property/circumstances is causing this behaviour with the client that it needs to be restarted? |
I agree. I built this version for @hlemmens so he does not need to manually restart the binding every time. |
@lsiepel , I tried debugging the issue, but I could not get to the root. I'm thinking that the connection with the tesla backend gets dropped after 28800 seconds. |
Previously your logs recorded:
You could try to log the raw request/response to a file and see how the first (binding init) and last (when it crashed) differ. If that leads to nothing, you might also handle the EOFException by retrying / resetting all tokens and retry or something. Is that of any help? I don;t own a Teslo so i can't test, but this would be my aproach i guess. |
Some connection related fixes have been merged after 3.4.4. Not sure if it also affects this issue, But could be usefull to check latest 4.1 snapshot or mile stone. |
Hi guys, |
It's an issue with changed API on Tesla's side, I didn't upgrade and see the same issue. |
see #16318 |
While working on a different PR that also has problems with a hard to reproduce / debug Would be nice if any of you who experience this issue are available to test an updated jar. |
Happy to test, but with the actual binding is not possible to send charging commands to the new Tesla's. Tesla has again changed the protocol for new cars. |
Do you have any details on the change and to what cars / versions / firmware etc it relates? |
You can find some information and an implementation example here: /~https://github.com/teslamotors/vehicle-command/blob/main/README.md And this is the Tesla documentation on this issue: https://developer.tesla.com/docs/fleet-api/getting-started/what-is-fleet-api Hope this can help. I didn't succeed to make a working python program to send controls to my Tesla. |
As i don't own a Tesla, i can only stick to small bugfixes. For an extensive change like this it is better that someone else picks this up. |
Since about a month, my Tesla binding is going offline every 8 hours. It seems to be a problem of getting a new access token once the old one has expired. After manually disabling and enabling the binding, everything works fine for another 8 hours.
Anyone experiencing the same issue? Any solution?
The text was updated successfully, but these errors were encountered: