Hola @Will_71,
Gracias por estos comentarios, son muy concretos y me alegra ver que tu integración de pellets está tomando forma.
Aclaro que Claude me ayudó a redactar este mensaje, pero fui yo quien reflexionó sobre cada punto 
1. Elegir la casa en una lista
Sí, es una buena idea. Hoy en día, las listas dinámicas (source) solo pueden proponer dispositivos de la integración. Vamos a agregar "source": "houses": la lista mostrará los nombres de las casas y registrará su selector, es decir, el identificador que ya te devuelve GET /house. Por lo tanto, podrás hacer la correspondencia directamente.
Funcionará en todas partes donde se utilice este formato de campo: configuración, acciones, ajustes de widget y escenas. Estoy preparando una PR.
Única restricción: tendrás que aumentar la gladys_version mínima de tu manifiesto, ya que las versiones más antiguas de Gladys rechazan una fuente que no conocen.
2. Valor decimal en la configuración
En realidad, es un error. El servidor ya acepta decimales, pero el campo numérico del formulario no tiene un atributo step: el navegador solo acepta números enteros y bloquea el registro. ¡Incluso el ejemplo de la documentación (una latitud a 48.85) no pasaba! 
He abierto un ticket: External integrations: `number` fields reject decimal values in the browser · Issue #3166 · GladysAssistant/Gladys · GitHub
La corrección se reduce a una línea y se aplicará a todos los formularios de las integraciones (configuración, acciones, widgets, escenas).
3. Ingresar un valor desde el widget
La necesidad es real, tu flujo actual (ir a la integración, cambiar el precio, volver al tablero de control) no es práctico.
Por otro lado, no quiero campos de entrada mostrados permanentemente en los widgets. Hemos optado porque los widgets sean de solo lectura + pulsación: es lo que permite a Gladys garantizar un rendimiento limpio en todas partes (móvil, tableta mural, tema claro u oscuro).
Mi propuesta: un botón de widget puede declarar campos. Cuando se presiona, un pequeño formulario se abre en la tarjeta, precompletado por tu integración, y Gladys valida los valores antes de enviártelos.
En tu widget, quedaría así (maqueta):
Si un valor está fuera de los límites que has declarado, el error se muestra debajo del campo:
Y una vez guardado, tu mensaje de retorno se muestra y la tarjeta se actualiza:
En cuanto a la integración, el botón gana una tabla fields, en el mismo formato que los campos de las acciones del manifiesto. Como el contenido del widget se construye a cada solicitud, el valor predeterminado puede ser el último precio que has registrado:
{
"type": "button",
"label": { "en": "Pallet delivered", "fr": "Palette livrée" },
"icon": "truck",
"action": {
"key": "delivery",
"fields": [
{ "key": "bags", "type": "number", "required": true, "min": 1, "max": 200, "default": 72,
"label": { "en": "Bags delivered", "fr": "Sacs livrés" } },
{ "key": "price_per_bag", "type": "number", "required": true, "min": 0, "max": 50, "default": 7.3,
"label": { "en": "Price per bag", "fr": "Prix par sac" } }
]
}
}
Y recibes los valores ingresados, ya validados, en values:
gladys.onWidgetAction('pellets', async (actionKey, params, { settings, values }) => {
if (actionKey === 'delivery') {
await stock.addDelivery(values.bags, values.price_per_bag);
return { message: { fr: `+${values.bags} sacs enregistrés` } };
}
});
Algunas reglas previstas:
- Máximo 4 campos, de tipo número, texto, casilla de verificación o lista;
- el formulario solo aparece después de la pulsación, la tarjeta en reposo no cambia;
- como los botones de widget actuales, es utilizable por cualquier usuario conectado: estos valores deben tratarse, por lo tanto, como un evento (una entrega), no como una modificación de la configuración de la integración.
Esto aún no está especificado ni desarrollado. ¿Qué opinas? ¿Esto cubriría tu caso?
4. Declarar dispositivos en las integraciones meteorológicas
Para el uso en escenas, no es necesario dispositivos: desde Gladys 5.1, cualquier integración, incluida una integración meteorológica, puede declarar sus propios disparadores y acciones de escena (scene_triggers y scene_actions en el manifiesto). Por ejemplo:
- una acción « Obtener el clima actual » que devuelve la temperatura, la presión, el viento… en
outputs. Las acciones siguientes de la escena pueden utilizar estos valores, y una condición « Continuar solo si » permite filtrarlos;
- un disparador activado por tu integración cuando algo ocurre (« lluvia anunciada en la hora », por ejemplo).
Para los gráficos, una integración meteorológica también puede declarar un widget con un componente chart alimentado por sus propios datos.
Por otro lado, no soy muy favorable a mezclar los conceptos de dispositivo y clima. En Gladys, un dispositivo es algo físico: un equipo que controlas o un sensor que mide en tu casa. El clima son datos proporcionados por un servicio, con su propio formato (condiciones actuales, pronósticos por hora y por día, alertas) y su propio widget. Si transformamos los pronósticos en dispositivos, terminamos con falsos sensores mezclados con los verdaderos (en las habitaciones, los gráficos, las escenas…), y cada proveedor meteorológico crearía los suyos a su manera.
Si necesitas una temperatura exterior real medida, un sensor físico sigue siendo la mejor solución, y él será un dispositivo.
¡Muchas gracias por estos comentarios!
