Hola a todos, hola @pierre-gilles,
Aquí tienes una idea sobre la que me gustaría tu opinión antes de seguir adelante: poder componer una tarjeta del panel de control a partir de varios elementos (valores, medidores, gráficos) elegidos entre cualquier dispositivo de Gladys.
El diagnóstico
Hoy en día, un widget = una función. Para seguir una habitación, por ejemplo, apilo:
- un widget « Temperatura de la habitación » para el valor actual,
- un widget « Gráfico » para el historial,
- un widget « Medidor » para la humedad.
Esto hace tres tarjetas, cada una con su título, sus márgenes y su espacio vacío, para información que va junta. En móvil, especialmente, se hace un rápido desplazamiento de mucha pantalla para poca información.
(Sé que el widget Gráfico ya muestra el último valor y la variación por encima de la curva: esto cubre el caso más simple, pero no la mezcla de varios dispositivos o de varios tipos de visualización.)
Lo que permitiría
Algunos ejemplos concretos:
- Una habitación en una tarjeta: temperatura y humedad en baldosas, curva de temperatura en 24 horas debajo.
- Energía: medidor de potencia instantánea + gráfico de consumo de la semana.
- Comparación: dos gráficos lado a lado (temperatura interior / exterior, producción / consumo solar).
- Calefacción: consigna, temperatura medida y estado de la válvula en baldosas, con el historial de la temperatura medida.
- Exterior: algunos valores de la estación meteorológica + la curva de lluvia.
Por qué no lo he hecho con una integración externa
He mirado si los widgets de las integraciones externas (Gladys 5.1) podían servir para esto, ya que su formato ya tiene casi todo: fila de baldosas (valor, medidor), gráfico vinculado al historial de los dispositivos, texto…
Pero dos cosas lo impiden, y es normal:
- Un widget de integración solo puede citar sus propios dispositivos. El núcleo ignora cualquier dispositivo de otra integración (un gráfico que cite uno es eliminado por completo). Es un aislamiento deseado, y me parece saludable.
- Un solo elemento principal por tarjeta (gráfico, lista o imagen), en un orden fijo por el núcleo: no hay gráficos lado a lado.
La única solución posible sería una integración que lea la API de Gladys con una clave de API para devolver datos « planos ». Funcionaría, pero sin tiempo real, con una clave de pleno derecho en un contenedor tercero y en contra del espíritu del aislamiento. No quiero seguir adelante sin tu opinión.
Dos posibles enfoques
Enfoque A — un widget nativo « Compuesto » (mi preferencia)
Un nuevo tipo de widget en el núcleo, cuya edición consiste en añadir bloques:
- bloques posibles: valor, medidor, gráfico (reutilizando los widgets existentes);
- disposición simple: una o dos columnas, los bloques se apilan en el orden elegido;
- cada bloque apunta a cualquier funcionalidad de dispositivo, a través del mismo selector que los widgets actuales.
Ventajas: nada sale del núcleo, no hay nuevas preguntas de seguridad, tiempo real por websocket como los otros widgets, y el código de los widgets existentes puede reutilizarse en gran parte.
Enfoque B — permitir que los widgets de integración citen dispositivos elegidos por el usuario
Un ajuste de widget de tipo « dispositivo » que propondría todos los dispositivos (y no solo los de la integración). El usuario daría su consentimiento explícito, dispositivo por dispositivo, en el momento de configurar el widget.
Ventaja: la comunidad podría publicar todo tipo de diseños sin tocar el núcleo. Inconveniente: abre una brecha en el aislamiento, ya que una integración podría leer datos que no son los suyos. Y no resuelve el límite de un solo gráfico por tarjeta.
Las implicaciones que veo
- Rendimiento: una tarjeta con varios gráficos hace tantas solicitudes de historial. Un límite (por ejemplo, 4 bloques, 2 gráficos) mantendría las cosas razonables, especialmente en Raspberry Pi.
- Móvil: dos columnas lado a lado deben pasar a una sola columna en pantalla pequeña.
- Edición: el formulario de un widget compuesto es más complejo que el de los otros widgets. Tiene que seguir siendo fácil de usar.
- Mantenimiento: el enfoque A añade un tipo de widget a mantener. El enfoque B desplaza este trabajo a las integraciones pero afecta al modelo de seguridad.
- Compatibilidad: los dos enfoques son aditivos. Ningún widget existente cambia.
Mis preguntas
- ¿Te habla la necesidad y lo verías en el núcleo?
- Enfoque A, enfoque B, o algo más (por ejemplo, dejar simplemente que los widgets Gráfico y Medidor muestren varios valores)?
- ¿El aislamiento de los widgets de integración es un principio que no hay que tocar?
Si el enfoque A te conviene, me encantaría encargarme de la PR, siguiendo tus indicaciones sobre el alcance.
¡Gracias!