Update EmonPi Button or Update EmonBase Button?

Getting Started FAQ
1

[Started new topic - moved from EmonHub still dying?]

Okay. I’ve done the update 20 minutes ago. So far so good.

BTW… From the admin page, how is emonbase update different from emonpi update? (I have an emonbase, but I did the emonpi update because the prompting on the page seemed to suggest the emonpi update is less impactful. And also because people in the community always seem to mention “emonpi update” and not mention “emonhub update”.)

2

Excellent!

They differ only in command string used to upload the firmware to the attached RFM device ie the emonpi board or the rfm69pi. The serial baud and firmware paths/names are different.

Since the firmware is always re-uploaded on each run of the update regardless of whether the FW has been revised it is often recommended to use “the wrong one” if you have calibrated your emonpi sketch or running custom rfm2pi firmware so that the uploading of FW fails due to the wrong baud, keeping your sketches safe rather than overwriting then,

Likewise we also recommend using the “wrong one” if you are unsure what model RFM2Pi you have OR if are sure you have an rfm12 based RFM2Pi as the rfm69 based firmware will still load on a rfm12 based device but it will stop it dead in it’s tracks until you figure out why you are not getting data and manually reinstall the rfm12 version firmware.

Bit of an oxymoron but in many instances the correct button is the incorrect button (and vice versa).

If you have a totally stock emonPi sketch you are best using “update emonpi” to keep up to date

If you have an emonPi with a modified sketch you are best using “update emonbase” to avoid overwriting.

If you have an emonBase and you know your RFM2Pi or RFM69Pi is rfm69 based and has a totally stock sketch you are best using “update emonBase” to keep it updated

If you have an emonBase with a rfm69 based RFM2Pi or RFM69Pi running a modified sketch OR if you have a rfm12 based RFM2Pi OR you are unsure what RFM2Pi you have you should use “update emonpi” to avoid over-writing the firmware.

Aside from the firmware differences the re is no difference both buttons fully update the emonSD used in both the emonPi and emonBase’s, there is no emonHub update button, emonhub is updated along with emoncms and other softwares in that same emonSD update.

3 Likes
3

What a great answer about what button to use to do an update. A link to your posting should be placed right next to those buttons. :slight_smile:

4

Would you have looked in FAQ for that information? I was wondering whether to add it in there, and your opinion might sway me.

5

I would have looked briefly and probably not have reached the FAQ. (Ideally we really need the ability for ordinary folks to annotate web pages with additional info and links they’ve found relevant and helpful.) Hmmm…

6

I do not see that happening, I have previously suggested the buttons be changed to something like “Update emonSD (inc firmware upload)” and “Update emonSD (excl firmware upload)” and provided the code for the update routine to be able to determine whether an emonPi or RFM69Pi was attached so it could select the correct baud/firmware etc. IMO that with a little warning that the “(excl firmware upload)” option should not be used with rfm12 based RFM2Pi’s would suit all cases in safe and controlled way.

I think it’s a good idea to put it or something like it in the FAQ’s, even if Jason hadn’t found it, we could have just provided a link to it rather than typing it all out, I have posted this stuff before, but I have no idea where.

1 Like
7

I know you have, and I too don’t know where. It’s going to be in the FAQ before long.
[Edit]
It’s now in the FAQ - near the bottom, at the start of the MySQL stuff.

8

I would probably include a link back here for those that want to know more otherwise the next FAQ is going to “Why”

(Looks like Bill gets credit for your edit as he is the OP of the FAQ topic)

9

There you are.

(The FAQ always was a joint effort between us - it’s just that he had the most recent version of the old site’s FAQ when it got axed.)

10

I did originally edit the “quote” code to use your name but it retained Bill’s picture so that was a bit odd so I put it back as it was.

11

Found a local copy of a test script used for determining the attached device, it was intended to used as the basis for a auto-detecting test script back in May but lack of interest stalled further progress and testing.

I have posted it here as I found it in the /home/pi folder of my test emonpi which had I had time was going to have a freshly downloaded image installed to it last week, so I nearly lost it.

It uses the exit code of the avrdude command to know if the command was correctly formed (ie has the correct baud and programmer), that combined with the current operational baud determines the board type. It will interrupt the data for a few seconds, it will momentarily reset the add-on board and it may even be necessary to stop emonhub (I have not had to but theoretically we should, besides if used as part of the update routine, emonhub gets stopped any way). Unfortunately this will probably not work on systems that are being debugged following a stoppage after an update, it does require a working device to function (but that could be changed).

#!/bin/bash


BAUD=$(stty < /dev/ttyAMA0 | awk '/speed/ {print $2}')

if avrdude -qq -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 115200 2&> /dev/null; then {
        echo "emonPi";
        echo "Load the emonPi sketch"
        }
elif avrdude -qq -c arduino -p ATMEGA328P -P /dev/ttyAMA0 -b 38400 2&> /dev/null; then {
        echo "RFM2Pi";
        # If upload baud is 38400 & operational baud is 9600 it is an original RFM2Pi v2 with an rfm12b
        if [ $BAUD -eq 9600 ]; then {
                echo "RFM2Pi v2 (ATmega328p+rfm12b) @ $BAUD";
                echo "Load the RFM2Pi sketch with '#define RF69_COMPAT 0' and '#define SERIAL_BAUD 9600'"
                echo "Keep using the 9600 baud as an indicator of an rfm12b device"
                }
        # If upload baud is 38400 & operational baud is 57600 it is an RFM2Pi v2 with an early rfm69cw
        elif [ $BAUD -eq 57600 ]; then {
                echo "RFM2Pi v2 (ATmega328p+rfm69cw) @ $BAUD"
                echo "Load the RFM2Pi sketch with '#define RF69_COMPAT 1' and '#define SERIAL_BAUD 38400'"
                echo "Phasing out the rare 57600 baud devices, no different to the 38400 RFM2Pi's"
                }
        # If both the upload and operational baud are 38400 this is a late RFM2Pi v2 or a v3 (RFM69Pi)
        elif [ $BAUD -eq 38400 ]; then {
                echo "RFM2Pi v2 or RFM2Pi v3 (ATmega328p+rfm69cw) @ $BAUD";
                echo "Load the RFM2Pi sketch with '#define RF69_COMPAT 1' and '#define SERIAL_BAUD 38400'"
                }
        else {
                echo "Avrdude found Unknown device, Non-standard serial baud (bootloader uploads at 38400)"
                }
        fi
        }
elif avrdude -qq -c arduino -p t84 -P /dev/ttyAMA0 -b 19200 2&> /dev/null; then {
        echo "RFM2Pi v1 (ATtiny84+rfm12b) @ $BAUD"
        echo "Can these be updated? or better lft alone if working ok?"
        }
else
        echo "Device not detected, Check avrdude-rpi install is configured and working!";
fi

example output

pi@emonpi(ro):~$ ./emonbase_type.sh
emonPi
Load the emonPi sketch
pi@emonpi(ro):~$

It is dependent on avrdude and avrdude-rpi being installed and functional (it is included on the emonSD), it was tested on all the boards I had available at the time and I just tested it again now on an emonPi.

12

If I’m told “check the FAQ” often enough, I’d start my search there. Right now I tend to search the web site/community and become overwhelmed with somewhat relevant information and leave with a partial understanding.

13

I think you’re saying there’s too much data and not enough information. I sympathise. That’s roughly what the ‘Learn’ section is for, but it doesn’t cover the emonPi / emonHub.

14

That would be a really nice improvement, the two buttons are confusing quite a lot. Did you send a pull request? In my experience Glyn was always quite happy and thankful to merge code contributions which was encouraging.

1 Like
15

Discovered something today that I felt I should share or at least make note of somewhere.

It seems the update routines for the emonSD image are not the same when triggered from either the “Update emonPi” or “Update emonBase” buttons as we/I suspected…

Ideally they would be identical except for the firmware part and that was how it was originally afaicr.

This bit of code will select whether to update the RFM69Pi FW or the emonPi FW depending on whether the update flag from emoncms containd the text “rfm69pi” or not.

The rfm69piupdate,sh file is more or less as expected, it gets the latest FW from github, stops emonhub, uploads the FW to the RFM69Pi and then restarts emonhub.

However, the emonpiupdate file isn’t so straight forward. It seems to have a few “bonus bits” in it.

Firstly it upgrades paho-mqtt .

Then it goes on to stop emonhub, uploads FW to the emonPi add-on board and restrts emonHub…

And then it goes on to
“# Add bash prompt RW / RO emonPi file-system indicator”,
“# Move ~/.npm folder to RW folder ~/data/npm to allow npm packages to be installed when emonPi is in RO mode”
and “# Install / update nodeRED emonPixel & Emoncms nodes”

which means we have a double standard of emonSD images that differs depending on not only the HW the user is using but also on whether they want the FW updated. Of the 4 use cases, only 2 are getting the full package of updates and a simple difference of having an rfm12 or an rfm69 based emonBase could result in different bash prompts, mqtt functionality in Python, NPM functionality and possibly miss out on nodeRED with the emonPixel and emoncms nodes too.