Eres un autentico MAQUINA ojala más gente haciendo un trabajo con tanto gusto y tan util para la comunidad GRACIAS!!!
@danimart1991 tengo una pregunta sobre la card que siempre se me olvida hacerte
¿sabes porque aparece este mensaje en rojo al crear la card?
Tambien es curioso que para que me funcionara tuve que añadir los dos recursos ¿puedes confirmarlo?
Buenas.
El Editor no se ha de añadir a Recursos, lo importo desde la propia tarjeta.
Lo que queda por solucionar es que el editor se muestre al añadir tarjeta, ahora solo aparece al editar. 
1 Like
Hola Buenas!! Alguien sabe como integrarlo para poder ver el precio actual… en homekit? Mediante la integración de homekit que tiene home assistant este valor no me aparece en la aplicación.
Gracias.
Hola @Miguel_Albiac_Roca,
Seguramente es por las unidades que tiene el sensor. Homekit no sabe lo que es un medidor en “€/kWh” 
Cuando se publica un sensor en Homekit se le debe asignar una clasificación, para que sepa qué es y ajuste la interfaz y demás.
Si quieres ver el precio ahí tendrías que montar un template sensor sobre el sensor.pvpc con unas unidades que Homekit pueda interpretar (y seguramente con alguna conversión de unidades para que los valores no sean tan pequeños, como €/MWh, y muy posiblemente pierdas precisión por el camino, ya que no creo que te muestre más de 1 decimal)
Hola @Dreamzonne,
No había visto estos mensajes, si no me citan (@azogue) no me aparece notificación 
Mi cabeza acaba de hacer 
El precio a las 13h en península sería el mismo que el de las 13h en Canarias (aquí no aplica lo de la hora menos)
Acabas de solucionar una duda trascendental que tenía!
Porque no tenía mucho sentido aplicar los precios simultáneamente en Canarias, en oposición a retrasar toda la curva 1h y aplicarla como tiempo local.
En alguna de las fuentes de datos (no estoy seguro de si es en la actual o en otra antigua), los valores de precios vienen con un datetime en UTC, por lo que se asumían de esa manera (sobre todo para tratar los días con cambio de hora, que son un follón). Esa fecha en UTC se convierte en la generación de atributos a hora local, y de ahí el desalineado…
¿Me confirmas entonces que la curva de precios de PVPC se aplica tal cual en Canarias, en invierno y verano?
(p.ej., en tarifa de 2 periodos el valle comienza a las 22h en invierno y las 23h en verano, right?)
Si es así toca rehacer la integración y la librería que hay por debajo 
Buenas tardes @azogue,
antes que nada mil gracias por la integración, la consulto con bastante frecuencia, y tengo la idea con la info de de programar un termo en las horas más económicas, para rascar aún más algún céntimo en ahorro.
Te confirmo que en Canarias los periodos PVPC con discriminación son idénticos a los de Península.
Como decía (en los periodos), no aplica una conversión horaria:
Invierno, periodo punta: de 12h a 22h, valle de 22h a 12h
Verano, periodo punta: de 13h a 23h, valle de 23h a 13h
Adjunto captura de mi última factura donde puedes observar la comercializadora: Energia XXI Las Palmas de G.C, y como los tramos horarios no cambian,
Lamento que debas rehacer código y no sea tan sencillo como tocar un valor y solucionado.
Quizá (bajo mi ignorancia) puedas sumar 1h a la info obtenida de ESIOS REE solo si la zona horaria local es: (UTC/GMT +01:00) Atlantic/Canary
Ojo, que la info de previsión del día siguiente si es correcta y no necesitaría conversión.
Espero ser de utilidad, y cualquier otra info o pruebas que necesites me comentas
Un saludo! y gran trabajo.
1 Like
Ok. Gracias. Ya lo tengo implementado y parece que funciona ok.
Hola, He estado buscando, pero no soy capaz de encontrarlo. ¿hay algun tutorial o descripción para hacer una automatización que encienda un interruptor cuando llegue la hora de precio más bajo PVPC? En la versión actual del PVPC, ¿sigue activo el WEB scrapping o es necesario escribir a REE para que me proporcionen la clave y poder utilizar la aplicación? Estoy haciendo en un trabajo fin de máster; el trabajo que se realiza aquí es impresionante, y quiero llamar la atención “académica” sobre él … Muchas gracias.
1 Like
Hola,
He visto esta página, para leer datos de consumo desde el contador. Creo que solo serviría para Iberdrola, pero imagino que en otros casos haya algo similar.
Sería una forma de tener el consumo “oficial”, sin necesidad de pinzas.
¿Cómo lo veis?
Me autorespondo. Hay muchas formas de hacerlo, pero creo que la más fácil es crear un value_template, con el precio 0,001€ más caro respecto a la hora más barata.
Entonces (con los datos de hoy),
Precio hora más barata: 0.04399 € / kWh
Precio hora más barata + 0.001: 0.04499 € / kWh
Como 0.04499 > 0.04399 si creamos la automatización de que se encienda lo que sea cuando el valor numérico sea menor de 0.04499 lo hará, ya que el precio mínimo para hoy será de 0.04399
#sensor:
- platform: template
sensors:
horabaratadehoy:
friendly_name: “Precio mejor hora PVPC de hoy”
value_template: “{{ state_attr(‘sensor.pvpc_electric_car’, ‘min_price’) +0.001}}”
Saludos 
2 Likes
Gracias! Lo probaré y te comento. Me parece una funcionalidad que debería ser muy requerida por mucha gente …
Buenísima integración.
Yo tengo 4 TP-Link HS110, en cuya integración incluyen sensores consumo instantáneo en W, de Consumo diario kWh y Consumo Total kWh.
A ver si consigo hacer que con esta fantástica integración pueda mostrar el valor en € del consumo total diario.
Gracias por el trabajazo.
Comprobado y funciona. Muchas gracias!!!
Un gustazo escribir en nuestro idioma en plena comunidad de HA! Aunque entiendo que a nadie más le interesa este tema.
Solicito ayuda para un novato con HA, sin conocimientos de programación, para implementar automatizaciones, dado que no me aclaro con la “value template” de arriba y otros casos:
- Trigger para el precio más barato del día.
- Trigger para activar a la hora más barata en una franja (por ejemplo a la hora más barata de 19 a 23h).
- Y para rizar el rizo: ¿Sería posible un trigger cuando sean las 2 horas seguidas más baratas (para ciclo largo lavadora)?
Mil gracias!
Hola. Gracias por el código.
Entiendo que esto va en sensor del configuration.yaml , si es así no me funciona, tengo como sensor pvpc este: PVPC 2.0 DHA . lo pongo así y no me lo detecta, me da un error al reiniciar HA:
- platform: template
sensors:
horabaratadehoy:
friendly_name: “Precio mejor hora PVPC de hoy”
value_template: “{{ state_attr(‘sensor.pvpc_2_0_dha’, ‘min_price’) +0.001}}”
Gracias.
Hola. Conseguiste automatizarlo para usar las horas mas baratas?. Gracias.
No tengas en cuenta ese sensor, esto funciona:
Config:
- platform: template
sensors:
pvpc_minimo_hora:
value_template: "{{ state_attr('sensor.pvpc', 'min_price_at') }}:00"
entity_id: sensor.pvpc
friendly_name: "Luz minimo (Hora)"
icon_template: mdi:thumb-up
precioluz_minimo_eur_kwh:
value_template: "{{ state_attr('sensor.pvpc', 'min_price') }}"
entity_id: sensor.pvpc
friendly_name: "Luz minimo (€/KWH)"
icon_template: mdi:calendar-range
unit_of_measurement: '€/kWh'
horita_barata_19_23:
value_template: "{% for state in state_attr('sensor.pvpc', 'next_best_at') | reject ('<', 19) | reject ('>', 23) -%}
{% if (loop.first) -%}
{{ state }}:00
{%- endif %}
{%- endfor %}"
entity_id: sensor.pvpc
friendly_name: "Luz minimo entre 19 y 23h"
Automat:
alias: Lavavajillas pvpc minimo
description: 'Arrancar lavavajillas pero ojo falta programar apagado a las 2 o 3
horas Osram 3'
trigger:
- platform: template
value_template: '{{ states(''sensor.time'').lstrip(''0'') == states(''sensor.pvpc_minimo_hora'')
}}'
condition: []
action:
- service: switch.turn_on
data: {}
entity_id: switch.on_off_plug_in_unit_4
- service: telegram_bot.send_message
data:
message: enchufe lavavajillas encendido a hora más barata.
mode: single
alias: Apagar lavavajillas 3h después minimo
description: Apagar a las 3 horas de haberse encendido desde el precio mínimo de
la luz
trigger:
- platform: state
attribute: last_triggered
entity_id: automation.lavadora_pvpc_minimo
for: '10800'
condition: []
action:
- service: switch.turn_off
data: {}
entity_id: switch.on_off_plug_in_unit_4
- service: telegram_bot.send_message
data:
message: Apagado enchufe lavajillas 3 horas después (desde encendido precio
mínimo)
Para el otro sensor, este es el trigger.
trigger:
- platform: template
value_template: '{{ states(''sensor.time'').lstrip(''0'') == states(''sensor.horita_barata_19_23'')
}}'
Soy novato todavía pero funciona todo.
1 Like
Gracias David!
Lo he integrado bien todo, per la automatización no me deja editarla:
- alias: Enciende Termo pvpc minimo
description: 'Arrancar lavavajillas pero ojo falta programar apagado a las 2 o 3 horas Osram 3'
trigger:
- platform: template
value_template: '{{ states(''sensor.time'').lstrip(''0'') == states(''sensor.pvpc_minimo_hora'')
}}'
condition: []
action:
- service: switch.turn_on
data: {}
entity_id: switch.pwm_manual_termo
- service: telegram_bot.send_message
data:
message: enchufe lavavajillas encendido a hora más barata.
mode: single
- alias: Apagar Termo 3h después minimo
description: Apagar a las 3 horas de haberse encendido desde el precio mínimo de la luz
trigger:
- platform: state
attribute: last_triggered
entity_id: automation.lavadora_pvpc_minimo
for: '10800'
condition: []
action:
- service: switch.turn_off
data: {}
entity_id: switch.pwm_manual_termo
- service: telegram_bot.send_message
data:
message: Apagado enchufe lavajillas 3 horas después (desde encendido precio mínimo)
Y luego el ultimo sensor que me pegas no se donde va:
trigger:
- platform: template
value_template: '{{ states(''sensor.time'').lstrip(''0'') == states(''sensor.horita_barata_19_23'')
}}'
Saludos.
Hola @bocaditos
Te ha pasado algo que ya me pasó a mí. Y es que editar directamente el archivo yaml de automatizaciones da problemas y se rompe. Borra lo que has incluido con el editor primero (restaura). Y luego crea la automatización desde el asistente con estos pantallazos (pendiente las ’ y ", que dan guerra).
El último trigger que te incluí por separado es como ejemplo para la hora más barata por tramos de horas (por ejemplo la lavadora no la pondría a las 4h), que te funcionaría sinhas incluido el sensor entre horas (entre 19 y 23 o las que quieras).
