Anyone still rocking a Pi Zero W smart drive for TeslaCam on Sentry Mode?

[DopeGhoti]

There is some magic with taking snapshots of the actual "live" (as far as the car sees) TeslaCam directories that I won't get into for the purposes of simplification.

When the Pi first boots, it will upload any TeslaCam and Sentry footage, and download any music found on the optional music share. It will then go to "sleep" until it's out of range of your wireless network. When it's "asleep", it presents itself as two USB Mass Storage Devices to the Tesla.

When you go out of range, it starts to watch for when you are back in range again. Once you're back in range, it will make sure you're still in range for a good twenty (by default seconds) and then:

If you've set up your Tesla credentials on the configuration file, it will make a note as to whether Sentry mode is on; if it is off, it will turn it on to keep the Tesla awake (and thereby powering the USB ports). It will then upload camera footage and download music again. Once this is complete, it will restore Sentry to its prior state, and go back to "sleep". My understanding (though I need to review the scripts more) is that it does remove the files from your flash media after they are uploaded, so it should never get full unless you're away from home for a long, long time.

 

[Phlier]

My understanding (though I need to review the scripts more) is that it does remove the files from your flash media after they are uploaded,.

This is exactly how mine works. Love it.

 

[chilman408]

I just started with the macrone fork of teslausb and it is working great. I'm just trying to understand what the best setup is. I have a fast 128GB SD card and currently my camsize=16GB and musicsize=0. I noticed that the video clips get copied upon boot from the 16GB bin file into /backingfiles/snapshots. So I suppose you only need a larger camsize if you endure lots of Sentry video's in one go.

I figure teslausb only reboots after the car goes to sleep and cuts power to the Pi Zero W. So if Sentry mode is on all the time and you are never connected to your home wifi the Sentry clips will just accumulate within the 16GB until it is full? Couldn't teslacam detect the 16GB is filling up and empty it into /backingfiles/snapshots during such time?

I dont think that's true (the last part). The pi is checking for wifi every minute if I recall correctly.

 

[DopeGhoti]

The pi is checking for wifi every minute if I recall correctly.

It's not checking for Wifi every minute; it's checking whether it can reach the CIFS (by default) network share for the camera and music files.

 

[RichieB]

I dont think that's true (the last part). The pi is checking for wifi every minute if I recall correctly.

Sure, but I am away from home for several days (so no wifi) and the Pi never reboots, it will just stay in Mass Storage mode and never empty the 16GB disk image? That could be a reason for me to increase it to 32GB. I've also seen people using camsize=100%. That doesn't make sense to me. This leaves no room in /backingfiles/snapshots so what benefit does that have?

 

[DopeGhoti]

Yeah, don't use camsize=100% unless your SD card is rather small. The Tesla will only store one hour no matter how much room there is, the code on the pi pulls them off to its internal partition so that you can keep more footage.

 

[SoCal Cal]

I'm trying to get this to work, but not sure exactly how to go about it. I have an always-on Mac mini running High Sierra acting as a server. I've set up a new user on this server with password and these are entered into the teslausb_setup_variables.conf file. I'm also using the ip of the mini, but not sure what to use for the sharename. Would that be the name of the directory where the cam/music files will be saved? Also not sure what CIFS version to use.

Second question is in regards to the wifi setup. I use a hidden ssid and also have mac address filtering enabled. I somehow got the MAC address from the Pi Zero W as it is in my filter list and I've discovered how to get the hidden ssid recognized by adding scan_ssid=1 into the wpa.supplicant.conf file. If I want to use the wpa.supplicant.conf file, do I just comment out the wifi in the teslausb_setup_variables.conf file? At some point I got the Pi to join the wifi network, but can't seem to get it to join again. I first run the headless setup with the wifi info in the teslausb_setup_variables.conf file, quit that and add the wpa.supplicant.conf file to the /boot directory. It hasn't wanted to connect again. I'm still in the process of messing with it to try and get it to work, but I'm not even sure if I have this set up correctly as far as the network is concerned.

When the Pi successfully connects, will the cam/music files be saved in the folder designated as the sharename? That has yet to happen for me. Anyway, all help and suggestions are appreciated!

 

[RichieB]

Yeah, don't use camsize=100% unless your SD card is rather small. The Tesla will only store one hour no matter how much room there is, the code on the pi pulls them off to its internal partition so that you can keep more footage.

I just went through the teslausb code to figure out how that works. Once the pi is setup the main script that is running is archiveloop which waits for the archive network folder (over wifi) to become reachable so it can do the actual archiving. Inside that script is a snapshotloop function that makes a copy-on-write clone of the complete cam_disk.bin file every hour. So right before the car starts deleting RecentClips a linked copy of all clips is made. Awesome.

My only concern now is the SentryClips slowly filling up the complete cam_disk.bin when I am away from my wifi too long. Or does the v10 software now delete old SentryClips automatically? If not, will teslausb do this to avoid filling up cam_disk.bin?

 

[dmurphy]

I started getting that immediately after V10, and then after a bit the Pi was just not getting seen by the car at all. Booting and checking the logs had the filesystem in a very bad way, and it needed re-imaging. This was replicated by some others using the same build; a fresh build should be immune, as it were.

So, I finally got off my duff and rebuilt the Zero with the Raspbian Buster image, and it’s working well. No speed issues of note.
I also installed a new 12V-to-USB charger (only had to drill one hole but I’m super pleased with the results) so I was able to eliminate my USB splitter and reduce the draw on the USB port to just the Zero W. That might be helping too.

Anyway, back in business and feeding my Synology NAS with Teslacam videos as we go.

 

[miles267]

Mine isn't synching any files to my windows share. using the default .conf values. The default is CIFS 1.0. Are Windows Server 2012 R2 file shares CIFS 1.0, 2.0, 2.1 or 3.0?

 

[DopeGhoti]

If you're actually sharing to Windows Server '12, go ahead and use CIFS3.

 

[miles267]

Great - thank you. I'll re-image my teslausb buster image with CIFS 3.0 instead. I've successfully setup Wi-Fi access and am able to access my Windows Server 2012 share from the Raspberry Pi Zero, however no data is being uploaded to the file share. Is there a recommended way to troubleshoot sync failures? I swear I'm constantly reimaging this microSD card and copying new .conf files to it and re-running setups repeatedly.

 

[DopeGhoti]

The easiest way to troubleshooot syncing is to SSH into the Pi, become root, and run the commands `touch /tmp/archive-is-unreachable` and then `tail -f /mutable/archiveloop.log` to see what it happening. The file you're `touch`ing simulates the pi (and therefore the car) "driving" out of range of your network. After a minute, it will check again, see your network (and hopefully CIFS share), and attempt to sync, and you should see log entries showing what has tipped over.

 

[Dan203]

Great - thank you. I'll re-image my teslausb buster image with CIFS 3.0 instead. I've successfully setup Wi-Fi access and am able to access my Windows Server 2012 share from the Raspberry Pi Zero, however no data is being uploaded to the file share. Is there a recommended way to troubleshoot sync failures? I swear I'm constantly reimaging this microSD card and copying new .conf files to it and re-running setups repeatedly.

You don't have to reimage. You can make changes after the fact. You just have to long in via SSH then...

sudo -i
/root/bin/remountfs_rw
cd boot
nano teslausb_setup_variables.conf
(make your edits)
Ctrl+X to save and exit
reboot

Note: This doesn’t work for changing your Tesla user/password. You have to edit a .py file for that and change the access token, or delete those files and rerun setup

 

[Dan203]

FYI anyone who got v10 you need to run this update command to make it work right...

marcone/teslausb

There were some changes in v10 that need to be accounted for and it wont upload your clips to the share until you run the update

 

[Phlier]

FYI anyone who got v10 you need to run this update command to make it work right...

marcone/teslausb

There were some changes in v10 that need to be accounted for and it wont upload your clips to the share until you run the update

Odd.. I’m running 11.1 and my Raspberry Pi is working fine.

Guess I better do the update. Kinda hate to mess with it since it’s working though.

 

[Dan203]

Odd.. I’m running 11.1 and my Raspberry Pi is working fine.

Guess I better do the update. Kinda hate to mess with it since it’s working though.

Mine wasn’t uploading. As soon as I updated I got 4 days worth of videos.

 

[focher]

Has anyone gotten OTG support working on a Raspberry Pi 4? I get to the point where I issue the "sudo modprobe g_mass_storage file=/piusb.bin stall=0" and it succeeds, but the drive never appears on the host device. Just wondering, because I explicitly am using a USB cable with OTG support.

 

[BioSehnsucht]

Has anyone gotten OTG support working on a Raspberry Pi 4? I get to the point where I issue the "sudo modprobe g_mass_storage file=/piusb.bin stall=0" and it succeeds, but the drive never appears on the host device. Just wondering, because I explicitly am using a USB cable with OTG support.

Are you using the USB-C port? That's the OTG port on the 4B.

Also you might need additional options. I've been using these additional options :

removable=1,1 ro=0,0 iSerialNumber=123456

(1,1 and 0,0 because I'm creating two separate mounts, one each for dashcam/sentry and music - otherwise would be just 1 and 0)

 

[Dan203]

So the Pi 4 works? Can it also act as a wifi hotspot?

I'm thinking maybe we could modify it to display a webpage on the Tesla's browser that could actually play the videos. I'm not sure the Zero is powerful enough for that, but the Pi 4 should be plenty powerful enough.