Model S Amazon Echo Integration

[wayner]

That made me think that the temperature variables weren't getting set, so I tried an experiment. I went to the car and opened the door to wake it up. Then I came back and did the quick and full status queries again, as well as asking for the temperature, and they all worked.

You are on the right track, however the Wake Up API command doesn't seem to always get you the temperature readings - and this is the case with other third party apps as well. The only way to get the temperatures for sure is to turn on the climate. Presumably "really" waking it up by opening the door and/or driving does the trick.

 

[dlmorgan999]

That did indeed fix the ClimateStart issue. Thanks! I'll keep poking at it and report any other issues I find.

 

[wayner]

That did indeed fix the ClimateStart issue. Thanks! I'll keep poking at it and report any other issues I find.

Thanks - there certainly will be differences for those who use F vs C for temps and then miles vs kms as well. Plus the car can be in different states which can cause different reporting, like not getting a valid temperature reading - and this doesn't appear to happen on a Model X. So keep feeding us any errors and we will try to squash them.

 

[dlmorgan999]

Plus the car can be in different states which can cause different reporting, like not getting a valid temperature reading - and this doesn't appear to happen on a Model X.

Interesting. I wonder why it's different for a Model S. For what it's worth, I just picked up my car on Tuesday evening, so it's brand new. I would have expected both models to have mostly the same firmware.

 

[wayner]

That's good to know. Michael, aka BizJet, said that he always got valid temperature responses in his Model X. I know that this has been inconsistent with my Model S P85D which is two years old. We thought that new Model S's would be like his Model X, but apparently that may not be the case.

 

[dlmorgan999]

Now that this is working, I think I'll take a peek at the API and see what other fun things might be possible.

Also one comment (and I realize this might be a parsing nightmare), but I always reference time in 24-hour mode. As such, it would be nice if I could say something like "Unlock the car until 13:30". I tried this command at 13:27, and it proceeded to tell me that it "would stay unlocked for 23 hours and 33 minutes until 1 o-clock pee em". ;-)

 

[dlmorgan999]

I found another issue. Most commands (including the quick status) report the correct lock status, but the full status said that my car was locked when it fact it wasn't.

Update: and now I see why. You aren't checking data['locked'] when you build the string.

 

[wayner]

Also one comment (and I realize this might be a parsing nightmare), but I always reference time in 24-hour mode. As such, it would be nice if I could say something like "Unlock the car until 13:30". I tried this command at 13:27, and it proceeded to tell me that it "would stay unlocked for 23 hours and 33 minutes until 1 o-clock pee em". ;-)

That should be doable and the Tesla even has this as one of its GUI settings - here is what is available.
{
"gui_distance_units": "mi/hr",
"gui_temperature_units": "F",
"gui_charge_rate_units": "mi/hr",
"gui_24_hour_time": false,
"gui_range_display": "Rated"
}
So we just have to build the logic, just like the temperature and distance units.

By the way, is your time reporting correctly? This is a bit of an issue between locally hosted code where the time is tz adjusted vs cloud hosted where the time is generally UTC.

 

[wayner]

I found another issue. Most commands (including the quick status) report the correct lock status, but the full status said that my car was locked when it fact it wasn't.

Update: and now I see why. You aren't checking data['locked'] when you build the string.

Ok, this should be fixed now. You are right the code wasn't actually checking, but hopefully this is working now.

 

[AMPUP]

THANK YOU for taking the time to write this up!

I'm running into some trouble at step 2.10 -- running the application throws an error:
urllib2.HTTPError: HTTP Error 401: Unauthorized

Sure enough, testing the skill returns this error, guessing since the application isn't actually running:
There was an error calling the remote endpoint, which returned HTTP 302 : Found

I'm not sure if that's related to the environment variables I entered, but I double checked them to ensure that they're correct, and in quotes.

I'm savvy enough in IT to put food on the table doing it, but not smart enough to be a developer

same issue, there is something a miss with the app id and user/password. Tried quotes in multiple places but this still throws an errors. Ill look more over the next couple of days but this is what I am getting too.

 

[wayner]

same issue, there is something a miss with the app id and user/password. Tried quotes in multiple places but this still throws an errors. Ill look more over the next couple of days but this is what I am getting too.

Are you using the Cloud9 method or the ngrok method?

 

[Cyclone]

By the way, another option is to just plug in a valid OAUTH code into the teslajson.py file if you already have on. But this will have to be manually changed every three months or so.

I tweaked this method since I'm using the Cloud9 method of Nikola. I added the first line and substituted the second, then defined one more environment variable with my OAUTH token (and put in dummy info for user + password).

TESLA_TOKEN = os.environ['TESLA_TOKEN']
tesla_connection = teslajson.Connection(TESLA_USER, TESLA_PASSWORD, TESLA_TOKEN)

I need to read up on the Alexa options. I would like to remove my authentication from the code altogether and have Alexa pass in my OAUTH on the service call.

 

[Cyclone]

To help with the efforts to make this more multi-user, I changed my application.py to have the Tesla Connection info as a called function. This required some tweaking of the code, but it let me do a few things:

1. Create a dummy "Example Intent" that spit out the variables for me
2. Prevent the Tesla Connection call from happening when starting the application in Cloud9
3. Let me set it up to pass through an OAUTH token from Alexa to use for the Tesla Connection
-- I put in an IF statement to substitute in my personal OAUTH token since I didn't configure my Alexa service to use User Linking yet

However, this gets the framework up. Would @BizJet & @wayner want me to create a fork on GitHub with those changes for potential inclusion?

 

[CuriousG]

@wayner Got it working. The intents.txt file is missing GetTemperatures that's referenced in utterances.txt. So who's ready to tackle smart charging?

So far all I've done is get status of car.
Unlock the car for X amount of minutes .
Lock the car.

 

[Cyclone]

To help with the efforts to make this more multi-user, I changed my application.py to have the Tesla Connection info as a called function. This required some tweaking of the code, but it let me do a few things:

1. Create a dummy "Example Intent" that spit out the variables for me
2. Prevent the Tesla Connection call from happening when starting the application in Cloud9
3. Let me set it up to pass through an OAUTH token from Alexa to use for the Tesla Connection
-- I put in an IF statement to substitute in my personal OAUTH token since I didn't configure my Alexa service to use User Linking yet

However, this gets the framework up. Would @BizJet & @wayner want me to create a fork on GitHub with those changes for potential inclusion?

I went ahead and created a GitHub account and read up on using it, so I put in a fork with my changes. Loving it so far!

 

[wayner]

@wayner Got it working. The intents.txt file is missing GetTemperatures that's referenced in utterances.txt. So who's ready to tackle smart charging?

So far all I've done is get status of car.
Unlock the car for X amount of minutes .
Lock the car.

Sorry about that. The files between my home PC an github got out of sync. I have fixed it now, but I imagine you did that in your own Amazon Ask screen.

 

[wayner]

To help with the efforts to make this more multi-user, I changed my application.py to have the Tesla Connection info as a called function. This required some tweaking of the code, but it let me do a few things:

1. Create a dummy "Example Intent" that spit out the variables for me
2. Prevent the Tesla Connection call from happening when starting the application in Cloud9
3. Let me set it up to pass through an OAUTH token from Alexa to use for the Tesla Connection
-- I put in an IF statement to substitute in my personal OAUTH token since I didn't configure my Alexa service to use User Linking yet

However, this gets the framework up. Would @BizJet & @wayner want me to create a fork on GitHub with those changes for potential inclusion?

I don't totally understand what you are doing but anything that allows you to securely put your authentication info and/or OAUTH token in the cloud is a fantastic addition.

 

[Cyclone]

I don't totally understand what you are doing but anything that allows you to securely put your authentication info and/or OAUTH token in the cloud is a fantastic addition.

Right now I'm coding in the OAUTH using an environmental variable. The application.py code will accept an OAUTH token from Alexa, but it appears Tesla is using the "password" grant type and Alexa doesn't support that. More digging will need to be done to see if we can leverage Tesla'a authentication server directly, but if not, a pass thru will be necessary. I'm hoping there is a solution to avoid that.

The plus side is that if you know your OAUTH token, you should be able to invoke the service with a properly formatted JSON request externally (but why not just use Alexa I don't know ).

 

[wayner]

I apologize if this is painfully obvious to most or all, but just to be sure this is my understanding of how the security stuff works.

• All of the calls to the Tesla API that read data or take action on your car require an OAUTH token.
• The email/password requirement is really just needed to acquire an OAUTH token. After you have the token you no longer need the email/password until...
• The tokens expire after 90 days or when your MyTesla password is changed.

Given the above you really just need an OAUTH token. But how do you do that securely in a cloud environment where many people may be using the Skill? And how do you deal with the case when tokens expire. When playing around at home I just store a token in a file called token.txt and I just read that whenever I hit the Tesla server as I figure that makes more sense then getting a new token every time you run somehting.

The User Linking from Alexa seems the way to go but it isn't clear that we can do this without Tesla's approval. Does somebody want to look into that.

 

[wayner]

By the way, I am going to start a new thread that is specifically on the Nikola Alexa skill to make it more clear to forum users that this exists and that can be the official thread for this skill.