ESIOS REE Integration (Spain National Network of Electricity)

Well, in Spain there are three principal rates [Default, DHA (2 periods) and Electric Vehicle (3 periods)] and a hourly prize change on regulated pricing. Also it is available a public API, that you can consult here and the API documentation, also there. You have to request your personal token via [email protected]

Now, HA has a current integration from ComED very similar in fuctions, but I have no idea how to do it (I should study Python :sweat_smile:). Also the user @azogue built a web scraper already in Python here, I don’t know if he uses the forum.

Hi there @nelbu,

The web scrapper is so old and not the best approach to get those prices.

A year ago I did another one as custom_component for HA, and it’s working for me without problems. I had the intention to make a PR but didn’t had the time :frowning:

I hope in next 2 weeks I will have some chance to do it :wink: (I need to update my HA first!)

From my current HA:

with config:

sensor:
  - platform: elecprice_spain_pvpc
    electric_rate: discriminacion
    timeout: 20

And I think I’m not using the esios token to access that information, not sure right now.

If you want to try my current implementation (dirty but functional), you can place the elecprice_spain_pvpc folder in custom_components folder in HA config (create it if you don’t have any yet)

4 Likes

Wow, that works really great! I hope you can find time to make a PR!

Thank you for your amazing work, azogue. Specially this days with really low rates thanks to Daniel and Elsa… :rofl:

1 Like

Lo he probado y está genial. Como sugerencia, sería crear un atributo que indique la hora más barata, así se podrían hacer automatizaciones para que encienda algo (calentador agua, recarga batería,…) en la hora más barata. Por ejemplo crear los atributos hour_cheap1, hour_cheap2 indicando la primera y segunda hora más barata.
Una pregunta, cuando habláis de crear un PR ¿A Qué os referís?.
Buen trabajado.

I haven’t tried this yet but it’s amazing for us the spanish, great work @azogue. It will be great to add what @serpini says so automations can be done based on cheap hours.

By the way I think PR means Pull Request :wink:

Hola, gracias por tu integración.
Si no tengo discriminación horaria, como tengo que configurarlo? Gracias crack!

1 Like

Thanks a lot @azogue. Working nice, i was just about to try implementing something like this :slight_smile:

1 Like

should be:

sensor:
  - platform: elecprice_spain_pvpc
    electric_rate: normal
    timeout: 20

Hola @Qyles,

Como bien apunta @fritanga, debes usar electric_rate: normal en el yaml. Pero me atrevo a sugerirte un cambio de tarifa: a no ser que tus consumos sean realmente a deshoras, la tarifa de discriminación horaria suele salir a cuenta sin necesidad de ajustar costumbres, consulta tus facturas (hasta hace poco estaban obligados a mostrarte los 3 precios finales, uno para cada tarifa). Puede suponer, fácilmente, un 10% de ahorro.

@serpini:

Como sugerencia, sería crear un atributo que indique la hora más barata, así se podrían hacer automatizaciones para que encienda algo (calentador agua, recarga batería,…) en la hora más barata. Por ejemplo crear los atributos hour_cheap1, hour_cheap2 indicando la primera y segunda hora más barata.

¿Qué tal algo así?

{
  "price 00h": 0.05228,
  "price 01h": 0.04622,
  # ...
  "price 22h": 0.05228,
  "price 23h": 0.05265,
  "min price": 0.04429,
  "min price at": 5,
  "next best hours": [23, 22, 21]
}

** "next best hours" muestra las mejores horas ordenadas por precio, pero filtrando las horas ya pasadas.

I hope in next 2 weeks I will have some chance to do it

No tuve tiempo en navidad :(, pero ahora sí puedo hacerlo.

Estoy corrigiendo la adquisición de datos “de mañana” (disponible normalmente a partir de las 21h), que no funcionaba, y randomizando el momento de la descarga de datos, no sea que se nos sature la API de Esios :slight_smile:

Intentaré colgar algo esta misma semana

1 Like

Gran trabajo, gracias! He visto que en tu GitHub hay una versión más moderna del sensor.py que la de Dropbox, cuál recomiendas?

Gracias @cantavro :slight_smile:

en tu GitHub hay una versión más moderna del sensor.py

La buena. Hice un poco de limpieza en el módulo, y tengo pendiente ver el tema de la integración en HACS, pero el código del sensor ya es final. Puedes usar el sensor.py más reciente.

La configuración cambia ligeramente (‘tariff’ por ‘electric_rate’), e incluye algunos atributos extra sugeridos en este hilo:

sensor:
  - platform: elecprice_spain_pvpc
    tariff: discriminacion

Había comentado el tema de proponer un nuevo componente en HA con ésto, pero posiblemente sea rechazado debido a 0004-webscraping.md, por lo que la vía de HACS parece más sencilla.

También estaba pensando en un renombrado… nunca me gustó ese elecprice_spain_pvpc, si a alguien se le ocurre algo mejor…

1 Like

El “tariff: discriminacion” no me funciona:

Invalid config for [sensor.elecprice_spain_pvpc]: [tariff] is an invalid option for [sensor.elecprice_spain_pvpc]. Check: sensor.elecprice_spain_pvpc->tariff. (See ?, line ?).

Si vuelvo a “electric_rate: discriminacion” sin problema. Ese “next best at” no sé qué es, pero parece que se ha vuelto un poco loco XD.

Recomiendas no poner “timeout”?

Hola @cantavro,

Puede que sea simplemente que HA comprueba la configuración en base a los componentes cargados, en vez de las versiones en disco (por eso el (See ?, line ?)., quizás?), y si tenías activo el viejo, se queja de no encontrarlo. Quizás cueste un reinicio de HA (en el 1º no encontrará tariff y usará el valor por defecto, que es la de 2 periodos :slight_smile:)

XD,

Como pedían atributos extra para “las mejores horas”, añadí ese "next best at" que contiene una lista de horas, ordenada por mejor precio, y sólo con horas futuras.

Así, ese campo se puede usar para hacer las automatizaciones más locas que uno quiera, como por ejemplo, obtener la mejor hora desde dentro de 2 horas hasta dentro de 5 h:

{% set hour = now().hour -%}
{% set best_hour = states.sensor.pvpc.attributes['next best at'] | select("greaterthan", hour + 2) | select("lessthan", hour + 5) | first -%}
{% set price_key = "price " ~ ("%02d" | format(best_hour)) ~ "h" -%}
hora: {{ best_hour }}h ('{{ price_key }}')
precio: {{ states.sensor.pvpc.attributes[price_key] }} €/kWh

Render:

hora: 17h ('price 17h')
precio: 0.12144 €/kWh

Lo de ver el valor de 47 en ese array también tiene su historia.

  • A partir de las 20-21h, se intenta acceder a los precios del día siguiente, que permanecen en los atributos del sensor como "price next day XXh", donde XX está en [0, 23].
  • Como en "next best at" hay un array de enteros, pues 00h es 24, 01h es 25, y así hasta 47 :slight_smile:
  • En el cambio de día desaparece la información de price next day, pues ya no es correcta, y hasta la tarde vuelve a usar sólo 24 valores.

Recomiendas no poner “timeout”?

Sí, ahora sólo se accede a la API de esios 3 veces/hora, y con el default de 5 segundos a mí no me da ningún problema desde hace meses.

1 Like

Reinicios hubo muchos, pero el sistema seguía insistiendo en usar electric_rate. Eliminando el componente por completo, reinicio y vuelta a instalar parece que ha solucionado el tema.

Solo por curiosidad, y perdón por el offtopic, cómo mides el consumo actual? Da gusto ver tu interfaz de HA :grin:

Muchas gracias de nuevo.

Hola @cantavro,

Solo por curiosidad, y perdón por el offtopic, cómo mides el consumo actual?

[OFFTOPIC on]

Pues he usado de todo a lo largo de los últimos 5 años, casi todo custom made, pero desde hace unas semanas tengo un ShellyEM con dos sondas que, la verdad, es una maravilla, altamente recomendables casi todos los cacharricos que hace esta gente (me hice con un montón de Shelly2.5 y Shelly1PM en el mismo pedido).

Están creando los IoT devices que me hubiera gustado desarrollar a mí :), y lo están haciendo cargados de detalles de buen gusto, IMHO. Por ejemplo, ellos tienen su propia cloud+app, pero viene desconectada por defecto!, puedes activar eso o configurar MQTT (que no es estrictamente necesario si no necesitas respuesta instantánea, el CoAP va bastante fino).

En resumen, a falta de calibrar las mediciones con la próxima factura eléctrica con el detalle horario, muy buenas sensaciones por ahora con el ShellyEM.

(este mensaje no está subvencionado, jajaja)

[OFFTOPIC off]

Volviendo al tema, me contesto a mí mismo:

Había comentado el tema de proponer un nuevo componente en HA con ésto, pero posiblemente sea rechazado debido a 0004-webscraping.md, por lo que la vía de HACS parece más sencilla.

estuve dándole otro repaso al documento y creo que, con mínimos cambios, sí es factible proponer el sensor como nueva integración en HA.

En este sentido, he simplificado el parser del fichero XML de la API Esios. A quien pueda interesarle, aquí el notebook con la comparación entre ambos métodos (spoiler: simpler usually means faster :slight_smile: )

Ahora me falta mirarme el tema del flujo de configuración en HA vía Integraciones (ya que nos ponemos, vamos a hacerlo bien, no?)

Si nada falla, espero poder hacer un último update aquí con el link a las novedades de HA 107.x/108.x :slight_smile:

En cualquier caso, y hasta entonces, el repositorio de mi HA contiene el custom_component actualizado.

1 Like

Genial, menudo aumento de rendimiento :open_mouth:
Muchas gracias por currazo :slight_smile:

1 Like

Hola @azogue.

Gracias de nuevo por la ayuda.

Siguiendo brevemente con el offtopic: le tengo echado el ojo al ShellyEM desde que salió, pero comentarios de gente que lo lleva usando un tiempo hablan de desviaciones de entre un 5 y un 20 % con respecto a la factura y/o pinzas amperimétricas. Hablan bien de las pinzas PZEM-004T y SCT-013, pero están en mi lista de futuribles. Por lo demás, Shelly rules.

Y volviendo al tema: tengo problemas con el precio entre las 00:00 y las 01:00. Llevo días prestándole atención y me ocurre lo siguiente:



“PVPC” es tu integración y “Mi PVPC” es un pequeño apaño que se han currado unos compañeros. A las 00:00 tu integración vuelve a marcar el precio de las 00:00 del día anterior y lo mismo con el resto de horas. A las 01:00 (o antes, no lo sé con certeza) ya marca todos los precios del día.

“Mi PVPC” básicamente es algo así:

- platform: rest
  #resource: https://api.esios.ree.es/archives/70/download_json
  resource_template: https://api.esios.ree.es/archives/70/download_json?locale=es&date={{ now().strftime('%Y-%m-%d') }}
  name: precioluz_ree
  method: GET
  json_attributes:
    - PVPC
  value_template: ''
  scan_interval: 99999

- platform: template
  sensors:
      precioluz_ree_fecha:
        friendly_name: 'Fecha coste luz'
        value_template: '{{ states.sensor.precioluz_ree.attributes.PVPC.0.Dia }}'
        icon_template: mdi:calendar-range        
      precioluz_00:
        friendly_name: 'Precio 00:00'
        value_template: '{{ states.sensor.precioluz_ree.attributes.PVPC.0.NOC | replace(",", ".") | float | multiply(0.001) | round (5)}}'
        unit_of_measurement: '€/kWh'
      etc:

Y una automatización para actualizar los precios de precioluz_ree cuando tú le mandes, que aún tengo que pulir un poco.

“Mi PVPC” es un pequeño apaño que se han currado unos compañeros

Se me acaba de caer la boca al suelo!!
No sabía que había una versión en JSON de los mismos datos! (a tomar viento el parser del xml!)

Yo estoy usando el archivo en archives/80, pero el de archives/70 tiene mejor pinta :slight_smile:

BTW, es un apaño estupendo, menudo currazo

En cualquier caso, terminaré la integración (ya está casi a punto, estoy con pijadillas):

Captura de pantalla 2020-02-21 a las 15.44.28

Y le echaré un vistazo a ese problema del valor en el cambio de día, seguramente el bug lo introduje cuando me puse a hacer cambios en el de-coupling de descargar datos / actualizar estado. Lo corregiré.

Muchas gracias por el aviso, eso es hilar fino!

1 Like

hola
molaría que indicaras la fuente de ese código, resulta muy interesate

si quieres te puedo pasar MI codigo
a las 20:00 consulta las tarifas del dia siguiente, y se crea un listado con los precios de las horas que quedan del día y todas las del dia siguiente
De esta manera se puede ver si conviene poner algo a las 23:00 o esperar a las 01:00