Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Estacion meteorologica - datos diarios - cambio entity_id #5

Closed
galambert75 opened this issue Aug 21, 2023 · 8 comments
Closed

Estacion meteorologica - datos diarios - cambio entity_id #5

galambert75 opened this issue Aug 21, 2023 · 8 comments
Assignees
Labels
bug Something isn't working
Milestone

Comments

@galambert75
Copy link

galambert75 commented Aug 21, 2023

Hola Daniel,

En los últimos días he tenido una incidencia con el Entity_ID de los datos diarios de la estación meteorológica.

Se generan dos entity_id's: sensor.meteogalicia_19055_station_daily_data y sensor.meteogalicia_areas_station_daily_data.

Luego se van alternando entre sí. Uno muestra los datos correctos y el otro pasa a estado "unavailable". Al cabo de unas horas, el que mostraba datos correctos pasa a "unavailable" y el que estaba "unavailable" pasa a mostrar datos correctos (pantallazo adjunto):

MeteoGalicia_Areas_Unknown

Esta es la configuración:

- platform: meteogalicia
id_estacion: 19055
scan_interval: 300

Los datos de 10 minutos funcionan sin problema.

Un saludo!
Roberto

@Danieldiazi Danieldiazi self-assigned this Aug 21, 2023
@Danieldiazi Danieldiazi added the bug Something isn't working label Aug 21, 2023
@Danieldiazi
Copy link
Owner

Danieldiazi commented Aug 21, 2023

Hola!
Voy a tratar de reproducirlo, porque lo raro es que el texto "areas" no lo tengo en ninguna parte del código.
Actualizo: Ya sé de donde sale lo de "Areas":

imagen

Bug localizado!

@Danieldiazi
Copy link
Owner

Tienes una versión Beta, por si puedes probar. En mi caso está funcionando ok.

Antes en el nombre e id del sensor metía el nombre de la estación que me venía en el servicio web, debe ser que en algún momento ese nombre no viene (igual cuando no tiene acceso al servicio web) y se cambia al por defecto que es el id de estación. Para evitar que eso pase, no pondré el id del sensor ni su nombre en función de lo que recibo o no de un servicio web.

@Danieldiazi Danieldiazi added this to the 2023.08.3 milestone Aug 21, 2023
@galambert75
Copy link
Author

Tienes una versión Beta, por si puedes probar. En mi caso está funcionando ok.

Gracias Daniel!

Anoche puse la versión beta y va bien por ahora. La estaré monitorizando.

Dos comentarios:

  1. El tag de la nueva versión beta es 2023.8.3-Beta. Hace un par de semanas habías publicado otra versión con tag 2023.08.3-Beta
  2. Me respondieron de MeteoGalicia y añadieron el balance hídrico que faltaba (aunque siguen faltando otros muchos valores). Con eso aumentó bastante la lista de atributos. Se me ocurrió que se podría reducir bastante (50%) si combinas la medida y la unidad en un solo atributo. P.ej. pasar de temperatura_value y temperatura_unit a temperatura = 25,4 ºC (incluyendo conversión del value a float). ¿Qué te parece la idea?

Un saludo!

@Danieldiazi
Copy link
Owner

Danieldiazi commented Aug 23, 2023

Tienes una versión Beta, por si puedes probar. En mi caso está funcionando ok.

Gracias Daniel!

Anoche puse la versión beta y va bien por ahora. La estaré monitorizando.

Dos comentarios:

1. El tag de la nueva versión beta es 2023.8.3-Beta. Hace un par de semanas habías publicado otra versión con tag 2023.08.3-Beta

2. Me respondieron de MeteoGalicia y añadieron el balance hídrico que faltaba (aunque siguen faltando otros muchos valores). Con eso aumentó bastante la lista de atributos. Se me ocurrió que se podría reducir bastante (50%) si combinas la medida y la unidad en un solo atributo. P.ej. pasar de temperatura_value y temperatura_unit a temperatura = 25,4 ºC (incluyendo conversión del value a float). ¿Qué te parece la idea?

Un saludo!

Holas:

Genial, espero que siga yendo bien, en mi caso así es. El problema estaba localizado en cuando el servicio web no estaba disponible. Por ejemplo a partir de las 00:00 que cargan los datos u en otros fallos puntuales. En ese momento, no le devuelve el nombre de la estación y por tanto el id de sensor (que usaba el nombre de la estación si estaba disponible) cambiaba su valor y por tanto se consideraba otro sensor. Eso está corregido. Igual lo que sí hago es que el nombre del sensor, no el id del sensor, si que se actualice con el nombre de la estación si está disponible, y sino, pondrá su identificador. No duplicará el sensor, pero puede ser más descriptivo.

Respecto al tag de versión, si, me di cuenta, funcionar va a funcionar igual porque antes me cargué la versión asociada a esa Beta de la semana pasada. Un fallo técnico :)

Con respecto al punto 2, entiendo lo que dices y comparto que son demasiados atributos, pero no lo veo, cuando hice este desarrollo, para mi era más cómodo que valor y unidad estuviesen en un solo atributo, pero lo separé porque así se puede trabajar con ellos de forma separada, por ejemplo, en una automatización yo puedo coger el valor para comparar de forma numérica en una condición. Si lo pongo todo junto, ya no sirve. Este funcionamiento es el mismo que hace HA para establecer el valor del propio sensor, por un lado tienes que pasarle el valor, y por otro la unidad. Luego HA en pantalla los junta si procede. De todos modos voy a ver si le doy unas vueltas a ver qué se puede mejorar ahí.

Otra cuestión sería crear un tercer atributo con todo junto, es decir, uno con la medida, otro con la unidad, y otro que sea una cadena con los dos valores, pero creo que no aporta mucho, pues con los dos primeros puedes luego trabajar y unirlos si lo necesitas.

A colación de que el servicio web de datos diarios no está disponible a partir de las 00:00, Meteogalicia (vuelvo a decir que son unos grandes profesionales!) ha contestado a mi duda planteada indicando que los datos diarios se calculan a partir de los sucesivos datos 10-minutales que se van recibiendo, y estos datos se obtienen en horario UTC (desfase 2h en verano, o 1h en invierno), por lo que ahora en verano no hay disponibilidad de datos diarios hasta las 2:10 de la madrugada.

Gracias de nuevo por tu feedback!

@galambert75
Copy link
Author

Holas:

Genial, espero que siga yendo bien, en mi caso así es.

Hola Daniel,

Sigue yendo bien. Creo que ya puedes dar por cerrado el issue.

Respecto al tema de combinar el valor y la unidad, tienes razón. Al final lo que hice fue crear sensores "template" para monitorizar los parámetros que me interesan como "measurement". Incluí el filtrado de -9999 (no disponible) que se muestra de madrugada porque me distorsionaba las gráficas.

  - sensor:
      - name: "MeteoGalicia - Areas - Balance Hidrico Diario"
        unique_id: meteogalicia_areas_bh_daily
        icon: mdi:waves-arrow-up
        unit_of_measurement: "L/m2"
        state: >
          {% if (((state_attr("sensor.meteogalicia_19055_station_daily_data", "BH_SUM_1.5m_value")) | float)==-9999) -%}
            {{ "unknown" }}
          {%- else -%}
            {{ state_attr("sensor.meteogalicia_19055_station_daily_data", "BH_SUM_1.5m_value") | float }}
          {%- endif %}
        state_class: measurement

Mil gracias!

@Danieldiazi
Copy link
Owner

Hola!
Perfecto y gracias por tus aportaciones!

En el caso del template, es una buena idea!
Podrías hacerlo desde la propia integración

`sensor:

  • platform: meteogalicia
    id_estacion: 19055
    id_estacion_medida_diarios: BH_SUM_1.5m
    scan_interval: 1800`

y así te devolvería el valor de esa medida. Lo que no hice fue indicarle la unidad de medida (en este caso L/m2) porque creía que HA igual no la reconocería. Por ejemplo hay una que me viene como "kJ/(m2.día)".

Esté metodo o el de template son igual de válidos, solo era por aportar aquí otra solución.

En el caso de -9999 para los valores de las medidas que vienen como atributos, voy a crear un nuevo issue para verlo, porque puede dar error. Lo que no sé en este caso es qué hacer, creo que lo mejor es que no añada ese atributo. SI viene a -9999 es que la medida no es válida, y no debe registrarse.

@galambert75
Copy link
Author

En el caso del template, es una buena idea! Podrías hacerlo desde la propia integración

Gracias!

En el caso de -9999 para los valores de las medidas que vienen como atributos, voy a crear un nuevo issue para verlo, porque puede dar error. Lo que no sé en este caso es qué hacer, creo que lo mejor es que no añada ese atributo. SI viene a -9999 es que la medida no es válida, y no debe registrarse.

No encontré un link específico en la página de MeteoGalicia con la descripción de posibles valores de los atributos. Pero sí encontré ésto donde indica para lnIconoCeo que "-9999 = Sen dato". Supuse que es igual para todos los demás valores... Igual sería buena idea dejar el valor en blanco / vacío en lugar de poner "unkown" como hice yo en el template.

@Danieldiazi
Copy link
Owner

Hola. En el código para los sensores, por ejemplo el de temperatura, controlaba ese valor

y en el caso de que sea -9999 el estado lo ponía a None
state = None

Voy a ver si puedo referenciar estas aportaciones en el nuevo issue que he creado, si no te importa, podemos seguir desde la nueva issue, así queda allí esta información, que será valiosa a futuro!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants