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.
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
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:
# 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.
echo This can take about 45 seconds to complete
echo Remote machine is $remotemachine
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
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.
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.