Hello,
I’m sure there is a simple solution to this but I’m not much of a programmer.
I want to backup my emoncms to a flash drive (/media/usb0) and not to the system SD card.
I have made the following change to /opt/emoncms/modules/backup/config.cfg:
# Destination location of exported backup .tar.gz - Must be writable
##backup_location="/var/opt/emoncms/backup"
backup_location="/media/usb0"
This works correctly but then the config.cfg is overwritten by the default version after the next update.
Obviously, I have something else to change but I’m at a loss what it is.
Thanks in advance to anyone pointing out my problem.
Cheers,
Bob
I don’t think the problem is one of your making. I’m running a test version of the new front end sketch in my emonPi, and if I stop and start that, or it restarts itself for any reason, emoncms automatically goes away and “downdates” itself, that sketch is wiped out and the default one re-installed. I’ve got a script to write it back, but it still needs human intervention. I think not enough consideration was given to the possibility that a user might want to not have the “standard” setup.
I’m not aware of a method of preventing that from happening. In my case, I don’t have an “unlimited” Internet tariff during the daytime, so I want to run costly updates between midnight and 8 am when I do have free data. In my book, automatic updates should be an option, not forced. It was forced updates that caused me to dump Mickeysoft and Windoze.
IIRC, there is a way to keep “changes” via the git stash command.
Ref:
After stashing your changes via git stash
check out the branch you want your changes on, and then git stash apply. Then use git diff to see the result.
After you’re all done with your changes—the apply looks good and you’re sure you don’t need the stash any more—then use git stash drop to get rid of it.
I always suggest using git stash apply rather than git stash pop. The difference is that apply leaves the stash around for easy re-try of the apply, or for looking at, etc. If pop is able to extract the stash, it will immediately also drop it, and if you the suddenly realize that you wanted to extract it somewhere else (in a different branch), or with --index, or some such, that’s not so easy. If you apply, you get to choose when to drop.
Thanks for the replies. I see what is happening and agree that the overwrite of config.cfg should be optional. I’m not familiar with the intricacies of git and will not attempt that approach.
Although I’m not a fan of using a penny in the fuse box, is there a simple workaround that I could use to avoid the changes in config.cfg such as removing part of this section of install.sh?:
# Creating backup module config.cfg file
echo "- Copying default.config.cfg to config.cfg"
cp default.config.cfg config.cfg
echo "- Setting config.cfg settings"
sed -i "s~USER~$user~" config.cfg
sed -i "s~BACKUP_SCRIPT_LOCATION~$backup_module_dir~" config.cfg
sed -i "s~EMONCMS_LOCATION~$emoncms_www~" config.cfg
sed -i "s~BACKUP_LOCATION~$emoncms_datadir/backup~" config.cfg
sed -i "s~DATABASE_PATH~$emoncms_datadir~" config.cfg
sed -i "s~EMONHUB_CONFIG_PATH~/etc/emonhub~" config.cfg
sed -i "s~EMONHUB_SPECIMEN_CONFIG~$emonhub_directory/conf~" config.cfg
sed -i "s~BACKUP_SOURCE_PATH~$emoncms_datadir/backup/uploads~" config.cfg
For now I’d create a local copy of the settings and copy it back after any update. It is a simple fix (my bash is not good enough to do the PR) but hopefully @TrystanLea will pick this up.
Here’s my bash script to copy the front end sketch from my laptop into the emonPi, and subsequently upload it into the ATMega 328P. You won’t need the second part. Note I’ve got a pair of keyfiles set up as per the comment at the top. These authorise the machine the script runs on to access the Pi. Obviously you’ll need to change the machine, source and target to suit:
#!/bin/bash
# Generate a SSH key pair with "ssh-keygen" Don't set a password.
# Keys are in /home/r/.ssh files are private key: id_rsa; public key: id_rsa.pub
# Copy to the Pi with "ssh-copy-id [remote id] e.g.remote-id = '[email protected]', password "emonpi2016" is required ]
# Needs SSH & SCP on source machine. Avrdude should exist on the Pi.
#
remotemachine='[email protected]'
sourcefile='/home/r/OpenEnergy/Software/rfmNATIVE/EmonPiCM/emonFrontEndCM/emonFrontEndCM.ino.standard.hex'
targetfile='/opt/openenergymonitor/emonpi/firmware/compiled/emonFrontEndCM.ino.standard.hex'
echo This can take about 45 seconds to complete
echo
echo Remote machine is $remotemachine
echo
scp $sourcefile $remotemachine:$targetfile
ssh $remotemachine sudo service emonhub stop
ssh $remotemachine avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:$targetfile
ssh $remotemachine sudo service emonhub start
exit
So have you - yet again. Have you read what the script does - and what I wrote wasn’t needed?
I can’t tell the difference - apart from file names and paths - between copying one sort of file and copying a different sort of file. It’s the same problem, transferring the file from a computer being driven from a keyboard (and not even that, necessarily, it could be a cron job) to the emonPi.
Brian,
I must still be doing something wrong here.
I modified config.cfg and set the backup location to /media/usb0.
Ran backup from console and everything worked correctly with .tar.gz
file sent to the correct location.
Ran full update from console.
Checked config.cfg and found it had been replaced as before with default.config.cfg.
Is full update not the correct way to go? Do I need to modify config.cfg each time I do a full update?
Sorry to be a bit dense on understanding here. Thanks.
It looks like you might usefully use my sledgehammer technique after all. Here’s a shortened version that will, when everything is set up, copy the file sourcefile on your laptop or whatever to the Pi remotemachine at the location with the name targetfile. Obviously, you need to change those to suit.
