Thanks... I think I have it figured out by restarting my phone, seems to work.
For what it's worth, I've programmed apps for Bluetooth on both iOS and Android, and I'll be turning OFF the walk up to unlock feature. (Note: I've heard it may have been removed as a feature for now anyway.)
If you want to hear a little off-topic technical detail, which is NOT interesting to most people, I know, read on.
The design of Bluetooth has always made certain assumptions about usage. These assumptions don't cover every edge case. Most notably, they assume that you will connect to a device and then stay within range during usage. This covers 98% of Bluetooth products, which are mostly related to audio. While Bluetooth does disconnect gracefully if you walk out of range, it doesn't always behave as well if you hover around the fringes of reception. Buried in various places in the stack are certain timeouts and retry limits that developers do NOT have access to that can "lock out" the app or the car and prevent further communication (until a reboot or network reset of either or both ends).
Bluetooth messages are transacted. Using iOS as an example, when your phone sends a message to the car ("Hey. You up?"), the car is expected to acknowledge receiving that message, THEN reply in another transaction (which your phone then acknowledges). But due to asymmetries in reception and transmission, it's possible for one end of this conversation to hear the question, but the other end can't hear the acknowledgement. If the app is written "optimistically" (i.e. keep asking the question, it will be answered when we are close enough) it can frustrate iOS, which is EXTREMELY biased towards saving power. After a certain number of failed acknowledgements, iOS will silently blackball the device to save power. It won't even bother sending any messages the app may request. The app and the app developer are none the wiser; the questions are never answered no matter how close you are to the car. To the app developer, it's like the car is not there.
My company discovered this and got around the problem (mostly) with a very pessimistic programming model. Our apps have a very short fuse (shorter than iOS's) when a question is not acknowledged. In other words, our app quits before iOS can get pissed. Works pretty well, but not foolproof, especially if you have other Bluetooth apps bugging the stack at the same time. It also requires that the user request to be connected, which is fine for our use cases, but is not acceptable for a "works automatically" key.
There may come a time that Tesla orchestrates Bluetooth unlocking a little better. Until then, I'll just touch the door handle to unlock. That's how my current car works anyway, and while it sometimes leaves passengers waiting for me to get to my door, it works very predictably. Assuming that "walk away lock" is one-time transaction, I'll probably leave that one on auto.
P.S. When Bluetooth stops working, reboot your phone and if necessary the car.
