In which case why don’t we just do away with the update emonbase button to reduce the chance of screwing up an rfm12 based rfm2pi?
Since Trystan is keen to bring the methods of updating for emonsd and non-emonsd systems closer. Why do we not just change the button to “update” and in the settings.php we have a “update path” setting that is “/home/pi/emonpi/update_emonpi” by default in the emonpi.default.settings.php (and even in process_settings.php if we must) .
then users can edit that line to $update_path = /home/pi/emonpi/update_rfm69pi or $update_path = /home/pi/emonpi/update_rfm12pi if they have an emonbase, (if they click update before changing it will fail to update due to emonpi defaults and not brick thier rfm12pi) OR the rest of us can edit it to something like $update_path = /home/randomuser/myownrepo/update_just_emoncms or some official offering perhaps?
This is safer, simpler, more flexible and broadens the use of the update button to non-emonsd installs.
[edit]
eg when the emonSTM comes out, just drop a update_emonSTM file into the emonPi repo (maybe it’s time the emonpi FW was seperated from the emonSD stuff!)
Also just fior some insight as to how these multiple scripts might work, I imagine something like
#!/bib/bash
source emonsd_update.sh
avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400 -U flash:w:/home/pi/RFM2Pi/firmware/RFM69CW_RF_Demo_ATmega328/RFM12_Demo_ATmega328.cpp.hex
where emonsd_update.sh is a universal update script called from each of the various individual update scripts that can be called from emoncms.
This also accommodates optional FW installs to the emonpi for legacy or CM when it lands. eg $update_path = /home/pi/emonpi/update_emonpiCM or $update_path = /home/pi/emonpi/update_emonpiBETA etc etc