I’m sorry too hear you are not going to be using emoncms, but I do appreciate you taking the time to explain why and although I am not a core emoncms developer I would like to respond to the points you raised, hopefully to help future users even if it is too late to tempt you back. It would be of great benefit to the project to have users with your experience on board.
-
Silent failures, agreed this is not a good situation, many softwares including previous versions of our own emonhub have relied on this response for confirmation of a successful post before deleting the local copy. It is an error and should be labelled as a bug. it now has “bug” status.
-
EmonCMS.org differences: Whilst it isn’t clear to many users there are significant differences between the emoncms repo and the code run on emoncms.org. There is a separate repo for emoncmsorg if you are interested in the code, but at the very least the user level differences should be documented or preferably, not exist. This is not a development verses stable version issue, there are very different stratagies applied and these need to be highlighted.
-
Named-key inputs: The issue here is that the “inputname” or the “inputindex” share the same “key” field so you cannot use both, when using CSV bulk input api the “key” is explicitly set to the input’s index number as an “inputname”, the input pages list “key” and “name” fields, behind the scenes they are actually “name” and " description" fields. I have regularly asked for an additional field so that both “inputindex” and “inputname” can be used simultaneously
-
API input names: Although poorly documented, this is actually possible using the input/set api see below. Also take a look at the emoncms device module, I use this a lot for bulk creation of inputs, processlists and feeds. Possibly not in the way it was designed but it works well for the purpose.
Set input fields http://localhost/emoncms/input/set.json?inputid=0&fields={'description':'Input Description'}
-
API create feeds: I agree. The API’s need an overhaul to be more user friendly or at the very least documented. There are many things that can be done via the api’s that are too complicated or simply not known.
-
Null datapoints: Although I haven’t tested lately, it is/was possible to pass null values to a local emoncms install. This is a feature I did contribute to emoncms some time ago, See the “Can you ‘load’ nulls in BULK json upload format to emoncms.org?” thread for some info.
-
Re-uploading history: Not entirely sure I have the right end of the stick here but… If you are trying to bulk upload back-data to phpfina or phptimeseries, the trick is to create the feed whilst there is no incoming data (or to use the feeds api) to create an un initialised feed. A feed is initialised upon recieving it’s first adta and the timestamp of that first data becomes the “start date” of the feed, once created you cannot post data earlier that the “start date” so making the first datapoint the earliest ever is essential to back-fill historic data.
If I can tempt you to retry emoncms I would happily try and answer any questions you have as I have a fairly good working knowledge of it. The position I (we) and future “power users” have is that it is currently complex, incomplete and undocumented, and because of that, many move on or just accepts its shortfalls. the result is nothing gets improved as there isn’t the demand for the more indepth stuff.
In actual fact it, is in the name of “simplification” that emoncms.org runs very different code to the emoncms repo and that the documentation is moving towards a “quick user guide”, so it good to know there is also a demand for in-depth documentation and advanced features too.