O erro que está nos logs foi corrigido na v1.0.1 lançada a 7 de Setembro, então ao removeres a integração quando adicionaste de novo foste buscar a versão mais recente. O melhor é ir vendo no HACS se há actualizações.
Então deve ser isso. Andei com uns erros, valores desconhecidos e acho que foi nessa data que consegui resolver. Por isso é que só há dados desde dia 6. vou aguardar.
Mais um café que fico a dever 
@luuuis, obrigado
Boas a todos.
Tenho verificado um pequeno constrangimento nos preços de dia seguinte, utilizando o template do tarifário coopérnico.
Os valores do atributo tomorrow_hours do sensor omie …spot_pt atualizam antes do mesmo atributo do sensor omie_adjustment. Durante o período em que o primeiro está atualizado e o segundo não, os valores do sensor template coopérnico estão iguais ao do OMIE. Ou seja, pelo que percebo (pouco), devido ao valor “MAJ” da fórmula estar do tipo None (null), os cálculos não são efetuados.
Há dias em que a atualização dos dois sensores omie (spot e adjustment) é quase em simultâneo, noutros (como hoje) pode demorar horas.
Já tentei mexer no sensor template da coopérnico, para que o null fosse visto com o valor 0 (até porque já há muito tempo que é sempre 0), mas não consegui. É possível fazer isto, certo?
Espero ter sido esclarecedor.
Obrigado,
AL
De facto, nunca percebi a razão de haver diferentes velocidades de cálculo do valor da Coopérnico. Já estive também horas à espera… Ainda hoje, neste momento, ainda não atualizou e já passaram 4 h desde a hora em que veio o OMIE… Se se conseguir melhorar, seria ótimo!
@Thy_Hunter @jsantosdias para evitar equívocos exponham s.f.f. a vossa situação neste formato.
- O que fizeram (incluir os vários passos se aplicável)
- O que aconteceu?
- O que esperavam que acontecesse?
- Bónus: incluir debug logs do período em questão.
Incluir apenas o detalhe suficiente para descrever a situação, informação supérflua por vezes causa confusão.
- O que fizeram
Nada.
Estou a utilizar esta integração e o Template Sensor sensor.template_coopernico_spot_price_simples, disponibilizado na Wiki
- O que aconteceu?
Valores do atributo tomorrow_hours do sensor “Preço marginal - Portugal” hoje, às 12.40
Valores do atributo tomorrow_hours do sensor “Preço do mecanismo de ajuste - Portugal” hoje às 12.42
Enquanto o primeiro tem valores e o segundo tem os valores “null”, os valores do atributo tomorrow_hours do Template Sensor sensor.template_coopernico_spot_price_simples assumem os mesmos do sensor “Preço marginal - Portugal”, não efetuando os cálculos da fórmula contida nesse Template Sensor
Isto pode ocorrer durante uns minutos ou horas.
- O que esperavam que acontecesse?
Idealmente, que o atributo tomorrow_hours do sensor “Preço do mecanismo de ajuste - Portugal” atualizasse ao mesmo tempo que o “Preço marginal - Portugal”.
Sendo que provavelmente, isto é uma questão da fonte não ficar disponível ao mesmo tempo, seria melhor que os valores “null” do sensor “Preço do mecanismo de ajuste - Portugal” fossem tidos como 0 (zero) na fórmula do Template Sensor da Coopérnico, para que o cálculo fosse na mesma efetuado. (Visto que o valor do ajuste tem sido sempre 0 desde Janeiro).
Obrigado,
AL
Obrigado, André. Podes tentar o seguinte código no atributo tomorrow_hours? Penso que isso irá resolver o problema, depois quando tiver um momento tentarei perceber melhor a que horas é que o preço do mecanismo de ajuste para o dia seguinte é disponibilizado para ver se se consegue fazer alguma coisa por aí.
{% set CGS = 4 -%}
{% set k = 10 -%}
{% set FP = 0.15 -%}
{% set TAR = -12.1 -%}
{% set ns = namespace(hourly_data=[]) %}
{% for h, PM in state_attr('sensor.omie_spot_price_pt', 'tomorrow_hours').items() -%}
{% set MAJ = state_attr('sensor.omie_adjustment_price_pt', 'tomorrow_hours')[h] | float(0) -%}
{% if PM == None %}
{% set price=PM %}
{% else %}
{% set price=((PM + CGS + k)*(1 + FP) + MAJ + TAR) | round(2) %}
{% endif %}
{% set ns.hourly_data=ns.hourly_data + [(h.isoformat(), price)] %}
{% endfor -%}
{{ dict(ns.hourly_data) }}
Alguém me pode ajudar com a integração no HA de um módulo para medir os custos diários de em eur dos consumos energéticos?
Este módulo faz isso? estou a tentar colocar como template e depois usar a integração ERSE mas não está a funcionar…
Já dei voltas e voltas…
Onde posso colocar o código? no ficheiro configurations.yaml? ou dá para por como template nos auxiliares? nesse caso que opções se escolhem?
Depois qd vou colocar a integração erse não me aparece como entidade para escolher…
(tb podemos falar no discord)
@luuuis no wiki estou a usar o codigo que lá esta para estes dois sensores:
contudo tenho uma duvida, se a janela temporal é diferente como é que os valores dos sensores são iguais?
@Thy_Hunter aguardo feedback para poder actualizar o wiki.
Provável erro da tua parte na definição dos sensores. Vê-se na tua captura que a janela temporal é igual nos dois. Aqui:
- Colocar o código do template sensor no
configuration.yml(se necessário, consultar uma das milhentas de páginas e vídeos que explicam o processo). - Clicar
e configurar o Home Assistant para usar o preço do template que adicionaste em (1) assim como configurar aí o teu medidor de consumo. - A partir abrindo
e conseguirás ver os custos diários, mensais e anuais.
Obrigado Luis…já instalei o OMIE pela HACS; depois aparecem as 4 entidades…
- Preço Marginal - Portugal
- Preço Marginal - Espanha
- Preço do mecanismo de ajuste - Portugal
- Preço do mecanismo de ajuste - Espanha
Na dashboard de energia escolhi como entrada a entidade do sensor que contabiliza os Kws que entram em casa - vai somando o total de Kws “que a casa consome”
Depois nas 4 opções dos custos em baixo, usei a “Utilizar uma entidade com o preço actual” - escolhi a entidade “Preço Marginal - Portugal”
Já está a contabilizar ali os custos em eur…vou verificar nos proximos 2 ou 3 dias e ver se fazem sentido os valorres que saem. É assim?
Já agora:
- se usar a opção “Usar uma entidade que acompanhe os custos totais” que valores saem??
Outra questão por curiosidade: para que serve a entidade “Preço do Mecanismo de ajuste - Portugal”? Acho que não se utiliza em nada certo?
Obrigado e parabéns pela integração!!
É quase isso @Helder_Passos mas deves usar como sensor para o preço actual o sensor do teu tarifário (Coopérnico, Luzboa, etc). Visto que não compras eléctricidade ao Preço Marginal do OMIE e tens as TAR, etc.
O valor do mecanismo de ajuste é usado nos sensores dos tarifários, embora o valor dele não passe do zero há largos meses.
Ok…boa…então tenho de usar o teu template da LuzBoaSPOT - pois é esse que tenho…
Em breve vou mudar para a IBELECTRA mas deve ser parecido…
Se usar “Usar uma entidade que acompanhe os custos totais” não vai funcionar direito certo?
Basicamente colar o código que tens aqui https://github.com/luuuis/hass_omie/wiki/Luzboa-SPOT-BTN-Simples no ficheiro template.yaml; mas só a partir de "spot… é isso?
Eu julgo que tenho tudo bem configurado mas o valor dos sensores é igual e não deveria, voltei a copiar novamente do wiki so alterei o nome do sensor.
alias está sempre com o mesmo valor 93.15
sql:
- name: omie_spot_pt_mes_to_date
unique_id: omie_spot_pt_mes_to_date
query: |-
SELECT FROM_UNIXTIME(stats.start_billing_ts) AS window_start,
FROM_UNIXTIME(stats.start_of_day_ts) AS window_end,
FROM_UNIXTIME(MIN(start_ts)) AS oldest_measurement,
FROM_UNIXTIME(MAX(start_ts)) AS newest_measurement,
COUNT(*) AS measurement_count,
ROUND(AVG(s.mean), 2) AS mean
FROM statistics s
JOIN statistics_meta m ON s.metadata_id = m.id
CROSS JOIN (
SELECT UNIX_TIMESTAMP(CASE
WHEN DAY(NOW()) > billing_offset
THEN CONCAT_WS('-', YEAR(NOW()), MONTH(NOW()), billing_offset)
ELSE CONCAT_WS('-', YEAR(NOW() - INTERVAL 1 MONTH), MONTH(NOW() - INTERVAL 1 MONTH), billing_offset)
END) AS start_billing_ts,
UNIX_TIMESTAMP(CURDATE()) AS start_of_day_ts
FROM (
-- ⚠️ ADJUST HERE AS NECESSARY (e.g. 20 to start billing cycle at midnight on day 21):
SELECT 20 AS billing_offset
) cfg
) AS stats
WHERE statistic_id = 'sensor.omie_spot_price_pt'
AND start_ts >= stats.start_billing_ts
AND start_ts < stats.start_of_day_ts;
column: 'mean'
unit_of_measurement: '€/MWh'
- name: omie_spot_pt_30_dias_rolling_average
unique_id: omie_spot_pt_30_dias_rolling_average
query: |-
SELECT FROM_UNIXTIME(stats.thirty_days) AS window_start,
FROM_UNIXTIME(stats.start_of_day) AS window_end,
FROM_UNIXTIME(MIN(start_ts)) AS oldest_measurement,
FROM_UNIXTIME(MAX(start_ts)) AS newest_measurement,
COUNT(*) AS measurement_count,
ROUND(AVG(s.mean), 2) AS mean
FROM statistics s
JOIN statistics_meta m ON s.metadata_id = m.id
CROSS JOIN (
SELECT UNIX_TIMESTAMP(CURDATE() - INTERVAL 30 DAY) AS thirty_days,
UNIX_TIMESTAMP(CURDATE()) AS start_of_day
) AS stats
WHERE statistic_id = 'sensor.omie_spot_price_pt'
AND start_ts >= stats.thirty_days
AND start_ts < stats.start_of_day
column: 'mean'
unit_of_measurement: 'EUR/MWh'
Será a base de dados corrompida? uso maria db
Os sensores parece que estão bem, vê-se nos atributos window_start e window_end que os intervalos de tempo estão correctos.
Tens é aí um problemas não relacionado, que é só teres dados (no Long Term Statistics) desde o dia 29 de Novembro, portanto não tens dados suficientes para calcular os últimos 30 dias. Podes comparar com a captura de ecrã que eu partilhei, devias ter 720 e 384 de measurement_count.
PS esse sensor para MariaDB parece que tem um erro off-by-one, começa o período a 20 de Nov. enquanto que o SQLite começa a 21 de Nov.
Peço desculpa a falta de feedback, tenho andado off.
Apliquei a alteração no dia em que a disponibilizaste e desde então não me tenho apercebido desse desfasamento. O histórico (10d) também corrobora que está tudo correto.
Obrigado
AL
De facto esta situação é estranha, o que pode ter originado isto? acho que o que vou fazer é passar a base de dados de mariadb para sqlite, pois já há uns meses ter lido que o sqlite está melhor.
obrigado pela atenção
Tem a ver com o que falámos aqui anteriormente: no momento em que actualizaste o HA 2023.9 sem actualizar também o OMIE deves ter ficado sem estatísticas. Situação essa que resolveste há 10 dias. 
Olha boa , que olhar atento .
Não me lembrava disso .
