As you can see from the rfm69pi update script the firmware update comes directly from RFM2Pi github releases. The firmware is compiled in the cloud using TravisCI and platformIO, see blog post.
Using GitHub releases for firmware deployment has several advantages:
Gets around the problem of users having non-commited (custom) changes in their local repos, this stops the repo from updating
Each firmware release is tagged with a version number and description which is linked back to a specific commit so we can be totally sure of the version
Version number can be displayed in the update log
The github releases pages serves as a firmware release log
Fimware can easily be rolled back by specifing a version number of release
In the future I would like to move emonPi firmware deployment to github releases. It’s already used by emonTx, emonTH and emonupload tool:
@glyn.hudson, rather than have 2 buttons for 2 starting updates on 2 different hardware setups when it will only ever be installed on any one (ie no user will ever use both buttons) could you not use a test to determine the type of board attached (if any) ?
Something like this small test can easily determine the difference between a emonpi and a rfm2pi type board by the baud of the bootloader (rather than the firmware) and therefore it is more in tune with the hardware differences than the sketch.
#!/bin/bash
if avrdude -qq -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400 2&> /dev/null; then
echo "rfm2pi";
elif avrdude -qq -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 2&> /dev/null; then
echo "emonpi";
else
echo "none";
fi
Using this in front of an update command line for each hardware set-up would remove the need for 2 separate buttons and 2 separate scripts.
If there is 2 buttons available, they would be better serving as seperate “update software” and “update firmware” buttons so that users can apply calibration and/or mods to the firmware without fear of it being overwritten or having to fore go updates to retain any firmware changes they’ve made.
Yes, this could work. However, I’m currently happy with the functionality of having the two buttons. I don’t think it’s a big issue since if a user does happen to click the ‘wrong’ button no damage will be done since the firmware update will just fail.
Sorry, I don’t have any free time to work on this further at present.
Ok, I would of happily submitted a PR for consideration, I cannot see it taking more than few minutes to do.
Nor do I, the bigger issue in my opinion was that fact the emonpi cannot be properly calibrated, I guess there is at least now the “backdorr” option to recommend users deliberately use the wrong one, so the update fails in order to retain any firmware customization.
Yes but that too is a bit of a hash. both the voltage and current scales need to also be applied to the power scales and it doesn’t cater for phase errors which can be a greater source of variation, even when you are using the “approved” CT’s and VT.
Plus the key feature of the RFM69Pi is the extra GPIO breakout, this is pointless if alternative firmware cannot be used.
I’m not suggesting we cannot continue to use emonhub scales= for an easy fix but I see no reason to force users to update their firmware when they may want to retain changes, having that option takes nothing away, it just makes the system more flexible.
I won’t push this point any further, It was simply an offer to replace the two separate update scripts with a single script that worked for both hardwares, it doesn’t effect me directly as I don’t use the emonSD.
