Ideas para sensores

[diamant-x]

Hola,

Sólo quería comentar que justo hoy he visto que Agbar ofrece consumos horarios del agua y he encontrado tu proyecto en github. Lo he instalado con HACS y el flow de login parece que funciona correctamente; la lista de integraciones ha aparecido y ha recuperado el ID de mi contrato correctamente.

Entiendo que aun está WIP. No se si tienes algun avance o posibilidad de incluir sensores de consumo? Entiendo que la dificultad será elegir el dato que sea más útil.

Si la referencia son los que salen en el portal, igual el mas interesante sería el consumo acumulado diario. De esa manera se podría pedir a la integración que se refresque 1 vez cada hora para ir actualizando el sensor con el crecimiento acumulado. Y luego en HA seria definir la entidad como un contador con un reset diario (total_increasing entity) y que ya HA haga sus cálculos de totales acumulados y demás.

Otra opción de sensor sería intentar recuperar el consumo horario individual, y montar sensor que se actualice con el consumo de esa última hora de refresco, y entonces que sea el usuario el que monte, si quiere, un integrador para calcular los totales.

Si necesitas ayuda para hacer pruebas, sin problema. Publica una nueva version en el github y la actualizaré via HACS. Un saludo!

[jaa73]

Hola, lo mismo digo, cuando publiques hacemos las pruebas. Saludos,

[duhow]

El problema lo tengo precisamente en programar para que funcione... Para eso sí necesito ayuda 😂 La documentación que hay para Developers cuesta de mascar, y estoy intentando basarme en ejemplos ya existentes para sacar algo.

[diamant-x]

Tirando del ejemplo https://github.com/home-assistant/example-custom-config/blob/master/custom_components/example_sensor/sensor.py que muestran aquí, empezaría por usar ese código como plantilla e intentar meter el código del Poc en ese update() que sale al final del ejemplo. Y para registrar el nuevo valor del sensor, parece que se hace reescribiendo la variable interna del sensor que se llama self._attr_native_value = <el valor del sensor recuperado de agbar>

Luego en la clase del sensor sería remplazar los atributos iniciales segun el tipo de sensor a implementar (https://developers.home-assistant.io/docs/core/entity/sensor) (desconozco lo que se puede o no recuperar de agbar, que preguntaba en mi primer mensaje). Por ejemplo si fuera el total diario de litros:

_attr_name = "Litros acumulados diarios"
    _attr_native_unit_of_measurement = UnitOfVolume.LITERS
    _attr_device_class = SensorDeviceClass.WATER
    _attr_state_class = SensorStateClass.TOTAL_INCREASING

Como primer paso tiraría por ahí (no tengo entorno de pruebas o desarrollo, así que solo puedo dar ideas de por donde probar).

[duhow]

Gracias @diamant-x , pero esa parte ya la tenía. Entre otras cosas, el DataUpdateCoordinator y la gestión de datos persistentes es lo que todavía no acabo de entender.

52d6a640a6d3dae7c38a654fcfbd4a4e50d5952a Ahora mismo puedo recibir el último valor disponible de hoy, queréis probarlo? @diamant-x @jaa73

[ffrants]

It works! I also can test the integration if needed

[jaa73]

@duhow, funciona! Va tomando forma la integración, gracias por el trabajo, David.

[diamant-x]

Gracias @diamant-x , pero esa parte ya la tenía. Entre otras cosas, el DataUpdateCoordinator y la gestión de datos persistentes es lo que todavía no acabo de entender.

52d6a64 Ahora mismo puedo recibir el último valor disponible de hoy, queréis probarlo? @diamant-x @jaa73

Gracias, veo los litros totales del contrato! Entiendo que este numero está basado en lo que se recoge al final de cada factura, por lo que para cuando vemos el número es un poco tarde.

• Se podría mostrar en su lugar el valor del ultimo consumo actualizado? Así se podría, ni que sea, ir forzando actualizar la integración para recoger nuevos datos mientras se avanza en el auto-refresh.

---

Respecto al DataCoordinator, podemos ir comentando las dudas a ver si lo resolvemos entre todos. Pero entiendo que no es obligatorio tenerlo para tener un sensor funcional, no? Es mas que nada para, cuando la integración tenga multiples sensores, que con una sola llamada a la API se puedan refrescar todas.

[duhow]

Las telemetrías que envía el contador de agua van con retraso, o se procesan lentamente. Por ejemplo, si ahora mismo son las 21:29, la última lectura que tengo disponible es de las 17:47 de hoy.

La idea con el proyecto es obtener esta información del consumo por horas y mostrarla en el panel de Energía, en su respectiva hora. Así se puede ver el consumo correctamente, al igual que se muestra en la página web.

El DataCoordinator tengo que seguir explorandolo, pero también es lo que me permite poder programar la actualización cada X tiempo, para no saturar el servicio.

[diamant-x]

Nice! Estoy con la 0.1.0. Pero no se por qué no se me actualizó pasadas las 6 horas. Pude forzarlo correctamente llamando al servicio:

service: homeassistant.update_entity
data: {}
target:
  entity_id:
    - sensor.contador

El reto del consumo es que saldrá con desfase entiendo, ya que se actualiza "ahora", pero los datos son de "ahora -X horas". No creo que HA permita escribir actualizaciones de estado a pasado..

Aún así, con esas consideraciones, yo he podido agregar el sensor como sensor de agua nativo al panel de Energía sin problema, definiendo precio fijo del coste de tramo de agua de mi factura (sólo uso un tramo así que puedo hacerlo fijo). Me sorprendió ver que el sensor reporta en m3, pero en Energía hace el cambio a litros directamente.

• ¿Crees que forzando un update cada hora (y con suerte la telemetría también será horariamente) saturaríamos la API?

PD: Otra integración que podria servir como referencia para el DataCoordinator podría ser https://github.com/uvejota/homeassistant-edata/blob/dev/sensor.py que también usa login-password para refrescar, y que ha tenido que gestionar el número de peticiones para no saturar la API. Igual ya la tenías en el radar :).

[duhow]

¿Crees que forzando un update cada hora (y con suerte la telemetría también será horariamente) saturaríamos la API?

Realmente no lo creo.

Pero si ahora fuésemos 100 usuarios x 1 telemetria por hora x 24 horas ... se notará que hay un uso programado del servicio de consulta. Ante todo prefiero evitar problemas, pero en algún punto tendríamos que ponernos en contacto con la empresa para asegurar de que se pueda seguir permitiendo el uso de API sin causar afectaciones.

De igual manera, insisto que la última métrica de agua ya va con varias horas de retardo, aumentar la cantidad de veces que se llama tampoco supone una mejora.

Y si, ya estoy basándome en el proyecto de @uvejota para estas cosas. :)