The other issue is overwriting users calibrated/modified/custom sketches, just because it has a emonGLCD doesn’t mean it is mandatory to run the stock sketch. What if users have something else attached to the GPIO serial port? Possibly a emonTx? Possibly something non-OEM perhaps?
I made a suggestion over in the emonSD first boot - #19 by pb66 thread to have a “update command” defined in the settings.php that could default to an “update emonpi” command to carry forward the existing emonpi update behaviour.
Removing the “update emonBase” button and just having one “update” button that defaults to an “update emonpi” command removes any possibility of a user “bricking” their rfm12pi accidentally as no rfm2pi devices will get updated due to the wrong upload baud. emonBase users will have to edit settings.php to update either their rfm12pi or rfm69pi by defining the appropriate update command (apparently it would be no biggy if they neglect to do so since the rfm??pi FW has not changed in quite sometime).
Possibly there will be (currently) a choice of 5 or 6 update commands update_emonpi(default), update_rfm69pi*, update_rfm12pi*, update_emonsd update_emoncms and update_custom.
[(*) - although even with a choice between rfm12pi and rfm69pi some notes will be needed as the rfm12pi’s came in 2 flavours rfm12b and then later, rfm69cw. This was way before the rfm69pi arrived with the additional IO broken out.]
The names can be agreed later but, these options can be either commented out or just explained in the notes. Users can always add their own, but we can add an update_custom file to .gitignore, and advise users that’s where they can write their own update scripts without fear of it being overwritten or included in any PR’s they may submit.
The update_emoncms option would be just that, just updates emoncms and all it’s modules and update_emonsd would just update the emonSD image completely, but without any firmware updates being done. Handy for users with custom FW that do not want to write their own update script or lose the updates to emonhub etc by using the update_emoncms command.
This is simple and easy to use but very flexible. It removes one of the 2 update buttons whilst increasing the options and removing the accidental “wrong button” usage. It will include a much wider audience rather than just the emonSD/Pi/base users. The 12v69 warning can be removed from the gui for a cleaner more professional looking all inclusive solution. With no additional config files, identifiers or assumptions forcing a mandatory overwrite of users hard work (customising or calibrating sketches).
The 5/6 commands simply call one of the 3/4 update script wrappers (update_emoncms and update_emonsd will be full scripts, in fact update_emoncms would even be part of update_emonsd too) eg for the update_rfm69pi
#!/bin/bash
# Update script for the emonSD on emonBase with rfm69cw based RFM2Pi module.
# First we update the rest of the image inc emonhub, emoncms and the FW repo's etc
source update_emonsd.sh
# Then we update the RFM2Pi with the correct firmware.
echo "Updating rfm69pi firmware"
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
whilst for the update_emonpi
#!/bin/bash
# Update script for the emonSD on emonPi.
# First we update the rest of the image inc emonhub, emoncms and the FW repo's etc
source update_emonsd.sh
# Then we update the emonpi add-on boards firmware.
echo "Updating emonpi firmware"
avrdude -v -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 -U flash:w:/home/pi/emonpi/firmware/compiled/latest.hex
These can be fleshed out with better log messages and/or comments etc, but you get the gist hopefully. The bulk of the updating is done via the same script, included in any number of simple wrappers that offer options to the various user groups, easily defined in settings.php and easily customised without becoming excluded through fear of overwrites and/or refused git pulls etc.
I’d be happy to implement this, this isn’t a demand for someone else to do it, just floating the idea, if it’s well received I will do the work, I just don’t want to spend hours doing it if it’s a non-starter.
…