Seemingly big discrepency between EmonTx4 and SDM120M measurements

So after moving my EmonTx4 to my EmonHP, I seem to be noticing a large discrepency between the power usage of the DB/CU the ASHP is connected to, vs what the SDM120M for the ASHP is suggesting.

L3 → DB3 → EM1

Most of L3 going to DB3 makes sense; the other things attached are an AC unit that is obviously not doing anything, and a 32A commando that isn’t doing anything either.

And similarly, most of the usage from DB3 will be the ASHP. The rest are very low usage, though some usage of the immersion overnight to finish the hot water cycle (and EM2 shows that).

The fact the EM1 seems to be reporting a value that is over 50% higher seems to suggest something is off. There’s no way the ASHP can have used more energy than the entire phase etc.

I haven’t dug much, but it doesn’t look like (unless I measure it myself on HA) the Sigenergy kit will show you usage by phase…

If it was a few % discrepency, I obviously wouldn’t really care. Just with it being so big.

Any obvious answers of where to look as to why these numbers might apparently be so far out?

Hello @reedy could the calibration for that CT have changed? does it show a step change on the data?

Needing the USB C connector the “right” way up will always get you…

Windows laptop (or two) didn’t want to work with it.. Booted up the emonpi as it was next to it, that didn’t work… Oh, flip the USB C… Probably will work on the laptop in that case too.

L3 is CT 3, DB3 is then CT9… Those numbers make sense.

Check the SDM for the ASHP a few seconds later, it’s showing as 642.3W, again, that seems reasonable. It’s obviously moving around a little, but it seems to be within range.

I suspect this is actually the answer though…

I notice that the electric_Energy is being used to calculate the numbers for the ASHP usage (ie what you guys setup), but I’m (for whatever reason, noting I set it up) am actually using P1-12 not E1-12 to do the numbers…

1 Like

emonTx 3phase — OpenEnergyMonitor 0.0.1 documentation seems to show using the power though…

But then as I’ve set it up:

I guess this wasn’t clear – I’m not saying it “worked fine before”, just putting it on my emonHP, I then integrated that data into HA, so it was very visible.

So I flipped it for that specific path, and after some DHW has gone through, the board is saying it’s used 3kWh and 2.2kWh specifically for the heatpump.

Give it overnight and see how the numbers look, and if it makes sense, shift the rest over.

So something isn’t right here now either…

There’s no way it’s done 90+kWh in a day (because the house hasn’t)…

Are you sure you know what the P and E numbers out of your emonTx4 represent?
I have only quickly scanned the thread, and I don’t know your abbreviations, but at first glance – are you trying integrate Wh (already energy) into energy again?

Hello @reedy I’ve had a quick look at your emoncms.org account and the setup looks ok there apart from the immersion heater feed which I’ve now fixed (selected it separately).

electric_Power is configured there for heatpump_elec (power in watts) and electric_Energy (log to feed join) = cumulative kwh feed. We dont usually configure local feeds only feeds on emoncms.org.

Which EmonTx4 CT is your heat pump power? Do you want me to configure your emonTx4 feeds on emoncms.org? I would just add log to feed on all the power inputs: P1,P2,P3.. etc and also power_to_kWh on those power feeds. The energy feeds E1,E2,E3 etc should only have “log to feed join” processes attached if your using those.

Which… Is what I had originally on that DB feed before the SDM?

With the kWhd too because that’s mostly what I care about for the export to HA - how many kWh has been used in a day.

And what was showing the difference between the SDM and the CT on the connection to the DB it was in?

As per the screenshot in Seemingly big discrepency between EmonTx4 and SDM120M measurements - #5 by reedy showing those (though for P1; I’d done it for all the feeds I had CT attached to).

Certainly possible I’m missing something very obvious…

Nope!

There’s some amount of “error carried forward” – I suspect I originally set this up based on whatever I’d had on my old emonpi (which was done from some documentation that probably doesn’t exist anymore), and the data differences only becoming more apparent as I’m actually integrating the usage of that data into other places, and seeing numbers that don’t make sense – a device upstream can’t have used a lot more/less than a advice downstream etc.

While there’s reasons you may want to do some weird things, maybe emoncms should give the users some more feedback if they’re trying to feed something that is (seemingly) of the wrong source into a processor that is going to do something that will almost certainly result in something that makes little to no sense!

Along with more contextual information about data sources? Especially for emon* devices that should be more known, and already have an amount of integration to begin with!

OK. Lets make a start.
P stands for the power being measured. This what your immersion heater, electric kettle or heat pump is defined by, and it is measured in watts, or a multiple thereof.
E stand for energy. This the amount of power over a period of time, and it is what you pay for. A 3 kW immersion heater run for 2 hours will consume 3 kW × 2 h = 6 kWh.

Your emonTx actually gives you the average power over the 9.8 seconds between reports, it also multiplies those averages by the time and adds them together and sends out a gradually increasing energy value (if you are consuming power, it decreases if you are exporting power). These are the P and E values you see coming in to emonCMS on the inputs page.

OK so far?

When you process the inputs, and because the old emonTx V2 and emonLib didn’t have the ability to accumulate the energy as it went along, Trystan helpfully included it in emonCMS in the form of the process step Power to kWh. This does exactly the same sum as your emonTx4 does, it takes the number you give it, which should be the power - like it says in the name, and multiplies it by the Feed Interval to give you units of power × time, which is energy.

Still OK?

So what happens if you give Power to kWh an energy instead of a power? it cannot know the difference because it only sees the numbers, there are no units attached, and it doesn’t know where they came from. So it does as it’s told and multiplies each energy by the time interval. The energy, which is already increasing anyway, gets bigger again. Which is wrong.

What you must to do.
Look at the units of the quantity you are processing. If it is a power and you want an energy (watts and you want kWh), then as Trystan says, use Power to kWh. If it is an energy and you want an energy, do nothing - or essentially nothing. Again as Trystan says, use the Wh Accumulator. This really only tidies up the data when something goes wrong. Quoting the help text of the Input process…

Use with emontx, emonth or emonpi pulsecount or an emontx running firmware emonTxV3_4_continuous_kwhtotals sending cumulative watt hours.

This processor ensures that when the emontx is reset the watt hour count in emoncms does not reset, it also checks filter’s out spikes in energy use that are larger than a max power threshold set in the processor, assuming these are error’s, the max power threshold is set to 60 kW.

So go through your process steps, and make sure you are using the correct steps with the correct input.

And finally, you may ask why did we add the energy values at source in the emonTx4? If the radio link fails, you lose the power information so you can’t continue accumulating the total energy. If you have it twice by the time you are inside emonCMS, you have a choice or a backup.

1 Like

Do you mean the data from the TX4 is now being processed by the emoncms instance on the emonHP?

Because Trystan seems to say (post no. 10) he edited it, it looks like that is a yes. However, as far as I know, the input processing steps remain the same in both Heat Pump and ‘ordinary’ versions of emonCMS. So all I wrote above (post no. 12) still applies.

1 Like