[tesla] Adapt binding to changed API from Tesla backend

[kaikreuzer]

Fixes #14894

The Tesla API has removed most endpoints that the binding was using for querying vehicle data.
The only one left is an aggregated call to fetch all data at once.

This PR does the necessary changes.
In my tests, all seems to work well. If enough people report that it works for them as well, this would be a candidate to backport to 3.4.x.

[jlaur]

Thanks for taking care of this!

There are some compiler and SAT warnings introduced, you could have a look at https://ci.openhab.org/job/PR-openHAB-Addons/15443/Static_20Code_20Analysis_20Report/summary_report.html#org.openhab.binding.tesla.internal.protocol.VehicleData.java for example.

For the particular DTO class, you can fix most of them by using the @SerializedName annotation and camelCasing the variables. The missing @NonNullByDefault can be ignored for now, or you could move all the classes to a dto directory to have them excluded from the check.

Most of the compiler warnings are because of changed code lines that already lacked proper null handling, so you can choose to ignore them for now.

Otherwise LGTM!

[kaikreuzer]

@jlaur I intentionally created the new DTO in the same way as the others as I didn't want to introduce a mix of variable naming styles in the same package.
I'd rather suggest to do a clean-up refactoring as an independent PR that then covers all of the DTOs. But in order to have a chance to backport this PR here, I prefer to keep the changes as small as possible.

[jlaur]

I'd rather suggest to do a clean-up refactoring as an independent PR that then covers all of the DTOs. But in order to have a chance to backport this PR here, I prefer to keep the changes as small as possible.

That's sounds sensible.

[hlemmens]

Probably stupid from my side, but when I install the 4.0.0 SNAPSHOT .jar file, I get a "ERROR:HANDLER" and "HANDLER_MISSING_ERROR" on the Tesla bridge. Should I and how should I install a new handler?

[kaikreuzer]

@hlemmens I'd suggest to simply update your openHAB to the latest 4.0.0-SNAPSHOT instance - the fixed binding is then a part of it and you do not need to install it manually.

[theater]

Not sure if you need any feedback Kai, but I tested today and the fix works just fine on 4.0.0.
Cheers,
K.

[kaikreuzer]

@theater Thanks, feedback is always welcome!

[hlemmens]

@kaikreuzer. Many thanks for the fix and the hint. I managed to install the 3.4.4 Snapshot.jar and it works. The old issue [Tesla] Binding going offline #14435 is popping up again. In the 3.4.2 version it was fixed with the commit thijslemmens@24b74c5. Can this fix be integrated as well? Is it already done in the 4.0.0 SNAPSHOT version?

[kaikreuzer]

In the 3.4.2 version it was fixed

Any fix that was in 3.4.2 should also have been done in 4.0.0, since we always only backport fixes, but never only fix things on older releases.

[hlemmens]

I’m afraid the issue with the access token renewal was not fixed in 3.4.2. . The commit I mentioned in previous comment has not been accepted and integrated as far as I know.

[jlaur]

@hlemmens - I don't see any pull requests from you, did you mean to create one?

[kaikreuzer]

If you are referring to this "solution", I would say that it anyhow isn't something to merge, since recreating the http client all the time does not look like a proper way to fix it.

[hlemmens]

This solution Is to my knowledge the only one that seems to work. Since I installed the fix for the changed Tesla API, every 8 hours I lose the connection with the car:
2023-05-05 07:28:40.348 [DEBUG] [sla.internal.handler.TeslaSSOHandler] - Exchanging SSO refresh token for API access token
2023-05-05 07:28:40.380 [DEBUG] [sla.internal.handler.TeslaSSOHandler] - An exception occurred while invoking a HTTP request: 'java.io.EOFException: HttpConnectionOverHTTP@d326f5::DecryptedEndPoint@1aa7a86{l=/my internal ip:39516,r=auth.tesla.com/23.55.96.81:443,OPEN,fill=-,flush=-,to=28816900/0}'

Happy to see a better solution than the existing one.