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.
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:
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.
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.
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.
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.
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.
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.
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?