Energy readings out of sync with power usage?

[djh (Dave Howorth)]

I have just noticed a weird situation and have no idea what is happening. Would welcome any thoughts as to what is going on and/or how to investigate it.

I have a graph that summarises my electricity usage. It has behaved well for a long time but in the last two days something strange seems to be happening. I’ll show a normal page first:

emontx3 is monitoring my CUs in the house where my emonBase is. It has four CTs fitted on my solar generation circuit (yellow), the power diverted to my immersion heater (green), and the power through the two distribution boards (blue and red). emontx4 is in the garage near the main electricity meter and the graph shows the grid import energy (purple).

So you can see various red spikes during the evening as the kettle is used and a bit between 1930-1950 where the immersion is on, plus dinnertime cooking. Then there’s a major red lump overnight as the duct heater comes on, with two extra bursts from the immersion heater. There’s more the next morning. You can also see some blue blocks where radiant heaters come on around 2000 and overnight. There’s not much solar or consequent diversion to confuse things.

The purple line of energy used roughly corresponds to the power used, although even here the timing is a little bit off, with the energy usage starting to climb about an hour before the power draw starts.

Then if we look at the current day’s graph:

We can see that the energy graph is totally out of sync with the power usage. The energy usage is practically flat whilst the major overnight power draw is taking place!

All feeds are PHPFINA. Import energy is a Power to kWh ‘kwh’ feed.

I think one factor that may be relevant is that emontx4 suffers from frequent radio transmission problems that have been especially bad in the current weather:

The interrupted blue line is emontx radio strength. Yellow is the nearby emontx3 and red is a Pi Zero W that feeds some other temperature and humidity data in. There are no interruptions shown for the purple line, which I think is a feature of the feed type. All timestamps correspond with the apparent time on the graphs when I check individual points on the graph.

Is there some problem of synchronisation with PHPFINA feeds and poor radio transmission?

[Robert.Wall]

@djh

the energy usage starting to climb about an hour before the power draw starts.

I doubt that it does, though the graph might start to climb…
What’s probably happening - you can check the times and expand the graph to see where the data points are to verify or otherwise - is in the absence of a power value from the emonTx just before it hits that 2 kW step, the graph has drawn a straight line between the points it’s got, the last one being half a time division before the step and the next a little after.

It might become clearer if you draw the RSSI and some of the data from emonTx 4 all on the same graph.

Is emonTx 4 totting up the energy itself and sending the accumulated value to emonCMS? That seems as if it’s what you’ve done.

I’d look to improving the signal from the emonTx 4 - adding ground planes is a cheap and simple first step, or move either or both ends by an inch or two, just in case one is sitting in a null where a reflected wave cancels the direct path.

[djh (Dave Howorth)]

@Robert.Wall

I doubt that it does, though the graph might start to climb…

Sorry, you’re quite right, I should have said ‘graph’ (or ‘chart’ actually, I think) to be technically accurate

Here’s the RSSI chart with the energy added (in green instead of purple). I’ve also shown the CSV data for the period of the knuckle in the knuckle in the middle of the apparently data-free region at 01:02. (I am assuming that there is no data from emontx4 when its RSSI is missing. So I don’t understand why there would be a knuckle there.

@Robert.Wall

Is emonTx 4 totting up the energy itself and sending the accumulated value to emonCMS? That seems as if it’s what you’ve done.

Dunno, I don’t know how the firmware in the emonTx works - it’s the standard sketch, whatever that does. I thought feeds were derived from inputs on the emonBase box though, not on the emonTx, since it has no way to communicate instructions to the emonTx that I’m aware of? As I said it’s a ‘Power to kWh’ feed type with a PHPFINA file, all derived from the power1 input from the emonTx. Maybe @TrystanLea knows more?

@Robert.Wall

I’d look to improving the signal from the emonTx 4 - adding ground planes is a cheap and simple first step, or move either or both ends by an inch or two, just in case one is sitting in a null where a reflected wave cancels the direct path.

Well, the emonTx has an external dipole mounted in free air, and the emonBase has its little bit of wire poking upright from the top of the case rather than coiled up inside. I’ve tried ground planes with no noticeable advantage. I will try standing it on a box to move it a little bit just in case. But the current drop outs I’m assuming are to do with the weather; lots of snow on the ground. I recently commented on my discovery that where I park my car affects the signal quite a lot on the thread where we were discussing such things.

I had just got used to the idea that my main meter data wouldn’t be continuous and started to accept it when I discovered this little wrinkle that I must try to fix. After setting up emontx3 and emontx4 I switched to PHPTimeSeries for everything and I wonder if switching to that would fix this problem. Who knows, maybe I should try it. I’d then have to try to import all the historical data into a new feed though, which would be fun.

[Robert.Wall]

Changing how the data is stored won’t help if the data doesn’t get there to be stored. The difference is, PHPTimeseries won’t create data points while the signal is not coming it, whereas the PHPFINA stores empty slots where the data should have been but isn’t.

@djh

I am assuming that there is no data from emontx4 when its RSSI is missing.

That’s true - but remember, unless you fully expand the graph so that you can see every data point, you might be missing just a single message that’s skipped over when the graph is drawn. The drawing algorithm chooses every nth point, it doesn’t average a bunch of points, nor choose the nearest if the one it wanted is missing - and so if there’s no data at the point it’s chosen, that’s it, even if there is for the ones either side. So I’ll bet there’s a data point there if you expand it far enough.

@djh

Dunno, I don’t know how the firmware in the emonTx works - it’s the standard sketch, whatever that does.

If it’s a recent standard sketch, it gives you the power (P1, P2, etc) and the energy (E1, E2, etc) for each of the 4 inputs. The energy is the integral over time of the power, and it’s added up on board the emonTx and the total from day 1 as a number is transmitted each time. So even if the radio drops off for a while, it will still be correct when it comes back, although you won’t know how it changed whilst it was away.

But you can, and you are, using power to kWh, to accumulate the energy in emonCMS. But in that case, if the radio fails to get through, so does the power and the energy accumulated remains static (and what is lost while that condition prevails) is lost forever.

@djh

the emonTx has an external dipole mounted in free air,

I presume it’s vertical - or in the same plane as the whip on the Base?

@djh

the current drop outs I’m assuming are to do with the weather;

I’d guess a wall has a damp outer surface that’s being rather too effective at screening the signal.

Do you have a programmer? If so, and it’s a recent sketch, you should be able to turn the R.F. power up on the emonTx (but you must bear in mind that Dan Bates turned up the power without an Aerial and cooked his RFM69CW, so there are risks). You’d need to change one number in the sketch, compile and reload it. Max. power will give you an extra 6 dBm, but you might need a 5 V USB power supply, as the internal supply from the a.c. adapter will struggle when the mains voltage is low.

I take it a cable isn’t feasible? And what is the Wi-Fi signal like in the garage? If raising the output power doesn’t help, those are the alternatives.

[djh (Dave Howorth)]

@Robert.Wall

If it’s a recent standard sketch

Depends whether you consider 2018 recent?

@Robert.Wall

it gives you the power (P1, P2, etc) and the energy (E1, E2, etc) for each of the 4 inputs

The only inputs are the power.

@Robert.Wall

But you can, and you are, using power to kWh, to accumulate the energy in emonCMS. But in that case, if the radio fails to get through, so does the power and the energy accumulated remains static (and what is lost while that condition prevails) is lost forever.

I wouldn’t mind that so much. It’s the fact that the time seems to getting out of sync that bothers me.

@Robert.Wall

I presume it’s vertical - or in the same plane as the whip on the Base?

Yes, please refer to the other thread for details of the radio installation.

@Robert.Wall

I’d guess a wall has a damp outer surface that’s being rather too effective at screening the signal.

The RSSI is no worse when it’s working than normal, so I doubt the dampness of the wall is too important.

@Robert.Wall

Do you have a programmer? If so, and it’s a recent sketch

No and it isn’t, I guess.

@Robert.Wall

you might need a 5 V USB power supply

It has a separate USB supply I believe.

@Robert.Wall

I take it a cable isn’t feasible? And what is the Wi-Fi signal like in the garage? If raising the output power doesn’t help, those are the alternatives.

One of the things that attracted me to OEM in the first place was that the system didn’t rely on the wi-fi, or rather the lack of wi-fi. I can put a cable in, but that will involve major effort and disruption. I’m also considering a powerline connection.

[Robert.Wall]

Other than getting a programmer, downloading the Arduino IDE, the libraries and a recent sketch that’s got the energy values and the ability to adjust the radio power, then it looks as if a pair of powerline adapters might be the answer.

I don’t have any experience of those, other than to report that I had a friend who ran a farmhouse B&B in rural Scotland, and his neighbour’s milking machine blew up his Netgear Ethernet powerline adapters, and he ended up with a metre long masonry drill to get through the house wall and ran a cable instead.

[pb66 (Paul)]

The graphs seem to tally with what you say when combined with sporadic packets received from emontx4. The “timing” issues are due to lines being drawn between the irregular datapoints selected by the graphs sampling. Looking at the data packets in emoncms will have you chasing your tail because there are so many ways the data gets skewed, everything is aimed at providing a simplified general picture from a large dataset rather than every data point being absolute.

The info you need can be found in emonhub.log. I know you do not want to set loglevel to debug, but that would tell you so much about the emontx4 payloads. For starters, exactly when they are being seen and at what rssi. If you also set quiet=false then any incomplete or corrupted packets will still be seen as “discarded” packets rather than just silently slipping into the darkness.

Do you have any other spare CT’s?

The result of having just one CT on emonTx4 might be that the series of 6 zero bytes for CT’s 2,3&4 could mean the receiver is struggling to sync and the packets from emontx4 are failing CRC despite an acceptable RSSI. This issue would come and go with temperature and voltage fluctuations affecting both the tx and/or the rx ends. Plus CT1’s value will increase that string of zero values now and again too. If you have a spare CT, just plug it into “CT3” of the emonTx4 and clip it to a non-zero wire, you can ignore the reading so it really doesn’t matter what circuit as long as it’s not a “no load” circuit, although having said that even a loose CT would cause a non-zero value as it hovers around zero.

If this is what’s happening it would be very clear to see in emonhub (with the debug loglevel) but trying a spare CT (and restarting the emontx) would also do the job, just a bit more “trial and error” than the emonhub.log approach of identifying and confirming bad packets and being sure that good packets are then all passing through to emoncms faithfully.

I don’t know for sure that’s the issue you’re having but it fits the symptoms and application, the only way to know for sure is via the emonhub.logs, otherwise it’s just guesswork.

[Robert.Wall]

I concur.

@pb66

Do you have any other spare CT’s?

Even a spare 3.5 mm plug or two would do (even a mono one). All you need is something to remove the short to GND that the absence of a plug in the socket puts on (via the internal switch), and there’s going to be enough noise to assure a few non-zero data bits.
Even plugging in a pair of headphones would do.

If @djh wants to get a programmer and set up to use it, it’s very easy to throw together an up-to-date sketch with just one current input and a very short data packet, and if it was loss of sync as you suggest, it should go away.

[pb66 (Paul)]

Actually even just moving the one CT from CT1 to either CT2 or CT3 might split the chain of zero’s enough to allow the receiver to synchronise, I doubt I would rely on this approach to prove if that’s the issue or not, but if it is proven to be “bitslip” then it is another quick and easy option to try as a permanent fix.

[djh (Dave Howorth)]

@pb66

The info you need can be found in emonhub.log. I know you do not want to set loglevel to debug, but that would tell you so much about the emontx4 payloads. For starters, exactly when they are being seen and at what rssi. If you also set quiet=false then any incomplete or corrupted packets will still be seen as “discarded” packets rather than just silently slipping into the darkness.

I did in the end set the emonhub.log level to DEBUG I sent a patch to github to vary the number of logs it keeps but haven’t heard anything about that.

In consequence I have approx 12 hours of detailed logs. None remaining of any ‘interesting times’, sadly. Here’s a few seconds from just now to give you a flavour:

2021-02-11 09:15:10,781 DEBUG    MQTT       Publishing: emon/emontx3/rssi -27
2021-02-11 09:15:10,783 INFO     MQTT       Publishing: emonhub/rx/8/values 313,155,-225,0,251.39,300,300,300,300,300,300,82319,-27
2021-02-11 09:15:12,204 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 31 193 193 8 254 29 68 131 239 69 208 130 192 44 253 212 43 115 111 222 165 (-84)
2021-02-11 09:15:12,313 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 14 175 164 196 28 104 95 111 142 208 125 106 70 221 198 134 95 105 123 225 241 (-82)
2021-02-11 09:15:14,228 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 9 46 227 199 240 64 230 93 79 175 15 203 220 154 187 36 114 95 99 241 127 (-85)
2021-02-11 09:15:14,538 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 6 171 136 112 181 196 185 238 84 184 212 193 191 224 179 37 97 133 169 59 79 (-84)
2021-02-11 09:15:15,249 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 19 185 21 115 191 45 150 254 47 123 135 128 126 135 229 34 166 225 174 65 243 (-84)
2021-02-11 09:15:17,275 DEBUG    RFM2Pi     205784 NEW FRAME : OK 7 186 255 0 0 0 0 0 0 182 96 1 0 184 11 184 11 184 11 184 11 184 11 45 114 16 0 (-65)
2021-02-11 09:15:17,279 DEBUG    RFM2Pi     205784 Timestamp : 1613034917.27
2021-02-11 09:15:17,281 DEBUG    RFM2Pi     205784 From Node : 7
2021-02-11 09:15:17,282 DEBUG    RFM2Pi     205784    Values : [-70, 0, 0, 0, 247.58, 0.1, 300, 300, 300, 300, 300, 1077805]
2021-02-11 09:15:17,283 DEBUG    RFM2Pi     205784      RSSI : -65
2021-02-11 09:15:17,284 DEBUG    RFM2Pi     205784 Sent to channel(start)' : ToEmonCMS
2021-02-11 09:15:17,286 DEBUG    RFM2Pi     205784 Sent to channel(end)' : ToEmonCMS
2021-02-11 09:15:17,439 DEBUG    MQTT       Publishing: emon/emontx4/power1 -70
2021-02-11 09:15:17,440 DEBUG    MQTT       Publishing: emon/emontx4/power2 0
2021-02-11 09:15:17,442 DEBUG    MQTT       Publishing: emon/emontx4/power3 0
2021-02-11 09:15:17,443 DEBUG    MQTT       Publishing: emon/emontx4/power4 0
2021-02-11 09:15:17,444 DEBUG    MQTT       Publishing: emon/emontx4/vrms 247.58
2021-02-11 09:15:17,445 DEBUG    MQTT       Publishing: emon/emontx4/temp1 0.1
2021-02-11 09:15:17,447 DEBUG    MQTT       Publishing: emon/emontx4/temp2 300
2021-02-11 09:15:17,448 DEBUG    MQTT       Publishing: emon/emontx4/temp3 300
2021-02-11 09:15:17,449 DEBUG    MQTT       Publishing: emon/emontx4/temp4 300
2021-02-11 09:15:17,450 DEBUG    MQTT       Publishing: emon/emontx4/temp5 300
2021-02-11 09:15:17,451 DEBUG    MQTT       Publishing: emon/emontx4/temp6 300
2021-02-11 09:15:17,453 DEBUG    MQTT       Publishing: emon/emontx4/pulse 1077805
2021-02-11 09:15:17,454 DEBUG    MQTT       Publishing: emon/emontx4/rssi -65
2021-02-11 09:15:17,455 INFO     MQTT       Publishing: emonhub/rx/7/values -70,0,0,0,247.58,0.1,300,300,300,300,300,1077805,-65
2021-02-11 09:15:18,876 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 2 206 224 77 249 227 85 16 15 17 148 69 168 4 205 117 239 249 33 232 235 (-85)
2021-02-11 09:15:20,562 DEBUG    RFM2Pi     205785 NEW FRAME : OK 8 60 1 156 0 48 255 226 0 82 98 184 11 184 11 184 11 184 11 184 11 184 11 144 65 1 0 (-28)
2021-02-11 09:15:20,567 DEBUG    RFM2Pi     205785 Timestamp : 1613034920.56
2021-02-11 09:15:20,568 DEBUG    RFM2Pi     205785 From Node : 8
2021-02-11 09:15:20,569 DEBUG    RFM2Pi     205785    Values : [316, 156, -208, 226, 251.70000000000002, 300, 300, 300, 300, 300, 300, 82320]
2021-02-11 09:15:20,570 DEBUG    RFM2Pi     205785      RSSI : -28
2021-02-11 09:15:20,571 DEBUG    RFM2Pi     205785 Sent to channel(start)' : ToEmonCMS
2021-02-11 09:15:20,573 DEBUG    RFM2Pi     205785 Sent to channel(end)' : ToEmonCMS
2021-02-11 09:15:20,784 DEBUG    MQTT       Publishing: emon/emontx3/power1 316
2021-02-11 09:15:20,786 DEBUG    MQTT       Publishing: emon/emontx3/power2 156
2021-02-11 09:15:20,788 DEBUG    MQTT       Publishing: emon/emontx3/power3 -208
2021-02-11 09:15:20,791 DEBUG    MQTT       Publishing: emon/emontx3/power4 226
2021-02-11 09:15:20,793 DEBUG    MQTT       Publishing: emon/emontx3/vrms 251.7
2021-02-11 09:15:20,795 DEBUG    MQTT       Publishing: emon/emontx3/temp1 300
2021-02-11 09:15:20,797 DEBUG    MQTT       Publishing: emon/emontx3/temp2 300
2021-02-11 09:15:20,799 DEBUG    MQTT       Publishing: emon/emontx3/temp3 300
2021-02-11 09:15:20,801 DEBUG    MQTT       Publishing: emon/emontx3/temp4 300
2021-02-11 09:15:20,803 DEBUG    MQTT       Publishing: emon/emontx3/temp5 300
2021-02-11 09:15:20,805 DEBUG    MQTT       Publishing: emon/emontx3/temp6 300
2021-02-11 09:15:20,808 DEBUG    MQTT       Publishing: emon/emontx3/pulse 82320
2021-02-11 09:15:20,810 DEBUG    MQTT       Publishing: emon/emontx3/rssi -28
2021-02-11 09:15:20,812 INFO     MQTT       Publishing: emonhub/rx/8/values 316,156,-208,226,251.7,300,300,300,300,300,300,82320,-28
2021-02-11 09:15:21,184 DEBUG    RFM2Pi     Discarding RX frame 'unreliable content'? 10 233 190 216 97 95 109 97 39 68 189 254 166 95 112 211 111 87 95 190 123 (-87)

The RSSI values I see always seem to correspond with what emoncms shows me. I’m not sure what else I should be looking for?

@pb66

Do you have any other spare CT’s?

Afraid not, just what’s in the production system. I might be able to dig out a 3.5 mm jack if that’s useful though.

I stood the emonBase on a box last night. It seems to have increased signal level by up to 10 dB so maybe the problem is ‘fixed’ for now. i.e symptoms gone. Time will tell.

[Robert.Wall]

@djh

It seems to have increased signal level by up to 10 dB

That is a very significant increase. If the problem continues, then I’d be fairly certain it is bit-slip.

[Bill.Thomson]

@Robert.Wall

That is a very significant increase.

Especially if the values shown two posts above this one were what you were getting after you
put your emonBase on the box. If they were, the RSSIs in the -80s would be very close to the edge, if not a bit beyond, reliable operation. (the RSSIs of -28 and -65 are OK)

If the post shows the RSSIs before you put it on the box, then you should be OK. But if that’s all it
took to make that much difference in received signal strength, there are other factors at play.
e.g. multipath, a detuned antenna, moisture in a feedline, to name a few.

[Robert.Wall]

@Bill.Thomson

If the post shows the RSSIs before you put it on the box,

I think that’s the case.

@djh

I stood the emonBase on a box last night. It seems to have increased signal level by up to 10 dB

… makes me think that the receiver was sitting in (or very close to) a multipath null.

[djh (Dave Howorth)]

@djh

I stood the emonBase on a box last night. It seems to have increased signal level by up to 10 dB so maybe the problem is ‘fixed’ for now. i.e symptoms gone. Time will tell.

Hmm, I must have been more tired than I thought last night / this morning. What I actually did was get a box (about 100 mm high), go downstairs to the emonBase, discover that it was already sitting on a small box (about the height of the pi case), so I removed the little box and didn’t use the bigger box. There are only a few small dropouts now and the symptoms have gone. So the emonBase is now sitting on a laminate worktop; I’ve no idea whether that looks like a ground plane at the RF frequency.

All the previous charts showed data from before the move. The environment the emonBase is sat in is quite complex. It’s just underneath the CUs and associated emontx3 and alongside cable runs down from the CUs and other gubbins; it’s right next to my Internet router, which is right next to my Dect base station and the phone master socket. Here’s a couple more charts to show the current situation and how it compares:

Above is just the RSSI of the problematic emontx for the past two days.You can see the jump in signal level about 22:00 yesterday when I moved the emonBase and the much more reliable signal afterwards.

Below is a comparison of two measurements of the same thing: the net energy imported from the grid into my house over the past two days. Yellow is the problematic value derived from the CT’s power reading. Blue is the value from the optical sensor on the meter. Fairly similar in shape today but very different yesterday. Both differ from the actual meter reading of course, which was 31596 kWh at the beginning of this month.

The blue value counts both imports and exports as positive; it also got reset by one of the power cuts last year - it’s true value is about 13520993 Wh. The yellow value offsets exports against imports and also gets reset every time there is a power cut, so is much lower.

[Robert.Wall]

@djh

The blue value counts both imports and exports as positive; it also got reset by one of the power cuts last year - it’s true value is about 13520993 Wh. The yellow value offsets exports against imports and also gets reset every time there is a power cut, so is much lower.

I’ve had a request to look into saving the present values when there’s a power cut, to restore them on restarting. I don’t yet know whether it is feasible, but if it turns out to be, then that problem would go away.

[djh (Dave Howorth)]

@Robert.Wall

I’ve had a request to look into saving the present values when there’s a power cut, to restore them on restarting. I don’t yet know whether it is feasible, but if it turns out to be, then that problem would go away.

I’m not sure it would be worthwhile to be honest. The emoncms system has the same data and could afford to spend some compute time recalculating things afterwards. I’d think it was better to put the intelligence in the central system where it’s easier to reconfigure etc. At some point I may reprocess my optical readings to separate out the import readings and the export readings for example. It’s easy to add extra processing to do that in the pi.

[djh (Dave Howorth)]

The chart below is a good illustration of why there is an early evening peak of demand. All those spiky red bits in the peak are dinner cooking

At least the energy import line looks more sensible now. Thanks guys.

[Robert.Wall]

@djh

I’m not sure it would be worthwhile to be honest.

The thinking was, it would make it behave more like the supplier’s electricity meter.

In your (past) situation, there the power readings were never received. Had you been using the accumulated-at-source energy values, those would have been correct until a power cut. If that last value can be stored in the emonTx’s dying gasp, then the energy count can carry where it left off when power is restored.

[djh (Dave Howorth)]

@Robert.Wall

In your (past) situation, there the power readings were never received. Had you been using the accumulated-at-source energy values, those would have been correct until a power cut. If that last value can be stored in the emonTx’s dying gasp, then the energy count can carry where it left off when power is restored.

Yes, my point is that the emoncms system can carry out that calculation just as well, with more possibility for easy customisation and configuration.

For example, if you want to emulate the physical meter then when is it going to wrap around? How many digits, Wh kWh or something in between (two decimal places?)

How are you going to initialise the reading to match whatever’s on the meter when the emontx is first connected? And if you aren’t, why bother?

I’m sure there are more issues to consider.

[Robert.Wall]

@djh

Yes, my point is that the emoncms system can carry out that calculation just as well, with more possibility for easy customisation and configuration.

That’s only true when it receives the data in the first place.