Archived Forum

You should try and locate the cause and/or prevent reoccurrence before completely removing them as they may well keep popping up again!

Are you running emonhub? if so does the log show anything odd? is the loglevel set to debug?

What access points do you have eg rfm2pi, serial or urls etc?

Which node ids are created ? do they have many inputs? do the inputs have values?

Is it possible you are getting crosstalk from another rfm "group" ? could you try another group setting?

Paul

I get them frequently and some data is recognisable as belonging to other nodes which leads me to believe there are issues with RFM12B error checking I just go in occasionally and delete the errant readings

I do as well have extra inactive nodes with values that don't make sense to me.
I am transmitting (EmonTx) one node only and the Raspi pushes it to emoncms.org

Base station is RFM12Pi

Could this simply be bad data packets that are sufficiently good to be decoded (if you see what I mean)?

Could EmonCMS have a setting that allows you to specify which nodes are good and to ignore anything else?

I'm using one emonTX and one emonTH back to a raspi with the RFM board on the Pi.

@pb66 - how would you change group?  Would each node need re-programming?

I think I am using emonhub - how do I set the debug level? Where would the log be? (I am using the old HDD image (upgraded).

Rogue RF packets was my suspicion, I just wasn't sure if you were using RF,

Although here maybe ways to "limit" the inputs (are you using emoncms.org or a local install?) this will not prevent rogue inputs with live node ids contaminating your data, which is what I suspect your High Power reading thread is reporting.

The visability of the unused nodes created are an easy target for diagnosis as any rogue inputs using used nodeids will be hard to locate, BUT the hidden one's that effect your data are the most important to eliminate as they effect your data, as Br1an says you can just delete the others, they have no operational impact.

The group is set in each nodes sketch, so yes unfortunately each change of group required each node to have new firmware uploaded, a pain I know. setting the grooup id at the base is much easier (in emonhub.conf)

If you are using emonhub then you can edit loglevel = DEBUG in /etc/emonhub/emonhub.conf (emonhub -c on later SDcard images) the /var/log/emonhub/emonhub.log (emonhub -dl on later SDcard images) will record the movement of every packet it see's so you can use it to trace the root. 

You may also find it useful to set the rfm2pi "quiet mode" off for a while to observe the packets that are not being passed on by the rfm2pi (set quiet = True in the [[RFM2Pi]] settings of emonhub.conf) BUT I think early rfm2pi firmwares (ie pre rfm2pi with rfm69) had that feature disabled so may need a firmware update to use.

Another "tool" that may help is to temporarily set the group id of the base to group 0, this is a promiscuous mode and will not filter received data by node id. (It may be best to do this using minicom or similar as it may let in stray data), in promiscuous mode the data frame is prefixed by the groupid so you may be able to select a quite group id rather than unloading sketches in a random trial and error fashion.

see Spurious RF sent to emoncms for a similar issue that a group change cured,

Paul

Ok so first things first, the emonhub.log has the folowing error message;

Warning:  fopen(/var/lib/phpfina/11.dat): failed to open stream: Permission denied in /var/www/emoncms/Modules/feed/engine/PHPFina.php on line 118

Permissions are;

drwxr-xr-x 2 www-data  root      4096 Apr  3 22:45 phpfina

I remember having some issues around this when I upgraded to 8.4 and emonhub.

What should these be?

Oh my, I deleted the emonhub.log files as they were huge and now I am not getting a log at all.  I (Perhaps) foolishly thought the logger would recreate them :(

Plot thickens!

I wonder if the emonhub is actually feeding emoncms.  How can I tell?  Recreated log file and changed group and owner.  Rebooted and got this log

2015-06-15 21:00:31,431 INFO EmonHub Pre-Release Development Version (rc1.2)
2015-06-15 21:00:31,446 INFO Opening hub...
2015-06-15 21:00:31,448 INFO Logging level set to DEBUG
2015-06-15 21:00:31,451 INFO Creating EmonHubEmoncmsReporter 'emonCMS'
2015-06-15 21:00:31,466 INFO Set up reporter 'emonCMS' (buffer: memory | size: 1000)
2015-06-15 21:00:31,476 INFO Setting emonCMS url: http://localhost/emoncms
2015-06-15 21:00:31,479 INFO Setting emonCMS apikey: set
2015-06-15 21:00:31,482 INFO Creating EmonHubJeeInterfacer 'RFM2Pi'
2015-06-15 21:00:31,497 DEBUG Opening serial port: /dev/ttyAMA0 @ 38400 bits/s
2015-06-15 21:00:35,574 WARNING Device communication error - check settings
2015-06-15 21:00:35,577 INFO Setting RFM2Pi frequency: 433 (4b)
2015-06-15 21:00:36,580 INFO Setting RFM2Pi group: 210 (210g)
2015-06-15 21:00:37,584 INFO Setting RFM2Pi quiet: 1 (1q)
2015-06-15 21:00:38,596 INFO Setting RFM2Pi baseid: 15 (15i)

Note it is opening the port at 38400.  Should this be 9600?

From the other thread I was pointed to it talks about modifying the rfm12 file.  is that the firmware for the board or the pi file?  If so where is it?

Cheers

So I am getting no inputs now.

You can define the serial baud in the [[RFM2Pi]] settings in emonhub.conf by adding com_baud = 9600 to the [[[init_settings]]]. The auto baud selection can occasionally be a bit quirky, it works most of the time but if you are having issues or just for peace of mind it can be best to define it if known.

The emonhub.log files get created at start up and if you are running read-only the logfiles are held in RAM so the folder gets recreated at each boot too. In future you can use emonhub -rl (rl = reset logs) if using the last pre-built image or just ' echo "" > /var/log/emonhub/emonhub.log '.

The stray "permission issue" in emonhub's log is purely recorded as it was emoncms's response to emonhub posting data, that is probably unrelated and will need further checks if it reoccurs.

Paul

Brilliant.  I have data again!  Why on earth did it stop having run perfectly (well sort of) for ages?

Now, where is the emoncms.log?  I do not seem to have one.  if I create it, what shoudl the group/owner be?

Hi Paul,  The issue was that when I deleted the logs, emonhub did not seem able to recreate them.  I am running this on a HDD (the old HDD image upgraded to 8.4) as I run other stuff off this as well.

I have a feeling it was because I deleted the log file but did not restart the daemon although I thought I had rebooted so the problem may have been I did not delete the directory.

What is the best version of emonhub to run.  This reports as rc1.2

rc1.2 is the current (non-emonpi) version

Paul

Ok Thanks.