A quick mockup of what this could look like:
1 Like
3 thoughts,
- With the new sidebar, should we split out some of this into separate pages like an update page. Update, IMHO, is not the most important thing on admin page - health is - so I do not think it should be top and centre (and I understand this is a mock up).
- Iād like to split EmonCMS and EmonHub. They can be separate installations. The usefulscripts āemoncms_updateā script works well.
- What about underlying āSDā things (like logrotate, services not necessarily part of EmonCMS like Mosquitto)? Including that in the āupdate allā risk breaking systems that are not std EmonPi installations.
I think perhaps there needs to be a āyour system appears to be a standard [EmonBase, EmonPi] so it is suggested you update hereā [button]. To a non-technical user, the āUpdate Allā is a little scary!
Actually I had the emonpi and the move to CM in mind when I wrote that.
Yes I agree splitting of the admin page could make sense.
Seperate update of emoncms and emonhub also.
Yes I was also thinking about that. The UpdateAll would need to be selective, we need to think about that, what gets included and what does not. Do we agree that debian is a minimum requirement for all update options?
Ok fair point, the initial target for EmonLibCM is the EmonTx, I think we are still someway from EmonPi support. In the event that we do get it to work, yes that could be neat! perhaps the relevant firmware update script could edit emonhub.conf, add or amend the relevant entryā¦
Makes me think about individual module install and update optionsā¦ perhaps a future direction
Oh close that can of worms. I think for now, if someone has installed non-core modules manually, then the update will update them on the current branch and leave it at that. You could start to get into branches etc so I think avoid!
1 Like
Yes I did think that once mentioning it. It doesnt really add any benefit over the automated update and introduces problems that may arise from updating a module but not core.
Iāve added a brief readme to give an overview of how to run the current state of the update scripts in the update_refactor branch: https://github.com/openenergymonitor/emonpi/tree/update_refactor/update They run well from both the emoncms interface and manually via command line
- What should the user be able to do via the update UI?
- Location of configuration for firmware type?
Going back to these points, I think my preference for saving the firmware type is as a user preference in the mysql database. Alongside this there could be an attempt to detect the emonpi hardware by looking for the LCD, it would then give a first suggestion as to the relevant hardware, but allow the user to change the selection if its not right (e.g rfm12pi or custom). If the user does upload incorrect firmware, the dropdown selection for firmware type allows for then updating the correct version, which is a step forward from today. What do you both think of this approach?
I was thinking along those lines too. So the script/page lists all the available options for a particular item, and adds āBased on [past preference | hardware detected] you should probably choose [the sensible default].ā and make that the default choice.
1 Like
If the EmonPi is regarded more as a āfire & forgetā system, I still think having something in the boot partition that can be read and used to fix the type could be a better first step, if not found then determine type by other means.
Thanks @borpin While I think that would be a good, the main issue I see is that we produce one image that is used for both emonpi and emonbase systems that leave our shop. We could use the LCD detection method at first boot update to create such a file automatically but then is that any better than detection later?
1 Like
Not wishing to hammer the point home too much, hereās the problem rearing its head again: Compile calibration changes - #2 by Robert.Wall
1 Like
In the short term, if we have an entry called ācustom - do not overwriteā in the dropdown menu, the āUpdateAllā button could then skip the upload step.
In the longer term the emonhub based calibration approach using your unitless code @Robert.Wall will be the best solution for this.
I donāt have an emonPi so I canāt really test much of this, but going over the calibration process in my head, it feels like it should be possible to create an interface in the emonCMS admin page that lets you change the various ācalibrationā portions of the sketch, then compiles and uploads that to the ATMega add-on board.
The current calibration method for the emonTX requires the calibrating user to edit a handful of places in the code based on their own measurements, recompile and repeat. If those could be sedād into the .ino file by a script, it should be possible to fully calibrate the front-end firmware all from the web interface.
Obviously that still doesnāt fix the āIāve written my own custom firmwareā situationā¦ but for those users, they already know how to upload their own firmware using avrdude, pio or whatever.
Orā¦ have I seriously under-thought this?
I guess I could test the theory just with an Arduino hooked up to the appropriate Pi GPIO pins?
If I spent some time making something like this work, would there be any interest in it?
The problem with the emonTx is, it doesnāt have OTA input of any sort back from the base - it is transmit only. It doesnāt have to be that way, but there are a lot of factors to consider if we do move in that direction. I do know Paul B has it on his long-range radar, but whether it will ever come to fruition is another story.
In terms of the emonPi front end, itās a whole lot easier because the serial interconnection already exists, and when I get the chance, Iām actually working on combining on-line (via emonhub.conf) calibration and continuous monitoring for the front end.
The real problem for the user who wants to accurately calibrate his emonPi is the sketchās editing and uploading is a fiendishly difficult procedure - I canāt find the full instructions any more, so a new user has no chance, and when theyāve done it, it will always be overwritten unless they choose the wrong update method.
2 Likes
I think your unitless approach is the way to proceed here . It makes calibration much easier as its all in the emoncms interface and doesnāt require compilation and upload of code.
1 Like
I still donāt understand what that is? Are we still talking about updating the nodes section of emonhub.conf with scale factors, or something entirely different?
Re-reading my post, I can see how it was confusingā¦
To clarify, I was only ever suggesting fixing the calibration for the emonPi (as the emonTX is never in danger of being overwritten by hitting an update button). I merely used the emonTX calibration process as an example that I was aware ofā¦