Using the newly merged Docker functionality, Pi Zero W, and 64GB microSD.

What I'm seeing is that the drive is showing up as a drive, and rsync'ing data, but is not cleaning up apparently. Twice the SD has completely filled, and once it got down to 1.2GB available and stopped showing up as a drive.

In this last instance I SSH in, and try to attach to the docker cleaner container, and it took a while, then printed:

Running [find /video/RecentClips -mtime +2 -type f -delete]

I tried cleaning off a bunch of RecentClips, and nothing changed in the output (stayed attached). top doesn't show anything as consistently using a lot of CPU.

Not sure how to debug this one, honestly, but overall the Docker structure is working...once the cleanup works! :)

When the dashcam-monitor mounts an image and looks for files it always reports 0 files. This seems to be because the countFiles function returns 0. Tesla now always has two directories under TeslaCam (SavedClips and RecentClips).

Changing the following like from .isFile to .isDirectory fixes this but I am unsure if that is the right direction to go.

Opening this issue for conversation and to track a PR.

Could you update the install instructions to be more detailed? I have minimal knowledge of using the command line and I got stuck on node install. I'm also not sure if after booting the PI for the first time if that removes my ability to see the filesystem when plugged into the data port and connected to a windows machine.

Thanks for this code. Hoping to get it fully working. Here are the steps I've taken to go through the install. I've done everything thus far as root:

`Insert your SDHC card into your PC. Launch Etcher. Point it to the location of the Raspbian .zip file and flash the card. When that is completed, I ejected the card and reinserted it.
Connect the Micro USB to USB cable to the USB labeled port on the Pi Zero W

Use an SSH client to SSH to the Pi Zero W

hostname: rasbperrypi.local
username: pi
password: raspberry

Do everything as root:

sudo su -
cd /boot
vi wpa_supplicant.conf

Paste this for the WiFi Setup:

country=us
update_config=1
ctrl_interface=/var/run/wpa_supplicant

network={
scan_ssid=1
ssid="yourwifi"
psk="yourpassword"
}

reboot

SSH back into the Pi to install DaemonTools:

mkdir -p /package
chmod 1755 /package
cd /package

wget http://cr.yp.to/daemontools/daemontools-0.76.tar.gz
tar -xpf daemontools-0.76.tar.gz
rm -f daemontools-0.76.tar.gz
cd admin/daemontools-0.76

ed ./src/conf-cc
1s/$/ -include errno.h/
wq
package/install

apt-get install csh
csh -cf '/command/svscanboot &'
sed -i "1 a\csh -cf '/command/svscanboot &'" /etc/rc.local
chmod +x /etc/rc.local

Install Node.js:
mkdir -p /opt/node; cd /opt/node
wget https://nodejs.org/dist/v10.16.0/node-v10.16.0-linux-armv6l.tar.xz
tar -xvf node-v10.16.0-linux-armv6l.tar.xz
chown -R root:root node-v10.16.0-linux-armv6l
ln -s /opt/node/node-v10.16.0-linux-armv6l/bin/* /usr/bin/

apt-get install git
git config --global user.name "Me"
git config --global user.email [email protected]
cd /home/pi
git clone https://github.com/milesburton/teslacam
mkdir -p /etc/service;cd /etc/service;ln -s /home/pi/teslacam/services/* .
cd /home/pi/teslacam;npm install
cd /home/pi/teslacam/src/remote;npm install`

When I plug it into the USB port on the PI and the front USB on the Tesla M3, I never see the icon on the touchscreen that signifies the USB drive is seen.

I haven't done any DropBox integration yet as ultimately I want to upload to my Synology NAS

I do not believe the mv command has a -r option. It is recursive by default if you move a *

Error:

mv: invalid option -- 'r'
Try 'mv --help' for more information.

pi@raspberrypi:~/teslacam/video $ mv --help
Usage: mv [OPTION]... [-T] SOURCE DEST
  or:  mv [OPTION]... SOURCE... DIRECTORY
  or:  mv [OPTION]... -t DIRECTORY SOURCE...
Rename SOURCE to DEST, or move SOURCE(s) to DIRECTORY.

Mandatory arguments to long options are mandatory for short options too.
      --backup[=CONTROL]       make a backup of each existing destination file
  -b                           like --backup but does not accept an argument
  -f, --force                  do not prompt before overwriting
  -i, --interactive            prompt before overwrite
  -n, --no-clobber             do not overwrite an existing file
If you specify more than one of -i, -f, -n, only the final one takes effect.
      --strip-trailing-slashes  remove any trailing slashes from each SOURCE
                                 argument
  -S, --suffix=SUFFIX          override the usual backup suffix
  -t, --target-directory=DIRECTORY  move all SOURCE arguments into DIRECTORY
  -T, --no-target-directory    treat DEST as a normal file
  -u, --update                 move only when the SOURCE file is newer
                                 than the destination file or when the
                                 destination file is missing
  -v, --verbose                explain what is being done
  -Z, --context                set SELinux security context of destination
                                 file to default type
      --help     display this help and exit
      --version  output version information and exit

The backup suffix is '~', unless set with --suffix or SIMPLE_BACKUP_SUFFIX.
The version control method may be selected via the --backup option or through
the VERSION_CONTROL environment variable.  Here are the values:

  none, off       never make backups (even if --backup is given)
  numbered, t     make numbered backups
  existing, nil   numbered if numbered backups exist, simple otherwise
  simple, never   always make simple backups

GNU coreutils online help: <http://www.gnu.org/software/coreutils/>
Full documentation at: <http://www.gnu.org/software/coreutils/mv>
or available locally via: info '(coreutils) mv invocation'

I followed the directions and interpreted them how I should to make it work. However when plugged into the car I’m able to activate sentry mode but not access anything on port 3000. Ideas? Where are the logs. What triggers 3000 to start. I have the power for the pi in constant 5v and the usb into the cars port.

V10 brings a few changes to the way dash cams work. Opening this as a placeholder.

1. It adds rear camera to the recording (4th file) so we should consider making the image larger.
2. t adds an auto clean up of sentry cam files if the disk gets too full. We should consider how this will interact with our relatively small image files.

Sorry to trouble you but I am trying to configure a Raspberry Pi Zero W for use with a friends Tesla Model 3. Unfortunately, although I have installed Rasbian on the Pi, can SSH into it etc, I cannot beyond step 3 of your instructions in the “ On your TeslaCam Pi (via SSH)” stage of the install shown on your GitHub page (https://github.com/milesburton/teslacam). I think that the curl command is failing.

Consider using node instead of nodemon to host the backend and host the compiled frontend either from the same node server or use http-server with the proxy switch.

This will make it so the slow raspberry pi hardware doesn't have to do the heavy lifting of webpack compile.

Thoughts on switching from FAT32 to ext4 as the file system that is exposed to the Telsa?

Tesla's officially docs say it must be FAT32 but this is not true, the car will mount and happily write to ext4 (tested on my model 3 software version 2019.20.4.2).

The big advantage of this that I can think of is a journaled file system that won't get corrupted so easily plus ext4 supports multiple mount projection. This would allow us to mount it by the pi and copy files off it live. That would mean no more multiple images, we could just construct one very large image and work off of it.

Hey,

I haven't actually tried your code, but wanted to ask for help.

After the latest update with Sentry mode, have you been able to get the Tesla to write to the raspberry pi without showing the "Camera with X" icon

This is a self observed bug. Whilst compiling the UI artefacts the load on the PI zero increases which appears to cause a brown out - this was never an issue previously. The interim solution is to power the PI using a second power supply.

The answer is likely to precompile the UI before installing in your Tesla. Currently it's operating in hot-reload.

For now I suggest disabling the UI entirely - I've not found it particularly useful given the reliability of the dropbox upload.

Question: yarn or npm ?

I see a yarn.lock file but the readme mentions doing npm install.

No preference here, just want to keep consistent.

Excellent, is there anything I can do to help test or assist in the code?

Model 3 here as a testbed.

You'd be making my life a 100x easier if you could check out the branch I mentioned above and burn that to a fast SDHC card and see what it does.

If you can poke around and see if any changed you make results in a different outcome that would be helpful. Currently I've been comparing a standard USB drive vs. the TeslaCam and I've struggled to see a difference - I did wonder if the USB serial number or other information was bleeding through and maybe Tesla blocked it for security reasons.

Given the car doesn't offer any diagnostics to us mere humans, it's somewhat trial and error.

The car has absolutely mounted the pi with the above branch mounted, but after some time it dropped out. (I've also seen this on standard USB flash drives, so it could be unrelated).

Any help would be appreciated, once this is up and running again it opens up some cool prospects

Originally posted by @milesburton in #9 (comment)

Occasionally on my M3 (V10) it will warn that the drive is too slow to record dash cam video. I think this is happening when the 2nd image is having it's files rsynced off.

Consider rate limiting the offloading of the files from the image that is not online. Other options?

I am getting this over and over again.

docker logs 0e68aea53b3f
TeslaCam Dropbox Upload daemon
(node:1) ExperimentalWarning: The fs.promises API is experimental
(node:1) UnhandledPromiseRejectionWarning: Error: Warning, getFiles called under SSH, This will not work.
at getFiles (/usr/local/teslacam/src/common.js:74:11)
at init (/usr/local/teslacam/src/dropbox-upload.js:66:25)
at Object. (/usr/local/teslacam/src/dropbox-upload.js:78:1)
at Module._compile (internal/modules/cjs/loader.js:776:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:787:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Function.Module.runMain (internal/modules/cjs/loader.js:829:12)
at startup (internal/bootstrap/node.js:283:19)
(node:1) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
(node:1) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Hey, is it planned to allow support for more remotes than dropbox, like google drive?

I seem to be having trouble with the docker portion of the install script. I'm assuming the short url from the readme (https://git.io/fjPiW) is supposed to link to get-teslacam.sh ? right now its just 404

$ sh ${GET_TESLACAM}
Installing TeslaCam
# Executing docker install script, commit: 6bf300318ebaab958c4adc341a8c7bb9f3a54                                                                            a1a
+ sudo -E sh -c apt-get update -qq >/dev/null
+ sudo -E sh -c apt-get install -y -qq apt-transport-https ca-certificates curl >/dev/null
+ sudo -E sh -c curl -fsSL "https://download.docker.com/linux/raspbian/gpg" | apt-key add -qq - >/dev/null
Warning: apt-key output should not be parsed (stdout is not a terminal)
+ sudo -E sh -c echo "deb [arch=armhf] https://download.docker.com/linux/raspbian buster stable" > /etc/apt/sources.list.d/docker.list
+ sudo -E sh -c apt-get update -qq >/dev/null
INFO: Searching repository for VERSION '18.06.*'
INFO: apt-cache madison 'docker-ce' | grep '18.06.*.*-0~raspbian' | head -1 | awk '{$1=$1};1' | cut -d' ' -f 3

ERROR: '18.06.*' not found amongst apt-cache madison results

Since the Pi is simulating a USB drive, and the Tesla will likely never try to read the files after writing, would it be possible for it to simulate more than what's actually available and let the car continuously write? This would require some clever logic to handle the writes.

Or what if the Pi copied over and deleted video on the fly, in real-time as the car is writing to the same volume.