Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Model 3 scheduled/timed/smart charging

This site may earn commission on affiliate links.
The raw api does. The /api/1/vehicles/ endpoint will list basic info about all vehicles for the given access token, without contacting the car directly.

I've now written some python3 that calls the https://owner-api.teslamotors.com/api/1/vehicles/:id/command/charge_stop command at 4:30am (at that time Octopus tariff goes back up). This works sometimes but not others, even though the car has previously confirmed that it is not asleep, often I get "408 Vehicle unavailable". If I repeat it every 20 seconds then it often completes on the 3rd or 4th go, but sometimes on the first.
Any ideas why it is unreliable? Does it rely on the LTE phone signal, does it use WiFi? The calls to get vehicle status (asleep / offline / online) are reliable, but I assume that they come back from the server, and not the car.
 
Last edited:
I've now written some python3 that calls the https://owner-api.teslamotors.com/api/1/vehicles/:id/command/charge_stop command at 4:30am (at that time Octopus tariff goes back up). This works sometimes but not others, even though the car has previously confirmed that it is not asleep, often I get "408 Vehicle unavailable". If I repeat it every 20 seconds then it often completes on the 3rd or 4th go.
Any ideas why it is unreliable? Does it rely on the LTE phone signal, does it use WiFi? The calls to get vehicle status (asleep / offline / online) are reliable, but I assume that they come back from the server, and not the car.

Have you tried a POST wake_up before the POST charge_stop?

It shouldn't need it, as it seems that the car is always awake when charging, but you never know!

It would be nice if Tesla would just endorse the use of their API officially, so we had solid info on how it works, especially as it seems that there are now lots of app using the unofficial API anyway.

If I had to guess, I'd say the car is fine with just a wifi connection, as it seems to prefer to connect via wifi if it can (just going by it always connecting to my home network as soon as it's within range).

Like you, my guess is that all the GET stuff comes mainly from the recorded status held on the server, and doesn't bother to make any calls to the car, unless, perhaps, it's already awake.

BTW, I'm doing something vaguely similar, but using micropython on an ESP8266, just to make it a bit more challenging...
 
  • Disagree
  • Like
Reactions: Roy W. and T.F.S.
I've now written some python3 that calls the https://owner-api.teslamotors.com/api/1/vehicles/:id/command/charge_stop command at 4:30am (at that time Octopus tariff goes back up). This works sometimes but not others, even though the car has previously confirmed that it is not asleep, often I get "408 Vehicle unavailable". If I repeat it every 20 seconds then it often completes on the 3rd or 4th go, but sometimes on the first.
Any ideas why it is unreliable? Does it rely on the LTE phone signal, does it use WiFi? The calls to get vehicle status (asleep / offline / online) are reliable, but I assume that they come back from the server, and not the car.

408 will , more than likely, be the generic REST 408 error which is a timeout on the request. That probably explains why you retrying it eventually completes. It could be a server side issue but then again you would expect it to be consistent across calls rather than just for the charge stop call. So, it’s most likely that the car is switching states between processing a call and not but I have no idea why. Try catching the error and then calling a GET on the vehicle details. Do the same when it eventually completes and check if there are any obvious differences in parameter values it responds with - that may help debug it,

I’m a developer by profession and I’ve not got round to playing with the API yet but am quite looking forward to it. I’m probably going to be doing the same as you so, when I do, I’ll see if I can reproduce the issue.
 
  • Like
Reactions: Glan gluaisne
Have you tried a POST wake_up before the POST charge_stop?

It shouldn't need it, as it seems that the car is always awake when charging, but you never know!

It would be nice if Tesla would just endorse the use of their API officially, so we had solid info on how it works, especially as it seems that there are now lots of app using the unofficial API anyway.

If I had to guess, I'd say the car is fine with just a wifi connection, as it seems to prefer to connect via wifi if it can (just going by it always connecting to my home network as soon as it's within range).

Like you, my guess is that all the GET stuff comes mainly from the recorded status held on the server, and doesn't bother to make any calls to the car, unless, perhaps, it's already awake.

BTW, I'm doing something vaguely similar, but using micropython on an ESP8266, just to make it a bit more challenging...

Yes, the car always seems to be online when I attempt to stop charging, I always do a get ../api/1/vehicles call to ensure it is online. I only call the ../api/1/vehicles/:id/wake_up if the car is offline or asleep. Maybe I should try adding a wake_up in any case. Should not do any harm.
Good luck with your micro chip & micro python project.
 
  • Like
Reactions: Glan gluaisne
Hi All,

As this thread is still ongoing I just wanted to check that EVERYONE reading this has already raised a Service Appointment request for these issues with Tesla already? Can you Like this post if you have done it?

The only way they are going to prioritise getting this fixed is seeing lots of support tickets raised. Here is some text again to copy and paste into your request. It will take you 30seconds and make a big difference!

"I am raising a service request as my car is not operating as designed:
1. Car does not wake from sleep when offered charge
2. When using scheduled charge car always charges at 16A even though offered 32A
3. During charging car does not automatically accept the maximum charge rate (Amps) when the charger varies this over time."


Also I kept having issue number 2 and it happens on the nights I need the charging the most. I have therefore written a NodeRed workflow on my Raspberry Pi that checks the charge rate of the charger (OpenEVSE so has local API but you could use the Tesla API too) at 00:35 and if its <17Amps it disables the charger for 30seconds and enables it again which seems to clear the issue and charge at Max. If anyone wants a copy to play with I am happy to share.

@Jeremy Harris Did you get any further with your experiments on the pilot line and trying to simulate the UMC? I wonder if faking that the charging cable has been unplugged would wake up the car? Did you manage to intercept what the UMC was sending on the Pilot?

Thanks All!
 
  • Like
Reactions: G1201
@Jeremy Harris Did you get any further with your experiments on the pilot line and trying to simulate the UMC? I wonder if faking that the charging cable has been unplugged would wake up the car? Did you manage to intercept what the UMC was sending on the Pilot?

I've not got any further with trying to analyse the data during the initial few seconds when the UMC and car are using digital comms, mainly because it's been a bit too cold to be outside trying to capture data with a laptop.

I did change the software in my charge point, so that it delays turning on the control pilot PWM for a few seconds after detecting the plugged in state. I did this really just to partially emulate what the car and UMC do during that digital comms period. Since making this change I've not had a scheduled charge drop back to 16 A, although I have had a scheduled charge fail completely.

The latter is almost certainly unrelated to this problem, though, as I now believe it was a problem caused by a very cold overnight temperature, that caused the CP voltage to drop very slightly out of spec (the DC-DC converter that generates the +12V/-12V seemed to reduce the output voltage very slightly when very cold). I changed the DC-DC converter for one with a better temperature spec and all seems well, even when I've dosed the DC-DC converter with freezer spray (something that always caused a failure to charge before).

I also now always ensure that the car checks the charge point when it's plugged in for a scheduled charge. I've found that every time the car is plugged in as soon as I get home, and the scheduled charge screen comes up, with the charge point turning on and the current ramping up to maximum, before the car shuts the charger down, it charges at the maximum advertised current. Since adopting this procedure, together with the short delay before the CP PWM comes up, I've not had a single instance of reduced charging on scheduled charge.

I'm at a loss to understand what's really going on, though, but before I adopted this way of charging I was getting fairly regular scheduled charges at 16 A, rather than the set maximum.
 
  • Like
Reactions: Roy W.
I'd like to add to this thread if anyone can offer any help?

I have a Zappi 2 charger running the 2143 firmware trying to charge my Model 3 00:30 - 4:30

I cannot get the charger to wake the car for the Octopus Go period since the firmware updated.

Previously the car had a charge scheduled for 00:30 and the Zappi was on Eco+ with a timed boost for the same period and this worked flawlessly. Now the car won't wake to charge.I don't want to leave sentry on to keep the car awake nor do I want to give my login credentials to a third party app to send a wake command to the car.

Does anyone have any suggestions please?
 
I'd like to add to this thread if anyone can offer any help?

I have a Zappi 2 charger running the 2143 firmware trying to charge my Model 3 00:30 - 4:30

I cannot get the charger to wake the car for the Octopus Go period since the firmware updated.

Previously the car had a charge scheduled for 00:30 and the Zappi was on Eco+ with a timed boost for the same period and this worked flawlessly. Now the car won't wake to charge.I don't want to leave sentry on to keep the car awake nor do I want to give my login credentials to a third party app to send a wake command to the car.

Does anyone have any suggestions please?
Will it work if you use the car charge scheduling to start the charge at 00.30?
 
If you set Zappi to fast the timed boost will be ignored, it will switch on when the car wakes up, (whenever that is), or when schedule starts and then wont switch off until its fully charged.

If you put Zappi in eco Plus then it should do as you suggest.
 
I'd like to add to this thread if anyone can offer any help?

I have a Zappi 2 charger running the 2143 firmware trying to charge my Model 3 00:30 - 4:30

I cannot get the charger to wake the car for the Octopus Go period since the firmware updated.

Previously the car had a charge scheduled for 00:30 and the Zappi was on Eco+ with a timed boost for the same period and this worked flawlessly. Now the car won't wake to charge.I don't want to leave sentry on to keep the car awake nor do I want to give my login credentials to a third party app to send a wake command to the car.

Does anyone have any suggestions please?

You could try the up to date firmware that is now at 2.161. Updating the firmware on your myenergi devices - myenergi
However, it's surprising that the car was successfully woken previously by the Zappi anyway, if fully asleep, as this is an ongoing issue from the Tesla end of things. Myenergi have been tweaking the updates to try an work around some of the other issues such as M3s that have been charging at half rate. I must admit I just leave the Zappi on Fast and set the start time on the car.
 
  • Like
Reactions: Chopper
Thanks I think I'll try fast and guestimate the charge end time by dropping the charge %

I presume that like me you are on the Octopus 4 hour 00:30 to 04:30. On the SR+ I can get maximum of 56% in that 4 hour window so it's just a case of adding that number to my current battery percentage to see if it will reach my set maximum charge percentage and fit within the 4 hour window. Anyway, if it goes over a bit it hardly breaks the bank!
 
Thanks for those who replied. I've changed the Zappi to fast and used the cars scheduling which seems to have worked last night.

My Model 3 P seems to charge at 10.18% per hour so some simple maths allows me to adjust the charge limit to match whatever period I'm aiming for during the cheaper Agile prices.

Tesla really needs to add start and stop times to its options and also to add multiple time points in one day. It surely can't be that hard for them to add this?! It also needs to be able to be set from the app as well as in the car.
 
  • Like
Reactions: Roy W.
So, a dumb question.. I've ordered a Model 3 and hadn't even thought that this might be a problem.

I've got an Andersen A2 charger which is set to "unlock" between 00:30 and 04:30 to charge my (Evezy) i3. I plug the car in when I get back from work, it seems to sense that it is plugged in to a charger but nothing happens at that point. At 00:30 the charger unlocks and the car starts charging.

I don't have to use the scheduled charge time feature on the car at all, and in fact specifically don't use this because otherwise the car would use mains power to pre-condition itself in the morning before I set off (I have scheduled departure enabled).

Am I right in thinking therefore, based on the above, that this won't work on the Model 3? That I would somehow need to manually wake the car up to charge even if it "sees" something come alive and try to charge it?
 
Hi Durzel,

The Model 3 uses a non standard protocol for charging (even different to the Model S and X) so when it goes into sleep mode an EVSE cannot "wake" the car to charge.

If the Anderson (lovely bit of kit by the way) suffers the same issues as the Zappi then you will have to consider the following workarounds until Tesla brings their firmware in line with every other EV on the road!

1. Leave sentry mode on at home to keep the car awake (very power hungry and you will waste energy doing so).
2. Use a third party app such as Teslafi to "wake" the care before the Anderson starts the charge. Costs £5 per month.
3. Use the cars inbuilt scheduling to initiate the charge. (Currently you can only set a start time and not a stop time so you may run over into a more expensive electricity period - I presume from your timings you are on Octopus Go so you will shift from 5p to 13p per kWh) You can fudge the stop time by guestimating the % added as per my post #158