Odd… TeslaFi says I’ve already got a V3 token, but WebCoRE seems to not work when trying to wake up the car. TeslaFi definitely has full access. Up until a half a week ago, everything was working fine with the same token. Literally nothing has changed in the code. Here’s an example of your wake-up… with the rest disabled. And yes, the car is awake already prior to the test.
Tesla API Access
That’s not unexpected at this point. Unfortunately, I’m deep in other projects and it may take me a week or two work through this.
So I’ve been doing some experimenting and this is what I’ve done to get everything working for me. It seems to be the wake-up loop that got the errors for some reason now, so I modified/removed it. And yes… I turned all the variables to global.
The way my " TESLA Warm car at work at end of day" piston works is…
- check if the car is ASLEEP. > If yes… wake it (wait 60sec… probably 45 or 30 is also actually good)
- if “ASLEEP” wasn’t a match then check if ONLINE
- If not ONLINE then car can’t be reached so just exit piston
- if all worked out, then rest of piston will run
- so…
- check if at work
- If yes then start climate
- wait 40min then check if STILL at work
- If yes turn off climate as there’s a departure delay
- if no… exit piston since I’m now driving
Has anyone got setting temperatures to work? Since day one for me (since Nov), it has never worked. When the command is sent to the car, the cars’ climate automatically goes to “LO” and the (I’m assuming) AC comes on instead of the car being set to 24C.
Here is my test piston which I manually run via the TEST button.
And yes… the car is already awake.
Thanks for putting this together for the community! Any update on the status of an updated piston? My token has expired, and I’m not able to figure out how to get a new one. Thanks again!
I have made some preliminary efforts. While generating the refresh token appears to be outside the scope of webCoRE’s capabilities, I believe webCoRE will be able to refresh the access token as needed and that piston functionality can be restored with some modifications. However, I haven’t gotten that far yet.
As for the refresh token, I was able to generate one using a Python script. There is also an iOS app called Authla that reportedly can be used to generate a token, but I haven’t tried it.
I’ll be tinkering with this further in the coming days as time allows.
Since I also use TeslaFi, I’ve been relying on its auto-generated token to copy/paste it into WebCoRE. I find if I use these WebCoRE routines for token generation, it becomes a conflict with the TeslaFi token and is null since a new token was generated via WebCoRE. It would be great if there was a way to just automatically take the TeslaFi token and use here in WebCoRE.
Thank you!.. I use TeslaFi as well, so I’ve resorted to that for now and paused the refresh piston.
Great, thanks! I’ll keep an eye out for an update. In the meantime I’ll use the manual method noted by @PrometheusXex below.
Like I said before, unless of course it was working out for you, but when WebCoRE would do the refresh, it would kill the TeslFi token (and vice versa). They compete… not work with each other. So even though this issue is resolved with WebCoRE, it’s still a pain… at least it was for me.
Since I also use TeslaFi, I’ve been relying on its auto-generated token to copy/paste it into WebCoRE. I find if I use these WebCoRE routines for token generation, it becomes a conflict with the TeslaFi token and is null since a new token was generated via WebCoRE. It would be great if there was a way to just automatically take the TeslaFi token and use here in WebCoRE.
I thought I had documented this potential conflict, but reading back it’s apparent I didn’t do so within this thread. To the best of my knowledge, you’re right that you cannot have webCoRE and TeslaFi both generating and/or refreshing the access tokens independently.
Sharing the token or allowing an account to have more than one token are both good solutions, but a bit beyond the purpose of these pistons, which was to demonstrate how webCoRE could be used to access the API. However, with webCoRE and ST parting ways before the end of the year due to the demise of the groovy platform, I’ll probably be focusing my efforts elsewhere unless I decide to move to Hubitat.
Here is the updated Access Token Refresh Piston for the v3 API.
To use this piston, you will first have to obtain a Refresh Token. I used a python script available here. There is also an iOS app called Authla that purportedly can do this as well. I 'm sure there are other options I’m not familiar with. .
The piston employs a workflow workaround for a webCoRE bug that arises with pistons containing multiple POST statements, so a new global variable (type: Boolean) @tokenSwitch is needed. See the instructions within the piston itself for startup instructions.
As noted in this post, if you are using TeslaFi or another third-party service that maintains the access token, do not use this piston. You will have to manually update the value of @accessToken whenever those services refresh your token. (That should occur approximately every 45 days).
Because of the requests here and elsewhere, I’ve posted this without the longer range testing I usually prefer. I’ll update the original post with this new piston after seeing what, if any, feedback, I receive.
Thanks.
Web Requests are not working, can't access API's etc?
Thanks for putting this together @bthrock. I’ll try this out in a bit. Question regarding the variable @tokenSwitch. Should I use the variable type Boolean for it?
Question regarding the variable @tokenSwitch. Should I use the variable type Boolean for it?
Preferably, yes. Good catch.
Thanks again @bthrock! I’ll try to implement it this weekend and hopefully things go smoothly fingers crossed
Sorry to bother, but I tried importing the piston and had a quick question. After importing I noticed that the URLs are replaced with :xxxxxxxxxxxxxxxxxxxxxxxx0: instead of the [https://anonymized.webcore.co] as illustrated on your screenshot. Should I leave it as the xxxx… string or replace it with the [https://anonymized.webcore.co] from your screenshot?
Thanks again!
As noted in this post, if you are using TeslaFi or another third-party service that maintains the access token, do not use this piston.
Many thanks for updating this! Are you saying that I can’t have separate refresh tokens for TeslaFi and webCoRE (this piston) that will create separate access tokens? Does the Tesla API only allow for one refresh token and one access token at a time?
After importing I noticed that the URLs are replaced with :xxxxxxxxxxxxxxxxxxxxxxxx0: instead of the [https://anonymized.webcore.co] as illustrated on your screenshot.
I’ve updated the piston, using variables to define the URLs, so it should import cleanly now. The piston value under “Execute Piston” statement will likely still have to be manually entered and needs to refer back to the piston itself.
I’ve also tweaked the piston to address an issue with the refresh scheduling. Hopefully I’ve got it straightened out now. The new import code is dy93.
Are you saying that I can’t have separate refresh tokens for TeslaFi and webCoRE (this piston) that will create separate access tokens? Does the Tesla API only allow for one refresh token and one access token at a time?
My understanding is that you can only have one Refresh Token per account. I don’t claim to possess comprehensive knowledge of the API, however, so it might be a question worth posting on Tim Dorr’s github page.