Thanks, done all that.
I think I might have traced back the issue.
I don’t think I can update via the Tesla api. Even trying direct from the integration I’m getting an error (I can see up to date data as in sensors but can’t update)
Reading further into it, it looks like I need a fleet api proxy?
Any ideas how to overcome? I’ve been trying to setup the fleet side of things all day but stuck on the last step as I get an error “unable to share vehicle”
I’m lucky as my 2017 Model S still works on the old API.
I did however get the api proxy working (then disabled for future use) and it took me a good 2 days to get it working!
I got it working through the Cloudflare tunnel using this guide. You have to view the logs for each add-on to see the reasons they fail.
The first hurdle I had was the SSL certificates not working. The Let’s Encrypt add-on had created them, but nothing could access them. Restarting HA fixed this issue as it created a new symlink to the SSL folder.
The next issue I had was that the internal domain I had created on Cloudflare (homeassistant-internal.mydomain.com) wasn’t resolving. I could test it using this command on my Mac:
nslookup homeassistant-internal.mydomain.com
It must respond with the IP address of your HA.
This baffled me for a while and turned out to be blocked by my routers settings.
I had to disable DNS rebind protection which was actually labelled on my router settings as No DNS Rebind.
After fixing all these issues, the Tesla Proxy finally started up without an error.
Something just occurred to me, was your script able to start the charger and adjust the amp rates, but not stop it?
This doesn’t sound like it would be an issue with the Tesla API.
Try reducing the polling interval of the Tesla API.
No I haven’t been able to do any updates at all via the script.
If I use developer tools and call the service tesla_custom.api
command: CHARGING_AMPS
I get “failed to call service tesla_custom.api. Unknown error
That’ll be the first thing you need to fix before you can use any kind of automation.
Yep, any ideas?
Start with the Tesla Proxy installation by following the guides.
I have published by automation here:
It’s considerably different to the one @dikkertjedap started this thread with.
This is wicked, thank you!
Any chance you have a walk through on how to setup the Tesla HTTP Proxy? I’ve been trying and trying and I haven’t found success. I was using the old API method but for some reason my automation stopped working, its giving me Errors TeslaException
Thanks mate! After days of trying to get the proxy to work i gave up.
I have managed to get it to work another way though (paid option unfortunately) and that is through teslemetry and using your code!
Thanks so much for supplying, i tested it this morning and can confirm its working as expected!
You need to look at the logs and figure out what the error is. There’s so much to go wrong during the setup.
This has been so good! Thanks so much for putting this together so cleanly. Once I’ve got it all up and running I’ll do a PR to suggest a few tweaks to help others get started - there were a couple of things that I had to figure out but I had a blast doing it.
Thanks heaps!
Nice work Darren! You’ve really outdone yourself by breaking down all the math into separate automation steps, adding logging info and commenting all the individual steps in the automation. On the point of your automation being “considerably different”: although on first glance it doesn’t seem to add any new functionality to my original idea (and my personal opinion on code efficiency aside 
), I can see why this would appeal to a more wider user audience, as it is much easier to ‘understand’ the automation this way.
I was going through the tesla polling automations yaml, and was wondering why you would need so much polling: what is it you are achieving there?
PS some level of attribution = 🫶🏻
I do prefer more verbose code. I hate it when you have to sit and stare at a line of code for a while to truly understand what it’s doing.
Regarding polling, it’s a fine line to get it right. At the default level of 11 minutes, you could plug your car in at home and it would start charging at whatever rate it was last set to. It could be up to 11 minutes before HA is informed that it’s plugged in and charging and then adjust the charge rate as needed.
Same when you unplug, HA just won’t be informed for a while.
You also wouldn’t get any of the notification automations until the polling is triggered.
The polling automations came from the Tesla API wiki, the idea being that if the car has no chance of sleeping anyway, increase the polling interval to keep HA updated.
Attribution added to the git
Thank you for elaborating!
I’ve quite well understood that the polling settings add a fair bit of code and complexity when it comes to these automations. I must admit I hadn’t looked at the automation since last fall, and noticed that the polling policy indeed changed to 11 minutes (I recall this being updated almost instant all the time), which is probably why I didn’t notice any issue. But the sun is out now, so it’s time for some optimizations! At the moment I’ve set the polling frequency to 30 seconds and will see how that impacts the battery usage and what needs to change, but I thank you for bringing this to my attention.
As you might have noticed earlier, I’ve solved quite some issues in a different manner. Opposed to relying heavily on the cars’ sensor output and actual state, I am currently using state logic and assumptions, such as setting the smart charging boolean when the car arrives home and the sun is above the horizon. As the charging state (either charging or not charging) is always a variable that’s set by the automation, you’re not missing out on much.
A different issue I have is that some devices (such as the Qooker) are heavy ‘instant drains’ from the grid, causing the automation to bounce quite a bit.
I’ve used the HACS Average Sensor to create a one-minute-average sensor (implemented around 15:56), which does seem to flatten out the Qooker bouncing by quite some margin!
- platform: average
name: Average grid balance
duration:
minutes: 1
entities:
- sensor.power_grid_usage
I wasn’t too concerned about missing out on some, more the opposite.
When you plug the car in it starts to charge immediately, and if HA takes up to 11 minutes to be notified that the car has been plugged in, you could be paying for the charging for a while.
30 second polling is much better.
I’ve never used the average sensor, but it looks great for my second automation for my pool pump/heater as it’s a single high draw and I don’t want to be switching it on and off constantly.
Let me clarify: by using state logic, the smart charging can be switched on by any variable BUT the car’s sensor, for instance by you arriving home and/or by grid energy surplus by default. That way your smart charging start is independent of the car chargers’ state or connection sensor poll rate, and you won’t miss a ray of sun!
In this use case (just for argument sake, of course!) you could use a sudden drop in the grid power as the trigger - my assumption there would be (considering your 3-phase solution) that there will be close to none other devices that would immediately cause the power drop that your charging session causes. Coupled to situational logic (you just arrived home < 3 minutes, the movement sensor detected movement in the driveway < 3 minutes, your garage opener was triggered < 3 minutes etc.) you could figure out a pattern that would imply that the power drop is initiated by the car charger. In my case, the charger is connected to a specific phase, where there are no other big power drains, which makes this even easier to detect. In you 3-phase situation, a power drain => 5000 watts and sustained for => 30 seconds would imply a charge session has begun.
It’s not to say that it’s in any way easier, it’s just that this behavioral approach is a way of thinking about automations that are independent of how refresh rates of other sensors. Hope that helps and may inspire others who are wrestling to cover all the optimization edge cases!
Has anyone been running onto rate limiting issues with the Fleet API?
Hi, nice piece of work! Can your setup handle the following use case? I want my car to keep charging if there is some solar but it would still need to use some grid power in addition. I essentially want to keep charging my car as long as I use <= 3kw from the grid. My solar array isn’t very large and partially charging on solar is still cheaper for me.