The Import facility is not working as I expect it to do. I’m exporting and importing using the same version of the software (9.5). I expect the export to copy the emonhub.conf file and the when I import to bring in the same content. This is not happening as the import always seems to overwrite the emonhub.conf file with the default (factory) version regardless.
I have modified my emonhub file on my original system so that the nodes and inputs etc. have names that suit the nodes themselves and I have also added a node 11 and included an api key for writing to emoncms.org server. Whilst this information is definitely being exported (I can view, for example, the emonhub.conf contents from the archive, and it looks correct), it is not being imported.
The emonhub file seems always to revert to the default emonhub.conf. The upshot is all the node, input and apikey information I had on the original system is lost, until I manually re-enter the data. The changes I had made, in case this is useful, are to modify node 10’s content names etc. and adding a node 11 and adding an apikey.
Thanks, Paul. The upshot of the import method as outlined is that the feed and input data end up out of sync as the system seems to see the defaulted-to inputs by (identified by their old names) as still existing, even when the conf file is updated/corrected. This means that the system stops seeing any input on the defaulted to names once the .conf file is corrected: If I change two of the input names, then I end up with four inputs, two of which are not functioning, but are still there. I’ve not been able to determine if the database still maintains data from the default names or not.
May I respectfully suggest that the import script give the option of restoring the default configuration or using the modified one, with a suitable warning as to the potential conflicts if the modified version is used? That way when transferring data between systems based on the same version (as is the case, in my situation) or versions where this is not an issue, the import is smoother and avoids the issues I describe above.
Another possibility, when doing an import is that the system data collection be put on hold until the administrator is happy that all files etc. have been set up correctly and indicates as much to the system?
I think that is quite a good idea. Or a test mode that does not write any data? Or possibly a question asked during import in the form of ‘Do you wish to restore emonhub.conf’ with a suitable warning that the answer is usually no.
I agree the current method isn’t ideal.
emonhub needs a conf file to start so just omitting the conf would force the user to review the situation as emonhub would fail to run, but that wouldn’t be entirely self-evident and would rely on documentation for the user to be aware.
However, it would be better to have no data passed than incorrect data contaminating your existing data, after all if it wasn’t valuable you wouldn’t be using the import/export module in the first place. Plus a missing conf is much easier to spot than an incorrect one.
Although it may not apply to the emonpi variant now, the original emonhub had “pause” functions inbuilt. any interfacer or reporter could have it’s own input or output (or both) paused by emonhub.conf settings.