Try logging into the Tessie API Companion site and setting the temp from there
As FYI, I just ran a test from Hubitat setting the temp to 70F and saw it change within seconds on the Tesla Mobile App on my phone. I then changed it to 68F in Hubitat and again saw that change reflected on the Tesla Mobile App. Tessie developer site had the same results. Hence, if it works directly in Tessie it should work in Hubitat. If it doesn't work in Tessie then as @Alan_F suggested you might have a permission issue with your API key.
So I just fudged my way into trying it via Tessie and it set the temperature to my 20c setting. Just for fun I again went back to Hubitat at tried from there without any luck. Perhaps it's the driver and something to do with my setup?
If correct, since the temp commands are working using the Tessie API, it might not hurt to reset the app and driver in Hubitat. Change the device type to "device," save, and issue a command to "delete all states." Then uninstall and reinstall the Tesla Connect Tessie App and driver using Hubitat Package Manager. Re-input your Tessie Access Token and validate it finds your Tesla. Then go back to your driver change the type back to "tessieVehicle" and save. Then, see if temp commands now work. This method will prevent any rules and dashboards you have defined for the device from breaking.
Note: When you re-install the App it might create a new device that you can delete.
as mentioned instread of harping back and forth you neede to at least enable info if not debugging logging in the app as well as the car device and post the logs.. without that you cannot be supported..
i just tested even with car asleep and it worked perfectly
@kahn-hubitat
I am having issues saving the preferences with 2.4.0.148 when the 'time' inputs are present. When I comment them out, it works fine. I installed on a 2.4.0.x version, so not sure if this happened because of that and has been reported to @gopher.ny
text: String
number: Integer
decimal: Double
enum: List (this type requires a parameter options of type List with the >options); this is a pull-down menu.
bool: Boolean; this is an on/off slider.
Ok... after a lot of messing around, I took @gomce62.web advice and reloaded the app and driver. Sending temps worked, but then I had the issue with not being able to save preferences (which where all cleared on re-load). I rolled back the hubs FW to the older UI 2.3.9.201 which allowed me to now save preferences.
I then set temp in F and that worked. When I changed pref to C and tried setting temp I get an error. I went back to F and it worked again. Went back to C and failed again. And remember, this is the app/driver re-installed.
No rush, but I've been playing with it and I think it will be a great addition to the driver.
I'll humbly suggest that once you have the real-time web socket connected, you might want to consider simplifying the driver by removing the alternate presence, the outer radius, and the reduced refresh time features. It might still be necessary to keep occasional polling just in case something gets missed via the web socket, but with location updates every 1 to 2 seconds, there is no need for variable refresh rates on the polling. I'm currently running a modified version of the driver with those changes and it's working great.
Also, IIRC, isn't it the case that polling Tessie's API for updates will never wake the car? If so, the quick fix for the issue with the latest Hubitat versions might be to just remove the AllowSleep and fromTime/toTime settings, along with the associated functions/code. If Tessie won't wake the car, there is no need to disable polling to allow sleep.
no i believe some of the functions do wake the car and in addition, it not just to allow sleep it reduces the load on the hub and logging. if you know the car is going to be parked in the garage asleep for the night no need for all those api calls. in fact when i add the other interface it will disable that as well.
i also dont believe the webscoket has full api functionality so for instance if you disable poiling and you have the extra query to get the address. that would not work via the websocket.
i have not looked in detail but am hoping it returns ALL the data that the standard status query returns. so at least i can disable that... but on a cursery glance dont think so.. i dont think it returns heat levels tire pressures, charging status etc. so dont think i will be able to disable polling..probably just need to up the time so as not to step on each other.
From testing, I'm pretty sure you're correct. The web socket has the current route info, but not an address for the current location. Likewise, the iFrame map update is part of the polling. I haven't been using either of those features, but if users need those to update rapidly when near home, that would require keeping the variable refresh rates based on distance. However, when not using those features, rapid polling vastly increases the load on the hub since, as I understand it, the web socket is only sending values that have changed, while polling requires processing and updating every state variable whether it has changed or not.
ya i definately think we will be able to get rid of the alternate rapid polling etc. that was just to work around the fact that homelnk is no longer standard to know when you are home and for instance open the garage door.. it was not really to update the iframe in real time.. the websocket can definately remove that.. but just took a look and there are a lot of handle this or handle that still in his code so it will not be trivial to try and repro all the attributes the normal query was fillng in,, it is a goode start but it will be hell to debug say if one attribute is not getting set that previously was.. so it will take time.
When the car wakes up it sends a burst of all the websocket settings, then only send updates as they happen. When it first wakes up which is almost immediatly when the car wakes, I poke the refresh on a two second delay for the websocket to settle.
The websocket does NOT have all the polling REST API configuration data, but does have some the rest does not. So its a 'both' to get 'all' configuration.
I reduced the poll to 30min in the preferences.
When the debug is on, the code will spit out any unhandled or unreferenced websocket data that doesn't have a closure.
LMK if you have questions. So far its been pretty good and is fast.
There is some of that, but it's not as bad as it looks at first. I remember you recently said you didn't want to bloat this driver with lots of extra attributes (when we were adding the active route variables). The vast majority of those 'handle' logs are for things that you don't currently track in the driver, so they can be ignored. I have found one or two that are variables in the driver and it was pretty easy to add the handling.
If you are going to be updating the driver can you please consider adding a string attribute "Time_Remaining_to_full_Charge" that will take the value of "minutes_to_full_charge" and convert it to Hours and Minutes that can be used in Dashboards e.g. 85 minutes becomes 1 HR and 25 Min so it matches the Tesla Mobile App. I'm currently handling this via a rule that @Sebastien created This is how I converted Minutes to Hours/Minutes in RM but it would be nice if that attribute were just part of your driver. Thanks for giving it consideration
