Open andyylin opened 1 week ago
Hi @andyylin, thanks for bringing this up. We'll definitely audit this case and address where possible.
However I will say, once the command is sent to Tesla servers, it is largely out of Watchla's control as the Tesla API will follow its own protocol on this, regardless of whether Tesla or the vehicle are able to give a response back or not. The big issue case with this is when your device has enough of a connection to send the request but not enough to receive one when the response is sent or your vehicle doesn't immediately have enough of a connection to receive/respond to requests from Tesla but shortly after you send the command, it gains the connection to do so.
The good news is that we are coming out with a significant update to Bluetooth very soon which will increase connection start-up times & reliability, which will in-turn drastically reduce the chance that this case occurs in the first place.
I understand. Hoping the Bluetooth reliability improvements will help.
For this recent incident which prompted my feedback, I was only about 1.5 meters away from the car, but had just walked up to it.
I think maybe even first allowing a 1-2 second check for Bluetooth before sending to servers could be a possible solution.
I park in an underground garage with no cellular reception. So the support for Bluetooth instructions is great. But if I send a command before Bluetooth is connected, it might take forever to connect, so I'll try again with Bluetooth and it'll go through immediately.
The problem is that the first command that was trying to connect will eventually connect again and then be sent again. This is particularly a problem with the frunk because I'm afraid that I'll be driving and then the frunk might pop open. At the very least, it means that I then have to get out of my car to then close the frunk again.
I think the ideal behavior would be not to double up on commands such as opening the drunk, opening the trunk, etc. If the Bluetooth command goes through then an Internet based command should then be canceled.