Evolve sensor attributes for new tariff 2.0TD

[azogue]

cc @pove

closes #19

Changes:

• Determine tariff period (P1/P2/P3) for current hour, and calculate the delta hours to the next one, publishing attributes period, next_period, and hours_to_next_period
• Add price_ratio (value in [0,1] interval showing ~percentile position of current price), max_price, and max_price_at attributes
• Add price_position attribute (1 for cheaper price, 24 for the most high-priced), as suggested by @r-jordan in #23
• When there are cheaper prices ahead, add attributes next_better_price, hours_to_better_price, and num_better_prices_ahead
• Add contracted power in kW as new parameters (power for P1/P2 and power for P3) to show the available_power for each period
• Use holidays library to retrieve national holidays where to apply the valley period P3 for the full day

[codecov-commenter]

Codecov Report

Merging #21 (e5b84d9) into master (9b38c02) will increase coverage by 1.57%. The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           master       #21      +/-   ##
===========================================
+ Coverage   98.42%   100.00%   +1.57%     
===========================================
  Files           3         4       +1     
  Lines         190       234      +44     
  Branches       36        41       +5     
===========================================
+ Hits          187       234      +47     
+ Misses          2         0       -2     
+ Partials        1         0       -1     

Impacted Files	Coverage Δ
aiopvpc/__init__.py	100.00% <100.00%> (ø)
aiopvpc/const.py	100.00% <100.00%> (ø)
aiopvpc/pvpc_data.py	100.00% <100.00%> (ø)
aiopvpc/pvpc_download.py	100.00% <100.00%> (+10.00%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 9b38c02...e5b84d9. Read the comment docs.

[pove]

Hola de nuevo. He visto que has mandado un pull para corregir la propia librería de Holidays de Python, porque no incluía el Viernes Santo. Pero después de ver la lista de fechas, veo que este año sobra el 16 de agosto, mostrado como "Asunción de la Virgen (Trasladado)", lo puedes comprobar en el BOE.

[azogue]

Hola @pove,

He visto que has mandado un pull para corregir la propia librería de Holidays de Python, porque no incluía el Viernes Santo.

Sí, aunque todavía no tengo claro si usarla aquí, ya que, según la redacción del texto del BOE, no tengo claro si, precisamente, el próximo viernes santo tendrá tarifa P3... ya que se habla de festivos de fecha fija, y la pascua no lo es.

Si al final son sólo los días fijos, supongo q eliminaré la dependencia :)

Pero después de ver la lista de fechas, veo que este año sobra el 16 de agosto, mostrado como "Asunción de la Virgen (Trasladado)"

El observed=False de la expresión holidays.Spain(observed=False, years=day.year) evita ese tipo de traslados indeseados 👍

[r-jordan]

Buenas @azogue ,

Tengo una sugerencia para un nuevo atributo que ya utilizo desde hace tiempo en HA con un sensor template. Se trata de conocer en qué posición de los precios ordenados se encuentra el precio actual. También se puede entender como el número de precios que hay por debajo del actual en el periodo de 24 horas. Con este dato se pueden programar dispositivos para que estén encendidos durante las horas más baratas.

Yo lo tengo programado así en HA:

- platform: template                                                        
  sensors:                                                    
    electricity_number_of_cheaper_hours:   
      unit_of_measurement: 'hour'          
      value_template: >                    
        {% set price = states("sensor.pvpc")|float %}                            
        {% set ns = namespace(number=0) %}           
        {% if now().hour<21 %}                       
          {% for hour in range(0,24) %}              
            {% set price_next = state_attr("sensor.pvpc",'price_%02ih'%hour)|float %}            
            {% if price_next>0 and price_next<price %}                               
              {% set ns.number = ns.number+1 %}                                      
            {% endif %}                                                              
          {% endfor %}                                                                                              
        {% else %}                                                                   
          {% for hour in range(now().hour,24) %}                                     
            {% set price_next = state_attr("sensor.pvpc",'price_%02ih'%hour)|float %}                                
            {% if price_next>0 and price_next<price %}                               
              {% set ns.number = ns.number+1 %}                                      
            {% endif %}                                                              
          {% endfor %}                                                               
          {% for hour in range(0,now().hour) %}                                      
            {% set price_next = state_attr("sensor.pvpc",'price_next_day_%02ih'%hour)|float %}
            {% if price_next>0 and price_next<price %}                                        
              {% set ns.number = ns.number+1 %}                                               
            {% endif %}                                                                       
          {% endfor %}                                                                        
        {% endif %}                                                                           
        {{ ns.number }}            

Si fuera posible programarlo dentro de la librería pues sería genial. Además, en python será mas sencillo sobretodo teniendo ya los precios ordenados en un diccionario... :thinking:

Con este sensor el automatismo es tan fácil como observar cuando el valor baja del número de horas que deseas tener el dispositivo encendido. Espero que compartir este conocimiento sea útil para la comunidad :smile:

Saludos, Raúl.

[azogue]

Hola @r-jordan,

Se trata de conocer en qué posición de los precios ordenados se encuentra el precio actual. También se puede entender como el número de precios que hay por debajo del actual en el periodo de 24 horas.

En este PR ya hay un nuevo atributo price_ratio que te da el valor del precio actual en comparación al resto, en tanto por 1, pero mirando el valor del precio, más que el nº de precios arriba o abajo: Ejs,

• price_ratio=0.5 implica que el precio actual es exactamente el precio medio diario
• price_ratio=0.0 implica precio actual = precio mínimo diario
• price_ratio=1.0 implica precio actual = precio máximo diario Para automatizaciones, price_ratio <= 0.3 se cumple para todas las horas donde el precio cae en la banda del 30% + barato, y así...

Si no me equivoco, lo que tú sugieres es en esencia ~ lo mismo, sólo que usando el orden, en plan: este precio es el nº 5 más barato (hay 4 + baratos y 19 + caros)... ¿es eso? ¿la posición del precio actual sobre los precios del día?

[r-jordan]

En este PR ya hay un nuevo atributo price_ratio que te da el valor del precio actual en comparación al resto, en tanto por 1,

Sí, ya vi el atributo price_ratio. También lo tengo programado en HA con otro sensor de tipo template pero no lo estoy usando prácticamente para automatismos.

Si no me equivoco, lo que tú sugieres es en esencia ~ lo mismo, sólo que usando el orden, en plan: este precio es el nº 5 más barato (hay 4 + baratos y 19 + caros)... ¿es eso? ¿la posición del precio actual sobre los precios del día?

Exacto, eso es.

Creo que es muy útil porque es más fácil acertar cuanto tiempo va a estar encendido un dispositivo con un automatismo. Por ejemplo, si un termo necesita tres horas para calentarse puedes hacer que se encienda las tres horas más baratas. En cambio con un mismo ratio puede ser que se encienda todas las horas valle o solo una dependiendo de la distribución de precios de cada día.