And when would that be shown? On just all RPi based servers? regardless of whether it has attached hardware or not? Or permanently on all servers, even hosted?
What about when there are multiple hardware devices attached eg 3 emonTx’s for a 3ph setup?
So a list needs to be maintained and users are restricted to just those options?
Possibly not, if that’s the route you take, but instead of forcing all users to update their FW everytime you are now taking that option away from them and forcing a 2 step process even when they might be running a stock emonpi with stock FW etc etc. The U-turn might be an improvement on the existing process, but it still isn’t the best option. Let the users decide what they want!
Yes, update_emoncms would fully update emoncms and all it’s modules, it’s the choice of server only setups, if emoncms.org was “stock” it’s the choice you would use there when there is no FW, low-write or emonhub etc to consider.
update_emonsd would call update_emoncms! Plus update_emonHub and also update low-write stuff and the core Raspbian packages too.
Nooooooooooooooooooooooooooo! not another config file please. Some objection to my proposal is based on having to edit a single line in settings.php, another config file is a step too far I think. I’m not against a “recipe config” for the building of a image, but once it’s built and settings.php has had it’s “update_command” set there is no need for another config file.
I’m not trying to muddy the waters here. I would indeed prefer not to have the FW overwritten at every update and I think that users that want to seperate the FW updates from the server updates should have that option (as should those that want to do it all in one hit).
But, are we going to insist that users use both buttons together?
When FW is updated with new payloads, will emonhub.conf get updated at the same time?
Will the FW repos get updated as part of the FW update or the SW stack update? What about the emonpi FW will that be broken out to a new repo? Will the emonPiLCD
code get updated as part of the emonpi (FW?) updates or as part of the emonpi software stack updates? So will there be 2 emonpi repos or will the same repo be updated twice if users click both buttons?
What if they do them in the wrong order?
Pre-U-turn this option was the best route (IMO) and if implemented, different update strategies could have been easily tested by just adding a update_??? file and editing settings.php, in fact doing the u-turn would just involve changing the update command and (and adding a button to finish the (FW) update?), so future changes in stratagy could also be just a change of target file as would custom routines, eg my 3x USB emonTx based 3ph monitors, I could just write my own script to use all the existing bits, plus update each emonTx (if required, I have version based selection) and use the same button as everyone else, from what you propose, I doubt the USB emonTx option will be hardcoded into emoncms and there won’t be 3 additional update FW buttons.
I get that it’s an edge case, but many users are operating thier own edge cases, that’s why we need a fully configurable “open” option. Whatever you decide the default should be today, tomorrow or in years to come, it should be easy to break away from the default, we should not try to limit imagination and/or progress by trying to guess what everyone wants or worse, by telling them what they should have without option. What do we have against flexibility?