There are about 8 apps in the AppStore whose name follows the "xyz for Tesla" pattern. All these apps follow this naming convention because Apple actually recommended this naming pattern (presumably after rejecting an original name that included "Tesla" -- as they did for my app which used to be called QuickTesla). I suspect all these apps will be subject to this new Apple review team enforcement once they submit an update.
Model S REST API
- Thread starter timdorr
- Start date
-
- Tags
- Model S User Interface
There are about 8 apps in the AppStore whose name follows the "xyz for Tesla" pattern. All these apps follow this naming convention because Apple actually recommended this naming pattern (presumably after rejecting an original name that included "Tesla" -- as they did for my app which used to be called QuickTesla). I suspect all these apps will be subject to this new Apple review team enforcement once they submit an update.
Being able to see the number of free supercharging slots on your phone would be great even if it's provided in Tesla's default app and not through the public API.
Another important and useful feature that's missing from API is OAuth. A lot of users don't trust entering their credentials into a third-party app. OAuth solves that problem.
bmah
Moderator, Model S/X, California Forums
How about official support and documentation? Many of you might not be aware that what's known in the community about the Tesla REST API is the result of a lot of reverse engineering, deduction, and guesswork. Having an official, openly supported API, following commonly-accepted industry practices for documentation and maintenance, would mean a lot in terms of stability for the ecosystem that's built up around it, and that's way more important in the long term than a feature that Tesla could add and remove on a whim. (We've seen that removal, without warning, with the sunroof percentage control and the removal of battery current information.)
My completely uneducated guess is that if you presented a list of requests, as things stand today, the answer would be "we don't officially support that", because, as far as I know, there's no commitment to even maintaining the existing API.
If it were me, I'd first try to get a commitment of support for third-party applications using the API. After that you can talk about adding features.
Bruce.
I agree. I think Tesla so far has tolerated 3rd-party developers' use of the unofficial API. I'm not sure if Tesla sees the value of 3rd-party apps. In fact, 3rd-party developers put a lot of pressure on their servers which is probably why they periodically block requests sent from AWS (haven't tested recently).
Last edited:
Has anyone used this yet to create a simple scheduler to turn HVAC on at certain times? If so, can you share any specifics?
Here is my quick wish list of things to be added or in some cases documented...
sunroof
trunk/frunk
summon
homelink
set calendar (doc'd)
set charge current
set charge time
get energy used and wh/mi
get trip data
send GPS loc to nav system (like Lexus et al)
offer developer/app keys
sunroof
trunk/frunk
summon
homelink
set calendar (doc'd)
set charge current
set charge time
get energy used and wh/mi
get trip data
send GPS loc to nav system (like Lexus et al)
offer developer/app keys
Klaus
Member
- Apr 20, 2013
- 511
- 60
tliving
Member
If you dig in with Apple (which I've done) they actually plan on rejecting all apps that are specific to a single market/vendor unless that vendor (Tesla in this case) submits or approves the app (against Tesla's policy). That means "FooBar" would be rejected if its an app for tesla users only even if it never mentioned tesla anywhere in the app. This is their interpretation of the mysterious PLA 1.2 section. So a name change does not appear to do the job. In theory, this means all third-party apps on the Apple app store will eventually get kicked out. This has already happened for some trying to update their apps and for some others submitting new apps.
Thats pretty disappointing, but I'm sure people will find a way around it. For example I can see people marketing their apps as a "toolbox" for EVs and it supports every car API from Tesla to BMW or Leaf...
tliving
Member
Yes, Apple actually recommended that these apps support multiple vendors to avoid the "single vendor focus" issue. The problem is most other vendors have no API or a much smaller user base. Its also much more work for those small vendors making the apps to do that, plus they may have to buy/drive cars for testing that they would not otherwise want to. The BMW i3 has an undocumented API but a fairly small base, others even less so.
Does this also apply for apps to devices like Hue lighting? So that means that no one can make an app that does something with Hue lighting other than Philips?
But this is an especially stupid policy for apps for connected automobiles as you would have to think that everything is going to be unique to a specific brand of car.
SG57
Former Vendor
The past few days, anyone else experiencing could_not_wake_buses error messages when sending a command to a sleeping vehicle? Pulling vehicle data (endpoint: /data) works fine, telemetry reports correctly, but not sending a command, and summon is unreliable. Even sending a wake_up command fails immediately with a false result with no impact, leaving no way to wake the car up remotely besides playing with the key fob when you're close by. Car firmware is 17.14.23 with always-on/connected setting enabled in the car.
If I wake the vehicle, things work fine. I'll see if I can wake the vehicle up some other way, but doesn't look promising.
If I wake the vehicle, things work fine. I'll see if I can wake the vehicle up some other way, but doesn't look promising.
Anyone know of drive_state values when on Autopilot? Does shift_state contain something unique? I don't have an AP vehicle so can't test.
@dpskipper, Another suggestion for Tesla API:
Is there any way to get a limited access security token with less permission than a user’s password? Specifically, I want to be able to control when a car charges, check its state of charge & location, and perhaps start the climate control systems, but I do not want to be able to unlock the doors or start the car.
Separately, I'd like to find a business development contact at Tesla to chat about their cloud service. But that may be asking you for a bit much.
Is there any way to get a limited access security token with less permission than a user’s password? Specifically, I want to be able to control when a car charges, check its state of charge & location, and perhaps start the climate control systems, but I do not want to be able to unlock the doors or start the car.
- EVE Online provides a limited access API key for partially-trusted third party tools & web sites. The link includes a developer discussing their API key model, and it could provide inspiration for a similar limited access OAuth token for Tesla’s cloud service. The easiest solution is to do this automatically without user participation - I obtain the user’s credentials, ask the cloud service for an API key, then I throw away the user’s password.
- Ideally I could get an API key that does not expire.
Separately, I'd like to find a business development contact at Tesla to chat about their cloud service. But that may be asking you for a bit much.
HankLloydRight
No Roads
I'm going to make a wild assumption being that you're from Redmond, WA that you're from Microsoft?
Either way, and just FYI -- if you're going to try and sell them some product or service, just be aware that there as an extremely strong N-I-H ("not invented here") syndrome at Tesla.
Has the climate reporting changed? For my car, and I know for others, the API wouldn't return a value unless the car was on or the climate system was on. But now, whenever I open the app it seems to have the inside and outside temps updated. Was this changed recently?
I have noticed two options codes on my new S75D that I have not seen elsewhere. Can anyone help me figure these out?
BR05 - Battery Range Upgrade (vs BR00=no range upgrade; BR01=range upgrade applied)
BTX7 - Battery Option Code (vs BTX4=90D, BTX5=75D, BTX6=100D)
BR05 - Battery Range Upgrade (vs BR00=no range upgrade; BR01=range upgrade applied)
BTX7 - Battery Option Code (vs BTX4=90D, BTX5=75D, BTX6=100D)
HankLloydRight
No Roads
All the BR0x are firmware limited batteries. BR05 started showing up in March on Inventory cars.
The BTX7 code is a new one that's appeared several times. I've posted about it in the CPO Program thread. I believe (but have no proof) that the BTX7 code is a 85kWh battery firmware limited to 75kWh. Tesla very briefly listed two new Inventory cars as 85kWh cars, both had the BTX7 code, but that was long after the last real 85kWh battery car was offered or produced. They were later changed to 75kWh listings. BTX7 also started showing up in March.
So take that with a grain of salt, but that would be my guess.
The BTX7 code is a new one that's appeared several times. I've posted about it in the CPO Program thread. I believe (but have no proof) that the BTX7 code is a 85kWh battery firmware limited to 75kWh. Tesla very briefly listed two new Inventory cars as 85kWh cars, both had the BTX7 code, but that was long after the last real 85kWh battery car was offered or produced. They were later changed to 75kWh listings. BTX7 also started showing up in March.
So take that with a grain of salt, but that would be my guess.
SG57
Former Vendor
For anyone else wondering, rebooting my dash and center display corrected my recent could_not_wake_buses errors when attempting to interact with the vehicle while it was asleep.
Similar threads
