Stopping charge through the API

[JCremonini]

I’ve started writing an app to schedule charging at the times I want.

My code logic determines if the current time is in the charge period and, if it’s isn’t and the car is charging , it makes a charge_stop call ( I want to be able to go put, drive the car , come back and then plug it in to the charger and my app will stop the charge if it isn’t in the correct time period ). I also make sure the car is awake and online before I do this. The problem is that, despite getting a 200 result code from the call , it fails to stop the charging ( if I then make a charge_port_open call that returns a response of Result: false Reason: charging - and the charge_state remains at Charging)

Anyone had luck doing this ?

 

[Glan gluaisne]

Not tried this yet, but very interested in the outcome.

One problem we seem to have is that the API is unofficial and so not fully documented, so we have no easy way of finding out about any dependencies. It may be, for example, that POST charge_stop only works if there has been a preceding POST charge_start, perhaps?

I'm thinking out aloud a bit here, but there could be other priorities at work here, too. The physical interface from the charge port control to the car may have priority over commands sent via the API, perhaps?

I'd like to implement something very like the scheduled charging set up you're working on, but am way behind you at the moment, I'm still trying to get some hardware working for a dedicated control interface, that I will probably integrate into my charge point.

 

[tsh2]

I've noticed a couple of times recently where the app failed to 'stop charging'. Maybe on the first charge after a software update, unless that was a coincidence. I didn't investigate, just changed the 'charge percentage' instead.

 

[Jason71]

I am also writing some software. server based rather than app, but had not got as far as actually trying it in practice.
Worried by your post I just gave it a go using direct API calls from Soap UI.
Seems to work fine. My calls seem to do exactly the same as the "stop charge" button in the Tesla app, which is what you would expect.
I cannot replicate your issue:

This is what my request looks like:

POST https://owner-api.teslamotors.com/api/1/vehicles/xxxxxxxxxxxxxxx/command/charge_stop HTTP/1.1
Accept-Encoding: gzip,deflate
User-Agent: Jasons_Test_application
Authorization: bearer <insert token here>
Content-Type: application/json
Content-Length: 0
Host: owner-api.teslamotors.com
Connection: Keep-Alive

(no payload)


and the response is:

HTTP/1.1 200 OK
Server: nginx
Date: Sun, 05 Jan 2020 14:38:02 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 40
Connection: keep-alive
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
(plus a few other headers)

{"response":{"reason":"","result":true}}

 

[JCremonini]

Not tried this yet, but very interested in the outcome.

One problem we seem to have is that the API is unofficial and so not fully documented, so we have no easy way of finding out about any dependencies. It may be, for example, that POST charge_stop only works if there has been a preceding POST charge_start, perhaps?

I'm thinking out aloud a bit here, but there could be other priorities at work here, too. The physical interface from the charge port control to the car may have priority over commands sent via the API, perhaps?

I'd like to implement something very like the scheduled charging set up you're working on, but am way behind you at the moment, I'm still trying to get some hardware working for a dedicated control interface, that I will probably integrate into my charge point.

APIs are always unofficial as it makes it easy for the software company to pull the plug on them when they want.

Despite the principle that the charge_stop call should never have a dependency on a charge_start call I tested your theory and you are correct. This time the start_charge calls returns 200 with a Result: False Reason: charging ( which is what I would expect ). But it clearly triggers a flag which then enables the charge_stop call to then work ( Result: True) , and the port unlocks too. This, in my experience of developing REST based apps goes against all the principles of it.

Well done

I’ll see if I can determine what the state change is between the car starting the charge when I plug the cable in and it being triggered by the REST call.

 

[JCremonini]

I am also writing some software. server based rather than app, but had not got as far as actually trying it in practice.
Worried by your post I just gave it a go using direct API calls from Soap UI.
Seems to work fine. My calls seem to do exactly the same as the "stop charge" button in the Tesla app, which is what you would expect.
I cannot replicate your issue:

This is what my request looks like:

POST https://owner-api.teslamotors.com/api/1/vehicles/xxxxxxxxxxxxxxx/command/charge_stop HTTP/1.1
Accept-Encoding: gzip,deflate
User-Agent: Jasons_Test_application
Authorization: bearer <insert token here>
Content-Type: application/json
Content-Length: 0
Host: owner-api.teslamotors.com
Connection: Keep-Alive

(no payload)


and the response is:

HTTP/1.1 200 OK
Server: nginx
Date: Sun, 05 Jan 2020 14:38:02 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 40
Connection: keep-alive
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
(plus a few other headers)

{"response":{"reason":"","result":true}}

I was also getting Result : True from the charge_stop call it was the open port call which was returning false . You need to check with the car that it actually stopped charging.

 

[Jason71]

APIs are always unofficial as it makes it easy for the software company to pull the plug on them when they want.

Despite the principle that the charge_stop call should never have a dependency on a charge_start call I tested your theory and you are correct. This time the start_charge calls returns 200 with a Result: False Reason: charging ( which is what I would expect ). But it clearly triggers a flag which then enables the charge_stop call to then work ( Result: True) , and the port unlocks too. This, in my experience of developing REST based apps goes against all the principles of it.

Well done

I’ll see if I can determine what the state change is between the car starting the charge when I plug the cable in and it being triggered by the REST call.

I cannot see this dependency. its working fine for me
I can start charging from the car. Then stop it from the app.
The stop charging api call is exactly the same as the stop charging call from the Tesla app ( or it should be) it would be very odd if the "stop charge" option in the app did not work.
could it be a timing thing? does there need to be a delay for the charting to fully start before the stop command is accepted and acted upon?
if your app is stopping charge as soon as it starts could it be too soon some how?

 

[Jason71]

I was also getting Result : True from the charge_stop call it was the open port call which was returning false . You need to check with the car that it actually stopped charging.

i did. and it did stop charging.

 

[JCremonini]

I’m just running a test on my code to ensure it will work with a begin and end time then I’ll unplug from the car, plug back in and take the start_charge call out and report back with my test results.

 

[Jason71]

I’m just running a test on my code to ensure it will work with a begin and end time then I’ll unplug from the car, plug back in and take the start_charge call out and report back with my test results.

I just checked again. replicating your situation as best as I could. set the car to start charge as soon as charger connected.
plugged in the charger. Charging started. sent the stop command, Charging stopped ( checked via the api and the car itself)
there was probably a minute between the charging start and the stop command being sent since I am doing it from a laptop in the house
I think if there was an issue with the app being unable to stop charging under some circumstances we would have heard about it.
So it sounds to me as if the issue may be specific to you. For the record I am on 2019.40.50.1.

 

[JCremonini]

Update.

Well, I unplugged the cable , plugged it back in and allowed the car to start charging, took out the charge_start call and the issue does not reproduce . In a way I am pleased because it never made sense that the charge_start call was needed.

The only thing I did do before which may have actually got it working was to switch on to scheduled charging and then turned it off but as far as my code if concerned I definitely only added the charge_start call.

I’m more than happy really because my code works and will switch on and off charging at set times as I wanted it to do to start with.

 

[Jason71]

Update.

Well, I unplugged the cable , plugged it back in and allowed the car to start charging, took out the charge_start call and the issue does not reproduce . In a way I am pleased because it never made sense that the charge_start call was needed.

The only thing I did do before which may have actually got it working was to switch on to scheduled charging and then turned it off but as far as my code if concerned I definitely only added the charge_start call.

I’m more than happy really because my code works and will switch on and off charging at set times as I wanted it to do to start with.

OK, cool. Lets hope its a one off and not an issue that will come and go based on some factor that we don't currently understand. If it is I expect I will hit it sooner or later as well!

 

[NewbieT]

Sounds obvious but worth checking the car is ‘online’ when you’re testing charge start /stop commands. Caught me out a couple of times. I send a wake command pause 2 seconds and then the command just in case.

 

[JCremonini]

Sounds obvious but worth checking the car is ‘online’ when you’re testing charge start /stop commands. Caught me out a couple of times. I send a wake command pause 2 seconds and then the command just in case.

Already do that. I check the state and , if it is not online, I send a wake up call and retest the state, only going on if the car is online ( done using a simple while loop )

 

[pmg102]

Isn’t the car always awake while charging?

Genuine question... is assumed it would be, but I guess it might be able to charge whilst sleeping?

 

[JCremonini]

Isn’t the car always awake while charging?

Genuine question... is assumed it would be, but I guess it might be able to charge whilst sleeping?

It is, yes. But don’t forget the idea of this code is to set the car to charge so it might not be awake at that point. It’s easier to code a generic test/set function than worry about whether it may already be awake.

 

[Koenkk]

In my case it seems that the charge stop API call stops working after I enabled the "Planned departure" feature via the charging menu. After disabling this I'm able to stop the charging via the API again.

 

[Bobly]

APIs are always unofficial as it makes it easy for the software company to pull the plug on them when they want.
.

This is not the case, many systems rely on standardised, well documented and supported APIs to communicate and for some businesses this could be their entire operating model, for example.. Internio the company behind something many of us are familiar with "A Better Route Planner", sell access to their API - Iternio Route Planner API – Iternio, the google Maps API is another very common example or new businesses like Token | The Smart Move in Open Banking which provides an Open Banking API - this is pretty much all they do.

 

[JCremonini]

This is not the case, many systems rely on standardised, well documented and supported APIs to communicate and for some businesses this could be their entire operating model, for example.. Internio the company behind something many of us are familiar with "A Better Route Planner", sell access to their API - Iternio Route Planner API – Iternio, the google Maps API is another very common example or new businesses like Token | The Smart Move in Open Banking which provides an Open Banking API - this is pretty much all they do.

You are quite right of course. I was being a little blasé having been the victim of a pulled API or two in the past.