[FR]: mean tariff 3.0 based on time

[affer]

Describe the feature you wish to make a request for

add 3 more avg calculations based on time and tariff 3.0 and include this
mean of lavtariff 00-06
mean of hojtariff 06-17 and 21-00
mean of spidstarif 17-21

i know one should include tariff for this to have the most usable use.

people can use it to see daily tariff mean prices.. example: is hojtariff almost the same as spidstarif, then u can choose when to use power.

or if you have pv system with solar, u can see how much cheaper it is to charge battery at night.

Example, today 3 jan 2024 (with my tariff, afgift etc)
mean lavtariff is 167 øre per kWh
mean hojtariff is 236 øre per kWh
mean spidstariff is 354 øre per kWh

by looking at this, i can see a cost reduction from low ro spids on almost 200 øre per kWh, making my choice to do laundry at night even easier, or now that i saved almost 200 øre per kWh by charging my battery at night.

or if i know the mean price of above, it could be easy to make a logic that charge battery.. ie if spids is 100% higher, charge batteries..

Describe alternatives you've considered

ofcause the EDS service provides all hours and then one could make own calculation, but i have a feeling that this could be used by several people.

Additional context

No response

[henriklund]

Knowing this is an 'oldie', I do hope you have found another solution than what was suggest.

If I look at the data I have collected over for pricing, the proposed average calculation will provide little benefit. Please note that the data below is pricing based on my electricity agreement and tariffs (and any deductions I may have).

First of all, the load periods are defined to incentivize the consumer to move their consumption from Peak to Low. Consequently the gut feeling is that Peak should be most expensive and Low least expensive. Secondly, the periods that are proposed averaged are of such a length (specifically High) that I would not recommend using them for comparison. E.g. Dec. 7th 2024, the avg. for Low load was DKK 1,95 whereas av. for High was DKK 1,65. Thus looking at avg. alone the period 06-17 and 21-00 is cheapest. However, looking at an avg. for 6 hrs (same duration as 00-06), the avg. 06-12 would be DKK 2,11, whereas 11-17 would be 1,50. It thus makes a huge difference how much you intend to consume and when you place it. Average is simply to coarse.

If I plot data from early September until today into a graph, I can get three curves for the avg. Low, High and Peak load that resembles following:

As can be seen, for the majority of days, avg. pricing for load points at Peak > High > Low. Of course, the are outliers. These are:

• one day where avg. Peak was cheapest (DKK 1,85 vs Low at DKK 2,33),
• 17 days where avg. High load period was cheapest
• two days excluded for lack of sufficient data

What I would suggest is to use something like this to find a cheapest period rather than a simple average. For myself, I have two sensors calculating the X cheapest / most expensive hours within the next Y hours. Sensor input is obtained from other entities and the sensor output used both in a dashboard and in a graph (Plotly):

In a nutshell; I do not think the feature request is viable nor that any real benefit may come from its implementation.

[MTrab]

You mean lile this?
#35 (comment)

[henriklund]

@MTrab, yearh. Mine covers a few additional use cases, but your script will def. work far better than a simple 'let us average Low /High / Peak.