¡Gladys Assistant 4.66: Seguimiento de energía y Zigbee2mqtt 2.7.1!

Gracias @pierre-gilles por el desarrollo de esta funcionalidad y @Terdious por su financiación :ok_hand:

Es muy prometedor, pero debo ser paciente antes de mostrar mis información en el panel: el cálculo de los consumos y costos para mi historial está en un 3% en 30 minutos, por lo que me llevará unas quince horas. Con un Zlinky y una veintena de enchufes conectados, supongo que es normal :wink:

Quería compartir, sin embargo, dos aspectos sobre mi experiencia de usuario al implementar esta integración, si puede ayudar:

La documentación explica que se puede « ver la jerarquía de su red eléctrica » y que hay que « verificar que cada dispositivo esté bien asociado a su padre ». Creo entender más o menos de qué se trata, pero en realidad no estoy tan seguro, y me pregunto si podría haber una explicación en esta etapa de la documentación que explique por qué hay una jerarquía, qué aportará y cuáles son las jerarquías típicas. El ejemplo dado con el enchufe Nous es un poco ‹ ligero › para eso.
Por ejemplo, en mi caso tengo una integración Enedis, un contador Zlinky, un enchufe de medición de consumo pero que en realidad sigue la producción de energía de mis paneles solares, y una veintena de enchufes conectados que miden consumos, algunos de los cuales están ‹ apilados ›. Por ejemplo, tengo un enchufe de consumo ‹ multimedia › en la entrada de un regleta, y varios otros enchufes de consumo por dispositivos en esta regleta (la pantalla, el amplificador,…). Y no estoy seguro de la jerarquía que debo establecer :wink:
Bueno, admito que tal vez estoy llevando las cosas un poco lejos…

Y, por otro lado, cuando actualicé el Zlinky en la integración Zigbee, luego fui a la integración Seguimiento de energía, los 6 índices EASFxx (estoy en tempo) no tenían nombres claros (HC Azul, HP Azul, HC Blanco,…). ¿Podría ser porque primero hice la migración a 4.66, luego a 4.66.2 (porque creo haber visto que mejoraste algunas cosas sobre eso, Pierre-Gilles, pero tal vez las dos actualizaciones sucesivas no me han permitido beneficiarme de ello…). No sé si es posible hacer el nombramiento claro automáticamente.

¡Gracias por tu respuesta!

Mantenme informado tan pronto como esté calculado, estoy curioso por el resultado :slight_smile:

La idea es establecer una jerarquía en función de qué está conectado a qué.

Si una toma está conectada a otra, entonces la toma « padre » debe colocarse por encima en la jerarquía, y la toma « hija » por debajo.

A largo plazo, esto permitirá reconstruir correctamente el consumo real sin duplicar, especialmente cuando varios dispositivos están “apilados”.

Por ahora, esta posibilidad aún no se está utilizando, pero servirá más adelante :slight_smile:

Entonces hay dos cosas :grinning_face_with_smiling_eyes:

  • Hasta ahora, no había entendido muy bien lo de los EASFxx (debes estar en modo estándar). En mi caso estoy en modo histórico, y mi Lixee TIC devuelve más bien BBRHPJB, etc. Si puedes darme el significado de cada EASFxx, puedo integrarlos correctamente en Gladys!
  • Por otro lado, estos nuevos nombres más claros solo se utilizarán para los nuevos dispositivos emparejados en Gladys. No puedo permitirme sobrescribir los nombres de las funcionalidades ya existentes: si un usuario ha renombrado sus datos como desee, sería un poco violento reemplazarlo todo…

Ahora también podríamos agregar una pequeña ayuda en la interfaz Zigbee2MQTT para mostrar explicaciones específicas de este dispositivo, que, siendo honestos, es un poco complejo para todos (yo incluido :grinning_face_with_smiling_eyes:).

Por ejemplo, podríamos hacer esto:

Si me das el significado de cada funcionalidad (EASFxx + external_id en Gladys), ¡puedo integrarlo todo en la interfaz!

Según lo que he visto en Gladys, todos los índices/nombres del TIC estándar ya existen en un dispositivo MQTT llamado « Téléinformation » (incluidos los EASFxx), pero no en el TIC histórico (lo cual podría ser una mejora, creo).

Los EASF pueden cambiar según el proveedor de energía que tengas:

  • EDF Tempo, entonces se utilizan EASF01 a EASF06 para HCJB, HPJR, etc.
  • horas supervalle de Total Energies: HP, HC y HSC, entonces se utilizan EASF01, 02 y 03 solo
  • base EDF: EASF01
  • HP/HC EDF: EASF01 y EASF02
  • etc.

Creo que es difícil tener nombres específicos para el TIC estándar, sabiendo que si cambias de operador, EASF01 pasará del antiguo contrato al nuevo (pero ¿qué pasa con el índice…).

Hola a todos,

Esta mañana he trabajado en la continuación del widget « Consumo »:

  • Poder alternar entre una vista « coste » y « consumo » en kWh
  • Gestión dinámica de la moneda (euro vs dólar para nuestros usuarios estadounidenses !)

Añadido un estado « carga » cuando el widget se actualiza:

La PR:

¡Hola!

Al revisar esta mañana para intentar poner todo esto en servicio, vi que existe una funcionalidad MQTT de ‹ Producción de energía ›. ¿Esta funcionalidad se gestiona en la parte de energía de la que hablamos aquí?

Si es así, ¿es posible crear los dos intervalos de ‹ 30 minutos › de manera automática, como con los otros índices?

No, no se gestiona :slight_smile: En sí, las funcionalidades existen y puedes rellenarlas con datos, pero esta parte no existe actualmente en Gladys

Al principio, sigo este desarrollo desde un poco lejos, porque tengo paneles solares y utilizo su API para recuperar mis consumos/producciones.

Pero el lado del cálculo del coste con las horas punta/valle es realmente interesante.

No sé qué valdría más la pena al final: comprar un lixee para ponerlo en mi Linky o intentar ver si puedo integrar los valores de la API actual con estas funcionalidades de gestión de energía.

Por el momento, la API se comunica con NodeRed, y he creado dispositivos MQTT falsos para recuperar todo eso en Gladys.

@pierre-gilles, ¿qué opinas?

El cálculo de los consumos ha tomado efectivamente 15 horas, y ahora estoy esperando el cálculo de los costos: 18% realizados en aproximadamente 6 horas… :wink:

es correcto, está claro y entiendo la lógica para evitar dobles conteos con mediciones de consumo.
Pero ¿puedes confirmarme qué debo hacer con los ‹ bloques › Enedis, Zlinky y la medición de producción de los paneles solares? Los tres deberían estar al mismo nivel 0, y luego todas mis mediciones de consumo estarían bajo Enedis? Por defecto, Gladys lo ha hecho así: todo (Zlinky, paneles solares y cada medición de consumo) es hijo de Enedis.

En mi caso, tengo esto:
EASF01 = HC Azul (ID externo = zigbee2mqtt:Compteur Zlinky:teleinformation:easf01:current_tier1_summ_delivered)
EASF02 = HP Azul (zigbee2mqtt:Compteur Zlinky:teleinformation:easf02:current_tier2_summ_delivered)
EASF03 = HC Blanco (zigbee2mqtt:Compteur Zlinky:teleinformation:easf03:current_tier3_summ_delivered)
EASF04 = HP Blanco (zigbee2mqtt:Compteur Zlinky:teleinformation:easf04:current_tier4_summ_delivered)
EASF05 = HC Rojo (zigbee2mqtt:Compteur Zlinky:teleinformation:easf05:current_tier5_summ_delivered)
EASF06 = HP Rojo (zigbee2mqtt:Compteur Zlinky:teleinformation:easf06:current_tier6_summ_delivered)

Reconozco que no tengo opinión, es cosa tuya decidir lo que quieres hacer :smiley: El Lixee tiene la ventaja de que lo enchufas y funciona directamente, con la API tienes un poco de trabajo, tú decides :wink:

No, deja lo que Gladys hace por defecto, todo debe ser hijo de Enedis, de lo contrario tendrás que crear un contrato por dispositivo en la raíz (el contrato está vinculado a un dispositivo).

Gracias, pero entonces @mutmut decía antes que estas mismas funcionalidades no son necesariamente de Tempo, así que no sé si podemos hacer mucho por desgracia :sweat_smile:

Hola @pierre-gilles,

Gracias por esta gran funcionalidad. Creo que he hecho las cosas en el orden equivocado (después de leer la documentación :upside_down_face:), y he entrado en un error extraño.

Tengo el Zlinky y 4 enchufes Nous Zigbee, y primero creé la jerarquía, creé el contrato y lancé los cálculos, antes de “actualizar” los dispositivos en la integración zigbee to mqtt (para las nuevas funcionalidades). Después de hacer esta actualización, los dispositivos Zigbee han desaparecido por completo de la jerarquía… Pero lo más molesto es que cuando la tarea de fondo para el cálculo de costos se (re)lanza, el CPU sube al 100% y la GUI es inaccesible, tengo que reiniciar el contenedor. He tenido que desactivar el servicio de seguimiento de energía.

¿Habría alguna manera de limpiar mis errores y restablecer todos los parámetros de la nueva integración para empezar de nuevo de manera más limpia?

¡Gracias!

David.

Hola @davidm50,

En sí, no es tan grave, cuando actualizaste los dispositivos, ¿no se volvieron a colocar bajo el contador al que está vinculado tu contrato?

Ah, eso sí que es molesto. ¿Tendrías algún registro para compartir conmigo para que pueda intentar corregirlo? docker logs gladys --tail=10000 para mostrar las últimas 10.000 líneas :slight_smile:

No estoy seguro de que sea lo mismo, pero @mutmut tuvo problemas similares recientemente, ¡me encantaría entender qué está pasando!

¿Dices que es durante el cálculo del costo?

¡Quizás tengo una idea! En tu caso, puede que hayas creado sin querer una dependencia circular entre tus dispositivos eléctricos

A → B → C → A

Y eso crea un bucle infinito en el código

¡Voy a añadir código para manejar estos casos!

He añadido 2 cosas:

  1. Detección y visualización en la interfaz de las dependencias circulares con un botón para corregirlo:

  1. En el código backend, detección de dependencias circulares para no bloquear la tarea y no ocupar el 100% del CPU.

¡Voy a crear una rama y una versión con este parche!

Gracias por el comentario @davidm50 :slight_smile:

Gladys Assistant v4.66.3 está en vivo, con:

Seguimiento de energía

  • Detección de dependencias circulares para evitar bloqueos
  • Cambio de « moneda » a « kWh » y unidades dinámicas para la moneda (euro y dólar)
  • DuckDB actualizado a v1.4.3

MQTT

  • Corrección de un error donde los valores numéricos no se analizaban como « número » al usar un tema personalizado, lo que mostraba un valor bruto no redondeado en la interfaz.
  • Corrección de un error: si una escena escucha en el mismo tema que un dispositivo MQTT con tema personalizado, eliminar la escena ya no cancela la escucha del tema para el dispositivo MQTT.

El CHANGELOG completo está disponible aquí.

Finalmente, creo que me voy a equipar con un Lixee para no tener que complicarme.
Por otro lado, en mi caso la suscripción es la de Vert Électrique Week-End

Por lo tanto, los precios están detallados aquí: https://particulier.edf.fr/content/dam/2-Actifs/Documents/Offres/grille-prix-vert-electrique-weekend.pdf

Se trata de un principio de HP/HC donde se definen los periodos de HC, pero los fines de semana y días festivos también están en HC.

¿Se admite actualmente esta oferta?

Tras los mensajes que @mutmut me envió en privado, y las pruebas muy positivas de @Terdious sobre la modificación del límite de memoria de DuckDB, acabo de publicar la versión v3.66.4.

Esta versión reduce el límite máximo de uso de RAM por DuckDB, que pasa de 80 % a 30 %, para dejar más margen al sistema y a Gladys.

El CHANGELOG está disponible aquí.

Esta oferta no está soportada, y peor aún, no vamos a poder gestionarla con un simple contrato definido en JSON en GitHub. Va a hacer falta codificar una lógica especial debido a esta historia de fines de semana y días festivos :sweat_smile:

Los fines de semana es sencillo, pero los días festivos es el infierno :joy: Y no me digas que vives en una región con días festivos específicos, sería la guinda :joy:

Vivo en Guatemala, ¿funcionará? :rofl:

No, los días festivos son los mismos cerca de Toulouse que en toda Francia, creo ^^

Lo siento por tener que añadir algo fijo en el código.

Y ahí, en un clic, te das cuenta de que un día Rojo Tempo mal optimizado (con un consumo no lo suficientemente reducido), pues te cuesta un riñón



¡Gracias @pierre-gilles por esta novedad!

17€ en un día ?? :sob:

Es mi consumo de un mes eso aha

La bomba de calor se averió el invierno pasado, lo que me obligaría a pasar a una horrible resistencia eléctrica para calentar mi suelo radiante… :sad_but_relieved_face: