Archived Forum

While I can't offer any explanation for the 1st issue, I have to put my hand up to the 2nd. There was an issue in a pull request that got merged, a correction has been submitted and will hopefully be merged asap.

​The details are here if you want to manually edit the file in the meantime.

Paul

Paul,

Thanks for the parse error fix, worked like a champ!

Bill

Hi Thanks for fixing the 2nd issue. Surely somebody on here has to know where the inputs are stored. I don't think they are in mysql anymore because I looked in phpmyadmin. Is there a file on ubuntu somewhere I need to delete to clear out all the inputs in emoncms?

Try looking at this page, near the bottom: https://github.com/emoncms/emoncms/blob/master/docs/Backup.md

All of those folders are empty. I have even cleared my browser cache. Where else could the inputs be stored?

Why are my posts needing to be approved before they show up? I've been a member for over a year?

I am going to be as simple as possible for my issue. How can I delete all the garbage inputs without clicking the trash bin on each one?

Go to this link to see what i am talking about, user is bbroge, pass is winter.

http://24.181.167.25/emoncms/

I've never had such a ridiculous issue with this software. I've dropped the mysql database, removed and reinstalled the emoncms web folder, and deleted the following folders which are empty anyway.

/var/lib/phpfiwa

/var/lib/phpfina

/var/lib/phptimeseries
 

First problem is solved - I've changed your status. I don't know what the algorithm is for determining whether posts are held for moderation or not (but some of the spammers seem to know!), so I can't help you there.

Do you have directories with those names elsewhere - the data has to be stored somewhere. I'm no expert on emoncms so sorry, but I can't be of much help.

Thanks for fixing that. Bill noticed that when he logs in he can delete the inputs individually but then they pop right back up. I have reinstalled emoncms several times since this issue and everytime the api key changes and I don't have my brultech pushing data to this anymore, so I'm out of ideas. I have two nodes on my server now. Is there a way to delete everything for a specific node, "Node NoGroup"

I think there is a file or database I'm not deleting where this input data is stored when I have been reinstalling. I've used the instructions for re-installing the github version of emoncms.

If you have redis installed it's quite common for some old (thought to be rid of) data to pop back up unless you run

sudo redis-cli FLUSHALL

​I believe the inputs details (but not the data) are still kept in the sql tables.

To get more info on deleting the inputs you could take a look at the code to see what actually happens when click the trash can, while you are there have a look at the function directly below it  I cannot vouch for it as I've never used it but it looks like a "redundant input" removal tool, triggered using "clean" in an api url .

I assume something like http://localhost/emoncms/input/clean.json will trigger the action (USE AT YOUR OWN DISCRETION - no warranty expressed or implied)

Paul

Thanks for the tips, I'll give it a try. On another note I think I know why this happened:

I think 8.4.0 may have a bug... If I enter in the below two lines in my browser it doesn't update the existing. It will create two completely new entries or inputs. This isn't supposed to happen right? It is supposed to update the existing and that is why I got so many duplicates in the beginning.

http://emoncms.org/input/post.json?json={power:200}
http://emoncms.org/input/post.json?json={power:201}

I will work on downgrading my server version to verify this works but on my emoncms.org account it works as it is supposed to and doesn't create thousands of duplicates.

I can confirm, I got the same problem after I upgrade to 8.4.0 /Stema

I found my problem, my fault! I forgot to specify which node (node0) to be updated! It worked in previous versions, not anymore .. /Stema

Hi - can you shed any more light on this please - I am also facing the same problem following an upgrade from 8.1.1, in that I cannot update emoncms 8.4.0 by specifying the key name - instead, for each submission, the command is creating a new entry in the NoGroup node.

Here is the command I am using (and which was working fine with 8.1.1):

http://192.168.0.30/emoncms/input/post.json?json={boiler:1}&apikey=xxxxxxxxxxxx

I have also tried:

http://192.168.0.30/emoncms/input/post.json?node=0&json={boiler:1}&apikey=xxxxxxxxxxxx

but this does not make any difference.

The problem appears to be that in the current version, a node id is required (whereas this was not required in the previous version, and is not specified in the current API help page) and a node id of 0 is not accepted.

If I try:

http://192.168.0.30/emoncms/input/post.json?node=1&json={boiler:1}&apikey=xxxxxxxxxxxx

then this works as expected.

Is there a fix that I can apply that will revert to the previous behaviour please? (I don't want to create a new node because I will then lose my historical data - and because I am currently posting to both my local emoncms and the emoncms.org site).

Hi Engeeaitch, Your data is stored in the feeds not the inputs, so it should be relatively easy to switch to using a node id. I'm happy to help If you want to switch and need some assistance.

I think this "change" may of occurred when some changes were made to accommodate mqtt topics, but I can't be sure. likewise I'm unsure if this is an unexpected result that can/will be fixed or it the change is essential to future development. 

Hi pb66,

Thanks for your offer.

There are two issues with the new version: a node id is now required (or else every input results in a new entry under a NoNode heading); and secondly, the node id must be greater than 0.

On my local copy, I have now included a node in my input postings, and I have managed to change the the node to 1 (instead of zero).

I am concerned about emoncms.org, which is currently running on 8.3.5  If this is updated to 8.4.0, then unless I make changes at my end, all my postings will be converted to new entries with NoNode.  I have no way of changing my existing node on emoncms.org from 0 and so my only option as I see it, is to set up a new node 1 and start using that, which will mean that I will lose all my existing data. (My postings are following the current API specification e.g. http://emoncms.org/input/post.json?json={power:200})

I would like to request please that posting to node zero remains an option (either explicitly, or as the default if no node is specified).  If this is really not possible, then could someone change my current node id from 0 to 1 please.

You are right in thinking this could be problematic for emoncms.org if upgraded to 8.4, I hope Trystan see's this or is aware of the issue.

I would recommend protecting yourself by switching to a node > 0, this not only gives greater security due to "&node=n" being required in the url but also avoids any potential (existing or) future issues arising from not only unspecified node ids but also zero node ids, neither of these have a "value" and both equate to "false" in programming terms whist every other value is "True" so 1 and up are all more robust node ids. 

This is (relatively) easy to do as the feeds (where your data is held) are only connected to the inputs by the processing lists.

If you create a second input by either using the input api or changing the node id at source. you can then copy the input processing from node0 input1 to node1 input1 and so on for each input.

You will not have to create any new feeds, as you add the processes to the processlist you can select the same existing feeds you are currently posting to, totally replicating node0 as node1. it will be quick(ish) to do as there are no new feeds to create. 

Once the new "node1" is created you can stop posting to node0 and post to node1, when you are happy all is well you can delete all node0's inputs with no effect to your data or node1.

Paul

I've PM'd Trystan a "heads up" just in case. 

Thanks Paul - I had not realised that I could create a new input and send it to the same feed as the old input.  So I am now posting to Node 1, and that is logging to the original feed.  All OK for the moment.

Its strange, after upgrade to 8.4.0 I faced the same issue. Every new input log created new input. (I had app. 3000+ new inputs in few hours after upgrade :-((..)

After troubleshooting and finding that node is mandatory now, I had to rewrite all python codes and then I was able log my inputs values again.

BUT, I was able to create node 0 and I am using it and it works - its strange against to described new validation, isn`t ?

AND I have found another issue: Newly any name of sensor can not contain some special characters.

My old inputs were named as "e-mon_kw" and this does not work now. So I had to rename my inputs as "emonkw". 

I am writing this because I think  it could help somebody.

By far the most common source of data to emoncms is via the rfm network, the restrictions around node id numbers imposed by the rfm protocols used ie JeeLib, makes nodeids 1 to 30 the most common as node 31 is "promiscuous" mode and the use of node 0 when using JeeLib denotes "self" and gets replaced with the "host" devices node or base id reserving the "network use" of node 0 for use with OOK, 

Assuming data is from a specific device because it isn't asked where it's from therefore it can't tell you it's from somewhere else isn't sound logic and while setting 0 as a node id is marginally better than no node id, which should indeed be possible to do as int 0 is < 32 (the only restriction imposed by emoncms) it still isn't worth the potential confusion a zero node id could cause unless you have used every other available node id.

I'm not suggesting the unexpected change is welcome, but of all the node IDs, if there was to be an unexpected change that effected just one node id it would probably be 0 and since node 0 is "reserved" in the JeeLib it also the node ID that could attract future development (eg OOK) down the line, 

Interesting find about the input names, I was already aware of an issue with using special characters in feed names so have avoided using them for a while now.

Paul