-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
Anyone still rocking a Pi Zero W smart drive for TeslaCam on Sentry Mode?
- Thread starter chilman408
- Start date
Tz00
X
I have a small USB battery pack on mine, so it is available immediately. If the Pi loses power, it is going to take a minute or so for it to boot up for the car to be able to use it. A standard USB memory stick wouldn't have any boot-up time. So that seems normal. Same thing happens to me if I power cycle the Pi while in the car driving.
Do you mean the USB virtual mass storage gets corrupted? This custom Pi software has code in there to detect that and fix it automatically, each time it mounts the drive to upload I think. I've never had to flash the whole Pi image again.
i'm using marcone/teslausb because it has the auto wifi sync to home network of music and videos, but i don't think it auto fixes the corrupted mass storage...
Not sure if this is happening to everyone or if you came across this, but after the 2019.16.x usb disconnects will trigger the alarm. So when the raspberry pi zero decides to randomly disconnects with sentry mode on, your alarm will trigger. Had this happened to me a couple of times recently and came across this info under the issue section for marcones Github.
I'm on 16.2 and can't say I'm having this issue. Do you get a notification on your phone when the alarm is triggered also?
Very rarely does it disconnect when driving or in sentry mode (that I'm aware of), maybe once a month I'll notice it not connected while driving requiring me to unplug and reinsert. I do have it powered via the 12v, not sure if it matters. I use sentry mode anytime the car isn't parked at home but I do have it set up to turn sentry mode at home for 30 minutes to sync up files overnight, but never had the alarm trigger.
Tz00
X
I've had it happen a few times, and it seemed to be when I was at home (connected to WiFi) for a short time, where the Pi didn't have enough time to finish uploading all of the video, before the WiFi connection dropped when I drove away.
I've written my own Perl script to upload the data instead of the multiple shell scripts. I've had to work out a few bugs and have only been running it a few days, but it seems to not lose the connection to the car now, when I specifically drop the WiFi connection. Time will tell if this fixes the issue or not though.
This is the only problem I'm having with marcone/teslausb - the drive connects to my home wifi and begins archiving fine. If I don't give the pi enough time to finish archiving (drive away before it's done), the pi never stops trying to archive and remount the cam/music drives. I have to unplug and restart the pi to get the drives remounted and the camera recording.
I would love to know if your scripts have sorted that out, let me know!
Tz00
X
I've still got an issue with that. I thought it was fixed, but I had that situation today, and it hung up.
I've made some changes, so I'll see if that helps.
I've made some changes, so I'll see if that helps.
There is a fix on marcone/teslausb with keeping the car awake with your Tesla API credentials.
I never have to use this as everything works without it, I use 12v power to usb on the Pi Zero.
The 12v socket on my Model 3 is powered 24/7 since the recent FW updates...
Tz00
X
Yes, it appears to work so far. Basically the copy command was hanging forever, so I created an alert of 90 seconds that would kill it if it took more than 90 seconds to copy one file. Then before each file copy command, I check to make sure I can ping the server and check to make sure the archive is mounted before trying to copy the next file. Then it goes back to mount the USB again and only re-tries copying once it can ping the archive host again and the archive is mounted. I added a bunch of sleeps around things, as I want reliably over speed.
If I get time to finish what I started, I think I have an idea that solves the remounting / driving away while uploading problem.
Instead of raw partitions, use LVM, and in LVM have the filesystems. To start upload, take a snapshot, mount it, upload it, destroy when done. Do sort of the opposite for Music - when done transferring files, take a snapshot, and mount that to the Tesla. So later if you're fiddling with it, you don't have to unmount until you're done, and then you unmount the snapshot, destroy it, make a new one, mount it.
Of course if you want to remove clips from the dashcam, you'll have to unmount the drive, remove them, and then remount it to the Tesla, but that's something that can get queued and be done almost instantly.
I've partially tested this (mounting snapshots), and also tested trying to use ext4 (works for music, much faster indexing than FAT32, but doesn't work for dashcam). I haven't tested it yet but I also had the idea of using ext4 with symlinks to create faux playlists that can be played using the directory playback mode... rather than making extra copies (or hardlinks).
You can also get the Pi to be both a Wifi client and AP (even at the same time), so you could in theory connect your phone to it to review dash cam / sentry mode clips, even when not at home on your home wifi.
It's too bad there's no way for the Pi to tell (at least via USB) that the car has turned off, and then do maintenance tasks (like checking if the TeslaCam drive needs to be fixed or reformatted). There's not even an event to detect that the device was unplugged...
Instead of raw partitions, use LVM, and in LVM have the filesystems. To start upload, take a snapshot, mount it, upload it, destroy when done. Do sort of the opposite for Music - when done transferring files, take a snapshot, and mount that to the Tesla. So later if you're fiddling with it, you don't have to unmount until you're done, and then you unmount the snapshot, destroy it, make a new one, mount it.
Of course if you want to remove clips from the dashcam, you'll have to unmount the drive, remove them, and then remount it to the Tesla, but that's something that can get queued and be done almost instantly.
I've partially tested this (mounting snapshots), and also tested trying to use ext4 (works for music, much faster indexing than FAT32, but doesn't work for dashcam). I haven't tested it yet but I also had the idea of using ext4 with symlinks to create faux playlists that can be played using the directory playback mode... rather than making extra copies (or hardlinks).
You can also get the Pi to be both a Wifi client and AP (even at the same time), so you could in theory connect your phone to it to review dash cam / sentry mode clips, even when not at home on your home wifi.
It's too bad there's no way for the Pi to tell (at least via USB) that the car has turned off, and then do maintenance tasks (like checking if the TeslaCam drive needs to be fixed or reformatted). There's not even an event to detect that the device was unplugged...
Any chance you'd be willing to share that script? I'm all in for reliability over speed
Holy cow! I just did this! Just in case anyone is wondering, I did the One step setup from the marcone repository. I have a NAS box at home, so I made a "TeslaCam" SMB share. Went for a test drive, recorded some clips, got back, pulled into the garage, walked into the house and mounted the share and, sure enough, my clips were uploaded!
One FYI. When I first booted after inserting the SD card, I waited about 10 min, but the LED was just on solid... so I logged in and looked at /boot/teslausb-headless-setup.log, but the last entry was over 5 min ago... so, following the troubleshooting steps, I did
and it then proceeded with the rest of the setup and that's it!
The only downside I see with this is that takes about 30-60 seconds from when you "start" the car until it starts recording
One FYI. When I first booted after inserting the SD card, I waited about 10 min, but the LED was just on solid... so I logged in and looked at /boot/teslausb-headless-setup.log, but the last entry was over 5 min ago... so, following the troubleshooting steps, I did
Code:
sudo -i
/etc/rc.localThe only downside I see with this is that takes about 30-60 seconds from when you "start" the car until it starts recording
You just described my experience. I tried the manual install twice and it failed, one step worked fine after 2 tries... First attempt was the same as yours.
Similar threads
- Article
