The only way to detect would be to test the different baud rates.
However, updating the RFM69Pi firmware is unlikely to be needed, there has been any changes to the RFM60Pi firmware since 2016: Release V1.3.0 · openenergymonitor/RFM2Pi · GitHub. Therefore, as an emonBase user is doesn’t really matter if you run emonPi update instead of emonBase update since there is no new FW updates.
I agree, it would be good to make the microcontroller FW update a separate process from the emoncms update
I’m all for this. It would also reduce the risk of hitting the “wrong” update button if you had a custom sketch loaded (as @Robert.Wall posted above).
I agree. It’s the principal reason why I advise people against trying to calibrate/customise the front end, because it’s far too easy to lose it and have to repeat the work.
I’ve never understood why the front-end sketch has to be reloaded each time emoncms is updated - surely it should be an option, normally defaulting to ‘no’ and defaulting to ‘yes’ only when there’s an update to the front end sketch.
I think the key thing here is the fact I put a wpa_supplicant.conf file in the boot partition before installing to the Pi.
You may well be testing with an Ethernet cable or WiFi APmage to set up wifi since the Rasbian method I used was not possible on previous emonSD images due to the RO FS.
I believe (but have not confirmed or tested further) that the wifi network might not have auto-configured early enough for the firstboot to run properly. If this is the case, then whilst I understand why it might be this way due to the previous images being RO, moving forward, the emonSD should really support this route to setting up wifi. It is by far the easiest method.
Hopefully, if the firstboot script becomes a systemd unit to get rid of rc.local, we will have more control over what happens when. the “firstboot” service can be triggered after there is a network connection, regardless of how it comes about.
That is significantly different to mine. I would have expected the first time the updater runs (regardless of being at first boot or second) to be exactly the same if the image and update script versions are the same (aside from the lcd and rfm2pi/emonpi fw which could be different for very obvious reasons).
I did cite 2 errors in the text you quoted, emonhub is reported as not running in emoncms despite “it tells me emonhub has been restarted, more than once” and at the end of the script it tells me the “service runner process cannot be found, and yet it has been started” and yet in emoncms it shows as running. Isuspect the latter is just a hangover from the recent changes to the service-runner perhaps. It is running so it is NOT the problem the log reports. But emonhub has failed to be restarted for some reason (or crashed out very soon after the update).
Then there is the 2 minor errors about rpi-rw at the start and rpi-ro towards the end, as you say nothing to worry about and easily fixed.
I am also not concerned about the fw not updating, I have no rfm2pi or emonpi board on the bare RPi at this point. That was expected, as was the lcd warning.
But if you look closer there are these errors
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
fatal: unable to access 'https://github.com/openenergymonitor/emonpi.git/': gnutls_handshake() failed: Error in the pull function.
and
The following additional packages will be installed:
python-colorzero
Suggested packages:
python-gpiozero-docs
The following NEW packages will be installed:
python-colorzero
The following packages will be upgraded:
python-gpiozero python-rpi.gpio
2 upgraded, 1 newly installed, 0 to remove and 103 not upgraded.
Need to get 133 kB of archives.
After this operation, 261 kB of additional disk space will be used.
Do you want to continue? [Y/n] Abort.
In both cases there was obviously a working network connection, both seem odd, but the point here is that this is automated, I didn’t do anything to interfere with these operations and the network was up at this time. I have just checked and the apt-get installs (https://github.com/openenergymonitor/emonpi/blob/master/emonpiupdate#L18-L19) were not done, but succeeded first time when I just manually tried it.
And the emonpi repo wasn’t up to date either.
pi@emonpi:~/emonpi $ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
pi@emonpi:~/emonpi $ git describe
emonSD-22Dec2015-709-g4c1d84f
pi@emonpi:~/emonpi $ git pull
remote: Enumerating objects: 139, done.
remote: Counting objects: 100% (139/139), done.
remote: Compressing objects: 100% (23/23), done.
remote: Total 210 (delta 124), reused 121 (delta 116), pack-reused 71
Receiving objects: 100% (210/210), 58.16 KiB | 0 bytes/s, done.
Resolving deltas: 100% (135/135), completed with 24 local objects.
From https://github.com/openenergymonitor/emonpi
4c1d84f..56ce5b2 master -> origin/master
18b8859..003ad11 cydynni -> origin/cydynni
* [new branch] feature/update-tmpfiles -> origin/feature/update-tmpfiles
* [new branch] remove-reset-hack -> origin/remove-reset-hack
* [new branch] service_correction -> origin/service_correction
* [new tag] 2.9.1 -> 2.9.1
Updating 4c1d84f..56ce5b2
Fast-forward
emoncmsupdate | 565 +++++++++++++++++++++++++++----------------
emonhub-sudoers | 2 +-
emonhubupdate | 53 +++-
emonpiupdate | 7 +-
firmware/platformio.ini | 1 +
firmware/src/src.ino | 2 +
firmware/src/temperature.ino | 77 ++++--
lcd/emonPiLCD.cfg | 36 +++
lcd/emonPiLCD.py | 518 +++++++++++++++++++++++----------------
rc.local_jessieminimal | 2 +
service-runner-update.sh | 12 +-
stretch/motd | 2 +-
stretch/rc.local | 3 +-
13 files changed, 832 insertions(+), 448 deletions(-)
create mode 100644 lcd/emonPiLCD.cfg
pi@emonpi:~/emonpi $
If the emonpi repo is not successfully updated, there really in’t much point in continuing the update process as you end up in between versions or crossed version might be a better term. A warning and abort would be better at that point if not successful.
The fact it was updating from an old version of the emonpi repo is why the update is significantly different to Trystans example.
What ever the reasons behind the fail, maybe it was network, maybe this will be better managed in systemd, either way, I am just reporting what happened when I simply booted to a new image, I had not interfered with anything other than pre-adding the wifi details as explained above.
I have just booted this up again to check a couple of things (it was powered down after posting the other night) and when I navigate to the IP of the RPi I got the setup screen again
this time there is a “24” in the top left of the screen. I have to click “log in” to get the log in box.
The wpa_supplican.conf file is present and the content is as I left it on the boot partition.
pi@emonpi:~/emonpi $ ls -la /etc/wpa_supplicant
total 52
drwxr-xr-x 2 root root 4096 Oct 30 16:59 .
drwxr-xr-x 97 root root 4096 Mar 17 19:10 ..
-rwxr-xr-x 1 root root 937 Oct 14 2017 action_wpa.sh
-rwxr-xr-x 1 root root 25619 Oct 14 2017 functions.sh
-rwxr-xr-x 1 root root 4696 Oct 14 2017 ifupdown.sh
-rw------- 1 root root 556 Aug 8 2018 wpa_supplicant.conf
pi@emonpi:~/emonpi $
Whilst I don’t necessarily think you are wrong, I do not think that is the issue here. Or at least not the one I was referring too. I expected the FW update to crash out ungracefully, but as others have posted here, this is actually the “officially supported method” to avoid overwriting custom FW or temporarily bricking a rfm12 based rfm2pi.
In which case why don’t we just do away with the update emonbase button to reduce the chance of screwing up an rfm12 based rfm2pi?
Since Trystan is keen to bring the methods of updating for emonsd and non-emonsd systems closer. Why do we not just change the button to “update” and in the settings.php we have a “update path” setting that is “/home/pi/emonpi/update_emonpi” by default in the emonpi.default.settings.php (and even in process_settings.php if we must) .
then users can edit that line to $update_path = /home/pi/emonpi/update_rfm69pi or $update_path = /home/pi/emonpi/update_rfm12pi if they have an emonbase, (if they click update before changing it will fail to update due to emonpi defaults and not brick thier rfm12pi) OR the rest of us can edit it to something like $update_path = /home/randomuser/myownrepo/update_just_emoncms or some official offering perhaps?
This is safer, simpler, more flexible and broadens the use of the update button to non-emonsd installs.
[edit]
eg when the emonSTM comes out, just drop a update_emonSTM file into the emonPi repo (maybe it’s time the emonpi FW was seperated from the emonSD stuff!)
Also just fior some insight as to how these multiple scripts might work, I imagine something like
#!/bib/bash
source emonsd_update.sh
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
where emonsd_update.sh is a universal update script called from each of the various individual update scripts that can be called from emoncms.
This also accommodates optional FW installs to the emonpi for legacy or CM when it lands. eg $update_path = /home/pi/emonpi/update_emonpiCM or $update_path = /home/pi/emonpi/update_emonpiBETA etc etc
Interesting, it seemed the git pull on emonPi failed because of a gnutls_handshake() error. I’ve not seen this before. Searching the web for possible answers indicates this could be a network issue or some sort of firewall or proxy. Whenever emonSD runs the first update in the factory we have never had this error before, I will see if I can find any more info on this error.
The first boot updates checks for an Internet connection (by pinging google) before starting the update. Firstboot update will not run until an Internet connection is detected, this may not be the first boot if not connection was present initially
As I’ve explained, the firstboot did NOT run at the initial “first” boot, It would seem that the firstboot attempts too run too soon, ie before the wifi settings had been digested and setup by another process. Thus there may not have been network at the first firstboot.
However, once I realised it hadn’t run I rebooted the RPi, so on the second “firstboot” the network was all set up from the previous boot. But that doesn’t explain the errors that were then encountered after the script started since there must have been a network connection for it to commence.
I think much of this becomes irrelevant IF there is a plan to move the first boot to a systemd unit out of rc.local. But I do still believe that under any circumstance, errors should perhaps be expected and handled.
Why not just move updating the emonhub to the emonhub admin page?
You could say the same for all components… Then you’d need to go to each page and hit the appropriate update button. Sounds like a big step backwards to me 
For the general user, there needs to be one single update button that updates all of the emonCMS components. It makes absolute sense though for those individual update scripts to be specific to their component and then get wrapped into a “full upgrade” script - whatever that turns out to look like - that sits behind the (big shiny red) button to trigger the upgrade.
Well no. If you have a separate page for EmonHub management it makes sense to have an update for that.
There is an argument that says that emonhub is not an emoncms component they are both OEM components - and therein lies the issue.
There is no such thing as a ‘general user’ there are users of Emoncms (standalone), emonbase (RFM) and EmonPi plus some bits in between. What you do want is something that does not have surprises in it when you update!
You could have both!
We do need a central configurable “update button” so the user can update the whole caboodle from one point, but if we are going to divide the update up into smaller chunks so that the common/custom update script can call only the parts required, then there is no reason why there couldn’t be a update emonhub only button on the emonhub config page, I’m not sure it has much value as the current system stands since it would only be accessible via emoncms, so arguably, you may as well just use the full update.
However! It was my original intention that the emonhub module for emoncms would infact cater for multiple emonhubs, most arrangements will involve just one emoncms, perhaps with emoncms.org as a backup, but there could be maultiple emonPi’s/emonBases’s/emonhub’s running on other Pi’s etc. To be able to remotely update each emonhub from the one multi-hub config page would be useful, although I still thing the local emonhub (to the emoncms server) would probably still get updated with emoncms rather than on it’s own, but if the button is configurable, it’s the choice of the user and yet transparent to the “use as is” emonPi/SD users if the default settings are set correctly.
There’s a separate page for the Graph module, the Dashboards Module, the Sync Module, Visualisation Module, etc…I don’t configure any of those from the page that I currently hit the “Update” button on either.
I fail to see the distinction. I don’t have any use for any of those Modules I’ve just mentioned above, why would anyone suggest they are considered more part of emonCMS than emonHub is?
+++ This.
Having individual scripts that update each component (I’ll leave the argument about what constitutes a “component” for another discussion!), that can be run sequentially as appropriate to the particular installation, triggered from a single “Update” button on the Admin interface, would be the ideal solution.
Because it is reliant on a specific piece of hardware. It is not an EmonCMS ‘Module’.
Those running old hardware - the update assumes the latest RFM card. That is dangerous if it can effectively brick the RFM hardware. As it stands, to update emoncms from the admin page (actually as a standalone, self install user there is no update option) on a EmonBase, I am forced to update the RFM firmware which is daft.
So my analogy here is Home Assistant. I can update the HA system from the main page. I can update my Sonoff based items from a separate page but I am not forced to update them.
I really think separating the update of the PHP/OS part should be separate from the Firmware (perhaps excepting the EmonPi).
No it isn’t… I can use emonHub with a socket Interfacer and have no additional hardware. The fact that it isn’t a ‘Module’ is simply semantics.
Absolutely no argument there and I think I’d already suggested that the firmware upgrade needs to either properly detect the hardware so that it is upgraded only when required or appropriate… OR it gets completely decoupled from the rest of the “software” updates.
Absolutely - as has already been suggested elsewhere.
I think we’re disagreeing here because you are assuming that emonHub updates are tied to firmware updates of a piece of add-on hardware?
Not so much assuming as making a fundamental error in that there are 2 parts to this; the emonhub script and the RFM firmware.
I can see the logic of tying the two together for many users, but in hindsight the problems it has caused for those who have anything but the ‘off-the-shelf’ system has meant it was the wrong choice. It should always have been optional follow-on procedure.