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.
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!
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?
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.
