Emoncms graphs stop getting new data

I have an issue where inputs and feeds are showing as updating normally, and the graphs are missing the data.
This is on a emonPi. The same data logged to emoncms.org was captured by the graphs.
I’m assuming it’s not the graphs as such, but the feeds are not being logged correctly?
What process or logs should I be looking at to see what is going wrong? This has happened a couple times in the last few weeks. Running the latest emonPi SD image.

Can you please give us more info? Screenshots or the graphs with missing data perhaps?

What type of feeds are they? Where does the data originate? How often is it updated?

The most likely issue from the info given so far might be that you are using phpfina feeds with a shorter update interval than the data is actually updated. eg a 60s emonTH value being saved to a 10s phpfina feed will give a graph a 1 in 6 chance of finding valid data at each datapoint it uses and a 5 in 6 chance of finding null values.

It could also be an intermittent RF issue that you might not easily detect by watching the input page updates.

It could be something in the input processing if you have used logic processors.

Hi Paul,

I have 4 x emonTx’s and the emonPi. Also feeding data in is a couple of esp8266 based sensors feeding data via MQTT.

In the Feeds and Inputs pages, they were all updating every 10-30s or so, but the graphs had no data going back several hours.

Data to emoncms.org was not effected.

Some of the feeds have some processing, but most are just “log to feed”.

The emoncms.log file (which I usually follow with a shell and tail) seemed to be getting RF and serial data (two of my Tx’s are serial connected) which makes sense as the remote emoncms.org logging was getting data.

Is there a nice diagram in the doco some place that shows the data flow through the emonPi system?

I thought if the input and feeds page was showing valid updates, then that data must have passed the RF error detection stage?

Ahh ok, I had “guessed” that you meant intermittently missing when you said “the graphs are missing the data”, I now understand you mean data had abruptly stopped and guessing again I suspect it is ALL feeds, is that correct?

Is the feed writer service still running? You can check from the Admin page and also if you ssh is and use

sudo service feedwriter status

if it isn’t running try restarting it with

sudo service feedwriter restart

My bad, yes, the graphs stop and don’t come back until a reboot. I do get missing data on RF feeds, especially the longer links, but that is expected.

Next time it happens I’ll check feedwriter.

Cheers,

Michael.

Cool, yes the reboot is a bit of a wide brush, it doesn’t tells us much.

True, but it can be minimised, there are a few discussions on here about using a ground plane or connecting a ground wire equal to the antenna length to form a dipole, both methods have given good increases in signal and can be applied at both ends to double the improvements.

You need to experiment a bit and possibly look closer at what signals you do have, sometimes increasing sensitivity can pull in more noise having an adverse effect, if it’s interference that’s blocking or corrupting youf RF, then positioning and shielding is key, and if you ave several devices with closely matched (but obviously not absolutely identical) update intervals they can periodically “collide” (transmit at the same time) causing the loss of one or both packets, so there is no one fix fits all unfortunately.

Just in case there’s any confusion from misinterpreting what you’ve written here, adding a ground plane or making a dipole at the transmitter end won’t pull in more noise, at the receiving end it could well do.

1 Like