Tesla Connect 3.0 - Integration to Query Car Status - Deprecated, see below for replacment

This still works for some currently but is being deprecated due to tesla mothballing this api and release a new Fleet api requiring a company and possibly payment.

see

Control and Query your Tesla vehicles (via Tessie) (Tesla Connect Replacement )

You need to install both an app to integrate with tesla and then it will create the driver once the login is successfull.

latest version avail in hubitat package manager and here

for more info see the old thread here.

5 Likes

@kahn-hubitat Are you aware of a way to see the values in km and km/h without having to make conversions and dump them into virtual devices for display in SharpTools?

i can add an option, but i was under the impression if you hqve it set that way in the car it should read that way in the api? anyone in a foreign country that uses metric. whatq do you see?

Added option to display odometer and speed in kilometers instead of miles.. Note for this to work the car CANNOT be returning already in kilometers.. So someone in a foreign country where it is in kilometers please test.

ie

this is a change only to the device code not the app.. so either pick that up on the github or use package manager..

if it is already displaying in kilometers setting it to K will screw it up .. If that is the case i will add a 3rd parameter "D" for default that does no conversion so as not to be confusing.

2 Likes

slight change to driver there were duplicate update events for long and latitude so pull new version if you like.

First of all thanks so much for making the change. One thing I'd like to note though, unless I'm doing something wrong, the battery range seems to still be in Miles as opposed to switching to kilometers. Unless of course I'm doing something wrong? I've tried it with metrics on or off. I seem to get the same results.


Ya i forgot about that one.
I will fix that today.

1 Like

new version in github with fix for range to also be converted to kms

1 Like

Again... thanks so much for the quick responses. Where can I "buy you coffee".

Nh fl or mi depending

  • lgk v 3.05 change to only the tesla driver to add variable logging level. Setting to Info will be exactly the same as previous. Setting Full is the same as previously
  • turning on debuging, Setting to None turns all of except during initialize or an error.
  • Note: this is only for the driver, no effect on debugging in the related application.
    */
1 Like

GUI Bug? 3rd car device installed correctly but this GUI is a bit off

Weird what do debug logs show. Hard to test here

Make sure the device label on the actual car device has a name filled in.

Yep, that was it. There was no name in the car settings.

1 Like

thanks.. i will look at changing the code so it will use the device driver name if no custom name.

lgk 10/22 v3.1 add code to handle having a vehicle with no name just the "Tesla xxxx" driver name.

1 Like

@kahn-hubitat - A few questions/suggestions on tire pressure.

  1. Now that Tesla is displaying tire pressure in the app at all times, I’ve been monitoring the data and it seems like they push “last known” tire pressure through the API at all times (haven’t been seeing any zeros). So the “last known tire pressure” attributes that you added previously probably aren’t needed. Doesn’t hurt to keep. Just calling it out.
  2. Is there a reason that the “current” tire pressure attributes are set as strings (e.g. attribute "tire_pressure_front_left", "string") instead of decimals? I got a nail and a slow leak and didn’t notice right away because the car only showed a TPM warning below something like 35 PSI, so I’m trying to set up a notification if the pressure drops below a higher number (42 PSI maybe). I can’t use the “<“ operator in RM because these values are strings. I can use last_known_tire_pressure_XXX since these are decimals, which I guess would work fine (unless they get removed per my prior point :face_with_spiral_eyes:). I can change them to decimals in the driver and see what happens, but just thought I would check first.

LMK what you think. Thanks!

1 Like

Too bad your not using WeCoRE as it can convert strings to numbers.

the last_known are not string but decimal, so those are what you should be using in rules anyway as the others can be n/a when they are 0 (hence the string). On the other issue I will do some more digging and see if i dont see zeros they should be removed and changed over to decimal if that is the case. For now behaviour will not be any different if you are using last_known.

all in all i see no reason to change it even if what you say is true as it will break peoples rules (correctly using the last_known attributes) and it wont change anything for people who are as they are always the correct reading anyway.

1 Like