Ahhh! I was tricked into thinking he was referring to a emonSD image due to the emonBase reference. Yes you do not get it by default except on emonSD installs.
But you can still enable $allow_ emonpi _admin = true; even on a hosted server, I have it enabled on a test server, all I need is to install service-runner and then make sure there is something to run at the target path /home/pi/emonpi/emonpiupdate (IIRC).
Then I would have the 2 buttons “update emonbase” and “update emonpi” even though this is a Debian9 VPS.
That is fine, It might be a possibility. But it adds another layer of config, perhaps as a one use “build time” config file maybe eg to specify local emoncms or not, attached HW and other settings used to create an image and then deleted could work.
I believe that the shop would NOT edit the file, it would be set to emonpi for all because it’s time consuming, they do not always know what it’s going to be used with, there needs to be a default “as downloaded” setting and the emonpi is the 1st focus whilst the emonbase could be either rfm,12 or rfm69 as explained above, if all emonpi/emonbase users used the (default?) emonpi setting no damage is done and no recent updates are missed.
You are definitely not a minority in that respect. I really do not like the FW being constantly overwritten for no good reason, it’s unlikely we will hit the 10k writes but it’s still undue risk and wear. If it was done in a more orderly fashon and checked the FW version and only updated IF there was a newer version, that would be different. BUT even then, I would expect there to be an override, that’s why I suggested the method I have, there is the option for no firmware updates.
Exactly, however, whatever your views the decision is in the hands of G&T and they want it the way it is, hence my suggestion to keep it close to the way it is by default. It is IMO the best we will achieve.
I do understand their opinion of just having one button to click to do it all for simplicity. There are (arguably) valid reasons this might not be entirely great. But I do not see that opinion changing any time soon, plus users that are capable of self-building an image or installing their own firmware are capable of changing a setting in emoncms.php.