I have just finished rebuilding my emonPi sd card software and the emonPi appears to be working well. I have 5 CTs, 2 on the emonPi and 3 on the emonTx. I have found regular gaps in the data from my emonTx15, typically 20 mins or so data followed by 20 mins or so missing. However this is only on CT1 and CT3. CT2 works well as intended, with only a very few very minor missing data gaps. I have tried “reset” on the Tx but this does not fix the issue. The expected data is seen on both the input and feed screens, so this may be an emonpi issue? The Pi and Tx are next to each other; I don’t think I have any connection issues. The Tx is mains powered. Both units were purchased in March so I assume would be current models. Can anyone suggest any solutions (as there is too much missing data)? I attach a screenshot of a graph showing the issue; the last 80 mins shows the effect of changing the physical inputs to determine which of the 3 was working. As you can see it is only the input shown in red (CT2)
That’s weird.
And how are they communicating - by radio? If there was a comms problem, the data for all 3 c.t’s plus the voltage would be missing.
Did you start the emonTx with all 3 c.t’s plugged in? What do you really mean by this:
Are all 3 c.t’s plugged in all the time, when did you reset the emonTx, did you swap c.t’s around? It’s not clear to me what you did.
The gaps - are they really missing data or are they filled with zero values? If you watch the Inputs screen during the period that there’s “no” data, does it still show data coming in or does the elapsed time go above 10 s? Is this what you mean by
That’s important because the emonTx sends the data for everything in one packet (look at emonhub.conf to see what it sends) and by expanding the time scale, you should be able to see a set of values come in at 10 s intervals. You should see all three c.t’s and voltage every 10 s or so. If the emonTx is sending zero values, it should show as zero values. If no data is coming in, you won’t see each data point marked by a circle. If it is somehow not sending data for two of the c.t’s, emonHub would throw the entire data packet out as invalid.
What are the settings for the feeds? They should be slower than the rate at which the emonTx sends the data, 10 s or greater is fine, 5 s means you’ll get a NULL value and valid data alternating (roughly - the emonTx is set to report slightly faster than every 10 s, emonCM feeds are timed at exactly 5, 10, 15, 20 s etc. – this is intentional to avoid NULL values if a packet is delayed slightly between the emonTx and emonCMS). If the graph software happens to pick a NULL data value to plot (because it can’t plot every one due to your choice of timescale, then it will show missing data even though there’s good data either side.
Is there any software that’s not included in the standard SD card download, running on the Pi?
Hi Robert; thank you for your reply, following which I deduced that the Emoncms image must be corrupt.
To complete your understanding:
Yes, the Pi and Tx communicate by radio. (I wish I could just join them by a simple cable!)
Yes, I started the Tx with the 3 CTs plugged in.
I noticed that one of the three CTs was providing continuous data. So to eliminate the possibility that the CT itself was an issue, I swapped the three CTs between the three inputs. This is how I found that the input CT2 worked well with all CTs, and that CT1 and CT3 failed as per the Data Viewer graph above. I tried the Tx reset several times during this experimentation.
I had set the Tx feed inputs to 10s.
And yes, I have 2 additional programs loaded - NodeRed and a small program provided 5 years ago by the Open Energy Support Team (Glyn). This matched the sampling rate of the Pi to my Smart EVSE to enable Solar charging with excellent response to changing solar conditions. I checked with him recently regarding the use of this program on the 24Jul20 image.
Yes, the 10s data packet was being received by the Pi. During my research on the forums for this or similar issues I came across advice from Brian Orpin to run a particular Pi command, which I did, and found every 10 seconds the Tx sent a batch of data. (Forum: Data dropouts in “getting Started”)
With your explanation that all Tx data is sent in the one packet, I thought the issue had to be in my new rebuilt Emoncms.
I originally had trouble downloading the image; I noted your support with my concerns which turned out to be using Safari, thank you.
So I started again with a fresh download of 24Jul20 using Chrome - achieved without issue.
No issues whatsoever, all CTs from Tx working well without any dropouts, with both NodeRed and the accelerated Emonpi sample rate to match the Smart EVSE.
Whether the corruption was caused by the difficult download, flashing or just bad luck I will never know.
Charging my EV as I write, with a wall mounted iPad display to enable me to keep an eye on the energy available.
I appreciate your support.
Unfortunately, the ‘emon’ part of the emonPi uses the sole serial input of the Pi, and it’s the sketch in the ‘emon’ part that combines its own data with that incoming by radio. So without a 5-channel emonTx (or a 5-channel emonPi), you need to stay with the radio, I’m afraid.