According to Real Decreto 413/2014:

BOE-A-2014-6123 - ANEXO IV - perfiles horarios para las instalaciones que no cuenten con medida horaria

There is something to review here, probably I've a misunderstanding about the dragging process but can it be a bug.

It seems like the drag_key is defined based on the period of the previous gap iteration (the last gap period for the first iteration).

Could it be that the correct period key to define is the one of the current iteration?

The affected method [suspect line 375]:

Proposal solution:
Assign drag_key before period assignation (to exchange lines 375 and 376)

It's needed to provide a fake 3.X tariff that does not take care about periods definition.

The goal is to integrate all available periods into main P1 period to be able to profile metters with an erroneous configuration.

get_period_by_date doesn't properly identify period due wrong condition or timezone used to identify whether datetime is within interval limits specified by TariffPeriod

example:
date_time, 2016-01-01 12:00:00+01:00
date_time.hour, 12
tariffperiod 20DHA, winter, range_h= P1 (12,22), P2 (0,12),(22,24)

interval condition
range_h[0] < hour <= range_h[1]

P1 12 < 12 <= 22 FALSE
P2 0 < 12 <= 12 TRUE
P2 22< 12 <= 24 FALSE

Some coefficients of RE (solar) are 0 because there are no hours of sunshine. If it happens to have use this coefficient, the value of the measure will be 0

It's needed to implement 3.1A LB profiling process as done previously at ERP side.#

Close via #112

Done via: 9f9a0d7

If we pretend to estimate a profile that it's described just by an alternative period than master (p.e P2), get_estimable_consumption will raise a key error (trying to lookup 'P1' instead of the desired one for this scenario.

Maybe can be interesting to permit this kind of estimation / fixing for non-fully described profiles.

With it, if the profile just have another key than the first one, the estimation can be done taking care about just this/those periods.

It seems that holidays and weekends are not identified as expected.

Enerdata measure for hour X describes the consumption between X-1 and X, i.e measure=5 for datetime $DAY 17:00 describe that between the 4:00 and 4:59 the consumption is 5kWh.

Taking care about this, the holidays identification for the hour 0 of $DAY must analyze if $DAY-1 was a holiday, due to this hour describes the consumption between $D-1 23:00 to $D-1 23:59.

An example is this scenario:

# Weekend 15/02/14
datetime.datetime(2014, 2, 15, 0, 0, tzinfo=<DstTzInfo 'Europe/Madrid' CET+1:00:00 STD>

, that describes the consumption between 14/02/14 23:00 and 23:59.

This hour is not inside the weekend time.

The issue becomes here, where it is identified as weekend due to the global current day reviewing:

Review it and provide a fix

Will be interesting to integrate a way to pass an initial accumulated value to start Dragging.

This will support the profiling of partial time ranges taking care that the first hour will use the rounded accumulated for the previous hour although this is not in current Profile range.

So far if this previous hour is not inside current range, there are no way to take care about it.

Think about to be able to pass an accumulated initial value and initialize the Dragger for the first hour (also take care about the first period to increase just the first hour)

We need to review compatibility of this lib with Python3 (py3.5)

If not, try to identify which changes are needed to provide it.

REE does not consider the epiphany as a holiday.

Here it's used to confirm that the periods assignation is performed as expected based for each tariff:

Review it and provide an alternative date, maybe the All Saints (01/11).

ERP profiling improvements must use an isolated class that inherits from the base one.

The goal is to reach the same profiling functionality, but using a hardcoded Dragger key, to ensure that profiling accumulated energy is passed to the next gap (the next hour).

The base usage must be the same than now

Can be interesting to extend enerdata to integrate get_cof_per_tariff(tariff_name) method?

To reach the cof (A,B,C,D) for a specific tariff name.

If it, I will make the related PR.

ProfileHour must have a new property desired to store the accumulate to apply for the following measure

Add a minimum power test in evaluate_powers function to check that all 3.0A tariffs must be over 15kW

All tariffs specification must be asserted, testing that each hour is identified as the expected period of this tariff.

There can be no energy exported for hours with zero coefficient.
A function that performs a check and identifies the hours of an energy curve that violates this premise must be implemented.

If the balances on 3.1A tariffs energy on P4 is present, this is not correct, enerdata does not treat period 4 that's why it is added to P1

• Temporades
• 6.X

In RE profiling, the coefficients are indicated in solar hours, they must be translated at civil hours according to:

Los valores de las horas que aparecen en las tablas siguientes corresponden al tiempo solar. En el horario de invierno la hora civil corresponde a la hora solar más 1 unidad, y en el horario de verano la hora civil corresponde a la hora solar más 2 unidades. Los cambios de horario de invierno a verano o viceversa coincidirán con la fecha de cambio oficial de hora.

Estimate a negative consumptions.

Now:

>>> res = p.estimation(balance={'P1': -3})
>>> res
0

It's necessary?

As agreed with @ecarreras and @tinogis, Profile.estimate() will drag decimals based on hourly criteria, I mean, each accumulated decimals will passed to next hour independently of the period of both hours.

Review it and provide a fix