Community
OpenEnergyMonitor

Community

RFM69Pi Update Via Emoncms (emonBase)

update
rfm69pi
emonsd
Tags: #<Tag:0x00007f1feab9e248> #<Tag:0x00007f1feab9daf0> #<Tag:0x00007f1feab9d668>

(Glyn Hudson) #1

I have added a way for RFM69Pi users to easily update firmware on the unit directly from Emoncms.

The Emoncms update is currently in the ‘master’ branch, it will be merged into stable once further user testing is complete.

Update: It’s been merged into Emoncms stable branch, see post below


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) #2

Has anyone been able to test this?

It’s working fine for me, I will be merging into Emocnms stable in the next few days.


(Glyn Hudson) #3

Update: merged into stable V2.8.0 Emoncms release, see change log:

Button has been renamed rfm69pi update > emonBase update


(Paul) #4

@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.


(Glyn Hudson) #5

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.


(Paul) #6

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.


(Glyn Hudson) #7

Yes good point, I can see the benefit of splitting out the update into ‘Firmware update’ and ‘Emoncms update’.

However, calibration can be more easily applied by changing the scale factor in emonhub.conf. This won’t be overwritten by an update.


(Paul) #8

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.


(Glyn Hudson) #9

I agree, it’s good to have the option.