Some recent software update (presumably) on my Model S has broken my streaming script. Now, when I send a subscribe message, I simply get no response. It doesn't seem to matter if the car is asleep or awake. It seems much like how it behaves for Model 3, which I don't think anyone has figured out, so I don't have a lot of hope. But does anyone have any ideas?
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Model S REST API
- Thread starter timdorr
- Start date
-
- Tags
- Model S User Interface
Dan203
Active Member
Does anyone know what the end point...
/api/1/users/command_token
does?
I figured out that if you send it your user name and password as JSON, like the auth function, you get a 200 OK with this...
{
"response": "ReallyLongStringThatIAssumeIsAKeyToSomething"
}
I tried using the returned string as an auth token and it wasn't valid. Not sure what it's for
/api/1/users/command_token
does?
I figured out that if you send it your user name and password as JSON, like the auth function, you get a 200 OK with this...
{
"response": "ReallyLongStringThatIAssumeIsAKeyToSomething"
}
I tried using the returned string as an auth token and it wasn't valid. Not sure what it's for
pjw65
Member
As of Tesla JSON API there a some other "users" commands like "Powerwall order", "Service scheduling", "Referral data", "Roadside Assistance". What do they have in common?
From the "Endpoints File" of the link above:
From the "Endpoints File" of the link above:
Code:
"POWERWALL_ORDER_SESSION_DATA": {
"TYPE": "GET",
"URI": "api/1/users/powerwall_order_entry_data",
"AUTH": true
},
"POWERWALL_ORDER_PAGE": {
"TYPE": "GET",
"URI": "powerwall_order_page",
"AUTH": true,
"CONTENT": "HTML"
},
"ONBOARDING_EXPERIENCE": {
"TYPE": "GET",
"URI": "api/1/users/onboarding_data",
"AUTH": true
},
"ONBOARDING_EXPERIENCE_PAGE": {
"TYPE": "GET",
"URI": "onboarding_page",
"AUTH": true,
"CONTENT": "HTML"
},
"SERVICE_SELF_SCHEDULING_ELIGIBILITY": {
"TYPE": "GET",
"URI": "api/1/users/service_scheduling_data",
"AUTH": true
},
"SERVICE_SELF_SCHEDULING_PAGE": {
"TYPE": "GET",
"URI": "service_scheduling_page",
"AUTH": true,
"CONTENT": "HTML"
},
"REFERRAL_DATA": {
"TYPE": "GET",
"URI": "api/1/users/referral_data",
"AUTH": true
},
"REFERRAL_PAGE": {
"TYPE": "GET",
"URI": "referral_page",
"AUTH": true,
"CONTENT": "HTML"
},
"ROADSIDE_ASSISTANCE_DATA": {
"TYPE": "GET",
"URI": "api/1/users/roadside_assistance_data",
"AUTH": true
},
"ROADSIDE_ASSISTANCE_PAGE": {
"TYPE": "GET",
"URI": "roadside_assistance_page",
"AUTH": true,
"CONTENT": "HTML"
},
"AUTH_COMMAND_TOKEN": {
"TYPE": "POST",
"URI": "api/1/users/command_token",
"AUTH": true
},
"SEND_DEVICE_KEY": {
"TYPE": "POST",
"URI": "api/1/users/keys",
"AUTH": true
},Dan203
Active Member
I love the idea of using a real-world analog gauge for this .
you can figure out the actual power used by logging the charging_state.charger_power field.
it gives you the instant power being drawn from the wall . you have to do some math to figure out the actual kwh that were drawn over time .. you can then do chaging_state.charge_power_added / power_used to get efficiency if you care for that.. or calculate your costs for power using the power drawn rather than power added.
John Rucker
Member
Yep I can also get access to the charger's instant voltage and current. This is on the AC side and if I use Volts times Current = Power I get the same number as charger_power. The problem with this is I poll the car for that data ever minute and that only gives me a snap shot of the AC voltage and current at that moment. I could just assume that the current and voltage was the same for the time period between polls and could probably get pretty close. But at best it is still a guess of what is going on between my poll cycles.
So that is why I was looking for some percentage of overhead I could just add to the DC kWh being added to the battery. When I installed my home charger I put it behind a dedicated (calibrated) power meter. So what I did for about a month was just recorded the kWh readings from my dedicated meter and compared it to the DC kWh reported by my model X. Turns out there is an 8 to 10% overhead (90% to 92% efficiency ). So I just add 10% to my calculations to get my meter closer to really what is being used.
It is cool having the information displayed on a wall gage. Every morning we take a quick peek at the gauge and see what it cost to drive the car the previous day. A trip to WallMart and back in the winter can cost $1.25 but in the summer it is $0.75.
Just a FYI
We have a 7kW solar system at home and the next gauge I want to make will compare our solar generated kWh to the Tesla kWh used for charging. Our local electric here in down state Illinois is from coal & natural gas. It would be cool to know if I'm driving on sunshine or coal.
Thanks for the input!!
Looking for some assistance with API commands to start and stop charging. I have tried a tasker plugin and also home assistant Tesla integration and everything seems to work except starting and stopping charging. I have been able to unlock doors, honk the horn, turn on and off climate control, adjust charge limit (set to max and set from 50% to 90%). When I send the commands to stop charging I get a 200 response and "result": true response but the charging does not stop.
Instead of using the apps I mentioned before I ended up doing some tests with Tesla Owner JSON API · Apiary and have the same results. I have been able to get everything to work except for stopping and starting charging. As a work around if I set the charge limit to the lowest it will go, which looks like 50% and the car has charged past that limit already it will stop charging. When I set the limit higher than what it is at it will start charging again but this isn't the best solution because if it is less than 50% charged it will continue charging.
Using the Tesla android app I am able to stop and start charging so it works from there but not using any API calls. In searching and talking to the Tasker plugin author, I seem to be the only person that has this issue. Does anyone have any suggestions? Thanks.
I have a 2016, MS 90D.
Instead of using the apps I mentioned before I ended up doing some tests with Tesla Owner JSON API · Apiary and have the same results. I have been able to get everything to work except for stopping and starting charging. As a work around if I set the charge limit to the lowest it will go, which looks like 50% and the car has charged past that limit already it will stop charging. When I set the limit higher than what it is at it will start charging again but this isn't the best solution because if it is less than 50% charged it will continue charging.
Using the Tesla android app I am able to stop and start charging so it works from there but not using any API calls. In searching and talking to the Tasker plugin author, I seem to be the only person that has this issue. Does anyone have any suggestions? Thanks.
I have a 2016, MS 90D.
After setting up a packet capture I noticed that the Tesla App isn't actually working either. Commands are sent and the app looks like it stopped charging but after a minute the Tesla app updates and says it is still charging. Watching the car when I try to stop charging using the Tesla App, the charging is never actually interrupted at all. So I'll have to work with Tesla on why their Android app isn't working for me. I'm sure after that is resolved the API calls will work as well. Thanks
Thanks, helpt me really quick and easy! Created a Postman collection if anyone is interested, I can consider to share the Postman JSON data so you can Import into your Postman.
Does anyone know why the car's browser won't send its cookie when initiating a new WebSocket?
Just to be clear, I'm am not talking at all about Tesla's streaming endpoint. I'm playing around with a different web app. It can GET/POST just fine and sends a session cookie just as it should. But initiate a new WebSocket... not so much.
I've tried Chromium 79 on other platforms and they seem to work as expected. It's just Tesla's Chromium 79.
Example:
A normal GET request from Tesla's browser produces these headers:
GET /having/fun HTTP/1.1
Host: something
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; GNU/Linux) AppleWebKit/537.36 (KHTML, like Gecko) Chromium/79.0.3945.130 Chrome/79.0.3945.130 Safari/537.36 Tesla/2020.12.1-299292ad7782
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
cookie: TG9va2luZyBGb3IgU29tZXRoaW5nPw=="gAAAAABehmVJXHyjuD6oAhlOqjObu...HEeVh37uoEqGw="
But if initiated as a new WebSocket it produces this, without the cookie:
GET /no/fun HTTP/1.1
Host: something
Upgrade: websocket
Connection: upgrade
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (X11; GNU/Linux) AppleWebKit/537.36 (KHTML, like Gecko) Chromium/79.0.3945.130 Chrome/79.0.3945.130 Safari/537.36 Tesla/2020.12.1-299292ad7782
Origin: https://something
Sec-WebSocket-Version: 13
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Sec-WebSocket-Key: hAt/QCfMymssL/ROvUs4FQ==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Just to be clear, I'm am not talking at all about Tesla's streaming endpoint. I'm playing around with a different web app. It can GET/POST just fine and sends a session cookie just as it should. But initiate a new WebSocket... not so much.
I've tried Chromium 79 on other platforms and they seem to work as expected. It's just Tesla's Chromium 79.
Example:
A normal GET request from Tesla's browser produces these headers:
GET /having/fun HTTP/1.1
Host: something
Connection: keep-alive
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; GNU/Linux) AppleWebKit/537.36 (KHTML, like Gecko) Chromium/79.0.3945.130 Chrome/79.0.3945.130 Safari/537.36 Tesla/2020.12.1-299292ad7782
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
cookie: TG9va2luZyBGb3IgU29tZXRoaW5nPw=="gAAAAABehmVJXHyjuD6oAhlOqjObu...HEeVh37uoEqGw="
But if initiated as a new WebSocket it produces this, without the cookie:
GET /no/fun HTTP/1.1
Host: something
Upgrade: websocket
Connection: upgrade
Pragma: no-cache
Cache-Control: no-cache
User-Agent: Mozilla/5.0 (X11; GNU/Linux) AppleWebKit/537.36 (KHTML, like Gecko) Chromium/79.0.3945.130 Chrome/79.0.3945.130 Safari/537.36 Tesla/2020.12.1-299292ad7782
Origin: https://something
Sec-WebSocket-Version: 13
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Sec-WebSocket-Key: hAt/QCfMymssL/ROvUs4FQ==
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
insaneoctane
Well-Known Member
Anyone know how to access the firmware upgrade "queue" that TeslaFi has seemed to figure out? It would be useful for me to take some actions to ensure I am notified when I have new software available!
If I had to guess I'd say they are looking at software_update, returns something like this {"expected_duration_sec": 3000, "status": "installing", "download_perc": 100, "version": "2019.40.1.1", "install_perc": 30}.
pretty sure websockets by protocol definition are stateless and therefore cookieless.. they're pretty close to a direct tcp/ip connection with very little other context around the connection object itself. you'll need to manage state and session via the packet itself. Webrequest however (http/https) are stateful connections. So I'm not sure if you're referring to the same thing.
My script for renewing the session got this error yesterday. I had to tell it to not verify the certificate, and it worked fine. Oddly, my script for pulling the data did not have a problem with the certificate, so I'm not sure what's going on.
