Hi.
We've been trying to use the feed API and we're having issues.
Apparently, the documentation is not complete, and we didn't know, when creating a feed, how to pass the parameters (engine, datatype, etc.), so we've been proceeding by trial/error.
Is there any other source of documentation regarding this?
We've been looking in the code as well.
We first tried to pass strings such as "PHPFIWA" but it seems parameters should be passed as integers and we found a file in the code where the corresponding enums are declared.
While playing with the feed create function, we must have introduced broken data that the code should have refused, because now we can't even list the feeds.
Here's a few of the URL we used along with the answers:
http://emoncms.org/feed/create.json?name=test7&tag=1&datatype=2&engine=1 Notice: Undefined offset: 1 in /var/www/emoncms/Modules/feed/feed_model.php on line 113 Fatal error: Call to a member function create() on a non-object in /var/www/emoncms/Modules/feed/feed_model.php on line 113 http://emoncms.org/feed/list.json Notice: Undefined index: 1 in /var/www/emoncms/Modules/feed/feed_model.php on line 297 Fatal error: Call to a member function lastvalue() on a non-object in /var/www/emoncms/Modules/feed/feed_model.php on line 297 http://emoncms.org/feed/delete.json?id=91352 Notice: Undefined index: 1 in /var/www/emoncms/Modules/feed/feed_model.php on line 465 Fatal error: Call to a member function delete() on a non-object in /var/www/emoncms/Modules/feed/feed_model.php on line 465
I think both feeds 91352 and 91353 are concerned.
It looks like we managed to create a feed with an invalid field and when EmonCMS tries to get to the last value to display on the listing page, it calls lastvalue() on an object which is not an engine as expected. More or less the same with the delete() function.
I guess at least wrong entries should be detected and creation process exited with an explicit error.
If this is a bug, and you want to investigate, you may look in the database, as this is on the emoncms.org instance. You may also find all error messages in your webserver logs.
The instance advertise itself as 8.3.5 but surprisingly, the error messages point to lines in the code of that version that don't seem to be related to the message. Any reason for this? For instance, there is no lastvalue() call on line 297.
Should I open an issue on GitHub about this?
Is the feed API used and supported or is this a corner case (most people use input API) that may have other issues?
Is it supposed to cover all functionalities accessible through the GUI? Or is it WIP?
We want to display values about a building (temperatures, power consumption, etc.) that we get through csv files. We generate requests from the csv files. We will process all old csv files then catch up with the building and feed csv files as they come. Since there is no need for processing, it seems logical to use the feed API rather than using inputs and "log to feed". And since there may be a lot of feeds, using the API to create the fields would be a life-saver.
I've been away from OpenEnergyMonitor for a while, so please excuse me if I'm missing the obvious. I'd be happy if we could use EmonCMS in our project. And even more if it was improved in the process.
Edit - wrapped long lines - BT
Re: EmonCMS feed API?
Hello Jerome, thanks for finding and investigating this.
The feed creation method really needs improving as its currently allowing the registering of a feed for an engine that is not actually installed anymore on emoncms.org (engine 1 = timestore) That is then creating the other error's down the line.
The quick fix which I have now added to stop this from happening on emoncms.org is:
$engine = (int) $engine; if ($engine==1) return array('success'=>false, 'message'=>'timestore feed engine is not available'); if ($engine==3) return array('success'=>false, 'message'=>'graphite feed engine is not available'); if ($engine==4) return array('success'=>false, 'message'=>'phptimestore feed engine is not available');but it really needs a better long term solution. The emoncms.org code base is now quite a bit behind version 9.0 which Id recommend looking at if your installing your own server, see Chaveiro's great work here http://openenergymonitor.org/emon/node/11009.
Yes the line numbers on the errors on emoncms.org may not match the github code as I removed all the checks to provide a non redis mysql fall back mode on emoncms.org, the code has become a bit of a mix between the low-write branch of emoncms and v8.5, I need to review it again and work out to what degree it can be moved to the new v9 release too.
Re: EmonCMS feed API?
Hi Trystan.
Thank your for your answer.
We might install EmonCMS on our server. In this case, I suppose we'll go for a recent code version so that we can benefit from all latest features and perhaps contribute if possible.
My colleague started with the emoncms.org instance as a test to check EmonCMS was a correct fit for the project's needs. He is currently stuck because the feed list does not load due to feeds 91352 and 91353 being broken. I'm afraid there's nothing we can't do about it without DB access. Would it be possible for your to delete them manually from the DB? Or should he create a new account?
Is the feed API any safer in v9.0? Would you recommend its use (I mean the use of the API, not of v9.0)? Maybe if we validate the use of EmonCMS for the project we can justify spending a bit of time securing and documenting the feed API.
I guess the doc should include a comprehensive list of parameters (tag, engine, datatype, etc.) and the possible values or enum description for each of them. Or better, the API could accept strings instead of integers (like 'PHPFIWA' instead of whatever the number is).