Thank you for that info.
I was thinking about possible extensions to this integration leveraging the fact that it is now via Tessie rather than directly to Tesla. Does the Tessie API expose any of their higher functionality such as location definitions, automations etc?
I was thinking if such things could be made available in Hubitat it could increase the power of both Tessie and this integration considerably. As a trivial example if a 'Tessie Location' attribute was available with the name of a saved location at which the car was present (or none) then Hubitat could be used for more complex automations based on that location than what Tessie itself can offer, without having to do GPS calculations yourself in Hubitat.
Or if a Hubitat event could be generated when a Tessie automation is triggered there could be additional functionality associated with that event, etc etc.
Just a thought, no idea if it's practical or worth the effort!
i thought about that but is that really anyh easier than to write a rule based on the current address which we already have.
that is coming from tessie i dont do any gps cacluations
The nice thing would be you can easily define locations and given them meaningful names and active radii in Tessie, which you could then simply compare in a Hubitat rule. I must admit I was thinking in comparison to using raw lat/lon in Hubitat (which I've done a few times and it's fairly messy) as I'd forgotten about the 'current address' option. Does that require an extra query on every refresh though?
Either way does that mean the Tessie API does expose those sorts of higher functions? Events based on Tessie automations firing would currently have no direct way to do in Hubitat unless you duplicated the automation actions in Hubitat.
yes current address requires an extra query every go around.. unfortunately that is the way they implemented it. same as sleep status, both could be returned in the single query..
I asked but no go..
However, I don"t think they require an extra query to teslas fleet api .. only on our side..
But since they return saved location if there is one in the same address query and it took me about 15 minutes to implement it..
I did...
avail. now in version 1.92
There also is more error checking now.. address returns Unknown if it fails and likewise
savedLocation returns N/A if there is not a saved location that you are currently At.
2 Likes
That's awesome, thanks! This reduced one of my rules from 25 lines to 6!
2 Likes
Tessie supports this as part of the analytics. In the app, select the menu in the upper left, and then choose Saved Locations. In the web interface, it's directly on the left pane.
In the call https://api.tessie.com/{vin}/location, it returns an entry "saved_location". If the vehicle is within the radius of a saved location, the name will be returned there. If it doesn't match, saved_location will be null.
I believe the reason is because Tesla requires a separate location query, which is now a separately privileged call.
Not at least in the old api they just return lat long in the normal query and i assume tessie is looking up location from that but i could be wrong.
v 1.93 in github.. left a debug line in the lastest changes without checking if debug was on.
Just want to double confirm before I remove: with the Tessie integration, we no longer need wake, wait, and refresh commands at the beginning of our rules?
I've changed the coding in my WebCoRE pistons to refect this fact. So far no hiccups when executing commands in the past almost two weeks.
2 Likes
Given the impending doom with the original integration, I ended up getting this setup with a free month trial for the time being. Just wanted to clarify a few things, since I am not sure what might have changed with the new integration (and to make sure I understand correctly).
With the auto refresh feature, does this wake the car to refresh, or does it just pull the latest data from Tessie? This feature here:
Also, does pressing the manual refresh button on the device page have the same effect as the auto-refresh, or does it do something differently? I'd prefer to not wake the car if it is currently sleeping to get an update. Though, if it refreshes and it is already awake, I'm not concerned.
From my initial testing that is what it looks like it is doing with the manual refresh button. Though I figured I'd ask to clarify, thanks!
Tessie does refresh without waking.
1 Like
yes the refresh schedule and manual refresh are the same..
but you need the refresh time set becayse nothing will update on the hub side if there is no periodic refresh.. that is exactly the same as the old integration was.. ie it polls.
1 Like
Awesome! Thanks for the clarification guys!
I made the move to Tessie!
@kahn-hubitat, the one issue I’was seeing though is that the Set Charge Amp command was erroring out…
Looks like line 800 has an error. Changing from:
return executeApiCommand(child,"command/set_charging_amps?charging_amps=${ampsInt}")
To:
return executeApiCommand(child,"command/set_charging_amps?amps=${ampsInt}")
Fixes it.
This was the error:
1 Like
- v 1.95 as Sebastien noticed i screwed up on the set charging amps call so new version to fix it.
either that or tessie changed their api.. i swear i looked up the call must be loosing it...
1 Like
Lol. Maybe they changed it! But the important thing is that it works now.
1 Like
A surprise benefit of this Tessie integration with HE is I'm now subscribed to Tessie an APP I was not familiar with before. Tessie includes an Android Wear App and Apple Watch App so I can now unlock and send commands to my Tesla just using my Samsung Galaxy watch.
1 Like
