Integração OMIE: preços horários, diários, mecanismo de ajuste

Boas.
Mais uma vez agradeço a tua integração, que tenho como base para algumas coisas (antes usava scrape)
Não sei qual a base de funcionamento, mas estava aqui a tentar implementar a média mensal (tenho 2 hipoteses, ou desde o início do mês até ao fim do mês, ou dos últimos 30 dias (que no fundo acho que é melhor e dá mais versatilidade).
Tentei fazer através de um template trigger, mas infelizmente, e pelo que já li, não é possível em templates de yaml guardar uma lista como estado para um sensor, acaba por ser guardado como string, o que é muito estranho mas já vi explicações no fórum (https://community.home-assistant.io/t/list-of-mappings-in-a-template-sensor-attribute-templates/227821/2). Explico:

Fiz este teste para guardar uma lista de valores, só para ver como se comportava:

- platform: template
  - trigger:
    - platform: time_pattern
      hours: 00
      minutes: 00
      seconds: 15
    sensor:
      - name: "omie_historico_spot_media_30d"
        unique_id: historico_omie_spot_30d
        # unit_of_measurement: 'EUR/kWh'
        ## {{ [0.0964,0.04994,0.07878,0.1009,0.11523,0.11354,0.09947,0.07827,0.03549,0.02177,0.05086,0.06688,0.0389,0.05254,0.07557,0.08662,0.10105,0.09844,0.10475,0.05986,0.0624,0.01617,0.03399,0.072,0.072,0.072,0.072,0.072,0.072,0.072] }}
        ## {{ [(states('sensor.omie_spot_price_pt')|float/1000)|round(4)] + states('sensor.omie_historico_spot_media_30d')[:-1] }}
        state: >-
          {{ [0.0964,0.04994,0.07878,0.1009,0.11523,0.11354,0.09947,0.07827,0.03549,0.02177,0.05086,0.06688,0.0389,0.05254,0.07557,0.08662,0.10105,0.09844,0.10475,0.05986,0.0624,0.01617,0.03399,0.072,0.072,0.072,0.072,0.072,0.072,0.072] }}

Até parece que funciona:

Mas de facto, apesar do template de teste dizer que retorna uma lista (acima), retorna uma string:


(se tento sacar o rimeiro elemento da lista, o primeiro elemento da string é o ‘[’ que me retorna correctamente, se interpretado como string, mas erradamente se fosse uma lista).
Portanto a minha ideia fica aqui um pouco “bloqueada”. Está também explicado no posta acima que isto é possível, quase com o mesmo código, em python. Sinceramente, não sei como lá chegar.
A minha ideia depois seria, no início de cada dia, adicionar o valor da media desse dia à lista (que se sabe no dia anterior), tirando o mais antigo da lista (expliquei acima como estava a pensar fazer):

{%- set lista_anterior = [0,1,2,3,4,5,6,7,8,9,10] -%}
{%- set novo_valor = 5.44 %}
{%- set listafinal = [novo_valor] + lista_anterior[:-1] %}
{{lista_final}}

ou simplesmente, e aplicando o teu sensor:

{{ (state_attr('sensor.omie_spot_price_pt','day_average')/1000) + states(this.entity_id)[:-1]}}

Pelo que venho aqui perguntar se, da mesma forma que consegues obter os dados diários, também conseguirias obter uma média diária?
Hipóteses:

  1. Indo buscar, de alguma forma o valor ao site, como fazes para os valores diários (não sei fazer)
  2. Guardando os últimos 30 valores num atributo, de forma que expliquei ou parecida (também não sei fazer). Esta última abordagem permitiria calcular por 30 dias ou até ao dia que se quisesse (por exemplo, se estamos a dia 24, depois seria só calcular a média dos primeiros 24 valores).
  3. Usar os dados do HA de "long-term-statistics? Como??? Não sei… Li algures “If you want to retrieve the LTS values from the database for use with other cards you will have to create an SQL sensor.”. Já tentei e não consigo, se houvesse esta hipótese também não era mau…

EDIT: já consigo obter a média total por SQL:

SELECT mean
FROM "statistics"
WHERE metadata_id = (SELECT id FROM "statistics_meta" WHERE statistic_id = 'sensor.omie_spot_price_pt')

Alguém ajuda a limitar isto a 30 dias? :point_up_2:

Obrigado mais uma vez e, olha, se conseguires, muito bem :slight_smile: , se não terei de arranjar outra forma. Não queria adicionar mais base de dados nenhuma ao HA, mas não excluo a hipotese.

Eu através de mariadb, utilizo este

  SELECT  s.state, from_unixtime(s.last_updated_ts), s.metadata_id
			FROM homeassistant.states s
              left JOIN states_meta m ON s.metadata_id = m.metadata_id
			WHERE 
            m.entity_id = 'sensor.preco_energia_omie_hoje'
			AND s.state != 'unknown'
			AND s.state != ''
			AND (from_unixtime(s.last_updated_ts) > DATE_SUB(NOW(), INTERVAL 30 DAY))
1 Curtiu

Após ler as primeiras palavras da notificação por email vinha agora aqui sugerir um SQL sensor enquanto o Home Assistant não suporta nativamente melhores formas de extrair valores dos Long Term Statistics. :smiley:

Vê lá se este aqui serve.

sql:
  - name: omie_spot_pt_30d
    unique_id: omie_spot_pt_30_day_rolling_average
    query: >
      SELECT datetime(min(start_ts), 'unixepoch') as start, datetime(max(start_ts), 'unixepoch') as end, round(avg(s.mean), 2) as mean
        FROM statistics s JOIN statistics_meta m ON s.metadata_id = m.id
      WHERE  statistic_id = 'sensor.omie_spot_price_pt'
        AND  start_ts >= unixepoch('now', '-30 days')
    column: 'mean'
    unit_of_measurement: 'EUR/MWh'

1 Curtiu

Também dá mas sei que há malta que não quer ou não pode aumentar a retenção do recorder para muito mais que 7 dias (devem ter muitos sensores, não sei). Por isso é mais simples usar directamente o statistics, até porque não permite esses casos de unknown e afins.

Já agora, utilizas para que fim?

ENAAA, Burtal, isso mesmo :smiley: !
Muito obrigado! :slight_smile:

Para cálculo do valor médio do OMIE dos ultimos 30 dias.

Depois tenho outro, que me dá o valor médio do OMIE para o meu ciclo de faturação.

Basicamente, uso ambos para estimar o valor da minha fatura mensal na Luzboa

Boas, @luuuis!
Olha, eu “já sei” como fazer isto num sensor, estava no caminho certo e hoje a meio da noite fez-se uma luz e sei que vou conseguir implementar isto. A ideia que tinha acima, de quardar uma lista dos últimos valores, está correcta se usar não o “state” do sensor e sim um atributo. Esses já suportam listas.
Eu pretendo usar o teu sensor spot (podia utilizar o que tinha antes com scrape, mas não vale a pena), ou seja, acabo por fazer um sensor “companheiro” à tua integração, em que vou guardar 2 atributos novos:

  1. lista dos últimos 30 valores diários (controlar o tamanho da lista, descartar o último e inserir o novo, como faço acima). Algo como:
    valores_diarios_30d: "{{ [(state_attr('sensor.omie_spot_price_pt','day_average')/1000)] + state_attr(this.entity_id,'valores_diarios_30d')[:-1]}}"
  2. lista com valores mensais, que limpa no início do mês seguinte.

Os valores dos atributos apenas podem ser atualizados 1 vez por dia, por isso a lógica de implentar por um template trigger.

Isto permitirá depois fazer cálculos de médias para várias situações e formas de cálculo dos vários tarifários. Por exemplo, a Luzboa est´agora a mudar para o ciclo de 21 a 20, para bater certo com a E-Redes; para eu saber o que estou a pagar, por exemplo, dia 25 tenho de usar a média mensal desse mês, não a de 30 dias (se bem que não deve divergir muito); a partir de dia 1 já terei de optar: se usar a média mensal, só com um dia terei um valor muito incerto, pois só tenho 1; aí não sei bem como fazer a nível de cálculo, talvez seja uma questão de “compromisso”… mas tudo é quando não se sabe o futuro.

A minha questão é:

  • Achas viável adicionar isto ao(s) teu(s) sensor(es)? Ficaria mais completo e mais versátil e acho que a lista de valores dá muitas opções de adaptação (também era bom fazer o mesmo para o MIBEL). Antes de partir o resto dos neurónios que me sobram espero pela tua opinião, e se precisares de ajuda de um leigo (pelo menos no pensamento acho que estou lá) diz que explico como estou a pensar fazer a ver se consegues adaptar ao teu. Entretanto se calhar vou tentar aqui deste lado, se conseguir fazero que quero, eu coloco aqui.
    PS: a tua solução anterior do SQL é BRUTAL, mas faz-me confusão ter os valores a mudar constantemente ao longo do dia, pois estamos a usar o valor horário como base; está correcto à mesma, e estou a usar com muito bom agrado, mas faz-me confusão :stuck_out_tongue:

Abraço e obrigado!!!

A questão de actualizar hora a hora é fácil de resolver, basta ignorar o dia presente. Consulta a última versão do Last 30 days (rolling average) no Wiki para não estarmos a encher este tópico de YAML e SQL.Também acrescentei o Billing period average (month to date) para calcular as médias correspondentes ao período de facturação de cada um. :slight_smile:

Na minha opinião não vale a pena ir pelo caminho que estás a seguir com triggers e afins quando podemos de forma declarativa (neste caso SQL) extrair a informação que queremos do HA.

Para responder à tua pergunta, estou sim a equacionar algum tratamento de médias dentro do OMIE Home Assistant se isso facilitar a vida a uma parte expressiva de utilizadores. Provavelmente é a próxima coisa que vou ver uma vez que tenha corrigida a questão das horas não baterem certo.

O que eu ainda não tenho a certeza é se há uma “única” média que serve para todos. Pois uns têm simples, outros bi-horário, outros tri-horários, uns querem a média das 24 horas e outros querem várias médias consoante o período do tarifário, etc. Idealmente quero evitar entrar nesse pantanal de ter de suportar todas essas combinações.

2 Curtiram

Boa! :smiley: Thanks, vou deixar-me de maluquiras então!
A questão da média, posso esclarecer: é igual para todos, pelo menos a base que é o OMIE para estes tarifários. Acho que é essa base é que faz sentido abordar na tua integração, e não o resto. As nuances de cada operador terão de ser tratadas de acordo, à posteriori, junto com todas as outras condições do operador e ERSE, impostos e afins.
EDIT: pensando bem, talvez haja quem precise de outros dados, não sei; mas quem tem tarifários indexados à hora já tem os dados base na tua integração disponíveis.

Já se vislumbra a v1. Quem quiser pode testar a versão beta através do HACS (atenção que os vossos template sensores deixarão de funcionar até serem actualizados).


Não vou entrar em grandes explicações, espero antes o vosso feedback sobre a nova forma como organizei os sensores e atributos (alterações necessárias para suportar devidamente a questão dos fusos horários).

3 Curtiram

@luuuis uma duvida

nessa imagem, que está a vermelho esse valor corresponde à meia noite de Portugal ?
e é o valor sobre a venda e nao da compra correcto?

É o valor de referência para a hora 1 do dia, que corresponde ao período entre as 00:00 e 00:59 no horário CET usado em Espanha. Em Portugal continental corresponde então à última hora da véspera.

A v1(beta) já torna isso explicito ao associar uma hora a cada valor.

Já experimentei a versão beta, e pareceu funcionar tudo muito bem, mas não consegui colocar nos gráficos à conta das etiquetas de tempo. Fico à espera da atualização do wiki… :wink:

Basicamente onde tens isto:

  data_generator: >
    return entity.attributes.day_hours.map((price, hour) => [ new Date(new Date().setHours(hour, 0, 0, 0)), price ])

passas a usar:

  data_generator: >
    return ((hs) => Object.keys(hs).map((dt) => [ new Date(dt), hs[dt]
    ]))(entity.attributes.today_hours)

e igual para o entity.attributes.tomorrow_hours se for caso disso.

Portanto nesta imagem já está correcto esse valor de 90.3 corresponde então à meia noite correcto?
Pergunto isto, porque quero criar uma automação que me diga qual a hora mais barata do dia seguinte, para que consiga por alguns aparelhos gulosos a trabalhar. Se isto funcionar correctamente consigo saber quando ligar os aparelhos.
Idealmente a ideia era trabalhar com esses valores mais baixos juntamente com a produção dos paineis, ando a estudar uma forma “provisoria” de saber os picos de maior produção embora seja dificil.

Para fazer isso à maneira existem componentes de Programação Linear que calculam a melhor hora para ligar ou desligar as cargas baseado na previsão solar e preço de compra e venda do kWh. Pessoalmente tenho seguido com interesse o EMHASS Add-on.

Difícil porquê, não basta usar o Forecast.Solar ou o Solcast? Ou entendi mal?

Home Assistant - Home – Home Assistant 2023-05-02 08-22-08

1 Curtiu

Não conhecia isso vou nvestigar logo após o trabalho. Difícil no sentido que isso é uma previsão e não te dá certezas que nessa hora não exista algumas nuvens por exemplo que te estrague os cálculos. Ou estou a viajar demasiado nos pensamentos?

Para concluir o off-topic que eu próprio iniciei :sweat_smile: o Solcast pelo menos leva em contas nuvens (previsão e vai actualizando ao longo do dia). É certo que não há certezas a nível de meteorologia mas corresponde bastante bem à realidade.

Certo tens toda a razão iremos continuar a falar disto em outro tópico :slight_smile:

E em relação ao preço da Coopérnico? Será a mesma alteração?


Copyright © 2017-2021. Todos os direitos reservados
CPHA.pt - info@cpha.pt


FAQ | Termos de Serviço/Regras | Política de Privacidade