version 2.24 in github process alert websocket data (this is a totally different messge type versus the std data message).
- version 2.24 noticed alerts also come in in bulk (in realtime) from the websocket api when one occurs. Or it appears whenever a full wake command
- is issued the websocket api also sends all the alerts. (I assume this is in case alerts were missing while car was asleep.
- For this reason added code to just get the last alert from the set of them in realtime and put in 2 attrs lastFirmwareAlert and lastFirmwareAlertTime.
- Also, instead of rewriting all the code to process x alerts, when one
- comes in in realtime like this, after being processed it will call the exising full api (if enabled)
- to get the last 5 of them. I could also handle this here but the format
- in the websocket version of alerts is slightly different so I would have to make a separate version.
version 2.25 in github
noticed there is yet another websocket message type errors.
- v 2.25 process websocket api error message ..; store in attribute lastWebsocketError .
cant really test as i have never seen one of these messages but hopefully implemented correctly 
3 Likes
ver 2.27 in github
saw the alert record from the websocket api is not exactly realtime . on a full wakeup/reconnect to the socket we are getting duplicates... so
- v 2.27 silently ignore websocket alerts if the last alert is the same. Also convert the raw alert time I was storing in lastFirmwareAlertTime to localtime for easier readeability.
this took a bit of effort and finagling. as the normal api alert returns alert time in epoch time whereas the websocket api returns it in a utc format string.. I had to import a few java time related classes that i have never used before.
ie
import java.time.*;
import java.time.LocalDateTime
import java.time.format.DateTimeFormatter
4 lines of code that took me like 3 hours to implement ... lol
// convert utc alert time to localtime
Instant instant = Instant.parse(alertTime);
LocalDateTime ldt = instant.atZone(ZoneId.of(location.timeZone.ID)).toLocalDateTime();
DateTimeFormatter dTF = DateTimeFormatter.ofPattern("MM/dd/yyyy h:mm:ss a");
def formateddate = dTF.format(ldt)
1 Like
version 2.28 in github
new option added as a workaround in a hubitat bug in the getRawOffset in the location.timezone record. it is one hour off for DST.
before fix
after fix
2 Likes
Can you please provide some clarity as to when to use the "workaround" parameter as when I have it off the Firmware Alerts match what I'm seeing in Tessie. If I turn it on than it is 1 hour ahead of what Tessie is reporting. Also, is the reason I'm not seeing the new "lastFirmwareAlert" attributes showing up is because I have to wait for a new alert to come in?
What Tessie is reporting
What Hubitat driver reports if "Enable Workaround due to bug" is set to off
What it reports if set to on
yes you need to wait for a new alert before you will see last one.. it is a totally differ api that returns it.
as for the workaround it is for a bug in daylight saving time offset in hubitat.. are you in an area that does not have dst... if so that is why you wouldnt use it.
Thanks for the confirmation on why the new attribute is not showing up. As for the Timestamp, I'm in California, where we observe DST. I'm guessing that since my last alert was 3/5/25, which is before we switched to DST this past Sunday, that's why time stamps are matching with the Bug parameter off. It sounds like when I get a new alert, I will need to flip that Bug parameter to on to get the time stamps to match. Thanks again for continuing to make this Tesla Hubitat driver better and better.
i am not sure that is it.. maybe the bug is not affecting you.. will see when you get a new alert.. it seems to be hit or miss. and may be dependent on what time zone you are in.
For testing and feedback, is there a way to get more than the last 5 alerts? I had to turn on the hack, and then click the get firmware alerts button and the times corrected themselves by the one hour jump forward. However, all of the alerts are just after the time change. I do see a few more alerts in Tessie prior to the time change and am wondering if those times are correct or not. Or whether that would help figure anything out or not.
Edit: I turned on debug logging in the vehicle and the app, and OMG, I got all the alerts since October! (using the assumption that the timestamp is the unix epoch. Need to find a way to just process the last 10 messages or so.
ya that is really too many to show on the app page. Thats why i limited to the last 4. i can write some code that dumps out all the alerts in the logs if that helps.
the ones prior to the time change will be wrong with the hack on.
Ok, since you know they will be wrong, i'll just let it be. Unless there is something you'd like me to try or test.
Edit: Actually, if there was a way to dump everything into a CSV file or some file that I could take off of the Hubitat, that would be great. I want to filter and analyze messages to track down an issue, and it would be great to see the full history and see if I can correlate between those messages and things actually happening in the car.
Edit2: Nevermind. Figured out how to do it through Tessie. Didn't know I could. Good night!
version 2.29 in github
since apparently the dst issue with raw offset is not going to be fixed and is that way on purpose and there is no adjusted offset.
I rewrote the code to convert from epoch time to localtime without requiring that and removed the dst hack option.. Should be fine now.
1 Like
new version 2.30 in github
added option to set how many firmware alerts to display (not to be confused with the lastfirmwarealert which comes in via the websocket api).
Warning: All can be a lot of them..
3 Likes
Thank you to those who made the Tessie app work so well. I've also recently transitioned over from the deprecated app.
I ran across 2 problems which I'm unable to resolve, and I'm hoping someone can help me.
-
The thermostatSetpoint seems to be stuck at 21C as the default even though I've changed it in the Commands
-
I've set the current_charge_limit to 80%, and when the car is charged to the set limit and the chargingState indicates Complete, the Minutes_to_full_charge still has a certain value (mins) other than 0.
Thanks in advance.
#2 is normal, as that was the last known value Tessie has when the car was still charging. You will see this same value if you log into your account at tessie.com It is better to use the "Time To Full Charge" attribute as @kahn-hubitat has logic in the driver to have that attribute show "not charging" when charging is complete and when it is charging it displays in hours and minutes instead of just minutes.
1 Like
if temp is not changing you will need to turn on debugging on both app and device and try setting temp and posting logs...
really weird observation today..
wondering if the neural network goes as far as to mimic when people freak out!
someone was passing in my oncoming lane.. car freaked out and slowed and pulled to shoulder.. pretty cool but there was plenty of time.
after that it was driving like it was in shock.. 10 below speed limit set even on hurry mode, and wouldn't go on a green light..
lol
2 Likes
While testing after Bruce123's post, I found something strange. There are 3 temperature change messages in the logs per settemperature attempt AND the temperature in the device page changes to what you set, and then jumps back after a few seconds. Setting it again makes the new temperature actually stick. I have log screenshots from yesterday, but I can't get to them right now. I couldn't determine if there was a difference between the car being idle or awake. There were only a few random times out of dozens of attempts where the new temperature stuck the first time.
Until I can get those screenshots to you, please see if you can replicate that. On the device page, set the temperature to something significantly different from current set terp, e.g. 64 and watch the thermostat set temp and then try 70 or 75 and then back to 64. give it enough time in between each attempt to allow it to stick (5-10 seconds) and observe the thermostat temperature attribute. Sorry if it's not clear.
Migraining.
Here is my log.
I'm curious, as I'm using Celsius, but the log still shows in Fahrenheit. I wonder if it's the conversion.
Both the Tesla phone app and Tessie phone app are in sync, but using the Tessie Hubitat app, I'm always getting 1 degree C less than the phone apps. Also, setting the setpoint in the habitat app won't reflect on the Tesla or Tessie phone app.
