Help with feed calculation not always correct

Emoncms
21

What’s been a potential source of confusion all along is your naming system. Looking at the first post in this thread:

I would say:
Input 1 is the PV Infeed.
Input 2 is the Grid Infeed.
Both are positive when power flows in to the premises. (This is our convention so all is well so far.)

Therefore, House consumption = PV Infeed + Grid Infeed

The picture there shows “House consumption incl solar negative is export”. Going forward to Post No.11, “House consumption incl solar negative is export” shows as an input from your emonTx4. Unless I’m being exceptionally thick (and it’s early in the day for me so that’s entirely possible), surely this is the really the Grid Infeed?

Still in Post No.11, the processing shows House consumption = Grid Infeed - Solar Infeed
For that to be a minus and not a plus, as per

there’s at least a c.t. the wrong way round somewhere, or you’re not measuring what you think you’re measuring. Whilst this doesn’t appear to be the problem, there’s at least one place where there’s confusion somewhere along the line.

And where do they connect into your system?

If the batteries are included in ‘house consumption’, then the batteries exporting to the grid will give you a negative house consumption, and the spikes may well be due to the time taken for the battery control system to swap over from charge to discharge or vice-versa. How does the battery system control whether it charges or discharges?

Can I suggest that you start at the c.t’s and carefully check everything and assume nothing - and include the batteries? so that the three or four of us (you, me, Trystan & Nick) know exactly what you have and what’s happening.

A single line diagram (do you know what I mean by this?) showing the main parts of your house wiring and the points where you have your emonVs and each c.t. would be useful.

22

Robert, thanks.

Input and feed names changed as per your suggestions.

Yes, ‘House consumption incl solar negative is export’ is Grid Infeed. And yes, the naming is confusing.

The PV Infeed does read negative so the CT is the wrong way around. Hence the ‘House consumption’ calc uses a ‘-’ and not a ‘+’. I could change it around, but don’t believe that it will change the outcome I am seeing.

I’m confident that I’m measuring what I think I am. The three inputs we’re dealing with here all behave as expected on their own.

I don’t have a battery.

There are 15 CTs in my outside switchboard mounted directly above each circuit breaker. Each of these CTs run to an enclosure mounted directly above the external switchboard that houses the 3 x Tx4s and the emonVs-mini with a 3 way splitter to each Tx4.

I hope that helps. Pls advise any more info or screen shots you require.

23

I was going to raise this as a separate issue, but will do it here in case it’s related.

Why am I seeing emonTx4_122 that appeared a week or so after I installed the new equipment?

All I installed were nodes 17, 18 & 19 that all appear correctly.

image
image1582×650 30.1 KB

And then emonTx4_253 appeared a couple of weeks ago!!

image
image1587×452 20.3 KB

If it’s not related to the above issue, then pls ignore and I’ll post it later and separately.

Thanks.

24

Correct, it won’t - but it was/could well still be confusing.

So each emonTx4 receives the same mains reference voltage. That’s good.

It looks like I need to set up the same processing steps as you are doing, and see if I can reproduce the problem. Which sketch are you using, and what is going to each input of the emonTx4 in question?

This appears to be an undocumented “feature” that Trystan has invented to automatically create feeds and ignore emonub.conf. If you think you have a problem with two, here’s a snip of a PM I sent him, and his response:

I think by setting autoconf = 0 at the top of emonhub.conf, you might be able to inhibit the behaviour. But I haven’t seen any more since I updated emonCMS, so he might have solved the problem.

25

I have a result:

It appears indeed to be an artefact in the Input processing, and it is affected by the order in which the calculations appear. I’ve yet to complete a full analysis, and no doubt further tests will be needed.

Test Setup: An emonTx4, with 3 c.t’s - 100, 50 & 25 A from The Shop, all three on my c.t. test rig, all on the same “cable” but each taking a different number of turns so as to read the same in mV output. The emonTx4 running my 12-inputs demo sketch for emonLibDB.

Logging in emonCMS:
The 3 powers P1, P2 & P3
The 6 differences P1-P2, P1-P3, P2-P1, P2-P3, P3-P1 & P3-P2 which appear in this order in the input processing and so presumably are processed in this order.
P1-P2 & P1-P3 are processed on P1 Input page.
P2-P1 & P2-P3 are processed on P2 Input page.
P3-P1 & P3-P2 are processed on P3 Input page.
The current is set to show approx. 1950 W, stepped up to 2350 W, then back to approx 1950 W.

The initial results:

Screenshot 2023-10-29 13:02:33
Screenshot 2023-10-29 13:02:331426×562 95.4 KB

And the raw data:
“Date-time string”, “emonTx4_17:P1”, “emonTx4_17:P2”, “emonTx4_17:P3”, “emonTx4_17:P1-P2”, “emonTx4_17:P2-P1”, “emonTx4_17:P1-P3”, “emonTx4_17:P3-P1”, “emonTx4_17:P2-P3”, “emonTx4_17:P3-P2”
2023-10-29 12:40:30, 1974, 1958, 1957, 19, -16, 20, -17, 4, -1
2023-10-29 12:40:40, 1976, 1960, 1960, 18, -16, 19, -16, 3, 0
2023-10-29 12:40:50, 1980, 1964, 1963, 20, -16, 20, -17, 4, -1
2023-10-29 12:41:00, 1971, 1955, 1954, 7, -16, 8, -17, -8, -1
2023-10-29 12:41:10, 1967, 1951, 1950, 12, -16, 13, -17, -3, -1
2023-10-29 12:41:20, 1965, 1949, 1949, 14, -16, 15, -16, -1, 0
2023-10-29 12:41:30, 1958, 1942, 1941, 9, -16, 9, -17, -7, -1
2023-10-29 12:41:40, 2012, 1997, 1996, 70, -15, 71, -16, 56, -1
2023-10-29 12:41:50, 2357, 2339, 2338, 360, -18, 361, -19, 343, -1
2023-10-29 12:42:00, 2359, 2341, 2340, 20, -18, 21, -19, 3, -1
2023-10-29 12:42:10, 2361, 2343, 2342, 20, -18, 21, -19, 3, -1
2023-10-29 12:42:20, 2358, 2339, 2338, 15, -19, 16, -20, -3, -1
2023-10-29 12:42:30, 2361, 2342, 2341, 24, -19, 25, -20, 6, -1
2023-10-29 12:42:40, 2375, 2356, 2355, 33, -19, 34, -20, 15, -1
2023-10-29 12:42:50, 2365, 2346, 2346, 9, -19, 10, -19, -9, 0
2023-10-29 12:43:00, 2361, 2343, 2342, 15, -18, 15, -19, -3, -1
2023-10-29 12:43:10, 2368, 2349, 2348, 25, -19, 26, -20, 7, -1
2023-10-29 12:43:20, 2364, 2345, 2344, 15, -19, 16, -20, -3, -1
2023-10-29 12:43:30, 2356, 2338, 2337, 11, -18, 12, -19, -6, -1
2023-10-29 12:43:40, 2110, 2094, 2093, -228, -16, -227, -17, -243, -1
2023-10-29 12:43:50, 1982, 1967, 1966, -112, -15, -111, -16, -126, -1
2023-10-29 12:44:00, 1978, 1963, 1962, 11, -15, 12, -16, -3, -1
2023-10-29 12:44:10, 1980, 1964, 1963, 17, -16, 18, -17, 2, -1
2023-10-29 12:44:20, 1976, 1960, 1959, 12, -16, 13, -17, -3, -1
2023-10-29 12:44:30, 1977, 1962, 1961, 17, -15, 18, -16, 3, -1
2023-10-29 12:44:40, 1972, 1957, 1956, 10, -15, 11, -16, -4, -1
2023-10-29 12:44:50, 1975, 1960, 1959, 18, -15, 19, -16, 4, -1
2023-10-29 12:45:00, 1980, 1964, 1964, 20, -16, 21, -16, 5, 0
2023-10-29 12:45:10, 1978, 1963, 1962, 14, -15, 14, -16, -1, -1

Despite all three inputs seeing exactly the same current, averaging over exactly the same period to within two samples in a set of 12 samples (around 100µs), and reporting in the same data packet by radio:

P1 - P2, P1 - P3 & P2 - P3 show a large positive spike with increasing power and a negative spike on decreasing power.
P2 - P1, P3 - P1 & P3 - P2 show no spike (on the same scale).

My initial conclusion appears to be that a power lower down the Inputs list does not have its present value known when it appears in a process step higher up the process list, so a “last known” value is used.
e.g., looking at the CSV file lines 8 & 9 (the heading is line 0):
P2 - P3 (= 343) = P2[9] (= 2339) - P3[8](= 1996) which is indeed correct maths.

@TrystanLea Sorry, but you appear to be wrong when you wrote

1 Like
26

Robert, thanks for taking the time to set up a test rig. It’s good that you can replicate the issue.

I’m using the sketch that came with the Tx4’s.

On node 17, input 1 is Grid Infeed & input 4 is PV Infeed.

Thanks.

27

It looks as if your workaround will be to put the subtraction in the processing of Input 4 - the PV infeed.

Thus in Input 4, you do

  1. Log to Feed
  2. - input P1
  3. × -1 <= Makes it positive
  4. Log to Feed House consumption
    …to kWh & kW Log to Feed etc
    Reset to Original
    [I don’t think this needs the -1 here to make it negative for export]
    Allow negative
    Log to Feed: Solar export
    …to kWh & kW Log to Feed etc

Then Input 1 has its own Log to feed and kWh & kW and Log to feeds only.

28

Robert, thanks.

I’ll make these changes when I get some time later this week and let the group know how it went.

29

@Robert.Wall @TrystanLea good news guys. I made the changes proposed by Robert 4 days ago and have not seen a negative value.

Robert, in short (and newbie english!), what seems to be the issue and how best to avoid it going forwards?

I need more time to check if the PV export in EmonCMS is closer to that the energy retailer sees.

Thanks.

Matt

1 Like
30

I’d suggest @TrystanLea needs to look at reading all the data from one incoming packet of data into a buffer, and then using the buffer as rhe source of data (for inputs), rather than the last value calculated.

Remember there’s a problem!

Long-term, the solution would be for all sensing nodes to get and send the data on demand, then a consistent set of values from all sensors would be available. Until this happens (which might well be never), you need to remember that every calculation uses the most recent data available to it - it can’t look ahead to know the value of something that might have arrived but hasn’t been processed.

31

Robert, thanks and thanks for your help in replicating the issue and suggesting some work arounds.

1 Like
32

@Robert.Wall @TrystanLea update below.

Still no negative values for ‘House Consumption’, which is good news.

Compared my PV export vs my retailer. The EmonCMS is consistently (over 7 days) 97.x% of my retailer, so also happy with that.

Compared my ‘House Consumption’ vs my retailer and EmonCMS is 120-210% of my retailer over 7 days. I’ve added some new logs, straight off the ‘Grid Infeed’ input so it’s just logging, no maths, assuming that the feed will balance out the -ve values due to PV export and the +ve values when I have no PV export.

Will see how we go for another week.

Thanks again.

33

What does your supplier’s meter do when exporting? If it’s ‘Stupid’ and it obeys the same rules as the UK has, it should register import only and ignore export. If however it’s a “Smart” meter, you should have separate registers for import and export.

I’d have expected slightly better than 97.x% with an emonTx4. You can always add a ×1.02 in the input processing to tweak the value to be closer, or if you have on-line calibration of your emonTx4, change that by 2% or so upwards, for that power channel.

34

HI Robert, it’s a smart meter. Yes, it has 2 registers for import and export. There is an app and that is where I sourced my data from.

Thx, I’ll do the on-line calibration later. I would have expected a whole lot more from my set-up, it’s been surprising to say the least.

Matt

35

Is this comparing PV export meter vs a CT on that cable directly? would expect a bit better than that closer to the 1-2%.

Sounds like input processing still not quite right?

36

Trystan, yes, PV export is the CT on the grid infeed cable and only logging -ve values. I’m ok with 97.x% as it’s consistent and probably due to some error in both meters.

Yeah, the input processing is still not right. Even logging +ve values only on the grid infeed isn’t looking good after 2 days, so I’ll go back and check.

I’ll update everyone again in a few days.

Thanks for your help.

Matt

37

@TrystanLea I made the change to emonhub.conf as suggested above and no improvement. Thx.