Lucid Mobile App – UX Observations & Curious if Others Feel the Same

[Celeras]

How about this: turn bluetooth off on your phone and do the same thing. Walk up to the car with your phone out, stop a couple feet away, turn bluetooth back on. My bet is the car will connect and unlock in under 3 seconds. That’s been my experience. And that’s why I’m convinced it’s mainly the phone’s power saving that causes the delay for mobile key, not the car.

That’s a separate issue from remote control from the app though - that takes a SMS message from the cloud to wake up the car. That process is what seems to make remote wakeup particularly slow. My guess is the car doesn’t keep a constant cellular connection, instead connecting every 30 seconds or something like that. So wake up takes between 0 and 30 seconds depending on how the stars align.

I'll have to try it again later, because here's what happened:

-When standing next to the car, I turned on Bluetooth. I counted to 30 and nothing happened.
-I pressed the handle, counted to 30 again and nothing happened.
-I opened the Lucid app, which probably woke up the car with the SMS thing if your post is accurate. Then the mobile key bluetooth device connected and the handles popped 2-3 seconds after that.

That doesn't really tell us anything except that the car knows where the mobile key is pretty quickly when it's awake.. which nobody cares about because the problem is the mobile key waking it up lol. You still could be right but we'll have to see if I can get the proper test conditions to execute.

 

[johnse]

I don't have experience with Lucid yet, but I have experience in mobile app development and I am aware that the mobile Bluetooth stack is...finicky. The early experience with Tesla Model 3--their first phone-as-key car--was temperamental especially on Android.

When standing next to the car, I turned on Bluetooth. I counted to 30 and nothing happened.
-I pressed the handle, counted to 30 again and nothing happened.

This is most likely your phone's fault. One setting that can affect it is the permission for Always On vs while in use. This is a power-saving feature on the phone since any time the radios are on, it drains more power from the battery.
The moment the app is started, it wakes up the Bluetooth. The Bluetooth connection to the car should be very quick.

Most other features of the app--anything that can be done more that 30' from the car--is done via the Internet. The app communicates with Lucid's servers and those servers communicate with the car. This prevents a whole category of security issues since the car only talks to their servers via secure connections.

The servers need to wake up the car in order to communicate with it. I know that with my Model X, if it's gone to sleep, sometimes the app is slow to wake it... sometimes it won't wake until I get the key fob near it.

Just like with the phone, they don't want the radios in the car active at all times. Teslas normally experience about 1-2% "vampire drain" per day. But it can get much worse if people run third party data collectors that keep waking it up every few minutes.

People have said Lucid uses an SMS message to wake the car. How quickly that message gets to the car can vary. Think about text messaging before iMessage or RCS chat. Pure SMS can have variable delays. This is why some Two-factor authorizations can take a while...very noticeable when a web site says it's sending a code and you are waiting eagerly for it.

All this is to say that some of the remote wakeup variability may be out of Lucid's control. Other parts may be a poor understanding of the mobile APIs, or poor drivers on the Android phones (app compatibility on Android is challenging in the best of circumstances).

 

[Celeras]

This is most likely your phone's fault. One setting that can affect it is the permission for Always On vs while in use. This is a power-saving feature on the phone since any time the radios are on, it drains more power from the battery.
The moment the app is started, it wakes up the Bluetooth. The Bluetooth connection to the car should be very quick.

I don't disagree with anything you said, however that's a location permission. There is no "while in use" choice for Nearby Devices. Just on/off.

But yes are far the the UX is concerned when it comes to waking the vehicle, it may already be doing the best it can. I have a thread a few underneath this one that focuses specifically on Android and connection settings before we hijack this thread too heavily about the same thing haha

 

[borski]

For Android, for example:
"In order to use Bluetooth features in your application, you must declare two permissions. The first of these is BLUETOOTH. You need this permission to perform any Bluetooth communication, such as requesting a connection, accepting a connection, and transferring data.

The other permission that you must declare is ACCESS_FINE_LOCATION. Your app needs this permission because a Bluetooth scan can be used to gather information about the location of the user. This information may come from the user's own devices, as well as Bluetooth beacons in use at locations such as shops and transit facilities."

iOS is similar, for similar reasons.

 

[borski]

I don't disagree with anything you said, however that's a location permission. There is no "while in use" choice for Nearby Devices. Just on/off.

But yes are far the the UX is concerned when it comes to waking the vehicle, it may already be doing the best it can. I have a thread a few underneath this one that focuses specifically on Android and connection settings before we hijack this thread too heavily about the same thing haha

For Android, for example:
"In order to use Bluetooth features in your application, you must declare two permissions. The first of these is BLUETOOTH. You need this permission to perform any Bluetooth communication, such as requesting a connection, accepting a connection, and transferring data.

The other permission that you must declare is ACCESS_FINE_LOCATION. Your app needs this permission because a Bluetooth scan can be used to gather information about the location of the user. This information may come from the user's own devices, as well as Bluetooth beacons in use at locations such as shops and transit facilities."

iOS is similar, for similar reasons.

As a security measure, developers are required to ask for both, since Bluetooth can be used for location tracking anyway, so if you allow one you should allow the other.

 

[Celeras]

As a security measure, developers are required to ask for both, since Bluetooth can be used for location tracking anyway, so if you allow one you should allow the other.

Correct, I was saying there's no choice to "always allow" Bluetooth like he was saying. That's for location only.

 

[borski]

Correct, I was saying there's no choice to "always allow" Bluetooth like he was saying. That's for location only.

Totally. I’m not disagreeing. But - the reason location is required for mobile key is because it is required for Bluetooth; that’s all I was clarifying.

 

[johnse]

Yes. It has been a few years since I was directly developing Android apps. The permissions above need to be granted, and the app needs to be allowed to run in the background.

This permission moves around based on phone manufacturers and OS version. On my Pixel Fold, it's under Settings, Apps, (specific App), App battery usage, Allow battery usage.

Example from the FordPass app attached.

And yes, we can stop hijacking this thread.