A couple of reasons, potential cost (maybe unlikely, but not looked into it) and ease of using the data elsewhere, I've managed to swap hosting providers really simply when GCP was blocked for a while and back again (and then back once more!)
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
A couple of reasons, potential cost (maybe unlikely, but not looked into it) and ease of using the data elsewhere, I've managed to swap hosting providers really simply when GCP was blocked for a while and back again (and then back once more!)
Didn't think of the issue of transferring the data to another provider, in case we get a repeat of the aws/gcp/azure issue from last year.
Until now I've been taking snapshots of the server thinking I could run a one of backup of the TeslaMate data if I needed to move it anywhere, although think I should still be able to do this even if the API connection to Tesla was severed?
Glan gluaisne
Active Member
Just a word of caution for those using Teslamate on a Raspberry Pi. I had a µSD card failure yesterday, not sure why, but I do know that this isn't an uncommon event with a Raspberry Pi that's running 24/7. My Raspberry Pi 3B that's running Teslamate has been on for around a year now, never been turned off, as it's running from a UPS. Not really a problem, other than a bit of lost data since the last backup, a week or so ago, but it has reminded me to set up a regular back up task to the main house server.
For anyone interested, the early signs of failure were a couple of times when I couldn't access Teslamate/Grafana, fixed by rebooting, followed by a hard failure where the Pi just wouldn't reboot. Fixed by just restoring the data to a new image on a new µSD card. This time I'm trying a Samsung Evo 32Gb card, rather than the 8Gb Sandisk one it had been running on. I may build a more robust RPi4 box, booting from SSD, as I also run Pi Hole in another Docker container on the RPi3. Off topic - For those keen on cutting out crap from getting into their LAN, I can recommend Pi Hole, BTW. It seems to do exactly what it says, and what's more doesn't seem to trigger most ad blocker alerts.
For anyone interested, the early signs of failure were a couple of times when I couldn't access Teslamate/Grafana, fixed by rebooting, followed by a hard failure where the Pi just wouldn't reboot. Fixed by just restoring the data to a new image on a new µSD card. This time I'm trying a Samsung Evo 32Gb card, rather than the 8Gb Sandisk one it had been running on. I may build a more robust RPi4 box, booting from SSD, as I also run Pi Hole in another Docker container on the RPi3. Off topic - For those keen on cutting out crap from getting into their LAN, I can recommend Pi Hole, BTW. It seems to do exactly what it says, and what's more doesn't seem to trigger most ad blocker alerts.
phil4
Member
What you're backing up and how decides what you're protecting against. Server snapshot against server hack/corruption/loss. Data backup - hack/corruption/provider loss.
Also, for those backing up, don't forget to try restoring now and again. You don't want to find out the backup doesn't restore when you need it, find that out beforehand.
Also, for those backing up, don't forget to try restoring now and again. You don't want to find out the backup doesn't restore when you need it, find that out beforehand.
You definitely could, I'm just hopefully saving a step, also means the data is always available in the unlikely event of a region being down or something else (not that this is life or death data of course
)This may have been mentioned before but for info:
Any µSD card being used for a lot of read/write cycles should ideally be using one of the "high endurance" types of card intended for high duty use, typically made for CCTV and DashCam type uses, these are designed for repeated write cycles where your "average" SD card is not.
The "normal" SD cards are intended for long-time write and occasional read i.e. in still cameras and phones.
A "high endurance" card should give you many years of logging application service.
NB crashing the Pi (regularly) may of course still most-likely corrupt any card eventually so best avoided where possible.
Got this working with Google Client ID and Client secret, does anyone who uses the GDrive backup fancy being a willing victim / volunteer before I update my guide? (also add in an edit version, as you don't have to start from scratch).
MrBadger
Badger out
SD card wearing out and improperly shutdown device are the two main causes.
You can dial down the Pi logging to reduce wear on the cards, especially useful if using small media cards. The rest is down to the individual app. I wrote my own app for Solar logging, so it does minimal logging.
For power down corruption, a UPS HAT to handle improper dismount in the event of impromptu power shutdown - it will detect power failure and shutdown gracefully and restart when power restored. A very worthwhile £30 or so iirc. Mine appears to be a slightly older version of UPS PIco - Uninterruptible Power Supply (HV3.0B+)– The Pi Hut - just watch the size of any battery and case - I got the more limited slim line battery which is good for a brief outage before having to safely shut everything down - not a problem as I was logging solar which needs power on to run plus router would be out anyway.
The other suggestion is to take a zipped image backup of the whole media card and store the image away somewhere. So when the inevitable does happen, a new media card can be easily restored. Obviously a additional backup strategy is needed for any persistent data that may be stored. I log to an external repository so max I have to lose is a single 5 minute aggregation of data.
My current Solar monitoring setup has been running this setup 24/7 since early 2014 and has been very reliable although I did swap out the card early on due to power supply failure corruption - thats when I went with the UPS HAT. Only gets a reboot when we have a sustained power cut - ironically some issues getting the Tesla home charging put an end to its longest uninterrupted run of a month shy of 2 years.
You can dial down the Pi logging to reduce wear on the cards, especially useful if using small media cards. The rest is down to the individual app. I wrote my own app for Solar logging, so it does minimal logging.
For power down corruption, a UPS HAT to handle improper dismount in the event of impromptu power shutdown - it will detect power failure and shutdown gracefully and restart when power restored. A very worthwhile £30 or so iirc. Mine appears to be a slightly older version of UPS PIco - Uninterruptible Power Supply (HV3.0B+)– The Pi Hut - just watch the size of any battery and case - I got the more limited slim line battery which is good for a brief outage before having to safely shut everything down - not a problem as I was logging solar which needs power on to run plus router would be out anyway.
The other suggestion is to take a zipped image backup of the whole media card and store the image away somewhere. So when the inevitable does happen, a new media card can be easily restored. Obviously a additional backup strategy is needed for any persistent data that may be stored. I log to an external repository so max I have to lose is a single 5 minute aggregation of data.
My current Solar monitoring setup has been running this setup 24/7 since early 2014 and has been very reliable although I did swap out the card early on due to power supply failure corruption - thats when I went with the UPS HAT. Only gets a reboot when we have a sustained power cut - ironically some issues getting the Tesla home charging put an end to its longest uninterrupted run of a month shy of 2 years.
Last edited:
Glan gluaisne
Active Member
I have a power strip powered by an APC UPS that runs a landline phone, a couple of fanless PCs, the fanless home server, the power feed to our router, and this RPi,. That APC UPS was, without a doubt, one of the best things I've ever bought. Apart from the normal power cut protection, it's just incredibly useful to have always-on power for things like the landline phone, given that self-powered phones seem to almost be a thing of the past, and that we can't get a mobile signal here. Also handy for times like the SSE chap pulling the fuse (again) this morning. It meant that I could phone his office for him when he discovered there was no signal here, he'd isolated the power and then needed to urgently ask someone at his office a question . . .
spooksman
Member
I can assist if you want, even though I only just got mine working again.
I'm not great with Unix mind, so you'll need to be gentle with me...
Thanks to @spooksman for testing the revision to what's needed for the backup, I'll get the new instructions written up by the end of the week, I'll cover off both a fresh install and also how to edit your existing setup.
It's a bit more of a pain than it should be as Google upped security on the app/api interface last year, but we can still get it working and hopefully the backups will be a bit more reliable now too!
It's a bit more of a pain than it should be as Google upped security on the app/api interface last year, but we can still get it working and hopefully the backups will be a bit more reliable now too!
If you need another victim/volunteer to test the steps give me a shout.
Thanks @StuC - Once I've typed it up, if you could run through it, that'd be great
Have you got the backup in place at the moment, or would you be starting from scratch?
I have it in place and get the same Rate Limit error others have seen
So I updated the cost on a geofence location and got the box that asked me to apply it to all unreported fields so I did that. Shortly after I realized I missed a couple of decimal points so its showing the cost way higher than it should be. I updated the cost on the geofence but I no longer have the option to update all of the fields at once and don't really want to update over 100 fields manually.
Is there an easy way to update all of the charging cost fields simultaneously?
Is there an easy way to update all of the charging cost fields simultaneously?
Moderator comment - several posts moved from Octopus Go versus Agile
I have just switched to Octopus Go and would like to collect and analyze my usage using the Grafana that comes as part of Telsamate. I run Teslamate on a hosted Ubuntu server. I have tried to add the Octopus energy data source to Grafana, but am not able to get it to work. Has anyone does this as well and is willing to help?
I have just switched to Octopus Go and would like to collect and analyze my usage using the Grafana that comes as part of Telsamate. I run Teslamate on a hosted Ubuntu server. I have tried to add the Octopus energy data source to Grafana, but am not able to get it to work. Has anyone does this as well and is willing to help?
Last edited by a moderator:
Similar threads
