-
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
Solved it myself. For any others interested, you need to set STOR BIGINT AS STRING in your jason_decode function. Otherwise it will store a float value which creates problems when dealing with the API.
hans
P631
Yes. Nothing has changed then with the new apis. Somehow I just got the two confused again. Probably because they are so much larger now ( the new short length id is longer than the old long length id). Now Tesla is covered in anyone ever buys more than a trillion vehicles ;-)
Idempotent commands
Most of the commands in the API seem to be idempotent. For example, if I send the command to unlock the doors, then send it again, the second call returns success. It doesn't return an error saying they are already unlocked. This also holds for setting the HVAC target temp, setting the pano roof to a given state, etc.
The one place I've seen the API operate differently is the "set charge limit" call. If I set the charge limit to 90% and then do that again, I'll get an error with the reason "already_set" as shown below:
Does anyone know of other calls that return an error even when the desired state has been achieved?
Most of the commands in the API seem to be idempotent. For example, if I send the command to unlock the doors, then send it again, the second call returns success. It doesn't return an error saying they are already unlocked. This also holds for setting the HVAC target temp, setting the pano roof to a given state, etc.
The one place I've seen the API operate differently is the "set charge limit" call. If I set the charge limit to 90% and then do that again, I'll get an error with the reason "already_set" as shown below:
Code:
[FONT=Menlo]{"response":{"reason":"already_set","result":false}}[/FONT]Does anyone know of other calls that return an error even when the desired state has been achieved?
Here's a working curl command:
Code:
curl -H "Authorization: Bearer e7434f7a1...96b739" \
-H "Content-Type: application/json" \
--data '{"percent" : "90"}' \
-i [URL="https://owner-api.teslamotors.com/api/1/vehicles/5854725160300941028/command/set_charge_limit"]https://owner-api.teslamotors.com/api/1/vehicles/58547...028/command/set_charge_limit[/URL]The equivalent works through my Java client API.
Tesla Companion already fully integrate the calendar into the App, still is under Beta and is been tested for aboout 50 users (waiting for all language translation to be released to the store), the API to integrate the calendar is fairly simple once you replicate the calendar structure JSon request.
If you are interested to know more about the calendar structure let me know and I can dump it here.
If you are interested to know more about the calendar structure let me know and I can dump it here.
My logger hasn't changed since August of 2013 but has been reporting
for the last day or so. I haven't used any other REST to talk to the car in at least a week, so no increase in querying rate on my end. They may be having "the Azure bug" again.
Code:
System.Net.WebException: The remote server returned an error: (429).@brianman - Is that an intermittent error message? Looking back at my data from yesterday I can tell that it was cutting out every so often.
hans
P631
HTTP 429 Too Many Requests
Did Microsoft do something to Azure that ran too many copies of your code or something? Maybe some other Azure hosted client is getting their public IP blocked.
It is possible that Tesla is tweaking their DoS and other security thresholds. I got a message yesterday about having to reset my password because of too many failed login attempts. It was true that my login attempts were incorrect (debugging some new code) but I don't remember getting cut off so quickly before.
By "the Azure bug", I'm referring to my working theory that all Azure VMs on the same host or cluster or whatever probably come through a common hub/router/whatever and Tesla's throttling probably doesn't filter it's load throttling by account/car id.
hans
P631
That might explain why some people get unexpectedly blocked. I would think that the same problem would effect anyone running their code on AWS or Heroku or any other cloud provider. All the internal IPs are unregistered so the outbound traffic gets mapped to the same public IP by the NAT. I suppose if enough people at Google have Tesla's and use their corporate WIFI they could even get Google blocked.
hans
P631
Finally posted the Node-Red stuff I've been working on. It's a drag n' drop web based GUI for wiring up the Tesla with the "Internet of Things". Full post in the TeslaMS thread if anyone wants to try it out and give me feedback.
Anyone else noticing that their car has been charging slightly over the preset with 6.0? Here's is my charge_status from this morning (likely 9 hours after charge complete):
{"charging_state":"Complete","charge_limit_soc":90,"charge_limit_soc_std":90,"charge_limit_soc_min":50,"charge_limit_soc_max":100,"charge_to_max_range":false,"battery_heater_on":null,"not_enough_power_to_heat":null,"max_range_charge_counter":0,"fast_charger_present":false,"fast_charger_type":"<invalid>","battery_range":230.88,"est_battery_range":242.62,"ideal_battery_range":269.58,"battery_level":91,"usable_battery_level":91,"battery_current":0.0,"charge_energy_added":30.02,"charge_miles_added_rated":102.0,"charge_miles_added_ideal":117.5,"charger_voltage":0,"charger_pilot_current":null,"charger_actual_current":0,"charger_power":0,"time_to_full_charge":null,"charge_rate":0.0,"charge_port_door_open":false,"motorized_charge_port":false,"scheduled_charging_start_time":1414035000,"scheduled_charging_pending":false,"user_charge_enable_request":null,"charge_enable_request":false,"eu_vehicle":false,"charger_phases":null}
{"charging_state":"Complete","charge_limit_soc":90,"charge_limit_soc_std":90,"charge_limit_soc_min":50,"charge_limit_soc_max":100,"charge_to_max_range":false,"battery_heater_on":null,"not_enough_power_to_heat":null,"max_range_charge_counter":0,"fast_charger_present":false,"fast_charger_type":"<invalid>","battery_range":230.88,"est_battery_range":242.62,"ideal_battery_range":269.58,"battery_level":91,"usable_battery_level":91,"battery_current":0.0,"charge_energy_added":30.02,"charge_miles_added_rated":102.0,"charge_miles_added_ideal":117.5,"charger_voltage":0,"charger_pilot_current":null,"charger_actual_current":0,"charger_power":0,"time_to_full_charge":null,"charge_rate":0.0,"charge_port_door_open":false,"motorized_charge_port":false,"scheduled_charging_start_time":1414035000,"scheduled_charging_pending":false,"user_charge_enable_request":null,"charge_enable_request":false,"eu_vehicle":false,"charger_phases":null}
Temp differences between charge completion time and subsequent SOC reading?
I note a bit of a range difference for a given SOC depending on temp. If the pack was colder when charging and then subsequently warmed up, might it read at a higher SOC?
I note a bit of a range difference for a given SOC depending on temp. If the pack was colder when charging and then subsequently warmed up, might it read at a higher SOC?
Similar threads
