2023 Model Y - Must Click Connect Drives To Host In Web UI To Recognize USB

[cmgraz]

Describe the problem

It seems that the only way I can get the Raspberry Pi Zero W to be recognized in my 2023 Model Y is to go to the Web UI and manually click "Connect drives to host"

The last two lines on the diagnostics before clicking this are:

[Mon Aug 7 14:55:03 2023] CIFS: Attempting to mount //192.168.1.3/TeslaCam
[Mon Aug 7 14:55:09 2023] CIFS: Attempting to mount //192.168.1.3/TeslaMusic

After about 5 minutes of uptime with no changes I click the button and then the diagnostics add this:

[Mon Aug 7 14:58:56 2023] Mass Storage Function, version: 2009/09/11
[Mon Aug 7 14:58:56 2023] LUN: removable file: (no medium)
[Mon Aug 7 14:58:57 2023] LUN: removable file: (no medium)
[Mon Aug 7 14:58:57 2023] dwc2 20980000.usb: bound driver configfs-gadget
[Mon Aug 7 14:58:57 2023] dwc2 20980000.usb: new device is high-speed
[Mon Aug 7 14:58:57 2023] dwc2 20980000.usb: new device is high-speed
[Mon Aug 7 14:58:57 2023] dwc2 20980000.usb: new address 2

Once the button is clicked, everything works wonderfully. Then it seems once the car goes to sleep, if it wakes back up I have to click that button again to get the drive to be recognized.

Device

Raspberry Pi Zero W

OS Image

Prebuilt TeslaUSB image

Car Model

Model Y

USB connection

Glove box

Logs

teslaUsb_diagnostics.txt

Additional information

No response

[marcone]

It looks like when the Pi booted it started archiving files that it didn't archive previously. Since your network connection is quite slow (each 1-minute recording takes over 2 minutes to archive, per previous entries in the log), this took a while.
By clicking that button in the web interface you forced the drive to be connected to the car, but did so while still mounted on the Pi. This is generally a bad idea, because two computers (the Pi and the car) will be accessing the drive at the same time.
I'd recommend looking into getting a stronger wifi signal where you park your car (i.e. a wifi repeater or a dedicated AP), and configuring TeslaUSB to keep the car awake during archiving so that it completes archiving when you get home.
Also, you don't have to wait for the drive to show, you can just drive away and when the Pi loses its wifi connection it will stop archiving and connect the drive to the car.

[marcone]

I'll keep this open because I've been meaning to change the startup sequence so it connects the drive right away. That would fix the problem you're seeing (though you'd still have problems archiving due to your slow connection).

[cmgraz]

Good catch. I'm going to take a look at this in a little bit to make sure that if there's nothing archiving that it detects the Pi without issues.

[cmgraz]

Just to make sure I'm understanding, you're saying that when the car wakes you'd have the Pi mount to the Tesla right away rather than mount to the network share?

And you were correct, when I got in the car before, when there was nothing to archive it automatically connected.

[cmgraz]

I'm attaching another diagnostics file here. Sunday morning when I entered the car a little after 10, I experienced the same behavior where the Pi would not connect to the Tesla. Understanding now why, I did as advised and simply drove off which would have disconnected from the Wifi and then ultimately should have attached the pi to the Tesla without manual intervention.

But after driving and arriving at destination an few minutes later, it had still not connected. Even after a unplug, plug back in it didn't seem to connect. I went for my run and abotu an hour later came back and now it was able to see the device.

Anything noteworthy in the diagnostics to explain why it didn't seem to auto-connect after losing signal from wifi?

diagnostics.txt

[marcone]

On Sunday morning at 10:02 the Pi started up, saw there was nothing to archive and then proceeded with the normal start up sequence. This was apparently interrupted, because at 10:06 the Pi started up again. This, too, was apparently interrupted, because at 10:07 the Pi started up yet again. This time it looks like you then drove away because the archive became unreachable, and at 10:10 it connected the drives to the car. Then at 11:22 the archive became reachable again, so presumably this is when you returned home. It then proceeded to archive 4 Sentry events consisting of 128 files total. The car (and thus the Pi) turned off before it completed archiving. The car next woke up at 22:20 and again attempted to archive those Sentry events, and again went to sleep before it could complete. Same thing again on Monday morning at 8:29, 8:34 and 8:54. At 8:59 it woke up again, and finally stayed awake long enough to finish archiving and it also synced 31 new music files.

[cmgraz]

On Sunday morning at 10:02 the Pi started up, saw there was nothing to archive and then proceeded with the normal start up sequence. This was apparently interrupted, because at 10:06 the Pi started up again. This, too, was apparently interrupted, because at 10:07 the Pi started up yet again.

I would assume there's no way to know what could have potentially interrupted the startup?

[marcone]

Assuming the cable is good, the only reason for a restart would be a power interruption, e.g. the car goes to sleep and powers off the USB ports. It seems odd that it would do this twice within a minute of each other though.

From the logs it looks like you didn't configure TeslaUSB to use the Tesla API to keep the car awake during archiving, so that's something you might want to do.

[mSarheed]

I have the exact same issue. On a M3 2019. USB not recognized. When I go to the webui and connect then it works fine.

[cmgraz]

I have the exact same issue. On a M3 2019. USB not recognized. When I go to the webui and connect then it works fine.

Have you looked to see if the issue is because it's currently transferring files to your share?

Also, what happens when you drive away? Does it connect at some point?

[mSarheed]

I have the exact same issue. On a M3 2019. USB not recognized. When I go to the webui and connect then it works fine.

Have you looked to see if the issue is because it's currently transferring files to your share?

Also, what happens when you drive away? Does it connect at some point?

I haven't looked at the log, so not sure if it's because it's transferring files.

So sometimes the red x on the camera icon disappears within a minute of entering the car/driving. I believe it's the pi powering up.. other times the red x won't disappear even though I've been driving for 10 minutes..

I will look at the log when it happens again.

[cmgraz]

I'm still experiencing issues with USB connecting to host after departing from wifi.

This was my most recent experience from departure to arrival home and steps taken:

On Mon 21 Aug are 16:20 I got in my car to depart. The USB was not connected to the host, presumably doing some sort of archiving.

By 16:22 I had departed and was outside of my wifi range. The Pi still did not connect to host.

By 16:33 I had arrived at my destination, still not connected to host. At this point I unplugged and then plugged the pi back in. I waited a couple of minutes, but it still did not connect.

I left for a run and returned to the vehicle around 17:35-17:40 time frame. At this point the USB was visible.

I began driving at 17:45 and returned home at 17:52.

teslaDiagnostics-2023-08-22.txt

[marcone]

Looks like TeslaUSB was already running when you left around 16:20 (and had been for a while). The drive should already have been connected to the car because TeslaUSB connected it at 14:59:

Mon 21 Aug 14:59:54 EDT 2023: Connected usb to host.

Shortly after you left though, TeslaUSB restarted:

Mon 21 Aug 16:23:06 EDT 2023: Archive is unreachable.
Mon 21 Aug 16:23:06 EDT 2023: Waiting for archive to be reachable...
==============================================
Mon 21 Aug 16:18:06 EDT 2023: Starting archiveloop at 33.61 seconds uptime...

(the time jump is because Raspberry Pi doesn't have a battery backed clock, so on startup it initializes the current time from a previously saved timestamp. The real time of the restart is probably around 16:34, based on the 16-minute clock adjustment it ends up doing when you arrive back home at 17:52)

TeslaUSB connected the drive to the car at the 16:19 timestamp (which would have been about 16:35 actual time)

Mon 21 Aug 16:19:05 EDT 2023: Connected usb to host.

at the 17:16 timestamp (or about 17:32 real time), TeslaUSB took a snapshot. The car was writing to the drive, so at least that time, the car definitely saw the drive:

Mon 21 Aug 17:16:13 EDT 2023: write in progress

You can get a better idea of when the car actually saw the drive by looking at the RecentClips in the Recordings tab
of the TeslaUSB web interface and checking which recordings exist between 16:20 and 17:45.

Given the random restart while driving, it definitely seems like there's a problem with the USB port, the cable, or the Pi itself.

[cmgraz]

The drive should already have been connected to the car because TeslaUSB connected it at 14:59:

This is hard to reconcile because when I got in the car at 16:20 the USB was not accessible for music and the dashcam had the x on it.

Shortly after you left though, TeslaUSB restarted:

Very interesting. By 16:23 I was definitely in transit so I wonder if some movement in the car had it disconnect due to a bad cable or something. I'll have to try another one.

TeslaUSB connected the drive to the car at the 16:19 timestamp (which would have been about 16:35 actual time)

This makes sense because at 16:33 I had unplugged and plugged it back in after arriving at my destination.

I'll begin to tinker with some of the variables like the cable & port and see if I get more consistent bootups/connections.

[marcone]

The drive should already have been connected to the car because TeslaUSB connected it at 14:59:

This is hard to reconcile because when I got in the car at 16:20 the USB was not accessible for music and the dashcam had the x on it.

TeslaUSB connected the drive to the car at 14:59, and when it took snapshots of the drive at 15:11 and 16:10 it found new files, so the car was definitely recording to it.
This is why I suggested looking at the Recordings tab in the TeslaUSB web interface, because it will show you exactly when the car was recording.

[cmgraz]

I'm not sure if anything with this has changed, but I just can't seem to get consistent working results with this.

I'd say about half the time when I first get in the car, within a couple minutes of being out of WiFi range I'm good to go. The other half the time the x remains until I unplug/plug in the device.

If I park, go do something, and return later, many times I see the x in the red circle. I then have to plug/unplug the RPi and wait a little bit for things to get going again.

I don't know that if maybe when the car goes into sentry mode there's not enough power to keep the rpi zero going? I rarely get sentry events now whereas before anytime someone got close to the car it would record to the native USB.

The other day someone dropped some pamphlet about god inside my cracked window, but the RPi did not catch the event.

I'll have to put the USB back in until I'm able to look into this some more.