@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.
if avrdude -qq -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400 2&> /dev/null; then
elif avrdude -qq -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 2&> /dev/null; then
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.