no because the legacy vehicles still use the websocket not not telemetry i believe.
but i can set an attribute if we get a speed from the websocket and if set just ignore speed and motion from the legacy.. that may be a good workaround,.. what do you think,.
Maybe set an option that lets a user specify that they have a model S or X and need legacy, and use that in the code to select the required data?
ok version 2.20 in github
better solution.
backed out version 2.19 hack..
set state variable (reset on startup to false)
on first receipt of a vaild speed from the web socket api (and it is still enabled via preferences)
This signals you have speed via telemetry data and
from then on ignore speed/motion data from the legacy api (so as not to get the erronous speed reports).
3 Likes
Anybody have an 18 or older m3 and notice that the latest release 2024.45.32.20 broke the fsd. It was working on the previous relese 32.15 other than the normal annoyances.
Now it suddenly is unuseable and not safe to drive with fsd on. Its hugging and sometimes even crossing the left lane marker/center line.
Weird thing is on our loaner and also our new/used 22 m3 on the same build is not doing it. Not sure what would be different. Maybe the sonic sensors the car itself KNOWS its on the center line as shown in the visualization. And as soon as you turn off fsd and goto autodrive it centers perfectly so its some sort of aoftware issue or incompatibility with the latest ai stack and my older car. Ie.
That is horrible! Have you tried to recalibrate the cameras? It might be worth a try. At the worst, you won't have FSD for a few/many miles until they calibrate. Best case, the very dangerous FSD is fixed.
yep did no change and its obviously not the cameras as the car knows its on the line.
unless it thinks something is in the right camera.. but then i would think if that was the case autodrive would not work as well.
I have a 2018 M3 with Enhanced Auto-Pilot on 2025.2.6 I'll try going on Fwy tomorrow and activating auto-pilot and see if it stays in the center of the lane.
1 Like
Correct FSD and Enhanced Auto-Pilot (EAP) are different. I believe the version numbers are different between m3 with FSD H/W and those without FSD H/W. FSD can handle more complex driving scenarios like navigating city streets, stop signs, and traffic lights, while Enhanced Autopilot mainly focuses on highway driving with features like lane changes and speed adjustments. What I would hope is on a highway both EAP and FSD will stay in the center of the lane. I have not used EAp since I got 2.6.2 so I'm curious if it the car will stay in the center of the lane.
Yes as i showed in the 2nd pic. on eap it stays in the lane fine just fsd is failing.
1 Like
Interesting that EAP is fine but FSD is not. Did you submit the bug to Tesla via "bug report" voice command while it is occuring
1 Like
Probably a lounge topic, but was always something I assumed just would work. But this is a method to use your iPhone Bluetooth to trigger your phones hotspot to allow the Telsa to join. Clever.
2 Likes
@kahn-hubitat, I've created pull request #11 to add getting the weather at the car's location.
- This is my first ever attempt at contributing anything at github. Apologies in advance if I have done something incorrectly.
- I've made getting the weather exactly like getting the address: it's a preference in the device driver with the default to off, so it should not affect any current users nor new users who do not choose to get the weather.
- There are a number of attributes. I have added them all to the code, but commented out all but 4 of the most useful ones. The app processes all of the weather information if the weather is fetched. The driver only currently presents 4 attributes to the user. Please feel free to uncomment out any of the others as you see fit.
- I struggled to decide what to name the attributes. Finally settled on Weather XYZ so they would be grouped together and also make it clear it was from the weather command.
- I've been using the weather for a few weeks and has been working without issues.
True, but close enough, at least where I live in urban/suburban areas. Rural areas might be very different. In my rule, I'm also looking to keep some kind of track of, let's say, the last 2 hours. If there was rain or snow, then err on the conservative side and say it's that way now. Rain = don't crack open the windows, snow = turn on defrost mode instead just regular climate control when preheating the car.
True. Over the last 3 weeks, I've found it to be close enough. The weather data also includes the location of the reporting station, which is not exactly where the car is, but again, close enough, within a couple miles, at least in the areas I'm in.
This works great when at home. The OWM integration is "hard coded" to one set of coordinates. I've been trying to re-code it, but this is my first attempt at groovy and javascript. Having the weather in this driver just makes it simple for a user who doesn't have OWM or currently can't use it for the dynamic location of the car. Use case: the weather where I live is very different from where I was visiting 100 miles away.
Hopefully someone else will find this addition as useful as it has been for me.
1 Like
Version 2.21 in github
i integrated your code manually with some changes, ie temp not automatically converting to fahrenheit then back to celsius.
also enabled windspeed with appropriate conversions since that impacts range.
- v 2.21 pull out the websocketspeed state that was getting set to false every morning or whenever you schedule to reenable.. It still gets set to false
- if you manually save preferences.
- Also, add in a modified version of the outside implemented weather api call and associated attributes,.
- Also add code to clear out address and weather attributes if you disable those options so stale attrs dont hang around,.
*/
*
2 Likes
new version 2.23 in github
- version 2.22 get firmware alert api added and attribute and command. Only show last 5 alerts. Also option to call getfirmware alerts on wakeup once a day.
1 Like
Thanks for adding these new attributes as they will come in handy. Unfortunately, I just installed the new version and it is not showing the new Firmware attributes. Any idea why based on these screen shots?
Refresh Exectued:
Logging into Tessie shows the following alerts:
Firmware alert is only one attribute and you misunderstand the notes ..
It doesnt show up immediately ie in every query as it really is not needed every query.
You either have to manually run the command in the device panel ( or schedule it to run with a rule), or with that option you have turned on that only would request it whenever the car re-enables assuming you have set a time to disable and re-enable it (in your case 6am),
also why is your version showing 2.04?
That is very old are you manually updating and only the driver device... you need to update both the app and device (recommend you use hubitat package manager). it wont work if you dont update both.
Thanks for the clarification, and yes I'm using HPM to install and update the app and driver.
Good catch on the version. I didn't realize I had two instances of the App installed and the driver is bound to the wrong version of the app. I'll get that fixed tonight.
1 Like
The duplicate Tesla App was the problem. Everything is now working perfectly including Firmware Alerts. Glad this new version uncovered that issue with my Hub that I had not noticed before. Now time to create some notification rules and dashboards off these new firmware attributes 
1 Like
