Since you decided to fork, I hope you don't mind I'm opening an issue for you since you made an ideas section of your readme :) A few recent reddit posts on v9 seem to indicate multiple partitions on a USB stick give the ability to have one partition for the "teslacam" storage and a separate one for media/music.

Assuming that split partitioning works, It'd be a great addition here to also sync down a media library to a secondary mountpoint. I just ordered a pi and won't be able to try til it gets here. Happy to try and do this myself and submit a PR

32gb SD card

Went through the following steps:

1. Used Etcher on Windows PC to flash Raspbian Stretch Lite onto SD card.
2. Using mini hdmi/keyboard - did not use headless setup
3. Went through all of the steps - Archive server was reachable
4. Set campercent to 100
5. After reboot - got an error regarding "/mnt/archive" - Something about unable to Mount. Everything
   else showed OK.
6. Wasn't sure what to do at this point, so I unplugged the pi and plugged it back into Windows PC
7. Windows showed 2 drives - One as a boot drive with around 40mb total space 20 used and one as
   29gb empty unformatted drive. The drive was not accessible, so I tried to format as FAT32 and created
   TeslaCam directory, but I don't think I was in a usable state regardless.

Had a friend look at it, and it seems like the partitioning might not be giving me enough space to mount the archive? Any tips and what I should try to do next, or if I did something wrong?

Thanks.

I was thinking about the problem of powering the Pi when the car turns off - long enough to upload.

The best solution I could find was this HAT by Alchemy Power. With an 800mAh battery in place, given ~250mA max draw on the Pi, that's still plenty of power even assuming fairly heavy losses. I'm planning to ignore the low battery GPIO - if you shut down on low battery, there's no signal to restart unless you press a button. I'll know more tomorrow when it arrives; for now, it seems to be pretty much the same thing as using a splitter and connecting a USB battery.

Assuming shutdown isn't an option, is there anything useful to do when we know the car's off? (Corollary problem: the car might come back on before we lose power, so there's no guarantee of a clean boot.)

I'm also planning to build a watchdog circuit for this problem unless Tesla ships automatic camera upload before I have time to think about the problem - I'll publish all of my work/research in a fork under the same license, of course!

This way, rather than adding scripts to the pi to copy/move files to the server, the server can detect when the pi is accessible and pull the files or sync the music. Also, a user can manually look at files without copying files on the server first.

I should start by saying I haven't exactly run the scripts in this repo, but I ran most of what's in the reddit thread. When I set the root fs to read only in fstab, the usb storage becomes read only too, and thus the car is unable to record any dash cam footage. What do I need to do to make the usb storage writable while keeping the root filesystem read only, to avoid corruption?

Ok this didn't end up testing when the commit was all said and done.

sed -i -e "s/rootwait/rootwait modules-load=dwc2,g_ether/" -e "s@ init=/usr/lib/raspi-config/init_resize.sh@@" fails with sed -e: No such file or directory

I originally had sed -i'.bak' to create the backup files, per this thread:
https://stackoverflow.com/questions/4247068/sed-command-with-i-option-failing-on-mac-but-works-on-linux

specifically:

There is no portable way to avoid making backup files because is impossible to find a mix of sed commands that works on all cases:

sed -i -e ... - does not work on OS X as it creates -e backups
sed -i'' -e ... - does not work on OS X 10.6 but works on 10.9+
sed -i '' -e ... - not working on GNU

The command works on Mac if I append the .bak (or choose your extension :) ). I'll PR it and you can test if desired.

Now that we have the /mutable partition we should keep the log from archiveloop and the other runtime scripts there.

Since they'll persist we should also add some primitive log rotation/truncation.

So, the dual drives was working great for me for about a day. Now, I see a bunch of USB drives in the media app. The first time I noticed this, I tried to click one of the "drives" just off the top of the screen and I could see my music, but now, even that doesn't work. I suspect the car keeps seeing progressively more and more empty drives and the one with music is now pushed way off the edge of the screen. Or I could be totally wrong.

[(https://imgur.com/BbaiWyu)]

Formatted the card with Etcher
Setup the pi using the Windows Powershell Instructions
Logged in via wifi and setup rclone
Ran setup-teslausb and received this message:

Downloaded /tmp/verify-configuration.sh ...
Verifying that there is sufficient space available on the MicroSD card...
STOP: The MicroSD card is too small.

parted shows the following:

/dev/mmcblk0:64021856256B:sd/mmc:512:512:msdos:SD GC2QT:;
1:32256B:4194303B:4162048B:free;
1:4194304B:50119679B:45925376B:fat32::lba;
1:50119680B:50331647B:211968B:free;
2:50331648B:1866465279B:1816133632B:ext4::;
3:1866465280B:63915950079B:62049484800B:ext4::;
4:63915950080B:64021856255B:105906176B:ext4::;

Is it possible to just copy over all recorded footage rather than the save*?

I plan on working this one, just wanted to open it for feedback.

Utilizing apache2 & php, have a simple web UI running on the Pi that can provide some statistics (such as space used/free), mount status, and then enable control of new settings to drive minor variations in script behavior such as copying files instead of moving them. Potentially also add the ability to trigger the copy process manually if it did not fire for some reason.

I had to either set the cifs version option to 1.0, or remove it (so it autonegotiates). The default of 3 didn't seem to work for me. I did also try setting the Windows compatibility option on the Mac share. Mac CIFS/SMB is often iffy anyway, so there's probably a "most compatible" setting, and it may change after Mojave even. I'm not going to update the share server to Mojave for a bit though, so, fine for now.

From #5

setup-teslausb should be able to mount the cam drive and create the TeslaCam directory automatically. This would eliminate several steps from the setup instructions as the pi would not need to be connected to a PC before being used in a Tesla.

I can make this change tomorrow if there are no objections about its usefulness.

From #17

Presumably this is for people that have to use shared Wifi networks.

Following the latest instructions. I finish the "Get a shell on the Pi" section and I'm logged in via SSH. But the next sections starts with "Now that you have Wifi up and running....", but my WiFi is not up and running. I believe earlier instructions required manually starting the wlan interface? Now it's supposed to be automatic?

I run ifconfig and wlan0 is up, but doesn't look connected (no IP Addr or anything).

I checked /etc/wpa_supplicant/wpa_supplicant.conf and ssid and password look good.

running sudo wpa_cli -i wlan0 reconfigure gives this error:

Failed to connect to non-global ctrl_ifname: wlan0 error: No such file or directory

What am I doing wrong? I got it up and running last week.

The car could move out of range of the network in between the time that the check for connectivity is preformed and the attempt to mount the archive is made.

Some folks have another raspberrypi on the network and might get confused when they try to reconnect to raspberrypi.local and wonder where all their changes went. (Like this somebody 😉) Suggest "teslapi" or similar. Simple sed exercise likely.

Looks like something is going on in the new method of creating backing files.

Configured the archive scripts.
Fixing the modules-load parameter in /boot/cmdline.txt...
Fixed cmdline.txt.
Error: The location 124735488 is outside of the device /dev/mmcblk0.

I believe this is on mkfs.ext4 -F /dev/mmcblk0p3.

Here's the mount status:

oot@raspberrypi:~# mount
/dev/mmcblk0p2 on / type ext4 (rw,noatime,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=217624k,nr_inodes=54406,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=30,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
sunrpc on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=44388k,mode=700,uid=1000,gid=1000)

Fdisk -l

root@raspberrypi:~# fdisk -l
Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram1: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram2: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram3: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram4: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram5: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram6: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram7: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram8: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram9: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram10: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram11: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram12: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram13: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram14: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram15: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/mmcblk0: 59.5 GiB, 63864569856 bytes, 124735488 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x40fa9455

Device         Boot Start       End   Sectors  Size Id Type
/dev/mmcblk0p1       8192     97889     89698 43.8M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      98304 124735487 124637184 59.4G 83 Linux

and df:

root@raspberrypi:~# df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/root       61339276 1078076  57736860   2% /
devtmpfs          217624       0    217624   0% /dev
tmpfs             221940       0    221940   0% /dev/shm
tmpfs             221940    8660    213280   4% /run
tmpfs               5120       4      5116   1% /run/lock
tmpfs             221940       0    221940   0% /sys/fs/cgroup
/dev/mmcblk0p1     44143   22501     21643  51% /boot
tmpfs              44388       0     44388   0% /run/user/1000

Tried to mount a share folder on my Synology NAS. Got the "mount error(95): Operation not supported" error when running setup-teslausb. Message to the user suggest this: "

Try specifying a lower number for the CIFS version like this: export cifs_version=2

This actually doesn't work. I suggest changing this to:

Try specifying a lower number for the CIFS version like this: export cifs_version=2.0

This works.

I'm a h/w guy and this is my first time really on github... If it's alright with you guys, I would like to try my hand at contributing with this minor change. Would I just open a pull request? Sorry for being a total newb.

Imagine that the car is in an accident outside the range of a cell tower. You'd like to get the video onto your phone so you can show the local police what happened. You don't have a laptop in the car.

It should be possible to configure the Pi so that it acts as both a WiFi client and AP at the same time: https://www.raspberrypi.org/forums/viewtopic.php?t=138730

With just that change the scenario would be achievable with a terminal client and an SFTP client running on the phone.

A further enhancement would be to add a simple web server on the Pi which allow one to trigger

1. (virtual) ejection of the USB drive from the car
2. mounting the backing file

A yet further enhancement would be to list the saved clips through the website for direct download to the phone.

I'm still thinking this one through, but it's quite annoying that files are 1min / 30MB in size and having to deal with them after they get copied off. It'd be nice to have an option to combine files within a range (like everything for a given day stamp) before copy.

FFMPEG can concatenate, given a list of files, so it would be something like "for every file with name like %date% and file size == 30.1MB" written to a file and FFMPEG cats them.

This may never make sense unless you're doing the climate control trick, or a passthrough battery trick. You need to ensure file integrity and so on, obviously.

Putting out there to solicit feedback either way.

Is the apt-get update part of make-root-fs-readonly.sh required? I let that step run for a few minutes and it was estimating it had more than 30 minutes remaining to update the package list.

If this is not essential, it may be worthwhile to remove the package update from the script.

Maybe we'll do this if people express interest.

I guess Tesla has a habit of recording corrupted video.....at least 1 file per day sometimes more.

Is there an easy to search and delete them all?

CAM drive not mounting on windows (multiple machines) fresh install

Further scripting & automation would be aided by having setup-piForHeadlessConfig.ps1 and setup-teslausb accept command line parameters and prompt for the values only if the command line values are not present.

setup-piForHeadlessConfig.ps1 needs SSID & key
setup-teslausb needs archiveserver, sharename, shareuser, sharepassword, campercent

Perhaps this would help make regression testing easier as well?

it does seem like it's eating the IP address somehow.

Originally posted by @rtgoodwin in #8 (comment)

I have been finding that sometimes the files deposited on my server are only 2K in size, and since they are purged from the PI there is no recovery. Given that these may contain important video the default should be to preserve it on the Pi and just copy to the file server, then if there are any problems the originals are still available.

So I got this thing setup last night and it seems to work...

I have plug the drive to my Tesla and I see a partial file copied to my TM3 folder in my windows server.

However, this morning I only see that a 5mb file is copy to my shared folder under this name:
saved-front-2018-10-16_01-36.mp4

And this file is incomplete because it is not playable.

So then, I got to the office today and directly plugged the drive into my laptop. I don't even see this file on the drive anymore.

So a couple of questions....(sorry, didn't mean to combine questions):

1. Is this the correct behavior? When the readme says "archive" does it mean it will delete the copied over file? (If so, can I just assume in this case that Tesla didn't record correctly?)
2. Or does this script require the Pi Zero to be constantly powered on? (Did I shut off the car too quickly?)
3. Does this script record everything that start with "Recent-...."? Or only the "Saved-Front-..."?

Thanks!

Maybe we'll do this if people express interest.

I believe you can use the name options to specify something so it doesn't show as "NO NAME" when mounted on a computer. Definitely personal choice.

From: #5

Question about "sharename", can this be a full path of a samba share or it has to be a folder name in the base of the Shareserver?

Allegedly this is a thing that can happen to Raspberry Pis.

Thanks for the merge!

Just tested and looking good except for a minor change I'll be pushing to the image to default to your master branch. If using the conf sample file you'd probably be fine, but in mine I had fully commented out the repo/branch which made the initial script download fail.

But this prompt happened during a manual run where partitioning which will stop the interactive setup:

Warning: You requested a partition from 63757999616B to 63864569344B (sectors 124527343..124735487).
The closest location we can manage is 63758663680B to 63864569344B (sectors 124528640..124735487).
Is this still acceptable to you?
Yes/No? 

First time I've seen this, I'm guessing it's not going to be hit for everyone, or maybe a recent change?

I added the -s flag ("script"/non-interactive) to parted in a new branch more_logging but parted doesn't consider this a passable error.

Starting to create backing files partition...
Checking existing partitions...
Modifying partition table for backing files partition...
Modifying partition table for mutable (writable) partition for script usage...
Error: You requested a partition from 63757999616B to 63864569344B (sectors 124527343..124735487).
The closest location we can manage is 63758663680B to 63864569344B (sectors 124528640..124735487).

That's from this morning's codebase... do we need a slightly more conservative set of partition boundaries, or maybe it's a calculation bug?

the USB drive still isn't mounting to the host.

root@teslausb:~# mount -a -v
/proc                    : already mounted
/boot                    : already mounted
/                        : ignored
/backingfiles            : already mounted
/mnt/cam                 : ignored
/mnt/archive             : already mounted
/var/log                 : already mounted
/var/tmp                 : already mounted
/tmp                     : already mounted

root@teslausb:~# ls -la /backingfiles/
total 56235672
drwxr-xr-x  3 root root        4096 Oct 17 15:36 .
drwxr-xr-x 23 root root        4096 Oct 17 15:36 ..
-rw-r--r--  1 root root 57585291264 Nov  3  2016 cam_disk.bin
drwx------  2 root root       16384 Oct 17 15:36 lost+found

root@teslausb:~# cat /etc/fstab
proc            /proc           proc    defaults          0       0
PARTUUID=7fd599a5-01  /boot           vfat    defaults,ro          0       2
PARTUUID=7fd599a5-02  /               ext4    defaults,noatime,ro  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

/dev/mmcblk0p3 /backingfiles ext4 auto,rw,noatime 0 2
/backingfiles/cam_disk.bin /mnt/cam vfat noauto,users,umask=000 0 0
//MYIPHERE/TeslaCamFiles /mnt/archive cifs credentials=/root/.teslaCamArchiveCredentials,iocharset=utf8,file_mode=0777,dir_mode=0777 0

tmpfs /var/log tmpfs nodev,nosuid 0 0
tmpfs /var/tmp tmpfs nodev,nosuid 0 0
tmpfs /tmp    tmpfs nodev,nosuid 0 0

Not sure where the mount logic or file creation logic changed to break this.

Originally posted by @rtgoodwin in #30 (comment)

When the archive can't be mounted we can't currently determine whether the problem is the CIFS version or the username/password.

verify-archive-configuration.sh could be replaced with another script, say, "get-archive-configuration" which would return the mount options, or at least the CIFS version.

This script could iterate through the four different CIFS versions that mount.cifs supports, and fail if none of them work instructing the user to check the username/password.

It would be great to be able to sync media files from multiple networks in addition to their home network such as at work or via a mobile hotspot.

One way to enable this is to provide support for two things:

1. Allow user to specify multiple SSIDs to automatically connect to when available.
2. Allow the user to specify parameters for a VPN that would automatically be connected to.

This would allow one to securely sync their media files to their private network whenever they connected to a predefined list of wireless access points.

Got Wifi working, but can't get setup-teslausb to run to completion. On second run it stopped because /root/bin existed. Deleted that. Then it stopped because /backingfiles existed. Deleted both /root/bin and its contents, and /backingfiles, and third try got me down to where it downloaded /root/remountfs_rw, and then it quite with the error "The location 65333952 is outside of the device /dev/mmcblk0.

Don't know what to change to fix that..

Right now the Pi only scans for and fixes corruption while attempting to archive. If the backing files get corrupted by a loss of power, we can probably fix the corruption when the power is restored.

Not all hosts are discoverable by name; for example mine isn't. So the script lines that find the share server IP by resolving the hostname won't work for me.

From #5

I completed the configuration instructions up to the last part about Get the Pi set up for your Tesla. Windows would never see the Pi as a USB drive. I manually created the TeslaCam directory on the Pi via ssh and tried to connect to my car. The Model 3 never detected the Pi either.

After much debugging, I discovered the issue was with the USB cable I was using. Once I swapped cables, the Pi was detected by Windows as a USB drive and the Tesla started to use it.

TLDR: check your USB cable if your Pi is not detected after configuration

I can work on this one, since I want to update the script that sets up USB networking anyway.

You can put the credentials in /boot/wpa_supplicant.conf before booting the Pi the first time and it will autocopy and configure on first boot.

If you split the dirs out into Windows and Mac/Linux then that will help even more in this case since we can ensure that someone can edit the USB connect script with a *nix compliant editor.

Then just run it, eject the card, and boot your Pi into glorious USB and (assuming you did it right) Wifi options right off the bat.

It looks like no new log data is getting written for archiveloop or archive-te3slacam-clips and the files are reported as not writeable. I am not seeing any files transfer even though I have clicked the camera to save some and have booted up a couple of times. Both files have the same last timestamp of "Thu 3 Nov 17:17:10 UTC 2016" which appears to be created during the setup, and nothing after that.

Are there other log files to look in for logs to determine what is up?

Where can I find the camera files on the PI to be sure that they are visible to code running on the PI? I wanted to verify that there are files visible to the Pi, but I haven't been able to find them through SSH looking in places like /mnt/cam and everywhere else I can think of. The files do appear on the USB drive when I plug it into my PC.

I'm getting this error right before the reboot step. So after reboot, the CAM drive does not show up on windows.

Error: The location 62535680 is outside of the device /dev/mmcblk0.

Downloaded new files today (October 23rd around 9:30 EDT) and after running setup-teslausb and rebooting it comes up wtih a USB device not recognzied error. I've tried multiple cables that work for data transfer, using both data and a second on the power to ensure it isn't insufficient power, reflashing and redoing the whole process. Also has this issue yesterday before the commits last night and this morning. Attached is the powershell window, hope I scrubbed it all.

Detail.txt

I am attempting to set this up to upload files to an azure storage file share. I can manually mount the share on the pi, however, it fails when using the same values in the setup script.

What is the reason for using the IP address instead of the name supplied?

I'm planning on modifying this in my repo to skip this and use the name instead of IP. I can PR that change if desired.

Maybe we'll do this if people express interest.

Not sure if you've had a chance to test on an actual car, but I verified it this morning on a Model 3, v39.7! And great jump on making the setup script; I was going to do that but didn't get to it yet. 👏

Created the Pi Zero W + 64GB MicroSD setup on a Macbook with Mojave; network share is on a USB drive on a Mac Mini High Sierra. I didn't use the full df size, chose 40GB instead. Some notes...

1. It takes about 45 seconds to become available, sometimes less. (Maybe fsck from dirty shutdown?)
2. I didn't use your setup script, but it looks to be right. I may redo things from scratch just to help test that for you. Especially if you end up making the changes below before I do. :)
3. The requisite improvements asks below; I might try to do them myself but it may take a couple of days to find time (and re-google-learn my bash scripting):

• Suggest changing the hostname in hosts (127.0.0.1 entry) and hostname. Some folks have another raspberrypi on the network and might get confused when they try to reconnect to raspberrypi.local and wonder where all their changes went. (Like this somebody 😉) Suggest "teslapi" or similar. Simple sed exercise likely.
• Optionally change mount name in vfat mount options: I believe you can use the name options to specify something so it doesn't show as "NO NAME" when mounted on a computer. Definitely personal choice.
• Not all hosts are discoverable by name; for example mine isn't. So the script lines that find the share server IP by resolving the hostname won't work for me. Suggest checking the archive name value to see if it's an IP to bypass that bit if needed.
• I had to either set the cifs version option to 1.0, or remove it (so it autonegotiates). The default of 3 didn't seem to work for me. I did also try setting the Windows compatibility option on the Mac share. Mac CIFS/SMB is often iffy anyway, so there's probably a "most compatible" setting, and it may change after Mojave even. I'm not going to update the share server to Mojave for a bit though, so, fine for now.

I also changed the archive script to copy ....TeslaCam/* instead of ....TeslaCam/saved*, since I've seen at least one other pattern in there. (recent- files) This may not be the smart thing to do, not sure if it messes with the rolling recording, but if the goal is to always archive everything (which makes sense as you obviously won't be viewing in the car...), it seems to make sense. I'll have to do a solid hour drive at some point to validate if the recent- get compiled down to a single file (which would be a reason to keep them around); just not sure that they do.

Working on this as a test project to ease a lot of setup. Please mark enhancement.

Tried setup twice with same results, have a 128GB Samsung Evo SD card. The first go round I follow the manual instructions on reddit, the second go round I used the scripted setup here on github. With the same results both times, initial setup goes fine, it shows up as a Ethernet adapter, I get it connected to WiFi, but failure seems to be in the USB storage emulation. It fails to show up on my Windows machine and fails to show up in the Tesla. If I check device manager in Windows I see the error Unknown USB device ( Device Descriptor Request Failed) Hardware ID USB\DEVICE_DESCRIPTOR_FAILURE