What might cause >12kW spikes?

Newby oem/Emoncms user with first post so please make allowances!

I have just set up a simple system with an emonTx transmitting PV output on input 4 and house use (Combined from 2 consumer units using 2 CTs in parallel) on input 1. No solar diverter (yet) and only a kettle approaching 3 kw rating.

I did extensive calibration on each CT individually, and the ones in parallel, using the readout from the PV inverter as a reference during the recent sunny weather.

I’m expecting to get some spikes - from 2 freezers and 2 fridges, iron, etc - and can see these on the traces but I cannot explain the occasional spike I’m getting of over 12 kW.

I can’t find any topics specifically relating to such high random instantaneous readings so am hoping someone can point me towards the reason I’m getting them.

PS emonTx offline around 12.30-13.30 whilst I mounted in final location.

Thanks for any help you can give.

Welcome, Gordon.

In short, you have a rather unusual problem.

I don’t think it can be spurious data getting into the path from your emonTx to the (presumably, you don’t say) emonBase.

You can get large spikes if you earth the c.t. input. That’s due to the input seeing a 1.65 V step as the input level suddenly changes. Could that be a possibility, as it’s on the input with the two paralleled c.t’s?

If that can be ruled out, I think it has to be another sort of interference picked up by the analogue department of the emonTx. There are two ways it could be getting in, either via one of the current inputs, or via the voltage input, or (if you’re using a 5 V USB power pack) the 5 V USB power supply. Or it could be a combination of these.

Is it possible that you have a neighbour who is switching a large electrical machine, and that’s causing spikes on the mains supply?

1 Like

I see big spikes on my EmonTX when I use the induction hob of up to 6500W. Do I remember correctly that this is a feature of induction and how the energy used is measured @Robert.Wall?

Many loads exhibit inrush. This is where the current required to start up is greater than the running current. The magnitude - normally expressed as a percentage of the normal running load - depends on what the load is, and there are only ‘rules of thumb’ that will give a guide. One of the major factors that also influences the magnitude of the inrush is where you catch it on the mains cycle.

For a tungsten lamp, the inrush is normally about 12 - 13 times the normal running current on the first few half-cycles, and drops rapidly as the filament goes from ambient to its normal temperature of around 2800 °C. This is entirely down to the resistance increasing by the same ratio. A transformer can be broadly similar as the flux is established in the core. An induction motor will normally be less than this, a few times running current, but it can take a lot longer to fall to the running current.

But coming back to the original problem, unless there’s a highly reactive load being switched, and the maximum load mentioned is a kettle (which should have almost no inrush - maybe the current falls by a few percent as the element heats up) then I think it’s probably not inrush that Gordon is seeing.

That only two spikes have been seen could be misleading, remember that the standard emonTx sketch samples for 200 ms every 10 s, so all you can say with certainty is two 12 kW spikes were captured. The might have been many more that fell into the 9.8 s gap between samples and went unrecorded.

It might be interesting to transfer the c.t. from the line conductor to the neutral (facing the other way, of course). If it’s a voltage spike that’s being picked up by capacitance between the cable and the c.t. secondary winding (I believe there’s no electrostatic screen), then that spike is less likely to be on the neutral - but I can’t guarantee that.


Thank you @Robert.Wall and @borpin for replying to my post.

I’m sending directly to from the EmonTX to Emoncms, specifically to keep things simple (I’m a mechanical engineer so can only measure things in buckets).

I’m pretty sure the CTs’ wiring is sound but they are wired, per the Openenergymonitor instructions, on 3 pole jack plugs and on occasion I have found a plug not fully home. So you’ve raised in my mind the possibility that these spikes could be when a plug has been re-seated.

On the day the trace relates to I minimised the number of electrical appliances - we have a gas cooker & hob - and switched the central heating and HW off.

Interestingly today’s peaks have been just over 4KW attributable to kettle on both occasions.

Either way, further monitoring required with the benefit of some acquired knowledge.

Again, many thanks


Although I think it’s a safe bet that reseating the plugs would explain the spikes, for the record, how does the data get to emoncms, and which one?

There’s emoncms.org, but to get the data there you need either the EmonESP or the emonBase (Raspberry Pi + radio module) or an emonPi; or you can run your own emoncms on your own server (which could also be a Raspberry Pi).

And I wouldn’t totally discount your gas cooker and hob - if it has spark ignition, that is.


Would you credit it? Just as I posted that spikes had not happened today I got one, interestingly at 19.00ish (same time as several occured yesterday) and I was nowhere near the EmonTX - I was posting here. So maybe its an external factor as suggested.

I’m sending data to emoncms.org - using the EmonTX, fitted with the Huzzah WiFi module - using the guide.

It was straightforward and has been very reliable, thus far.

I have to say I’ve been most impressed by the Openenergymonitor/Emoncms set up. Back around 2012 I built a HW diverter, based around a Nanode (Arduino clone), using a lot of Openenergymonitor help with programming & logic. That device has served me well but does not work off grid current so will not interface with a smart EV charger, such as Zappi. I can’t face re-learning / reprogramming so will be replacing it with a proprietary diverter. Anyway, today’s Openenergymonitor/Emoncms sites are a credit to the obvious hard work of enthusiasts over the years and a big improvement on 2012.

Yes I would. :wink: Interference like this can be a real nightmare to solve, and you may never know the cause.

OK, that leaves me more or less certain that it’s truly electrical in nature and not a programming fault.

You could look at Robin Emley’s diverter: https://mk2pvrouter.co.uk - developed here.

1 Like