[teslascope] Initial contribution

[psmedley]

Title

• [teslascope] Initial contribution

Description

Binding to support Tesla vehicles via the Teslascope API

[lsiepel]

How does this binding relate to the Tesla binding?
I remember something called the fleetapi.

my actual question is if this should be a separate binding or included in the other Tesla binding

[psmedley]

How does this binding relate to the Tesla binding? I remember something called the fleetapi.

my actual question is if this should be a separate binding or included in the other Tesla binding

This uses the API provided by a 3rd party - https://teslascope.com/ - it is definitely a separate binding.

The problem is that Tesla are going to start charging for accessing their API, and it's problematic as it requires a proxy. Using services like Teslascope (which I already use as a Tesla owner for other reasons) avoids paying Tesla for the use of the API.

[lsiepel]

How does this binding relate to the Tesla binding? I remember something called the fleetapi.
my actual question is if this should be a separate binding or included in the other Tesla binding

This uses the API provided by a 3rd party - https://teslascope.com/ - it is definitely a separate binding.

The problem is that Tesla are going to start charging for accessing their API, and it's problematic as it requires a proxy. Using services like Teslascope (which I already use as a Tesla owner for other reasons) avoids paying Tesla for the use of the API.

And why should it then be a different binding as it is similar to the existing binding, just using a different api?
It controls the exact same cars?

[psmedley]

Whether it's a new binding I guess is a decision for the OpenHAB maintainers. It's an alternative way to access Tesla vehicles using a different API. For anyone buying a new Tesla, the current tesla binding using the legacy API won't work.

But for people with older vehicles, the current tesla binding will work (for now).

[lsiepel]

Whether it's a new binding I guess is a decision for the OpenHAB maintainers. It's an alternative way to access Tesla vehicles using a different API. For anyone buying a new Tesla, the current tesla binding using the legacy API won't work.

But for people with older vehicles, the current tesla binding will work (for now).

@kgoderis as you are codeowner for the tesla binding, can you comment? Or maybe @hakan42 or @kaikreuzer as frequent contributers to that binding.

[kaikreuzer]

It's a tricky question as both perspectives have valid arguments.
Looking e.g. at Philips hue bulbs, these can be used in openHAB through the hue binding, but you can also use them through the zigbee binding or e.g. through MQTT, if you have a zigbee2mqtt server running. So the same hardware device can potentially be supported by different bindings, which would speak for teslascope being a separate binding.

Then again, the thing-types for the cars are likely identical in our case here and they are very extensive (huge number of channels). It feels wrong to duplicate all of this and treat it as something different. (Note: for LED bulbs, we have at least system channel types, which are shared by the different bindings).
Considering that it's "merely" two different web APIs that make the difference here, ideally there should be two "account" bridges (one for Tesla API, one for teslascope API) and all (car) thing types should possible be members of the one or the other; in such a case a user could ideally switch between the APIs simply by assigning a different bridge within the thing.

@psmedley What are your thoughts on this? Do you think something like that would be feasible?

[kgoderis]

I follow Kai's argumentation

It is no different than other bindings where different protocols (ex IP or serial) can be used to access Things in the real world.

If there would be a change in policy by Tesla, then this also the route with least resistance for users to switch over at some point in time

[kgoderis]

Teslascope is using the Fleet API which is aimed at fleet operators/business. Little information exists on when the Owners API will really be phased out. Also, apparently the Fleet API is not compatible with older MCU based cars

Similar discussions are ongoing in other open source initiatives

@kaikreuzer We could investigate whether the openHAB foundation could act as a partner in line with the Tesla terms and conditions, and implement something equivalent to openhabcloud as a shared service

[psmedley]

It's a tricky question as both perspectives have valid arguments. Looking e.g. at Philips hue bulbs, these can be used in openHAB through the hue binding, but you can also use them through the zigbee binding or e.g. through MQTT, if you have a zigbee2mqtt server running. So the same hardware device can potentially be supported by different bindings, which would speak for teslascope being a separate binding.

Then again, the thing-types for the cars are likely identical in our case here and they are very extensive (huge number of channels). It feels wrong to duplicate all of this and treat it as something different. (Note: for LED bulbs, we have at least system channel types, which are shared by the different bindings). Considering that it's "merely" two different web APIs that make the difference here, ideally there should be two "account" bridges (one for Tesla API, one for teslascope API) and all (car) thing types should possible be members of the one or the other; in such a case a user could ideally switch between the APIs simply by assigning a different bridge within the thing.

@psmedley What are your thoughts on this? Do you think something like that would be feasible?

Unfortunately I don't think this is feasible. There is (for example) no way to get a 'Products List' out of teslascope, so I have only a single 'Thing' and all channels are listed whether they are available or not (eg sunroof).

Teslascope implements a subset of the channels the Tesla binding does - most are there but a good number don't exist.

[psmedley]

Teslascope is using the Fleet API which is aimed at fleet operators/business. Little information exists on when the Owners API will really be phased out. Also, apparently the Fleet API is not compatible with older MCU based cars

Similar discussions are ongoing in other open source initiatives

@kaikreuzer We could investigate whether the openHAB foundation could act as a partner in line with the Tesla terms and conditions, and implement something equivalent to openhabcloud as a shared service

The issue will be that likely Tesla will charge for access to the fleet-api. Right now it's free, but this will change "soon". I implemented fleet-api already (https://github.com/psmedley/openhab-addons/tree/tesla-fleet-api) but it relies on a proxy which I'm currently hosting. Owners API should have already been phased out based on their timeline https://developer.tesla.com/docs/fleet-api?shell#announcements-amp-api-changelog "Fleet API is Tesla's official 3rd party API and the only supported API for vehicle interactions. The list of available endpoints can be found at Endpoints and Regional Requirements. Starting April 2024, any vehicle APIs not part of this list will be phased out."

[kaikreuzer]

That's indeed no good news for the tesla binding - it sounds as if it will cease working soon. 😢

Tesla published a new message yesterday:

2024-07-08: Open-source Support
Developers can now create open-source applications through https://developer.tesla.com/, which enables application use without publishing secrets. Open-source applications are limited to the discovery tier and do not use a client secret for token creation.

I've registered an openHAB application, but I am not sure if this will be the right way for us - the discovery plan is said to be only temporary and the only option for open source applications and it has very limited request quotas. But I guess we should create a dedicated issue for that discussion, I am getting out of scope here.

Wrt teslascope: It is ok for me to keep it separate, if the channels are a fairly different set than for the Tesla API as you say. And especially in the light of a soon to be broken Tesla binding, it definitely gives you much less headache, if you can work independently, @psmedley.

[psmedley]

That's indeed no good news for the tesla binding - it sounds as if it will cease working soon. 😢

Tesla published a new message yesterday:

2024-07-08: Open-source Support
Developers can now create open-source applications through https://developer.tesla.com/, which enables application use without publishing secrets. Open-source applications are limited to the discovery tier and do not use a client secret for token creation.

I've registered an openHAB application, but I am not sure if this will be the right way for us - the discovery plan is said to be only temporary and the only option for open source applications and it has very limited request quotas. But I guess we should create a dedicated issue for that discussion, I am getting out of scope here.

Wrt teslascope: It is ok for me to keep it separate, if the channels are a fairly different set than for the Tesla API as you say. And especially in the light of a soon to be broken Tesla binding, it definitely gives you much less headache, if you can work independently, @psmedley.

Thanks Kai.... I do have FleetAPI mostly working too - see https://github.com/psmedley/openhab-addons/tree/tesla-fleet-api but the question around the access to the API stopped me raising a PR....

[lsiepel]

Some more comments.

[lsiepel]

Thank you for this contribution. The core is already in a good shape, so there might not be many iterations.
Did you consider to have a bridge Thing as service with just the apikey, maintaining the connection and multiple vehicle Things with just the publicID with all the channels and so on? This might be more future proof if you have multiple vehicles?!

Happy to consider this - but I have no real idea how to do this. I do have multiple (well 2x) vehicles currently - but I suspect I'm in the minority.

1. The current service Thing can be renamed to vehicle and the thing-type.xml should be adapted to point to the bridge Thing.
   The handler for this service can be cleared from the API calls. Interaction between the bridge and vehicle thing can be both ways.
2. A new service bridge Thing can be created with its own handler. this should control the WebTargets class.

There are multiple bindings with this model, for developer documentation check here: https://www.openhab.org/docs/developer/bindings/#bridges

[psmedley]

Thanks for this. Please correct me if I'm mistaken - but for a bridge to be feasible - wouldn't there need to be an endpoint that uses only the apikey and not the publicID in order to validate the apikey is correct?

Looking at https://teslascope.com/developers/documentation/vehicles there is (currently) no such endpoint.

At some point in the fututet, Tesla scope will move away from an apikey to an oauth login - which should allow a move to a bridge/thing design.

[lsiepel]

Thanks for this. Please correct me if I'm mistaken - but for a bridge to be feasible - wouldn't there need to be an endpoint that uses only the apikey and not the publicID in order to validate the apikey is correct?

Looking at https://teslascope.com/developers/documentation/vehicles there is (currently) no such endpoint.

At some point in the fututet, Tesla scope will move away from an apikey to an oauth login - which should allow a move to a bridge/thing design.

Ok, in that case it is better to leave it as is. I would still opt to rename the service Thing to vehicle. Once the oAuth is imeplmented at teslascope, it can be refactored to use a bridge.

[psmedley]

Ok, in that case it is better to leave it as is. I would still opt to rename the service Thing to vehicle. Once the oAuth is imeplmented at teslascope, it can be refactored to use a bridge.

Done :)

[lsiepel]

Thanks for fixing the comments quickly, LGTM.

Now, you could add your binding's logo to the openHAB website. See https://next.openhab.org/docs/developer/addons/#add-your-add-on-s-logo-to-the-openhab-website-and-the-ui

[psmedley]

Thanks again for your patience and help supporting this addon! I learned a lot from the comments on this binding, as well as the previous bindings that made it into 4.2 :)