48°/1 Gemiddelde maandpiek afname: het rollend gemiddelde van de 12 laatste maandpieken
afname met inachtneming van de minimumwaarde van de maandpiek, zoals gedefinieerd in de
tariefmethodologie, vastgelegd door de VREG. Indien de maandpiek nog niet voor 12 maanden
beschikbaar is, is de gemiddelde maandpiek het gemiddelde sinds de eerste relevante maandpiek
48°/1 Gemiddelde maandpiek afname: het rollend gemiddelde van de 12 laatste maandpieken
afname met inachtneming van de minimumwaarde van de maandpiek, zoals gedefinieerd in de
tariefmethodologie, vastgelegd door de VREG. Indien de maandpiek nog niet voor 12 maanden
beschikbaar is, is de gemiddelde maandpiek het gemiddelde sinds de eerste relevante maandpiek
To avoid misunderstandings, let me summarise:
When you start taking measurements, for the first month the monthly peak and the average monthly peak are identical.
1st monthly peak: a kW ==> average monthly peak: a kW
2nd monthly peak: b kW ==> average monthly peak: (a+b)/2 kW
3rd monthly peak: c kW ==> average monthly peak: (a+b+c)/3 kW
…
12th monthly peak: l kW ==> average monthly peak: (a+b+c+d+e+f+g+h+i+j+k+l)/12 kW
13th monthly peak: m kW ==> average monthly peak: (b+c+d+e+f+g+h+i+j+k+l+m)/12 kW
14th monthly peak: n kW ==> average monthly peak: (c+d+e+f+g+h+i+j+k+l+m+n)/12 kW
…
==> “het rollend gemiddelde van de 12 laatste maanden” or “the rolling average of the last 12 months”
Yes, your summary is correct. (Only the case <2.5kW is missing.)
More formaly: (With the correct terminology.)
The average monthpeak is the rolling average of the available monthpeaks, with a window size of 12. This window size is reduced to the amount of available monthpeaks if there are less than 12 monthpeaks available.
Pay attention to:
If an available monthpeak is less than 2.5kW, you must use a value of 2.5kW to represent that monthpeak in the calculations of the average monthpeak.
(Technically the monthpeak itself remains on its original value of less than 2.5kW.This might become relevant if the minimum value of 2.5kW in use today is changed (lowered) in the future. Today’s value was actualy determined by other net usage information and it can be reviewed and changed in the future if required.)
Also:
It doesn’t matter when “you” start taking measurements, but when the network operator starts.
Today, monthpeaks are only relevant for consumption, not injection. However, if deemed necessary, this could change in the future so injection might then also be subject to a similar calculation (which might employ different numerical values).
It is unclear (not defined) what happens when you move to a different location within the geographical area where this capacitytarif is applicable, or when the legal owner of the electricitycontract is changed without moving. (Will the previous monthpeaks of the legal contractowner be used? Will the previous monthpeaks of the meter be used? Will you start again with no available monthpeaks?)
I’m trying to understand following in the automation ‘Maximum maandpiek’
If the first condition fails and failing means that the monthly peak is < 2.5 kW (2.5 kW is the minimum value of the input_number january in this example)
all the next steps are not done?
If so, the input_number.max_peak_2 is never reset and remains with his value.
February will then start with the value of the previous month in input_number.max_peak_2??
I’m trying to set up something similar. The difference for me is that my monthly rate is calculated from the 5 highest hourly energy use figures each month. Any good ideas how I might achieve that? I’ve successfully set up @gieljnssns’s configuration so far, yet that obviously onnly gets me the single highest figure for the month.
Could somebody help me in the right direction? I’m trying to use the utility_meter with cycle string: quarter-hourly but I’m not getting the right result. I’m fairly new at this so cut me some slack
cycle string (Optional)
How often to reset the counter. Valid values are quarter-hourly, hourly, daily, weekly, monthly, bimonthly, quarterly and yearly. Cycle value bimonthly will reset the counter once in two months.
I’ve added the following to allow me to be able to measure the “kwartuurpiek”.
However, the sensor seems to add up consumed power instead of just measuring. Thereafter I changed the kind of measurement in ‘entity customization’ into ‘measurement’ instead of ‘total increasing’ because the entity doesn’t have a unique ID (because it was added in YAML.). But this doesn’t change its behaviour.
This entity (‘sensor.energy’) does not have a unique ID, therefore its settings cannot be managed from the UI. See the documentation for more detail.
You can overwrite some attributes in the [entity customisations] section.
Because I needed the ‘mean’ value I added statistics sensor. Normally this should already give the mean value
The statistics sensor platform consumes the state from other sensors. It exports the mean value as state and the following values as attributes: count, mean, median, quantiles, standard_deviation, variance, total, min_value, max_value, min_age, max_age, change, average_change and change_rate. If the source is a binary sensor then only state changes are counted.
Am I approaching this all wrong? What do I need to change in order for this to work? Also am I missing something? Do I need to multiply the value?
@Giovanni85, I’m trying to understand your post, but have difficulty to follow you.
I imagine that this sensor, in his raw value, is giving you the actual power consumption (W or kW) of your installation? This value is the real-time power consumption from the grid, correct?
Be careful if you have solar panels! You must only have the grid consumption!
This value must be converted to kWh (kilo-watt-hour), the number of kW per hour.
For this you can use the Riemann sum integration from HA.
### creat quarterhour utility_meter from the riemann sum sensor.smappeemqtt_grid_afname_kwh
smappeemqtt_quarterhour_gridenergy:
source: sensor.smappeemqtt_grid_afname_kwh
cycle: quarter-hourly
Now you can follow 2 ways for the calculation of the average peak power per quarter.
via a template sensor
- platform: template
sensors:
### create from the utility_meter sensor the average peakpower per quarterhour ###
smappeemqtt_quarterhour_grid_averagepeakpower:
value_template: "{{ states('sensor.smappeemqtt_quarterhour_gridenergy')|float * 4 }}"
unit_of_measurement: "kW"
icon_template: mdi:calculator
friendly_name: "Gemiddeld piekvermogen per kwartier"
I have solar panels and to answer your question: sensor.p1_meter_active_power gives the grid consumption (positive number) and grid injection (negative number). This in fact works very well in Grafana.
Thank you for your help, I’ll take a look at it tomorrow when I’m back clearheaded, which isn’t the case at the moment
Yes, you should use the sensor p1_meter_active_power as starting point.
If this sensor can be positive (grid consumption) and negative (solar production), then you must convert it to get only the positive part and 0 if it is negative.
This new sensor is then the starting point for the Riemann sum integration.
I have two sensors, giving me the production of solar power and the current consumption of the house. Via a template sensor, I get a new sensor.smappeemqtt_grid_consumption.
This sensor is then used in the Riemann sum integration.
Dear can you please provide the full/complete config yaml for the first option/ way to calculate the piek consumption. Whatever I adjusted in the coding it keeps giving errors or HA refuses to restart ….
Hi @ew-ewim, what are the errors you get when restarting or checking your config?
My config is spread over several configuration files. The code in my topic above is a copy-paste from these files, so the syntax must be correct.
So let start with the error messages you get when checking the configuration. Please post the complete error here.
In which version of HA are you working?
Dear Evb, tx for your reaction and reaching out. Seams that I took your instructions literally and added them as posted and sequentially in the config yaml. Forgot to add the avg peak cons/quarter to the sensors defined. Seems Ok now.
Another question however: on your implementation I am missing the history of the avg peak cons/quarter opposed to the solution of Giel?
