id suggest getting a longer usb cable and putting the pi where you can see the lights with the car off/locked. Testing purposes only. And leave your phone away
if it’s still on, then you can try and login, etc.
-
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
id suggest getting a longer usb cable and putting the pi where you can see the lights with the car off/locked. Testing purposes only. And leave your phone away
if it’s still on, then you can try and login, etc.
There's actually a shortcut for doing this... you delete three files (I need to go get my Pi to get the names of them.. I'll edit/add here in a sec), then you transfer over your configuration file back to the boot partition of the Pi. Make sure that you always keep a copy of the configuration file on your computer. Keep the actual configuration file you used to create your teslausb.
After deleting those files and then copying over the new configuration file, you just power up the pi and wait. It won't take nearly as long as starting over from a brand new flash.
Also, were you able to supply your actual server name in the config file, or did you have to use the server's IP address? I couldn't get server_name to work with anything other than an IP address, so I had to setup my desktop computer to have a static LAN IP address.
@A-Wimoweh Too late to edit my above post, so here's a shortcut to starting over without having to reflash the drive from scratch.
Insert the micro SD drive into your computer, and open up Windows Explorer. Browse to the "boot" volume. You'll need to delete three files:
TESLAUSB_SETUP_FINISHED
WIFI_ENABLED
teslausb-headless-setup
After deleting those three files, copy your config file back to the "boot" volume, and power on your pi. It'll take much less time to get going again, as it's smart enough to not re-do stuff that doesn't need to be.
Technically, you don't need to delete the "teslausb-headless-setup" file, as it's just a log that lets you know what happened each time it runs your config file, but it can get really cluttered if you have more than one configuration attempt written to the one file. So deleting it each time assures you that the only information in that file will be what happened during the most recent run of your config file.
Edit: Also, don't worry about Windows complaining that a bunch of drives need to be formatted. Make sure you hit cancel to each of those popup dialog boxes. That's completely normal. After you've canceled out of all of them, you will have access to the "boot" volume, and that's all that matters.
One last edit: After your configuration file is run, the pi deletes it from the "boot" volume. This is why it's essential that you keep an exact copy of it on your computer.
Mine is working great now, but I need to get a WiFi extender for the garage. It takes forever to copy stuff over. Oh, I just realized you asked about that... your Pi not having enough time to copy stuff over before the car sleeps.
I guess I'm a bit too trusting; I went ahead and un-commented out the part in the config file where you can have your Pi use your Tesla account credentials to send API commands to the car to keep it awake while it's transferring files. Haven't had it time out yet using this method.
Insert the micro SD drive into your computer, and open up Windows Explorer. Browse to the "boot" volume. You'll need to delete three files:
TESLAUSB_SETUP_FINISHED
WIFI_ENABLED
teslausb-headless-setup
After deleting those three files, copy your config file back to the "boot" volume, and power on your pi. It'll take much less time to get going again, as it's smart enough to not re-do stuff that doesn't need to be.
Technically, you don't need to delete the "teslausb-headless-setup" file, as it's just a log that lets you know what happened each time it runs your config file, but it can get really cluttered if you have more than one configuration attempt written to the one file. So deleting it each time assures you that the only information in that file will be what happened during the most recent run of your config file.
Edit: Also, don't worry about Windows complaining that a bunch of drives need to be formatted. Make sure you hit cancel to each of those popup dialog boxes. That's completely normal. After you've canceled out of all of them, you will have access to the "boot" volume, and that's all that matters.
One last edit: After your configuration file is run, the pi deletes it from the "boot" volume. This is why it's essential that you keep an exact copy of it on your computer.
Mine is working great now, but I need to get a WiFi extender for the garage. It takes forever to copy stuff over. Oh, I just realized you asked about that... your Pi not having enough time to copy stuff over before the car sleeps.
I guess I'm a bit too trusting; I went ahead and un-commented out the part in the config file where you can have your Pi use your Tesla account credentials to send API commands to the car to keep it awake while it's transferring files. Haven't had it time out yet using this method.
Last edited:
Just to update I've now got this working
There was a commit done three days ago that fixed the time issue, rebuilt tonight as per normal, then following using the mkdir command to make the correct directory and rerunning rclone as per @YauKwan has got my files syncing
There was a commit done three days ago that fixed the time issue, rebuilt tonight as per normal, then following using the mkdir command to make the correct directory and rerunning rclone as per @YauKwan has got my files syncing
Last edited:
Man, I apologize for the chain posting, but I keep thinking of more stuff after it's too late to edit previous posts.
Something that I don't think is covered very well in the teslausb documentation is the flashing LED and what it means.
Continuous Rapid Flashing: The Pi is attempting to transfer your dashcam footage to your computer and/or synching your music folder.
Two Quick Flashes: The Pi is in "USB Flash Drive" mode, and is ready to be used in your Tesla for recording sentry cam, dashcam and playing music back.
Something that I don't think is covered very well in the teslausb documentation is the flashing LED and what it means.
Continuous Rapid Flashing: The Pi is attempting to transfer your dashcam footage to your computer and/or synching your music folder.
Two Quick Flashes: The Pi is in "USB Flash Drive" mode, and is ready to be used in your Tesla for recording sentry cam, dashcam and playing music back.
OK, one last post... for now.
A few tips for those of you that are having problems with this...
1. Try to keep all symbols for your account names, passwords, WiFi SSiD's, etc. to letters and numbers only. Don't use anything else. Trying to get the single quotation marks to work when you have to pass a character that would be "special" to the Pi doesn't work consistently. Trying to explain the exact meaning of that last sentence is "beyond the scope of this post."
2. Don't use single or double quotation marks at all. Example: export sharename=TeslaCamRecordings
Don't do it like this: export sharename='TeslaCamRecordings'
Don't do it like this: export sharename="TeslaCamRecordings"
Because of the fact that certain characters (like #) have special meanings to the Pi, it becomes very difficult to use them as part of a value (like a sharename or a password) that contains those characters as part of the name (or password). Avoiding the use of any characters other than letters and numbers is the workaround, as single and double quotes don't appear to be working as they should...they are supposed to be a way for the Pi to ignore the symbol and pass it as a value instead, but it's just not working right in this config file. You could also "escape out" any reserved symbol, but again.. that's beyond the scope of this post.
3. If you are using a flavor of Windows later than (and including) Windows 8 for your shared folder(s), uncomment the CIFS version line, like so:
# export cifs_version="3.0"
becomes this:
export cifs_version="3.0"
Now I know I said not to use double or single quotes, but this is an exception.
4. If you know that you've setup your share correctly, but the Pi complains that it can't reach the share server, use the actual LAN IP address of the share server instead. If you're using a share on your computer, you'll want to setup your computer to use a static LAN IP address. Do a Google search on "how to setup a static LAN IP" if you're unsure how to do this. Please note that this is a static LAN IP address, not a static WAN IP address. Big (and important) difference.
5. If you have a problem, please post your config file and a description of the problem you're having here. If I can't help you, I should at least be able to point you someplace that can.
A few tips for those of you that are having problems with this...
1. Try to keep all symbols for your account names, passwords, WiFi SSiD's, etc. to letters and numbers only. Don't use anything else. Trying to get the single quotation marks to work when you have to pass a character that would be "special" to the Pi doesn't work consistently. Trying to explain the exact meaning of that last sentence is "beyond the scope of this post."
2. Don't use single or double quotation marks at all. Example: export sharename=TeslaCamRecordings
Don't do it like this: export sharename='TeslaCamRecordings'
Don't do it like this: export sharename="TeslaCamRecordings"
Because of the fact that certain characters (like #) have special meanings to the Pi, it becomes very difficult to use them as part of a value (like a sharename or a password) that contains those characters as part of the name (or password). Avoiding the use of any characters other than letters and numbers is the workaround, as single and double quotes don't appear to be working as they should...they are supposed to be a way for the Pi to ignore the symbol and pass it as a value instead, but it's just not working right in this config file. You could also "escape out" any reserved symbol, but again.. that's beyond the scope of this post.
3. If you are using a flavor of Windows later than (and including) Windows 8 for your shared folder(s), uncomment the CIFS version line, like so:
# export cifs_version="3.0"
becomes this:
export cifs_version="3.0"
Now I know I said not to use double or single quotes, but this is an exception.
4. If you know that you've setup your share correctly, but the Pi complains that it can't reach the share server, use the actual LAN IP address of the share server instead. If you're using a share on your computer, you'll want to setup your computer to use a static LAN IP address. Do a Google search on "how to setup a static LAN IP" if you're unsure how to do this. Please note that this is a static LAN IP address, not a static WAN IP address. Big (and important) difference.
5. If you have a problem, please post your config file and a description of the problem you're having here. If I can't help you, I should at least be able to point you someplace that can.
Last edited:
Quick update on this, as it wasn't quite working as well as I'd hoped
The symlink hadn't auto created when I re-setup rclone under the mutable directory, not being a linux guy I didn't really know how to check. Working again this morning, some thoughts on how to fix;
First up, the latest branch now has the time fix in, so you don't need to install rdate, I can confirm this now works and sets the correct time/date.
Secondly, I'm not convinced you need to rerun rclone for the mutable config, I think you can just move the dir based on some more reading I've done.
SSH in and run;
mv /root/.config/rclone /mutable/configs
This should move the config to the correct dir.
To check if the symlink is in place, run this;
ls -l /root/.config
You should see (ignoring the timestamp):
total 0
lrwxrwxrwx 1 root root 23 Oct 31 10:25 rclone -> /mutable/configs/rclone
If you dont (the important bit being the -> you can run the following to create the correct link;
ln -s /mutable/configs/rclone /root/.config/rclone
You should then see the symlink in place, reboot the pi and try again!
Thanks for the guidance on getting me to the right place
The symlink hadn't auto created when I re-setup rclone under the mutable directory, not being a linux guy I didn't really know how to check. Working again this morning, some thoughts on how to fix;
First up, the latest branch now has the time fix in, so you don't need to install rdate, I can confirm this now works and sets the correct time/date.
Secondly, I'm not convinced you need to rerun rclone for the mutable config, I think you can just move the dir based on some more reading I've done.
SSH in and run;
mv /root/.config/rclone /mutable/configs
This should move the config to the correct dir.
To check if the symlink is in place, run this;
ls -l /root/.config
You should see (ignoring the timestamp):
total 0
lrwxrwxrwx 1 root root 23 Oct 31 10:25 rclone -> /mutable/configs/rclone
If you dont (the important bit being the -> you can run the following to create the correct link;
ln -s /mutable/configs/rclone /root/.config/rclone
You should then see the symlink in place, reboot the pi and try again!
Thanks for the guidance on getting me to the right place
I got it running - I think.
Are the mounts to the archive server for /mnt/archive, /mnt/musicarchive, /mnt/can and /mnt/music only there when there is something to transfer.
I take it that this is only fired off when you get connected to your Wifi? Is there a way to fire off the transfer of music without waiting for the car to sleep and then walking it up?
Also, is there a log someplace that tells me what's happening with the program?
Are the mounts to the archive server for /mnt/archive, /mnt/musicarchive, /mnt/can and /mnt/music only there when there is something to transfer.
I take it that this is only fired off when you get connected to your Wifi? Is there a way to fire off the transfer of music without waiting for the car to sleep and then walking it up?
Also, is there a log someplace that tells me what's happening with the program?
There seems to be an issue with the Teslausb raspberry pi Z W and some Tesla models. For some reason the MCU 1/AP 2.5 models cannot mount the drive. I can mount in on my PC and see the 2 drives popping up. In my Nov 2017 model S nothing shows. The LEDs are working ad intended. 1 blink/s when not in reach of my Wifi, 2 blinks per second when connected to my wifi. There's a github issue on this @marcone build. Thuggery posted a workaround with a hub that I cannot confirm yet. Is anyone experiencing the same issue? Has anyone a working solution? Can anyone tell me what the nvidia chip does that it doesn't mount the drive or know code to edit how to get it mounted?? Thanks! R
Tz00
X
Tz00
X
Who said it draws more than 10W? Read the specs.
Raspberry Pi 4 specs and benchmarks - The MagPi Magazine
It works fine plugged into the car.
Can you take a video on this set up running?
I mean the link doesn't link to the specs. It did show measured powered draw but the official Pi4 psu runs 15W.
Not saying your lying but idle load at 3.5W doesn't mean an TM3 usb port will power the Pi4 unless the Pi4 is idling the entire time you're using it. (i.e. having wifi running...each module draws power).
Any power draw over 5W will give u issues.
Tz00
X
Yes, 15W max for accessories on the Pi. Even at full CPU load, the Pi is less than 10W. Just because the power supply is 15W rated does not mean it needs/uses it.
Thanks for all the feedback. From reading up on the question myself;
Looks like the TM3 USB ports delivers around 2-2.1A based on different sources (One of them: Front USB ports now supporting ~2.0A on my Model 3 with 2018.14.13 : teslamotors)
The Pi4 draws 1.12A at peak (Raspberry Pi 4 vs Raspberry Pi 3 Plus (Model B) - Tutorial)
And the Samsung T5 draws around 0.5A at peak (Samsung Portable SSD T5 Review: 64-Layer V-NAND Debuts in Retail)
So this/my planned setup should work fine.
Looks like the TM3 USB ports delivers around 2-2.1A based on different sources (One of them: Front USB ports now supporting ~2.0A on my Model 3 with 2018.14.13 : teslamotors)
The Pi4 draws 1.12A at peak (Raspberry Pi 4 vs Raspberry Pi 3 Plus (Model B) - Tutorial)
And the Samsung T5 draws around 0.5A at peak (Samsung Portable SSD T5 Review: 64-Layer V-NAND Debuts in Retail)
So this/my planned setup should work fine.
Sorry, here is a more recent thread about TM3's usb power delivery.
Did Voltage for front USB ports change w/ 50.6?
I did these measurement myself a year back and was never able to repeat the 2A draw claim.
Similar threads
- Article
