Community
OpenEnergyMonitor

OpenEnergyMonitor Community

Calculate quarter-hour peak in kW

I would like to calculate the quarter-hour peak in kW of my imported electricity. Eg:

  • 19.15 u. : 4511,123 kWh
  • 19.30 u. : 4511,623 kWh → 0,500 kWh, which is 0,500 kWh / 0,25 h = 0,500 * 4 = 2,0 kW
  • 19.45 u. : 4512,248 kWh → 0,625 kWh, which is 0,625 kWh / 0,25 h = 0,500 * 4 = 2,5 kW

Is this possible with Emoncms? I have a SDM630 installed and can read its registers with modbus, eg. register 72 can read ‘Total Import kWh’ (see page 2 of the SDM630_MODBUS_Protocol.pdf). I already have this one as input in emoncms (namely EI = Energy imported) and I log this one. But maybe another register is more suited?

The reason is that billing will change in Belgium. Some part of the price will be related to the quarter-hour peak in kW. The reason is that a grid can’t be build for the average demand, but should be build for some peak demand. If I plug in an BEV, cook, use the dishwasher, … all at once, it will cost me more than plugging in one after the other.

The highest quarter-hour peak in kW per month will be logged by the ‘smart meter’ (at the moment I still have my analog Ferraris meter). The 12 month quarter-hour peaks will be averaged and that value will be used for the billing. And that is the reason I would like to know them, so that I can learn what ‘activities’ cause a high peak.

Perhaps register 84, Total system power demand
or
register 86, Maximum total system power demand?

Wow, that is interesting.

My initial thought is that if you have appliances with high startup draw (a big motor on a compressor for instance), this could really hammer you cost wise.

@Robert.Wall is this something a modified EmonTX sketch could monitor and measure? (as you know I am ignorant on all things related to measuring power). Is there another way to measure max power draw?

It shouldn’t be very difficult to implement that in an emonTx, but I didn’t suggest it because @m2ts specifically wants to calculate it in emonCMS, and similarly but in my case, it’s the internals of emonCMS that I’m (mostly) ignorant about.

Plus, we don’t know that he has an emonTx.

@m2ts:

What you have written in the thread title is not the same as what you have presented using the numbers.

If your requirement is for what I would call the quarter-hour average maximum demand, then it’s relatively simple to do in the emonTx sketch. The sketch would need to accumulate the kWh values reported by emonLibCM (which you must use, in order not to miss the peak completely) over the quarter-hour period and average those, and report them to emonCMS. And the easy way to do that is to make the emonTx two Nodes, so the first NodeID reports the standard values every 10 s, the second reports every 15 minutes (and our RFM library can do that, or the standard serial interfacer; NOT the “EmonHubTx3eInterfacer”).
EmonLibCM could in theory report every 15 minutes, but there’s a danger that the internal variables could overflow - it was designed for and tested up to 5 minutes reporting interval.

If your requirement is exactly according to the thread title, then we need to know what is the averaging time that the meter will use? if it is the peak over 1 cycle (the practical minimum), then that’s quite unfair because a normal refrigerator draws a peak of something like five to ten times the running current for a few cycles on starting - it’s called “inrush” and it’s perfectly normal and largely harmless (to the system, because it’s of such short duration, though it can make a lamp flicker). I would think that you would need an averaging time at least an order of magnitude larger than an inrush peak, and I’d refer you to a recent post PV and night tariff + EV and immersion heater - #24 by dBC that indicates one specific type of meter works on a 1 second cycle. If your meter is the same, then you’d need to set that to report to the sketch every second, which it’s quite capable of doing, the sketch will need to record the maximum power and report that every quarter-hour, in the meantime accumulate those 1 s values and report the 10 s average values as normal.

This is not a completely new concept, when I was an apprentice 50 years ago, the firm I worked for was making a controller that could turn off non-essential loads if the half-hour average demand was predicted to exceed a set value - and this was using analogue electronics.

I think it’s that, after reading this this link. So @m2ts’s example maths is headed in the right direction. So as you suggest, if you gather the 15-min-average-power readings, you then just need to keep track of the highest one seen so far this month, then start looking for a new maximum next month.

With regards @Bill.Thomson’s suggestion, I see your meter does allow you to set the demand period to 15 mins (see the Demand Period register at address 40003), so it may be it’ll do what you need. I suspect your 15 min window will need to be aligned with your provider’s though, to get the same results. I guess they do it by the wall clock on the 15-minute boundary as per your example. You might need to do some controlled load experiments with the SDM630 to see exactly how it works.

Good

Yes but…

True, I was asking if it was possible…

I think it is specifically Max Power in each quarter hour - not max energy. I found this in a thread on Home Assistant forum on the same subject. Wat verandert er? | VREG. Explains it pretty well including this -

“The capacity tariff is charged on the basis of the ‘average monthly peak’ (kW)”

I would postulate that this is impossible to currently get from EmonCMS as a very short, high power demand, would be averaged out under the current circumstances.

Could the EmonTX put out the max value for each reading period as a separate element, so the CT1MaxkW? If so, then Emoncms could do the hard lifting to calculate the average over what ever period is required.

Except everyone is basically the same.

Unless everything comes on at the same time I would guess.

As a slight aside, I wonder if something could appear on the consumer market that would flatten those peaks?

By definition, maximum demand is a power, not an energy.

I don’t think I mentioned energy except in the context that any digital metering system (emonLib, emonLibCM, all the energy monitoring i.c’s) measures instantaneous power and assumes that applies for a fixed and very small time interval, so it can treat it as a quantum of energy. It then accumulates those quanta, only dividing by time to get back to an average power to report that. So in fact the emonTx - or emonCMS - would need to record the energy over the quarter-hour averaging period and divide by time to get the quarter-hour average maximum demand figure.

So the problem with emonCMS, as I see it, is simply that there isn’t a process presently available to calculate maximum demand over a given interval. If that were available, the output could be logged and examined exactly like any other variable.

Yes, it’s called a battery and an inverter. Or a synchronous machine equipped with a very large flywheel. Both are an energy store, one converts electrical energy to chemical energy and back again, the other to mechanical. In fact, you’re touching on a problem for the grid controllers: there’s now a lot more generation than there used to be that hasn’t got the stability that a lot of large spinning turbines and generators provides.

If you are referring to the inrush peaks, then yes.
There is a device for electric motors called a soft-starter, that deals with that issue.

Ref:

Is that not what I said?

Key bit is the EmonLibs measure instantaneous power so the sketch could record the max instantaneous power value seen during the recording period (same period as the power accumulation is done over).

No, because the user need max power not energy. this can be recorded each reporting cycle (i.e. what was the max instantaneous power seen in this period).

Emoncms could then take those figures and calculate the max, mean, SD or whatever is needed (and yes it might be a new process is required).

Key thing here is the EmonTX could provide the data quite easily and I expect few other devices could.

I was wondering if there would be something you plugged your washing machine or fridge into (like an extension lead) that could do it. Presumably it is just a big capacitor? Perhaps this would be an incentive for manufacturers to build it into their products - reduce inrush load - reduce cost of electricity supply.

Typically, demand is an issue industrial ot commerical users have to deal with.
In general the residential electrical customer doesn’t, but as we’ve seen in m2ts’s case,
it does happen.

The soft starters are typically found in an environment with large motors.

AFAIK, there’s nothing on the market for use with typical household devices.

It’s a bit more than just a capacitor. The link above describes some of the devices typically used.

Looks like everyone in Belgium will!

My though was that if it makes sufficient difference in cost, they might appear and manufacturers might build them in.

which is why i mentioned

Generally, small devices like a fridge or washing machine don’t place much of a demand on the electrical grid, so there’s not really a need for them. Soft-starters would make things last longer
simply because starting a motor slowly vice nearly instantly would be easier on the mechanical
parts of an appliance. But, from what I understand, soft-starters aren’t cheap.

We are way OT here but it will come down to the economics. Of course one way would be to regulate and reduce the load, however, if you have a home fast charger, your fridge will be the least of your problems unless there is a TOU tariff for power as well as energy.

Compared to a fully controlled variable speed drive, they are. Hence their popularity with the very common industrial induction motor. But in absolute terms, they aren’t cheap enough for the consumer market.

1 Like

VSD. Ouch!

Yes. Tnx for the much improved explanation. That was essentially what I meant.
Just didn’t say it right. But you did. :wink:

I realize the OP asked how could this be done in emonCMS, but what I don’t understand is why hasn’t it been suggested to m2ts that his meter is capable of doing what he wants, and go that route instead of trying to do it inside of emonCMS.

From his question But maybe another register is more suited?
It sounds like he may be a bit lost/confused.

The Total System Power might return it - the use of Total does not seem to be right but that could be a translation error. It is the only one in Watts (without a footnote).

Looking back at the top post, there are several steps involved:

  1. Obtain the average demand over a quarter-hour period.
  2. Detect and retain the maximum of those each month.
  3. Average the 12 monthly maxima to give a “annual average maximum”.

I can see the meter / emonTx being able to do the first, but surely the implied knowledge of dates means that emonCMS must be needed for steps 2 & 3.

Unless there’s something seriously wrong with my maths, the average of the monthly maxima won’t be the same as the average of all the quarter-hourly maxima; and I suspect that’s what you might end up with unless you know the full details of the calculations that a meter is doing. Unless of course it’s programmed to do exactly that for the Belgian market.

According to the docs he linked to, that value is the sum of all three phases as measured by the meter
The demand register is what he needs to use. The docs say it can be set for an interval of
15 minutes. He’d need to know the type of interval his supplier uses e.g. block, rollng, sliding and as Robert mentined, the market details.