EmonTX missing data on CT4 input at regular intervals

Hardware emonTx
1

Hi,

I have a EmonTx transmitting directly to Emoncms.org.

I was wondering why I was getting ‘plateaus’ on the app view of my data, then discovered the missing data feature on Econcms data viewer. This shows that input 4, high res, data (Green on the trace below) is being transmitted/received only intermittently. The noticeable thing is that the on/off interval is very regular This is very evident during the night as it records solar energy so flat-lines.

Plugging the CT into a different input (orange trace) restores unbroken data transfer.

The red trace on another standard input is continuous throughout.

It appears that input 4 transmits with a different quality than the other 3 inputs - 44% verses 90% on this trace - which seems wrong, as I would expect them all to be the same quality. Having said that this is the 2nd trace I’ve put on this post and I noticed the qualities for the previous trace were 31% for input 4 and 61% for the others so clearly the quality is changing over time.

image
image723×778 60.5 KB

Is there something wrong with the EmonTx channel or am I misunderstanding how the data transmission works?

Thanks for any pointers you can give.

2

I don’t think you’ve ever said which sketch you are using, so I assume it’s the standard default one. I also seem to remember that you’re using an ESP8266. But I do not know how the “quality” is calculated.

However, the standard sketch measures each active c.t. in order for 200 ms (in your case, I think that’s 1 & 4), parcels that up into a data packet that carries all 4 c.t. powers, voltage, 6 temperatures and the pulse count, and sends the whole lot to the ESP.

The output statements in your emonTx sketch look something like this:

  if (DEBUG==1) {
    Serial.print("ct1:"); Serial.print(emontx.power1);
    Serial.print(",ct2:"); Serial.print(emontx.power2);
    Serial.print(",ct3:"); Serial.print(emontx.power3);
    Serial.print(",ct4:"); Serial.print(emontx.power4);
    Serial.print(",vrms:"); Serial.print(emontx.Vrms);
    Serial.print(",pulse:"); Serial.print(emontx.pulseCount);
    if (DS18B20_STATUS==1){
      for(byte j=0;j<numSensors;j++){
        Serial.print(",t"); Serial.print(j); Serial.print(":");
        Serial.print(emontx.temp[j]);
      }
    }
    Serial.println();
    delay(50);
  }

My initial approach would be to take out all the unused variables and see what the effect is.

Some years ago, we had problems with the RFM modules when it was decided to send 6 temperature readings, because the long serial stream of 0 bits allowed the two clocks to drift out of sync and the checksum failed (and it’s resurfaced with 4 ‘long integer’ energy values and emonLibCM). There’s no checksum on the serial link between the emonTx and the ESP8266, but I wonder whether you have the same problem. If you have, taking out the unused variables should cure it. This might explain also your 12 kW spikes.

You might not need to amend your processing in emonCMS to cater for the change, if you’re sending the data labels (“ct1:”) as well as the data.

1 Like
3

Thanks Robert,
I’ll look at doing that. Will need to dust down my USB to UART programmer stuff!
Looking at those output statements I’m wondering if removing the DS18B20 might improve matters pro tem. I assume, if removed, the status will revert to zero and remove a chunk of the transmission. Worth a try.

4

No, that made no difference :slightly_frowning_face:

Regarding signal quality:
Checking historic data I notice that up until today the quality of inputs 1-3 have been at or around 100%, input 4 at around 50%.
Today inputs 1-3 quality has tumbled to as low as 34% for a time, input 4 again around half of this.
What might be causing this drastic variation? I can’t think of anything that has changed.

Gordon

5

Is it a network problem - either on your LAN or between your router and emoncms.org? (i.e, your ISP?) I don’t know how “quality” is arrived at; if it’s documented anywhere, I’ve no idea where to look. If it’s purely the number of received packets versus the expected number over the same period, then a transmission problem - or even a variable delay which causes packets to fall into the wrong ‘slot’ - would explain it.
[What I mean by that is, if you’re using PHPFINA at 10 s rate, the data is simply dropped into the “now” time slot as it arrives. So let’s say a packet arrives 9.9 s into the time slot consistently, all is well. but if one packet gets delayed by 150 ms, it misses its slot and goes into the next one. If the next packet isn’t delayed, it goes into its proper slot and overwrites the late one.]

Why ct4 should be different, I’ve no idea. I don’t know what goes on inside the ESP8266, nor how the data is sent over the Internet (i.e. how many packets, of what size). But there’s no law saying that the data needs to be sent in that order, so you could shuffle ct4 up into 2nd or 3rd place, if you wished.

You don’t need to send empty values for anything you’re not using, so you could comment out ct3, maybe vrms, and pulse.

6

If its a network issue I’m relatively relaxed as that can be checked easily enough when it happens again. The ‘quality’ dropping off does not appear to affect the ‘good’ inputs anyway. Its back at 100% now.
I’m ultimately looking to use all 4 inputs and vrms so pulse could go.
Its the absolute regularity of the dropping out/coming back that puzzles me. Looks to be the same period on as off - ie 50% - suspiciously the ‘quality’ is also around 50% of the good inputs.
For now the workaround is to use inputs 1-3 but I want to be sure I’ve not got a faulty unit so have asked openenergymonitor support for a view.

7

In case this happens to someone else I’ll detail the solution.
OpenEnergyMonitor kindly checked out the hardware they had sold me and pronounced it OK.
When I reinstalled I had the same problem but on a different input.
I then started a new node on Emoncms.org and moved each input over to it, using identical Process Lists to create new feeds. Have had no problems since.
Can only conclude that the problem was within the original node on the Emoncms.org site.

8

I must say I find that rather surprising. Is @TrystanLea aware of your conclusion?

9

Sorry to bump an old thread, but Im bumping into this issue too I think.

Have emonTX with wifi.

Installed and connected solar yesterday, so today was the first full day. and the solar feed (on CT2) seems to freeze updating.

Nighttime now and the power usage is tracking but the solar feed and the "house consumption, ie solar gen + CT1) is cutting out for 20- 30 minutes.

I added a second log to feed (a new one) and that has been running fine, It may not be the emontx all along.

Going to nuke it and set up again and see if it changes anything. Could it actually be a bug in emon cms? trying to narrow it down will be difficult, esp if i cant re create it

Edit: nuked it and set it up again it is running fine and steady after an hour. Now how on earth could i break a feed. Will keep an eye out for it in the future.

10

You’re going to be using a totally different sketch in your emonTx - assuming it’s a new one (bought since the end of last year).

That’s the emonESP, or an emonTx with the ESP8266 module attached?

11

Just to say that since I changed node, as I described, I’ve had no further problems for nearly a year

12

Yep Emon tx with the emonesp.

It’s been perfect since I reset it too( the cms feed)

13

@TrystanLea
This sounds weird. Could it be a funny in emoncms.org, even though you looked a while ago EmonTX missing data on CT4 input at regular intervals - #7 by DickiePhitt

14

I cant see anything that might cause it on emoncms.org. @graememk if you want to send me your account name in a private message, I can see if there is anything associated with your account if you like?

15

It was on a raspberry pi 2 that I have Emon cms setup on and doing the recording.

Only thing I might have changed was that I originally set the update interval to 5 seconds rather than the default 10.

I’ll setup another feed on an irrelevant input and see if I can replicate.

Today it has worked perfectly.

16

image
image1120×658 48.8 KB

I was able to replicate it, Yep it was setting a feed to 5 seconds. (this is on a emontx +wifi, currently just plugged in to the AC, havent got around to installing it yet)

Currently its an input over mqtt, but had the same behaviour when posting over the http to a emoncms.

I can post to emoncms.org if you like and see if I can replicate the bug there.

17

Looks like I’ve got the same issue. There is 20 min worth of missing data on a regular basis, and i only ever 50% data quality in the feed summary. All other feeds maintain ~100%.
This is the data from my newly added ‘solar diverted’ feed. This is CT on the live wire of a cable running from an mk2router to the immersion tank. Below is a night time data set (so no current to measure).

image
image1807×810 185 KB

Below is day time data set:
image
image1783×836 141 KB

The CT is connected to a TX, running a modified sketch from Robert Wall,
https://community.openenergymonitor.org/t/missing-temperature-feeds-on-emontx-and-emoncms-setup/17264/6?u=dr_w. The TX has 6 temperature sensors plugged in via a breakout board using an RJ45 cable.

18

Has your custom sketch run for the last 18 months, or have you only just put it to work?

19

Hi robert,
It’s been running since march 2021. No other problems that i’ve noticed, just this missing data when i added this new CT a few weeks ago.
I’m now wondering if i setup the feed wrong and didn’t set a time interval in the process list setup. I’ve added a new process duplicating the ‘solar divert’ feed but this time made sure i set a 10 s interval.

Is it possible to edit existing feeds to change the interval? Doesn’t seem to be an editable option in the feed setup.

20

No. The PHPFINA feed works by storing the start time, and calculating the time for each data point from the interval and the record number. You’d need to rewrite the file interpolating or skipping values to “change” the interval of historic data.

You can hover your mouse over the name in Feeds to see what the properties are.

1 Like