Tesla Integration to Query Status and Send Commands to Your Car

[kahn-hubitat]

@gomce62.web

reason why that attribute was removed as it was one I was planning to use a rule to have the car automatically "vent" the windows if the Outside temp got to hot

I dont recall removing it.. when was the last time yo usaw it.. i know the normal temp was removed when it was converted over to actual temperature capability

also i dont see it coming back in my info..

chargeState:[battery:85, batteryRange:250.18, chargingState:Complete, chargeLimit:85, minutes_to_full_charge:0], driveState:[latitude:42.908368, longitude:-72.398109, method:wgs, heading:90, lastUpdateTime:Tue May 24 13:36:56 EDT 2022], vehicleState:[presence:present, lock:locked, odometer:35032.75911, sentry_mode:Off, front_drivers_window:Closed, front_pass_window:Closed, rear_drivers_window:Closed, rear_pass_window:Closed, valet_mode:Off, tire_pressure_front_left:null, tire_pressure_front_right:null, tire_pressure_rear_left:null, tire_pressure_rear_right:null], climateState:[temperature:65.48, thermostatSetpoint:69.08, seat_heater_left:0, seat_heater_right:0, seat_heater_rear_left:0, seat_heater_rear_right:0, seat_heater_rear_center:0]]

[kahn-hubitat]

I dont think it was ever in there as i went back to my oldest code.

Anyway, I added outside_temperature as an attribute and also added
passengerSetpoint as an attribute (but you cannot change it via a therm. control) as with the normal setpoint which is an actual therm control.

[jakokln]

Updated to latest version on github. I'm seeing outside_temperature there now. All seems to be well, didn't need to get a new token to upgrade. I'll see if it continues to refresh or not, though I am assuming it will continue working just fine

[gomce62.web]

I think you are correct as it looks like I might have added outside_temp after the version I sent you back in Dec. 2020 and forgot to send you the update. Thanks for adding it to the current version of your code and huge thank-you to you and @brad for finding a way to solve the token refresh issue

[brad]

@kahn-hubitat

finally here is the new code to test thanks....
hubitat/tesladriver.groovy at master · lgkahn/hubitat · GitHub
hubitat/teslaconnectv3.groovy at master · lgkahn/hubitat · GitHub

I ran the endpoint option for a couple days using the v3 app and everything tested out ok. Switched to app refresh, and that’s been working great too for a day now through multiple refreshes.

I ended up used the code you linked just above, because HPM wasn’t showing any updates and when I tried to do a repair, I received old versions of the app and driver. I don’t see outside_temperature in this version, so I’m wondering if I’m on the correct one.

Disregard - I see it in the code. My car has been offline since the update, so the attribute hasn’t populated on the device.

[kahn-hubitat]

Ya i.havent updated the version on package manager yet.

[kahn-hubitat]

Some new changes, both app and driver update.
Decided to add attributes to show the last token update time, and the next scheduled time.
You can now use an app or right a rule to notify if the token update time does not change every so often.

It turned out to be a little more complicated than I thought as the updates occur in the app and the attributes are in the child driver.
I had to enumerate through children and call the fx in the child driver.

I also thought about the changes I wanted to do where commands were not working becuase the wake command it not finishing before the actual requested command is issued..
The 2 sec pause between the commands used to be sufficient but apparently tesla's api is slower now or something.

Anyway I talked about waking,, check status, till awake, issue command and check status again.
This would be a great deal of code change so as a stop gap to test I made the pause time user configurable in the app, It now is 2, 3, 4, 10, etc seconds

Since 2 secs is not working I also changed the default to 10 secs.

You need to go back in the app and set the new parameter.

8-10 secs seems to work well for me at least for my lock and unlock commands.

Of course as always you wont see the updated status in the car device unless you also do a refresh or wait for the next cycle.

Related to this I also implemented code to sense the vehicle unavailable error on any command, pause the pauseTime and issue a wake, pause again and then retry the command up to 3 times.
The pause will get exponentially longer based on your set pause time and the attempt number.
So if for example your pause time is set to 4 secs. it will after getting the error
pause 4 secs
issue the wake
pause 4 more secs.
retry the command

if it still fails on the next iteration it will pause for 8 secs instead etc. etc.

See below for example.

I also had to add an attribute with time in integer secs to make writing the rule easier.
Here is the rule I wrote to check, but there must be a better way. Someone more knowledgeable in doing date time match in rule machine may know and if you have a better way maybe I dont need the extra attribute .. thanks

These are some big changes and it took awhile.. especially the retries with exponential backoff.
So please test.

[brad]

Thanks! Installed and did some quick tests. Initially:

• Typo in the app for the new seconds delay config - issueing
• Tried Unlock and Open Charge point command and received error. Looking at the code, looks like this command wasn’t updated with the new pause app:6262022-05-26 08:14:55.897 errorgroovy.lang.MissingMethodException: No signature of method: user_app_trentfoley_Tesla_Connect_3_0_167.pauseFromEnum() is applicable for argument types: () values: [] on line 586 (method unlockandOpenChargePort)
• RE the new pause time - it looks like this is waiting the selected amount of time even for the first try. It would be better if it make one attempt (say with a 2-second pause) and then retries using the selected seconds. If the car is already online, I would want the command to happen ASAP (e.g. if I’m walking up to my car with groceries and I use a voice command to open the trunk)
• If I set the time too low and the command fails after 3 attempts, a Tesla token refresh is then executed by the app. I’m not sure if this is intended, but not sure why this would be necessary… maybe to ensure the errors aren’t caused by an expired token/auth issue?
• The code seems to jam up the hub a bit. If I issue a command and then try to switch to load logs, logs won’t load until after the sequence of commands has run. I’ll continue to test this more.

[kahn-hubitat]

@brad

• Typo in the app for the new seconds delay config - issueing
• Tried Unlock and Open Charge point command and received error. Looking at the code, looks like this command wasn’t updated with the new pause app:6262022-05-26 08:14:55.897 errorgroovy.lang.MissingMethodException: No signature of method: user_app_trentfoley_Tesla_Connect_3_0_167.pauseFromEnum() is applicable for argument types: () values: [] on line 586 (method unlockandOpenChargePort)

fixed it.. not a typo.. missed changing that..

as for the time.. it is supposed to not have to try and retry if you can help it so better to set a long enough time rather than causing multiple calls through the api..

as for hanging up your hub nothing like that here.

token refresh always occured after a failiure previously even on the first time, that has not changed.

[brad]

Got it. Thanks. I’ll continue to test and loop back with any additional feedback.

[kahn-hubitat]

maybe two different time parameters.. first and retry?

or get rid of the wake calls entiredly in the iinitial try? That may be the best option .
maybe try it yourself removing the wake call from one or two commands and then see how it performs with a longer pause time.

[kahn-hubitat]

ok more tweaking..
added new parameter..
controls whether the wake and pause are issued on the initial command or not.

That way you can keep the app working as it has or configure it to your liking with the pause time and rely on the unavailable/failure sensing to reissue the command.

Also changed it to 4 tries as you loose one try immediately if car is asleep.

[brad]

Nice. I turned this off so there’s no delay on the first attempt… and it works. It looks like since the first “non-wait” counts as an attempt in the code, it also steps up the wait. Not a big deal because you can select a lower initial #, but just a note. I had set to 6 seconds, and the first wait was 12.

app:6262022-05-26 13:42:26.469 info Pausing for 12 seconds between wake and command retry.
app:6262022-05-26 13:42:26.465 info Will Issue a Wake command, wait and retry.
app:6262022-05-26 13:42:26.462 info Got Back vehicle unavailable (408) ... Either disconnected or most likely asleep.
app:6262022-05-26 13:42:26.456 debug Vehicle Unavailable
app:6262022-05-26 13:42:26.450 debug set unavaiable to true 
app:6262022-05-26 13:42:26.445 debug got errorString = vehicle unavailable: {:error=>"vehicle unavailable:"}
app:6262022-05-26 13:42:26.441 debug in error handler case error = groovyx.net.http.HttpResponseException: status code: 408, reason phrase: Request Timeout response data = e.response data = [response:null, error:vehicle unavailable: {:error=>"vehicle unavailable:"}, error_description:]
app:6262022-05-26 13:42:25.516 info authorizedHttpRequest2 body: [command:vent]
app:6262022-05-26 13:42:25.512 info authorizedHttpRequest2 Tesla POST /api/1/vehicles/1234567890/command/window_control attempt 1
app:6262022-05-26 13:42:25.508 debug in authorize http req with child child=Tesla attempts=1
dev:6762022-05-26 13:42:25.492 debug Executing 'Venting Windows'

[kahn-hubitat]

@brad

Nice. I turned this off so there’s no delay on the first attempt… and it works. It looks like since the first “non-wait” counts as an attempt in the code, it also s

good catch.. i originally had the wait count as 0 as that is what was already in the app but it wasnt working right as 0 can also be confused as null in groovy, so I changed it to 1 intitially and didnt compensate.

fixed in the github.

[kahn-hubitat]

I thinik this is probably it for now unless you find something else as going away for the summer and the car will be lonely in the garage ...

Hopefully tesla will not change #$@ again while I am gone..

I hesitate to replace the older github directly as it will break without manual intervention.. What do you think.

[jakokln]

@kahn-hubitat

Hopefully tesla will not change #$@ again while I am gone..

I'm not sure we can get that lucky

Would it be worth releasing this as a new github entry and a new entry within HPM? Maybe update the old version with a notice saying it is depreciated and to use this version instead? Though, I feel most who are using this integration are probably aware of the issue (since things don't work anymore otherwise)

[brad]

@kahn-hubitat

I hesitate to replace the older github directly as it will break without manual intervention.. What do you think.

I guess my thought would be to leave it go as it is if you don't have time to create a new HPM package as jakokin suggested. Those on the HPM version that are unaware of the changes (if that's possible) can continue on as they are. If anyone is looking for a solution and stumble across this topic, they can read the instructions in the thread and update using the Github link you provided above.

[kahn-hubitat]

@brad

I guess my thought would be to leave it go as it is if you don't have time to create a new HPM package as jakokin suggested. Those on the HPM version that are unaware of the changes (if that's possible) ca

thanks
NO his idea was ok I am not leaving for another week I will create a new package..

[kahn-hubitat]

Had a weird error recently.. not sure if the auto refresh token after it fixed it or it fixed itself..

[brad]

@kahn-hubitat

Had a weird error recently

I saw this a few times too, and a refresh happened right after. Maybe too many calls at once so Tesla server ignored one causing the deadline exceeded timeout? Guessing

app:6262022-05-26 21:31:27.901 infoGetting updated refresh token and bearer token for access token
app:6262022-05-26 21:31:27.900 debugin refresh access token
app:6262022-05-26 21:31:27.898 errorRequest failed for path: /api/1/vehicles/1234567890.  [response:null, error:GRPC::DeadlineExceeded: Deadline Exceeded, error_description:]
app:6262022-05-26 21:31:27.896 debuggot errorString = GRPC::DeadlineExceeded: Deadline Exceeded
app:6262022-05-26 21:31:27.894 debugin error handler case error = groovyx.net.http.HttpResponseException: status code: 504, reason phrase: Gateway Timeout response data = e.response data = [response:null, error:GRPC::DeadlineExceeded: Deadline Exceeded, error_description:]
app:6262022-05-26 21:31:25.253 infoauthorizedHttpRequest2 Tesla GET /api/1/vehicles/1234567890 attempt 1