Community
OpenEnergyMonitor

OpenEnergyMonitor Community

emonSD next steps

We’ve got a real risk here of getting bogged down in a hard to follow discussion, are we trying to tackle too many things at the same time? What is the first item to tackle?

  1. What should the user be able to do via the update UI?
  2. Location of configuration for firmware type?
1 Like

A quick mockup of what this could look like:

1 Like

3 thoughts,

  1. 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).
  2. I’d like to split EmonCMS and EmonHub. They can be separate installations. The usefulscripts ‘emoncms_update’ script works well.
  3. 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.

Thanks @borpin @pb66

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…

A split out emonhub:

2 Likes

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?