Open r4nd0mbr1ck opened 6 months ago
rileymd88
commented
6 months ago I also received the same 429 error today. It looks like Tesla are starting to implement the rate limits which have been public for a while: https://developer.tesla.com/docs/fleet-api#membership-tiers
According to the API response header Retry-After I have been rate limited for 24 hours :|
r4nd0mbr1ck
commented
6 months ago Yikes! 50 commands per day? There goes my automation for excess solar charging.
alandtse
commented
6 months ago Short term, we need a PR to identify the time period specified in Retry-After and possibly delay polling until that point. We also would need to decide if we just queue the pending command, or just fail immediately with the error.
The issue is a user really needs to do something at this point if they are getting rate limited as it's unclear if Tesla will do anything negative, including ban users who continue to try to do things while rate limited.
peter-funktionIT
commented
6 months ago Short term, we need a PR to identify the time period specified in
Retry-Afterand possibly delay polling until that point. Maybe I misunderstand you, but just wanted to add that when I got rate-limited yesterday polling still worked fine, all my sensors like battery updated correctly. I just couldn't send any commands.
From rileymd88's link above (https://developer.tesla.com/docs/fleet-api#membership-tiers) I would guess I hit the "Command limits" of 50 reqs/day. Looking further down in the Tesla API documentation "Vehicle Commands" are all POSTs (https://developer.tesla.com/docs/fleet-api#vehicle-commands)
For "Device data limits" at 1 reqs/5min we should mostly be fine, as default polling interval is at 10 minutes if I'm not mistaken.
I do however agree with you on the solution to verify Retry-After and delay polling if this unlikely event should occur.
For Vehicle Commands however I'm not sure what to do. It's not really an option to delay the sending of the command for 24 hours.
Perhaps exposing a sensor, Rate Limited, with the number of seconds (taken from Retry-After) to wait until a command can be issued again?
That way the sensor can be used in automations as some sort of failsafe.
sgriessini
commented
6 months ago Yikes! 50 commands per day? There goes my automation for excess solar charging.
Same for me, automation uses data and commands every minute. Now I have to adjust manually 😕
zlymeda
commented
6 months ago Yikes! 50 commands per day? There goes my automation for excess solar charging.
Same for me, automation uses data and commands every minute. Now I have to adjust manually 😕
You can use BLE for commands (that are not rate-limited), as you are connecting to the car directly. I am running a modified version of the HTTP proxy, where I try to connect via BLE first, it is not perfect solution, I will need to improve it once I have time. sometime the BLE is stuck and even using the context cancelling in go, still won't prevent from deadlock from time to time. So If I detect the deadlock, I just restart the service..
rubin110
commented
6 months ago So I'm trying to understand this bug. I can no longer send commands to my car, however I'm getting data back and just as frequently as few months prior through Teslamate. Wouldn't both be hitting the same issue?
rileymd88
commented
6 months ago So I'm trying to understand this bug. I can no longer send commands to my car, however I'm getting data back and just as frequently as few months prior through Teslamate. Wouldn't both be hitting the same issue?
This add on uses the new Fleet APIs which have the rate limits. Teslamate still uses the old deprecated Owners API which did not have any rate limiting in place.
bkrishnadas-mq
commented
6 months ago Yikes! 50 commands per day? There goes my automation for excess solar charging.
Same for me, automation uses data and commands every minute. Now I have to adjust manually 😕
You can use BLE for commands (that are not rate-limited), as you are connecting to the car directly. I am running a modified version of the HTTP proxy,
Any links/doco on how this works and how to set this up?
NavBlue1
commented
6 months ago Does anyone please know how or if Teslemetry is getting around this?
I could be wrong but I thought it used the fleet api as well. And I’m not talking about the few entity’s you can stream with Teslemetry.
After getting rate limited using this custom integration, I got my old Teslemetry hacs integration up and running again I can do a “Home Assistant core integration : update entity” service call every 15s which effectively does a force update on all Teslemetry entities and not get rate limited.
sreuter
commented
6 months ago We contacted Tesla regarding this, and they confirmed that they started to roll out their documented rate limits. That being said, we believe their implementation is buggy. For instance, we get a 429 with a Retry-After: 86400 when calling the wake_up endpoint, which has a documented rate limit of 5 API requests / car / hour.
This value seems odd for two reasons:
86100. Otherwise, you might get a Retry-After: 86400 while it might work 2 minutes later again.86400 (a full day) does not make sense for an endpoint with an hourly measurement window.We told Tesla that we'd love to adhere to their limits (even tho some limits feel extremely small) but would need a bit more guidance. The whole wake_up thing also never made sense to us in the first place. It should just be possible to set a wake car if asleep flag on any important call instead of having to make a separate call first. Also, what if the vehicle doesn't have a signal for some time? One would waste their daily budget of 5 calls a day per car quite fast.
We hope they come around soon to help their consumers with better advice. ¯_(ツ)_/¯
abreingan
commented
6 months ago I also seem to be having this problem, using llamafilm's Proxy, which I only started using a few days back. I am using this for solar charging and it normally works well until sometime in the afternoon and then stops. I would be interested in zlymeda's comment about BLE. If this works to change charging amps then that is most of the commands I issue.
zlymeda
commented
6 months ago the go repo for running http proxy, as well as using BLE is here: https://github.com/teslamotors/vehicle-command you should find all the necessary information there.
then I modified the method loadVehicleAndCommandFromRequest. first I try to use BLE connection.. if that fails I will fallback to HTTP:
// try to use BLE
conn, err := ble.NewConnection(ctx, vin)
if err == nil {
car, err = vehicle.NewVehicle(conn, p.commandKey, p.sessions)
if err == nil {
return car, commandToExecuteFunc, nil
}
}
// if above fails, use HTTP
car, err = acct.GetVehicle(ctx, vin, p.commandKey, p.sessions)
OrbitTheSun
commented
6 months ago When blocked, I found that the mobile app still has access to the vehicle data. This also applies when my cell phone and my server have the same IP address. By using the app, I was even able to temporarily unblock my server. Does anyone have any idea whether the cell phone app isn't blocked and how?
abreingan
commented
6 months ago Thanks zlymeda. I have just started using llamafilm's version of the proxy as I got cut off a couple of weeks back, so I might let things mature for a while and hope Tesla comes out with information about the scheme, especially how they might charge for this. That would be simplest.
I suspect that many will have the same issues as I do, my Home Assistant server is behind CGNat and out of BLE range from the car.
PedroKTFC
commented
5 months ago I've started getting the Error 429 this afternoon. Looking in the logs I notice I have the following entries:
2024-05-22 23:19:12.982 WARNING (MainThread) [teslajsonpy.controller] Unable to get vehicle data during poll. 429: TOO_MANY_REQUESTS
2024-05-22 23:19:22.986 WARNING (MainThread) [teslajsonpy.controller] Unable to get vehicle data during poll. 429: TOO_MANY_REQUESTS
2024-05-22 23:19:32.974 WARNING (MainThread) [teslajsonpy.controller] Unable to get vehicle data during poll. 429: TOO_MANY_REQUESTS
2024-05-22 23:19:43.041 WARNING (MainThread) [teslajsonpy.controller] Unable to get vehicle data during poll. 429: TOO_MANY_REQUESTS
2024-05-22 23:19:52.973 WARNING (MainThread) [teslajsonpy.controller] Unable to get vehicle data during poll. 429: TOO_MANY_REQUESTS
2024-05-22 23:20:02.974 WARNING (MainThread) [teslajsonpy.controller] Unable to get vehicle data during poll. 429: TOO_MANY_REQUESTS
2024-05-22 23:20:12.993 WARNING (MainThread) [teslajsonpy.controller] Unable to get vehicle data during poll. 429: TOO_MANY_REQUESTS
2024-05-22 23:20:22.975 WARNING (MainThread) [teslajsonpy.controller] Unable to get vehicle data during poll. 429: TOO_MANY_REQUESTS
2024-05-22 23:20:32.982 WARNING (MainThread) [teslajsonpy.controller] Unable to get vehicle data during poll. 429: TOO_MANY_REQUESTSNote these seem to be going on continously, this is just a selection.
It seems like something is (re?)trying a poll every 10 seconds. Since the 429 started, and reading about the 50 a day limit, I've changed my polling interval from 660 seconds to 2000, which should total less than 50. I've no idea about the underlying process but could these be swamping the Tesla servers?
In fact, might this mean I will never recover (these are continuing to spew out as I write this)?
alandtse
commented
5 months ago Yes, the old API used to let you access the list of vehicles and determine basic status before connecting to the vehicle without a rate limit. This was hitting Tesla's server and not your car. We do it every 10 secs. Apparently that is rate limited now. Happy to take a PR but this now means we can't detect wakeups as quickly so there might have to be a complete rearchitecture.
PedroKTFC
commented
5 months ago Ah, thanks for the comment and link. So it looks if I set the car's Polling switch off the car isn't polled but are the Tesla servers always polled every 10s by the integration? If so I'll raise a PR.
Also, in my automations, I use the Charger switch to start and stop the car charging. Some questions about this:
Force data update or Wake up buttons?For my case I don't need the car's information to be always up to date, only when I want to request it.
raphmur
commented
5 months ago Same problem here, and same goal: usage of excess solar... I really like the BLE option, whether you are in range, or could setup an ESP wifi to BLE relay or other contraption... However @zlymeda I don't really get what you have done by modifying the method. I mean, is this Go library already used by this Tesla integration? If yes, that would be a simple option to be added, or even systematic...
dreamonhigh
commented
5 months ago +1
zlymeda
commented
5 months ago the original HTTP proxy only connects to cars via HTTP, not BLE. however, the repo contains a cli for executing commands via HTTP or BLE. I had to modify the method (in the proxy) so that the BLE is tried first, if BLE fails => I use HTTP.
for my "solar excess" usage it is enough. but it is not great. the better solution would be to "know" if the car is home, and so BLE is reachable. I need to find more time to improve it. the problem, I mentioned before is that the BLE sometimes gets stuck and even context cancellation does not prevent it from blocking forever. so my workaround is: if this is detected kill the app. I run the app as a service, so killing it means restarting. even the BLE connection is issued every time there is a request. this is a proxy for multiple cars (potentially). but I think, we could build a "single car" proxy, that could re-use the ble connection and probably other things as well.
I tried monitoring the car via BLE, but once it is monitoring it can't do other things, like issue command via BLE. the BLE seems not to be able to do more things at once. so I'll need some strategy to detect if the car is home (asking HA?, checking the GPS via HTTP?, ...) and based on that use BLE or HTTP.
also there are issues in the official repo about reading information via BLE. right now, we can issue commands via BLE, but we don't know the state of the car and we need to use HTTP for that. if they add support for reading charge limit, charging state, ... via BLE, then we could build solar excess charging solely using BLE.
raphmur
commented
5 months ago Thanks. Looking at the code from the Tesla Custom Integration, I do not see any reference to the official vehicle-command library, as the API call URLs are hardcoded in library teslajsonpy https://github.com/zabuldon/teslajsonpy @zlymeda Did you manage your solar charge regulator with HomeAssistant and Tesla SDK? or any other wizardry? :)
I am no fluent in Go, but happy to learn and to help to upgrade with this BLE integration... For what I need:
The ideal way of working (maybe) would be for this TeslaCustomIntegration to use directly (or fork and change) the vehicle-command SDK... Again, happy to help, but the starting point is not super clear for me.
PedroKTFC
commented
5 months ago I confess to not following the comments above about BLE - is it possible to do everything through BLE that you can do through http? Also, are you trying to detect if the car is at home? This is something I'm also trying to do as I want to open my electric gate when the car gets home and when someone gets in the car to drive away. I did this in my previous car with a very simple ESP32 board that I plugged into the car's USB port. HA would ping this every second and, if it got a reply, an automation would trigger to open the gate. However, I'm finding the USB ports in the Tesla can become active almost at random, especially if the car's plugged in, with my gate then opening unexpectedly! I'm trying to add a test for if a user is present but of course this will be affected by any throttling. However, detecting the car purely through BLE might be an option although I need to understand this better.
I also thought I'd update on how I'm getting on with polling etc. After a few trial and error attempts, I think (!) it's possible to control how data is collected from the car as follows:
Polling flag normally offForce data update button and then reset the Polling flag to offI have a Lovelace page where I display some key car data. On this page I now have a button that sets a toggle helper to true, which causes an automation to trigger (I actually use NodeRed) that does what's in the second bullet above and then clears the helper. This causes the data on my page to be refreshed. I can use similar logic to run other automations. I've since seen no throttling errors.
i-am-shodan
commented
5 months ago I thought I'd mention that I think Tesla's rate limit is over all requests to a particular vehicle, not just from a particular registered virtual key. So if you have two different integrations both trying to query the car both will fail even if one isn't polling every 10s.
This is what's happening with Octopus my Energy provider. My tariff with them enables them to charge my car when they decide. They use the fleet api. Since Tesla changed their rate limit logic my provider has been unable to charge my car.
llamafilm
commented
5 months ago @i-am-shodan thanks for sharing. That’s interesting. I would be surprised if that’s true; I assumed the limits would follow the developer account, not the car.
I’m glad to know that electric companies are using this feature too; I hope they will put some resources into fixing it sooner than later. But my guess is they will try to solve it at the EVSE, so it works for all makes of car.
chrispazz
commented
5 months ago We have a big problem :)
https://developer.tesla.com/docs/fleet-api?javascript#membership-levels
rubin110
commented
5 months ago I'm very lost with all of this. So my integration was configured with what I'm guessing was the old API route, and had sensor date provided by Teslamate locally. A few weeks ago I noticed that through HA I could no longer interact with any of the controls through HA, however my local Teslamate is still grabbing telemetry being fed into HA.
It seems like most people can still grab telemetry via Teslamate's method of talking to Tesla via the v2 API, but some no longer can.
Digging around and trying to understand (please correct me if I'm wrong), there's a new v3 Fleet API that's more websockets based and requires the "app" to be registered with them to get access to the API. There's a Tesla HTTP Proxy as an HA addon/docker image which connects with Tesla and then the HA integration through authentication with Tesla gets what it needs to talk to the proxy. And then the spice should hypothetically flow.
For the HA integration is interacting with the v2 API done, or is there some use case where it should still work? Should I get on ith getting the HTTP proxy working locally?
What's keeping this project from just using the API endpoints that Teslamate is using? At least until Tesla makes it a little more clearer as to how their rate limiting actually works.
Sorry I've I'm being a bit clueless here, I'd just like to know if there are any paths forward for my setup.
abreingan
commented
5 months ago I'm very lost with all of this...
I do think it is valuable to understand the situation as it seems to vary by location. I was on the old HA Tesla integration and was also using TelsaMate (basically the same as rubin110). Then about 3 weeks ago I lost the ability to send commands through HA Tesla integration but Teslamate still worked. That is because they are different APIs. I then applied for a developers license and got the new "Fleet API" working with HA thanks to llamafilm's proxy addon. That license suggests that I cannot continue to use the TeslaMate api, so I am trying to use the new Fleet Telemetry api. Unfortunately this is more complex in my case as I am behind CGNat. The new Fleet API also comes with some quite severe restrictions on the number of commands per day (50 so far). That might be bypassed by using a bluetooth connection directly to the car but I haven't go that working as I can just get my charging done under the 50 commands most days. I hope that helps.
PedroKTFC
commented
5 months ago We have a big problem :)
https://developer.tesla.com/docs/fleet-api?javascript#membership-levels
I agree not ideal but for automations in HA I should be able to manage within these limits. For example, I'm very unlikely to want to issue more than, say, 4 at max charging commands a day. I'll have to ensure my automations are very "slow"!
chrispazz
commented
5 months ago I just inserted a feature reuest for adding call counters (sensors).....
https://github.com/alandtse/tesla/issues/985
At what time Tesla resets its api limit every day?
rubin110
commented
5 months ago That license suggests that I cannot continue to use the TeslaMate api, so I am trying to use the new Fleet Telemetry api.
@abreingan I think I'm reading that wrong. When you applied for new keys with the Fleet API, did that kill Teslamate's ability to grab data?
abreingan
commented
5 months ago That license suggests that I cannot continue to use the TeslaMate api, so I am trying to use the new Fleet Telemetry api.
@abreingan I think I'm reading that wrong. When you applied for new keys with the Fleet API, did that kill Teslamate's ability to grab data?
No I can still get data via TeslaMate but I am unsure if this will continue and there is a clause (below) that suggests fleet may be revoked if the old APIs are used.
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. Per the Fleet API policies, continued usage of unsupported APIs will result in the revocation of Fleet API access privileges.
rubin110
commented
5 months ago After a few hours last of banging my head against something hard trying to troubleshoot local DNS, I have the Tesla HTTP Proxy Docker image running. I configured the custom integration to grab details from MQTT and to only poll once every 3600 seconds. 12 hours later I can still flip my sentry mode off and on from HA.
i-am-shodan
commented
5 months ago @rubin110 are you changing const.py? If so to what values?
rubin110
commented
5 months ago I have not changed any code, at least nothing outside of configs like for docker compose. I only have a model 3, no solar/power wall. What I have going on:
As of right now (3 days later), I can still flip sentry on/off through HA and see that change reflected in the Tesla app.
Not sure how much this may matter, but for these three days my car has been sitting idle out next to the curb on the street, not on wifi, not charging, sentry mode on.
raphmur
commented
5 months ago Hi all,
I spent quite some time fiddling around... Main target for me is excess solar charging regulation, for which I refresh the charging amps every 2 minutes. I was seeing generic "TeslaException", and well, I assumed I was rate limited, but in fact I was using the old API.
1st action is to setup FleetAPI. The "howto" in the Tesla HTTP Proxy Add-On is sufficient, but be very focused, especially if you are not a specialist. Then re-create your Tesla in HA with FleetAPI. Please be aware that you need some sort of business credentials (probably not mandatory though). --> It restored the possibility to send commands. However, I am now clearly rate limited mainly on commands This way if you set limits (as above posts) on polling rate, you should be ok for now if you don't abuse.
2nd action / hack is to use the official Tesla Vehicle Command SDK, which contains cli tools to send commands via BLE to your Tesla. This package is already part of the proxy deployed in step one, but only for the HTTP proxy. @zlymeda managed to directly integrate BLE calls within the Tesla HTTP calls (in the proxy) as a hack, but not working for me... To make it short: I installed tesla-control on a spare machine and used shell/ssh commands from HA to send commands via BLE to the Tesla. Steps taken:
ssh -i /config/ssh/id_rsa -o StrictHostKeyChecking=no -q [login]@[ip of ble machine] /path/to/tesla-control/tesla-control -ble -vin [your VIN] -key-name /path/to/teslakeypair/private.pem -key-file /path/to/teslakeypair/private.pem $@To make things sustainable for solar charge regulators, I would see:
rubin110
commented
5 months ago Thanks for the write up. I don't know why I thought that getting local BLE access was going to be as easy as tossing an ESP32 in the garage and then seeing some auto discovered Tesla BLE integration pop up in HA.
Anyhow I drove around a bit today and car is now in the garage plugged in. While out I was successful 3 times with my hack of yelling "turn on the car AC" at Google assistant and that flipping on the Tesla climate control in HA,. And my automation of turn off sentry mode if parked in the garage worked. Other than some stale telemetry with the integration (from the 1 hour poll time), everything looks correct. Teslamate is still kicking in and my app works.
abreingan
commented
5 months ago Hi all, I spent quite some time fiddling around...
Thank you raphmur for some very productive fiddling. A few questions if I may. You say - Generate a new keypair to send ble commands to your Tesla. I assume this is a new key rather than the one generated by the Tesla HTTP Proxy Add-On. Did you have to create another app in the Tesla Developers site? I was afraid this might disable the proxy and have been trying, without success, to get the private key out of the proxy addon container. Not helped by the fact that its my first time playing with large slabs of this technology. I also want to try and get the Fleet Telemetry working and it seems over the top to have three different keys. It does seem as if one key would work for all.
As for a long term solution, I am happy with the separate pi solution as my HA instance is out of BLE range from the car. Obviously good to have it all integrated and as much visible from HA as possible. Would the BLE proxy work for this?
raphmur
commented
5 months ago Indeed, I did not mention. I tried also to recover the keypair from the proxy, but no success. So I created a new (local) keypair using openssl as per the tutorial here (the one from Shankar K). It has no link with your Tesla Dav account, it is recognized by the car as a BLE key, and that's it. More or less the same way of working (I assume) as with pairing your phone as a key.
/!\ Please be aware that getting your Pi stolen or hacked will compromize your car (but you can delete the key from the car).
For BLE proxy, I did not read through enough.
abreingan
commented
5 months ago Thank you - I will go fiddle with that.
MrBLJ
commented
5 months ago Indeed, I did not mention. I tried also to recover the keypair from the proxy, but no success. So I created a new (local) keypair using openssl as per the tutorial here (the one from Shankar K). It has no link with your Tesla Dav account, it is recognized by the car as a BLE key, and that's it. More or less the same way of working (I assume) as with pairing your phone as a key.
/!\ Please be aware that getting your Pi stolen or hacked will compromize your car (but you can delete the key from the car).
For BLE proxy, I did not read through enough.
Thanks a lot for your work. It's most welcome and useful for charging our cars with excess solar power.
andreaconfa
commented
5 months ago Hi all,
I spent quite some time fiddling around... Main target for me is excess solar charging regulation, for which I refresh the charging amps every 2 minutes. I was seeing generic "TeslaException", and well, I assumed I was rate limited, but in fact I was using the old API.
1st action is to setup FleetAPI. The "howto" in the Tesla HTTP Proxy Add-On is sufficient, but be very focused, especially if you are not a specialist. Then re-create your Tesla in HA with FleetAPI. Please be aware that you need some sort of business credentials (probably not mandatory though). --> It restored the possibility to send commands. However, I am now clearly rate limited mainly on commands This way if you set limits (as above posts) on polling rate, you should be ok for now if you don't abuse.
2nd action / hack is to use the official Tesla Vehicle Command SDK, which contains cli tools to send commands via BLE to your Tesla. This package is already part of the proxy deployed in step one, but only for the HTTP proxy. @zlymeda managed to directly integrate BLE calls within the Tesla HTTP calls (in the proxy) as a hack, but not working for me... To make it short: I installed tesla-control on a spare machine and used shell/ssh commands from HA to send commands via BLE to the Tesla. Steps taken:
- Install basic raspbian on an old RPi 3B laying around (but any linux / mac machine with BLE should work). ~30-60min
- Clone and compile (with golang >1.21) the cli tools from the Tesla SDK. The one I am interested in is tesla-control ~10min
- Follow this tutorial from Shankar Kumarasamy to:
- Generate a new keypair to send ble commands to your Tesla (the tesla-keygen cli tool did not work for me) ~10min
- Push the public key to your Tesla with tesla-control ~5min
- Successfully send commands to your Tesla with BLE, then stop the tutorial there
- Be happy
- Generate SSH keypair to allow HA to connect to your spare machine on which you installed tesla-control ~5min
- Create a shell script in HA with the command below, and make it executable ~5min
ssh -i /config/ssh/id_rsa -o StrictHostKeyChecking=no -q [login]@[ip of ble machine] /path/to/tesla-control/tesla-control -ble -vin [your VIN] -key-name /path/to/teslakeypair/private.pem -key-file /path/to/teslakeypair/private.pem $@- Create a "shell_command" as per guide ~5min
- Then instead of calling the commands from the Tesla Custom Integration objects, you use the shell command created, with the arguments you need (see example below) depends on you
- Be more happy
- Finetune the delays as the BLE command may sometimes timeout or fail (busy device) I also adapted my solar regulation to "assume" Tesla state based on sent commands, instead of polling data. Maybe useless, but not tested.
To make things sustainable for solar charge regulators, I would see:
- Easy option: buy a wall charger with is controllable........ $$$
- Create a custom integration to implement only the BLE tesla-control, and then remove the need for third party beacon. Something like "Tesla local commands" --> I will try...
- Nicely integrate BLE commands in the existing integration. Maybe in teslajsonpy...
Hi, thank you for the little guide. I was able to deploy and use the raspberry toghether with home assistant to control my car via BLE.
The only problem is that, when i send commands to the car, i receive very ofter the error:
Error: ble: failed to enumerate device services: ATT request failed: input channel closed: io: read/write on closed pipe
Did you know how to solve this?
Due to this issue i had to create a script that check if the command is successful or not, and in this case it retry it for 5 time, maybe this can be useful for someone:
To change the charge setpoint of the car i call this script with arguments (like VIN and amps number). The script will cycle and and when the command is sent without error (for maximum 5 times)
BogdanDIA
commented
5 months ago Hi all,
I was searching the github issues list to find some info as yesterday my v2 API access seized to work. I did install the HTTP proxy and followed all the gory details to make FleetAPI working. So now FleetAPI works. However, BLE seemed from the beginning a better solution for charging from solar excess. I will write here what I've done so far.
BTW, just as info, this is one example of the BLE measurements (of the phone signal) done by the car and sent to the phone during the authentication phase when the user tries to open the driver's door but the phone is too far so the car will not unlock:
alert { alertHandlePulledWithoutAuth { timeSinceAlertSet_ms: 858 connectionCount: 1 deviceSpecificPayload { keyChannel: 3 RSSILeft: -78 RSSIRight: -92 RSSIRear: 127 RSSICenter: -88 } } }
All in all, I think the BLE will be good for communication with the car for charging and not only because there will be no rate limiting and no need for internet access. Hope Tesla will not try to monetize BLE as they try with the server connection.
raphmur
commented
5 months ago Super
Thanks @BogdanDIA for clarification! For BLE performance, I assume using a ethernet RPi3 and leaving the full antenna for BLE should improve...? Or using an external bluetooth dongle maybe....
@andreaconfa, I like your tweak, though it just becomes specific for one command (set charge amps), which should not be a big issue as this is one of the main goals... I did not see this exact error but some similar on busy channel or pipe.... I just retried the command and it worked. What I have found relevant:
I really used this "BLE trial & error spamming technique" as a last option :) So it could probably be done smartly with and integration, failsafe solutions, ... Oh well
BogdanDIA
commented
5 months ago Thanks @BogdanDIA for clarification! For BLE performance, I assume using a ethernet RPi3 and leaving the full antenna for BLE should improve...? Or using an external bluetooth dongle maybe....
@raphmur yes, the ethernet shoud work while having wifi disabled.
MrBLJ
commented
5 months ago Your post is super interesting, thanks a lot.
I tried a rpi5 that has the 5Ghz wifi band. This allowed a huge improvement for the BLE connection between the rpi5 and the car. Improvement is both in longer distance and stability of connection.
From what I've read, there is some kind of unicorn out there in the form of ESP32-C5 which is able to connect to 5Ghz wifi networks. However I don't think it's available yet.
Based on your experience, without interference from Wi-Fi and Bluetooth (using either an RPi 5 or an Ethernet connection), what is the maximum distance at which we can place the device from the car? I am trying to decide whether I should run an Ethernet cable to my garage and use an old RPi 3, or buy a new RPi 5 (which costs at least $60 where I live) and utilize the 5 GHz Wi-Fi.
detecting if the car is home I've done with an ESP32 by receiving the iBeacons sent by the car.
Can you expand on that :
ESP32 should be quite nice to have in this project.
I'm pretty confident in telling you I'm not the only one that'd be very interested in such a solution. In this case however, could we have issues between Wi-Fi and Bluetooth ?
BogdanDIA
commented
5 months ago Your post is super interesting, thanks a lot.
I tried a rpi5 that has the 5Ghz wifi band. This allowed a huge improvement for the BLE connection between the rpi5 and the car. Improvement is both in longer distance and stability of connection.
From what I've read, there is some kind of unicorn out there in the form of ESP32-C5 which is able to connect to 5Ghz wifi networks. However I don't think it's available yet.
Based on your experience, without interference from Wi-Fi and Bluetooth (using either an RPi 5 or an Ethernet connection), what is the maximum distance at which we can place the device from the car? I am trying to decide whether I should run an Ethernet cable to my garage and use an old RPi 3, or buy a new RPi 5 (which costs at least $60 where I live) and utilize the 5 GHz Wi-Fi.
detecting if the car is home I've done with an ESP32 by receiving the iBeacons sent by the car.
Can you expand on that :
* Are you using [esphome with BLE beacons](https://esphome.io/components/text_sensor/ble_scanner.html) ? * How reliable is this ? For now I'm using a [proximity](https://www.home-assistant.io/integrations/proximity/) sensor in HA with a few device trackers, it works _most_ of the time but I'm wondering if it could be improved.ESP32 should be quite nice to have in this project.
I'm pretty confident in telling you I'm not the only one that'd be very interested in such a solution. In this case however, could we have issues between Wi-Fi and Bluetooth ?
I've checked the ESP32 C5 few months ago but as you said it was not ready. The major work would be porting the golang to the ESP. Encrypting the FW in ESP should give a good level of protection for the car's keys.
I think you need to experiment with the maximum distance you can obtain as it depends on many variables like LOS(line of sight) or not, number of other networks in the area, existing walls, etc. A for myself, I started with having a laptop at 5 meters from the car and making the BLE FleetAPI working on it I switched to rpi3 by placing it in the same spot as the laptop. It did not work as there were a lot of comm errors so that is why I switched to rpi5 on 5Ghz band. Did not check max distance, though.
For car presence I started with the iBeacon HA integration which was awfully slow especially when departing from home so I decided to use ESPHome with my own implementation. Instead of using the RSSI in calculating the distance, I used the count of the iBeacon messages received from the car. This works very well in this case where the car sends tens of messages per second. When there is no message received for e.g. 3 seconds it is clear the car is not close. This worked flawlessly for more than 6 mo now.
One thing to note is that during car's software update there is a period of 15-20 seconds when iBeacons are not sent and this needs to be taken in consideration e.g in HA automation that will not trigger the action while updating the car.
But there are other ways to change the charging parameters for the experimenters, one of them being with CAN commands. Been fiddling with CAN for sometime with an rpi/ESP32 and a OBD2 dongle, no keys needed, just 8byte messages. I don't recommend it though as I've seen Tesla changing some of the CAN commands format from time to time during the years. And also that some people say that Tesla logs strange CAN messages that do not come from MCU but from other busses of the car. On the flip side, the S3EXY buttons from enhance do the same thing by sending CAN messages instead of MCU or other devices on the buses.
i-am-shodan
commented
5 months ago I'd check out https://github.com/pmdroid/tesla-ble and see if the API is the same.
iainbullock
commented
5 months ago Thanks for everyone's contribution to this.
I have created a docker container which will send commands from Home Assistant via MQTT to a car using BLE. It is useful to run on a remote device e.g. Raspberry Pi located close to where the car is parked. MQTT will auto-populate the various entities in Home Assistant, such that Buttons can be pressed (and Services called from Automations) to send commands. There is a Number entity to set the charging current. It's a first release so will need further work no doubt
andreaconfa
commented
5 months ago Hi, This is awesome. Unfortunately I already see an issue for my use-case.
I have two car (and this mean two different vins). Maybe you can make the VIN number as a setting in home assistant instead of passing it directly to the docker container….
Do you think is possible ?
Thanks
Is there an existing issue for this?
I have read about the Fleet API and understand I may need to use it
Version of the Tesla component
3.21.0
Version of the Tesla car software
2024.14.3
Model
Model Y
Current Behavior
I setup the Fleet API via Tesla HTTP Proxy add-on a few days back. The custom integration was working at that point and I could see vehicle status and also issue commands. Today, commands stopped working but stats get updated. The integration been throwing a range of errors. Initially it was throwing UnknownException and since then I have deleted the integration, generated new Refresh Token in Tesla HTTP Proxy and set it up again. See latest log here https://pastebin.com/3R0s2Wcr - this starts from custom integration setup and until includes issue of one command.
Expected Behavior
Commands should work
Debug logs
Anything else?
I can see Running controller.update() in the logs every 10 seconds or so. Not sure if that has any implications. Polling is at the default 660 seconds.